Search Unity

  1. Check out the Unite LA keynote for updates on the Visual Effect Editor, the FPS Sample, ECS, Unity for Film and more! Watch it now!
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    Dismiss Notice
  4. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  5. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Input System Update

Discussion in 'New Input System' started by Rene-Damm, Dec 12, 2017.

  1. mdsitton

    mdsitton

    Joined:
    Jan 27, 2018
    Posts:
    12
    Another issue with InputSystem.AddStateChangeMonitorTimeout it doesn't look like it takes the time offset into account between the unity startup time and the internal input system time so there would be no decent way of externally setting this timeout to something that gives any expected behavior.
     
  2. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    365
    Yikes, missed a bunch. Sorry for the delay. Was OOO for a couple days.

    ATM we haven't yet promoted the input system package to the production server due to how little quality assurance there is ATM. At this point it's only available from the staging server. Also, it's not part of the curated list yet that's being presented in the package manager.

    To install the package from the server, go to Packages/manifest.json and overwrite the beginning of the file with

    Code (JavaScript):
    1. {
    2.     "registry" : "https://staging-packages.unity.com",
    3.     “dependencies: {
    4.         “com.unity.inputsystem: “0.0.9-preview”
    5.  
    We're still missing proper reset behavior on focus change which means the keyboard ends up retaining its current state and will miss changes happening when the app isn't focused. There's an overall pass on focus handling scheduled to happen any day now. There's a few items that still need to be finished with relation to focus handling.

    Just in case it's still useful: there isn't necessarily a single path (other than the path for the whole device) for a single event. State events contain full or partial snapshots of an entire device and may thus contain state changes for several controls.

    Once you've established it's a state event or delta state event using IsA() and grabbed the device for the InputEventPtr.deviceId using InputSystem.GetDeviceById(), there's basically two scenarios: (a) you know what kind of device and input you're dealing with or (b) you're writing some generic event processing code.

    For (a) you'd grab the specific controls you're interested in and point them at the event data with ReadValueFrom to read state from the event.

    For (b) you can, for example, iterate over the controls using the "allControls" property on the device.

    The API needs some more work. Not yet very obvious how to use it and some things are odd and don't fit well yet.

    The idea is that AddStateChangeMonitorTimeout() adds a timeout to an *existing* state change monitor. I.e. you'd set up your state change monitor with AddStateChangeMonitor() and then add a timeout whenever you need it by passing it the same instance you used to register the timeout.

    The version of AddStateChangeMonitor() that takes delegates returns the IInputStateChangeMonitor instance it creates for you (internally, that's StateChangeMonitorDelegate). That version is really more of a convenience. The idea is that normally a single IInputStateChangeMonitor would be monitoring several pieces of state at once.

    Anyway, sort of like this:

    Code (CSharp):
    1. // Put monitor on gamepad.leftStick.
    2. var monitor = InputSystem.AddStateChangeMonitor(gamepad.leftStick,
    3.     (ctrl, time, eventPtr, index) =>
    4.     {
    5.         Debug.Log("leftStick changed value");
    6.     },
    7.     timerExpiredCallback: (ctrl, time, monitorIndex, timerIndex) =>
    8.     {
    9.         Debug.Log("Timer expired on leftStick");
    10.     });
    11.  
    12. // Add timeout at some event time + 0.1 seconds.
    13. InputSystem.AddStateChangeMonitorTimeout(gamepad.leftStick, monitor, eventPtr.time + 0.1);
    I'll take a look at improving and streamlining that API.

    Good point. Indeed pretty much only works ATM if you have an event you can grab a time from or when you have access to internals.

    I'll take a look at that. Would prefer for the API to take a relative time value ("set timeout of 0.1 seconds") instead of an absolute time value ("set timeout at 234.53 seconds") but does have some drawbacks.
     
    Last edited: Oct 25, 2018
  3. Mooncakecmdr

    Mooncakecmdr

    Joined:
    May 27, 2013
    Posts:
    47
    What is the best aproach to use new input system inside hybrid ECS and Pure ECS?
     
  4. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    365
    ATM "best approach" equals "workable approach".

    The solution that's known to work is to process input in a system's OnUpdate() function just like you'd pick up data from any main-thread-only API. Input can be fed freely into jobs there but only if read out on the main thread. In that sense, it's no different from how ECS combines with the old input system (see here).

    There's two pieces that will likely make things better here but aren't fully there yet and won't yet (fully) work.

    One is InputUpdateType.Manual which is meant to allow switching the system into a manual updating mode. This will allow you to call InputSystem.Update() right in your ComponentSystem. It'll still have to happen on the main thread but it'll put input processing directly under the control of the ComponentSystem.

    The other is InputActionQueue which allows recording traces of actions and should allow safe access from threads in the future. With that in place, after calling InputSystem.Update() in ComponentSystem.OnUpdate(), you'd be able to take as is all input that has happened and feed that into jobs.

    Ideally, it should be allowed to just move the entire system to a different thread (as in, not make it thread-safe but allow making the "input processing thread" a thread other than the main thread) but this will likely not happen for 1.0.
     
    Last edited: Oct 29, 2018
    FROS7 and Mooncakecmdr like this.
  5. Mooncakecmdr

    Mooncakecmdr

    Joined:
    May 27, 2013
    Posts:
    47
    thanks for the fast reply! i'm using currently Hybrid ECS for a 2D game, and using the Input System(new) but when i started using that came to my mind how to use it. so thank's it realy help me. and just for you know the link you send about the example way to use ECS with Old Input System is not accesible to all.
     
  6. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    365
    Ouch, sorry about that. Didn't look close enough. Updated the link to point to the public repo here.
     
    Mooncakecmdr likes this.
  7. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    505
    @Rene-Damm Sorry if this has been covered already, but does the new input system support custom native input plugins? For example, I want to have Xbox One controllers trigger rumble working on win10 standalone, this isn't supported by new input system (in non-UWP setup) but I do have it running on my own native plugin which I could modify to suit this purpose. Or if I want to have FFB support for steering wheel, I would now have to run this separately from the input system which is far from ideal.

    So I'm asking, are custom input plugins supported or at least planned feature? Having input system still rely on Unity side of things for hw support will make it less useful as there will always be niche setups that require custom input libraries. From the looks of it, Unity itself only plans to support main input devices on specific platforms so this will leave a lot of devices out.
     
  8. mdsitton

    mdsitton

    Joined:
    Jan 27, 2018
    Posts:
    12
    I asked about doing this for midi devices a while back and it was said it was possible. I haven't tried to actually implement a custom input source yet though. I do wish Xbox One controllers using the xbox one wireless adapter would get detected in the input system though, with that said they are weird devices though did you know these adapters show up as a network device!??! What was Microsoft thinking here? Having a UWP input source from Windows.Gaming.Input support would be great though (and should be possible outside of uwp from what i've read?)
     
  9. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    365
    We don't yet have a native API but, while not for 1.0, it is planned.

    However, the managed API already permits creating devices and generating input pretty much just like the native backend. You can, for example, use PInvoke to call native APIs from C# and relay devices and input that way.

    Yeah, that's a sucky one. Not sure yet what we should best do there. Going to the controller through HID gives us access to the trigger motors but makes the triggers themselves unusable. Going to the controller through XInput makes us lose access to trigger motors but gives us working triggers. So, between a rock and a hard place.

    On a general level, though, I think the system should have the ability to let you respond to device commands (which the rumbles come out as) from wherever you want. Meaning it should be possible to intercept an XboxOneGamepadRumbleCommand sent to an Xbox One gamepad device and handle that yourself.

    By using the UWP APIs?

    Parts of it are there, some remaining parts are planned.

    Yup, 100% agree. It's an explicit goal is to make things fully hackable and have the native runtime be just one possible source of input that can sit alongside others.

    At least in the beginning, that will definitely be the case. I do expect that once we're past 1.0, breadth of support will become a priority. Probably not all of it will go in the main package (I doubt we'll manage to QA that consistently across all platforms) but I could definitely picture a separate package that just adds a ton of additional device support to the system.

    Yup indeed. On the list.

    We do support it in the UWP player, but not yet in the "classic" Windows player. I think it's more a when than an if question for that to happen. Right now, our Win32 player is still held back quite a bit in terms of new API support.
     
    rizu likes this.
  10. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    505
    I think WGI is officially in UWP API but like @mdsitton mentioned, you can use Windows.Gaming.Input outside of UWP apps, you only need to have the runtime initialized. You then use WGI like in UWP so you get both trigger inputs and rumbles on Xbox One controller. This works as long as the user is running Windows 10 with same update level as required by WGI feats you use (gamepad support is on really early versions so that's really no issue).

    Here's a sample snippet on how you can do it:
    https://stackoverflow.com/questions...e-windows-gaming-input-in-c-without-using-uwp (you can also dynamically link to the runtime on demand so you'll not create something that runs only on win10).
     
  11. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    365
    @rizu The main thing that's holding us back there ATM is less technical possibility but more the current "backwards-rooted" nature of our Win32 player. The team working on UWP has already suggested we converge our UWP and Win32 codebases more. Problem for the Win32 player is mainly that the thing still needs to support everything all the way back to Win 7 (luckily we finally got to drop Vista and XP). And the more you add support for going to different APIs based on system configuration, the more you end up with having to test a variety of combinations and a player that's really hard to keep stable.

    Anyway, I think there's no doubt it *will* happen. But not short-term.
     
  12. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    365
    Hey everyone,

    I wanted to give a general update on the state of the project.

    ATM we're in the process of wrapping up the final pieces of feature work to switch pace and start focusing on stabilizing, polishing, and documenting what we have. Also part of this will be building out the demo which covers showing how to do local multiplayer and such. And as is obvious from GitHub issues list alone, there's a pretty sizable number of issues big and small that need addressing to make the system ready for widespread use.

    I know that feature-wise we do not have everything covered that you have asked for. Some stuff hurts not having in time for 1.0. Personally, I could easily put together a 20+ item list of stuff I wanted to have in 1.0 but that won't make it (like this one). Just at some point the bag has to be zipped up and gotten out for real as a first version.

    In terms of timeline, the plan is to switch into full-on beta mode probably sometime in December and to reach 1.0 coinciding with the release of Unity 2019.1.

    Note that there is a non-zero chance we will have to bump the minimum version requirement for the new input system along the way. If doable, the goal however is to keep supporting everything from Unity 2018.2 onwards.
     
    orb, recursive and FROS7 like this.
  13. recursive

    recursive

    Joined:
    Jul 12, 2012
    Posts:
    384
    Thanks for the update!

    I know it sucks not getting every feature out the door, but you've been one of the most transparent feature developers I've seen on these forums for a good long while. Keep it up! :)
     
    sand_lantern and Rene-Damm like this.
  14. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,051
    Kinda using 2018.3 for a project, is this Input system in current state worth jumping on board with implementing now?
    And its not a package? can only get it from github?
     
  15. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    365
    That really depends on your tolerance for issues. If you use it in its current state, you *will* run into some. Some maybe annoyances, some may literally stop you from using something ATM. If you prefer something more stable, I recommend giving it another month or two.

    I recommend directly putting the package contents into the Packages/ folder by following the instructions on GitHub. There is, however, the option to install it from the staging server via a more or less hack as mentioned here.
     
  16. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    6,120
    Aside from bugs/issues, how stable is the API today?
     
  17. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,051
    Only needing basic kb/m and xbox1 controller for now with simple inputs, it should be good to handle that right? nothing complicated or combo keys or any such stuff
     
  18. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    365
    Overall, relatively stable except for two upcoming changes. For one, the system will move out of its current namespace. That should be pretty easy to deal with as it just requires updating usings throughout the project. The other change is a scripting API conformance pass which will mostly result in name changes as well as less intrusive changes like fields turning into properties and such. This second change will very likely be more cumbersome to deal with. That one may be one to wait out. It is scheduled to happen early on in our stabilization effort as we can't go into full beta without it.

    There's also some consistency passes that may prove a little disruptive here and there. For example, the current set of interactions we have needs a good consistency and cleanup pass. If you're using actions, that may require you to update a couple things here and there.

    Finally, separate from those two tasks, I do expect the occasional rename to still happen. Mostly these should be straightforward to deal with and come down to simple search-and-replace. As we get deeper into beta, we will have to become better about documenting changes in our changelogs, though.

    Mouse is known to have a set of issues but yup, overall I'd expect relatively smooth sailing with those.

    We do have some issues that may prove a little tear-my-hair-out-is-thing-annoying regardless of what you're doing specifically with the system. Like, several users have reported the system to just stop working entirely after they changed scripts in their projects, requiring a restart of the editor.
     
    LaneFox likes this.
  19. Ferazel

    Ferazel

    Joined:
    Apr 18, 2010
    Posts:
    305
    Well over a year later it's a bummer to hear the input framerate awake won't make 1.0. Hopefully, it's high on the priority list. Personally, this is the #1 feature I thought of when "frame-rate independent" input was proposed. I do however, understand the pressures of ship and can empathize cutting some highly requested features.

    Good luck with the release, and I look forward to seeing how much easier it will be to get local multiplayer controllers assigned and hooked up to actionmaps! Get this behemoth out the door and do it well. It'd wound me bitterly to wait so long only to hear shortly after ship the team dissolves or Unity starts over on a new input system.
     
  20. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    365
    I understand that must be quite disappointing.

    On the bright side, once we have 1.0 out the door with the basics working, I think it'll be much easier to get in work that goes beyond the basics. Platform-work (probably the most broadly coordinated kind of work happening in Unity) so far had been mostly about getting the basics of input covered first.

    Thank you :)