Input System Update

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.

 

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.

 

What is the best aproach to use new input system inside hybrid ECS and Pure ECS?

 

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.

 

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.

 

Ouch, sorry about that. Didn't look close enough. Updated the link to point to the public repo here.

 

@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.

 

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?)

 

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.

 

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).

 

@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.

 

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.

 

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!

 

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?

 

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.

 

Aside from bugs/issues, how stable is the API today?

 

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

 

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.

 

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.

 

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

 

Using Usage bindings in the editor doesn't seem to work:


Seems to use a slightly wrong Binding:


Fixed by adding the brackets:


I'm on 0.0.12 using 2018.3b11

 

I would be nice to have an api for InputAction like how Devices work

I'd love to be able to do something like InputAction.wasPressed or InputAction.ReadValue<Vector2>() within an update loop, instead of only having the option to use Events

 

I'm running into an issue with actions not hitting the cancelled phase

Code (CSharp):

1. public class InputMovement : MonoBehaviour
2. {
3.     public InputActionAsset inputAsset;
4.     InputActionMap inputMap;
5.  
6.     public Vector2 direction;
7.  
8.     void OnEnable()
9.     {
10.         inputMap = inputAsset.GetActionMap("DefaultControls");
11.         inputMap.GetAction("Fire").performed += ctx => Fire();
12.         inputMap.GetAction("Movement").performed += ctx => direction = ctx.ReadValue<Vector2>();
13.         inputMap.GetAction("Movement").cancelled += ctx => direction = new Vector2();
14.  
15.         inputMap.Enable();
16.     }
17.  
18.     void OnDisable()
19.     {
20.         inputMap.Disable();
21.     }
22.  
23.     (...)
24. }

When i was using the analog stick, i noticed the values weren't going to default, i tried adding a stickdeadzone but i don't think it works at all. So i decided to just set it to zeros once the input is finished? Seems to work great. But when i tried it on the keyboard, the values stuck on the last input and are never set to zeros. I tried all the interactions

Also side note: the interaction for Repeat on Hold doesn't seem to work

 

Just having the new input system installed seems to break the command-space shortcut to maximize the selected window (like the game view).

 

Confirmed. Will fix.

Been thinking about this one repeatedly but no final conclusion yet. Problem is that action state is a good deal more involved compared to the raw value state of devices. And even that one and the aggregation that needs to happen frame to frame already leads to a number of ugly issues.

A more reliable alternative to the callbacks is recording the actions as events as they happen. InputActionTrace (been renamed numerous times; used to be InputActionQueue) is meant to do that.

Still, a polling-based API on actions would certainly make things a lot simpler in many cases. The challenge is just to also make it work reliably (and quickly).

Whether 'cancelled' is fired depends on the interaction being used on the binding. In general, only interactions that represent a continuous interaction (as opposed to a one-off interaction) with the control and that may start but not finish, use 'cancelled'.

The interactions overall are up for a consistency and cleanup pass. The current set is inconsistent and in some places works in counterintuitive ways.

Yup, we have a bug open for that. While some not-getting-back-to-zero problems may come down to deadzones that need tweaking, there definitely seems to be a problem in the action system that adds on top of that.

We'll take a look. (ticket)

 

Awesome, thanks for the detailed reply!

One last thing, i noticed that in the latest updates, things like Keyboard.current is gone. But Gamepad has .all[]. Is it possible to have the same for Keyboard? It’s nice for quick iteration (like in the current Input system). Or is all that stuff going away in favor of just getting your Devices from the InputSystem?

 

Short answer: use InputSystem.GetDevice<Keyboard>().

Long answer: This has been quite the discussion internally The previous getters were indeed very convenient. Unfortunately, they were kinda misleading. Depending on the device, it can be quite involved to determine which one was actually last used by a user.

For example, a PS4 controller (and plenty of other HIDs) will constantly spam the system with events containing jittery data (mostly coming from its gyro). So if you have both a PS4 controller and an Xbox controller attached, the PS4 controller would constantly make itself current even if the user is actually playing with the Xbox controller.

To make this robust, we pushed for having reliable noise masking so that we can tell when there is meaningful data. Unfortunately, once that was in, event processing times went noticeably up across the board. Significantly so.

Which was unfortunate as the use case of "just give me the device of this type that the user last interacted with" has limited applicability. Once you have a game that uses actions and tracks what the/a user is actively using, .current becomes useless overhead. There's ways in which the overhead could be made lazy but not without adding overhead somewhere else. So... yeah...

So, after discussions, I made the call to nuke .current across the board and instead have InputSystem.GetDevice<TDevice>() return the last one of the given type that had *events* on it (which may have been just noise).

That said, there's probably a case to be made to introduce quick getters to certain devices which internally just do InputSystem.GetDevice<..>() for you. Was thinking of just adding 'any' getters. Like e.g. Keyboard.any and under the hood all it does is GetDevice<Keyboard>. Pretty much like .current but without the same costly to maintain meaning.

 

And how! Just having my PS4 controller attached to the iMac wakes it from sleep/keeps it from sleeping if I don't put it far away from anything which could trigger the gyro. I guess Apple support a lot of gamepad-like input devices for accessibility features, so the OS will listen to ANYTHING attached.

 

Hmm... this sounds like "filter noise" should be an option that the developer could enable...

Or if that is too difficult, perhaps "ignore gyros" option to the last used device listener? Very few games rely on gyro as their main input.

 

Things are starting to come together but I do have an interesting problem and a suggestion:

The other night I accidentally applied a Stick modifier to a composite DPad control baseed on a Gamepad's DPad buttons. This effectively silenced the input from the DPad.

A suggestion for post-1.0 release is this: Have a way of specifying bad combinations of controls/interactions/processors to prevent people from changing something (in my case I had copied the stick config manually and forgot to change it), or at least warn users "hey that may not be a good combination".

 

Hey everyone,

As part of working towards a more stable system, we've introduced a stable branch. We are aiming to perform weekly QA (limited so far but we'll build it out over time) on the branch before promoting what we have on the develop branch and publishing a new package. That should get us one step towards having a modicum of reliability.

This month, we're also aiming to make the jump with the package from staging to production so soon it should no longer be necessary to consume things directly from GitHub. Personally, I'm looking forward to where we're no longer constantly breaking stuff for everyone

Yup, agree. We have a couple places where the UI still allows you to set something up that won't work in practice. For interactions in particular we still need to add a mechanism so that they can advertise what they're compatible with.

Yup, this avenue is something I'm still contemplating. We do have the ability to tell if a device has noisy controls (InputDevice.noisy is true for a device that has any InputControl.noisy==true) and filtering device activity for noise could be made an option.

Unfortunately, it's slightly more involved than that in practice. For a given event, you'd want to know something like "compared to the current state, does this event indicate *user interaction*?" So even ignoring gyro noise, you still get noise on the sticks (and to some degree, triggers) when they're below threshold. So you end up with a two-way comparison overlaid by a noise mask and then you still have to actually go and look at some individual values.

Still, having the functionality but it sitting behind a switch might be the best compromise in the end.

 

Awesome.

That sounds like the best way to do it, as previous experience indicates there's no "perfect" solution for what constitutes noisy input. Will the specific masking be customizable by the end user at least? That could be a boon to folks dealing with devices that are experimental, prototype, or just weird project-specific use cases for things like installations and garage projects.

 

One Question.... Since the new input system was push back to 2019.1 i like to know would it be preview or somthing in the Alpha Version or are you going to wait for going to wait for the beta release to put it into the unity build were we don't have to go to the GitHub

 

Pretty much. When writing custom device layouts, it's up to you to determine what's noisy and what isn't. And for existing layouts, there's always the option to non-destructively modify existing layouts using overrides.

Code (CSharp):

1.         InputSystem.RegisterLayoutOverride(@"
2.            {
3.                ""name"" : ""DualShockGyroIsntNoisy"",
4.                ""extend"" : ""DualShockGamepad"",
5.                ""controls"" : [
6.                    { ""name"" : ""acceleration"", ""noisy"" : false }
7.                ]
8.            }
9.        ");
10.  

Which... now makes me realize that the way the code works will not allow overrides to unset the noisy flag once set. I'll take a look at that

A preview package is planned to make it to the production server sometime this month. It will work with Unity 2018.2+.

Just to clarify, the system will not ship as part of Unity but will remain a package (which, however, unlike now you can just install from the package manager window). After the release of 1.0-preview planned to coincide with Unity 2019.1, the plan is to look into making the package reach "verified" status, i.e. become part of Unity's stock set of packages.

 

What will happen if you don't have the package installed? Will you be maintaining legacy input, or will there just not be any input at all?

 

They'll not just suddenly remove the old system as it can work aside even now. In past Unity has been really cautious on removing older systems. Look how long it took them to get rid of DX9, UnityScript or the legacy Particle Systems for example. DX9 had to be dropped from practical reasons eventually, but rest were only dropped when majority of the user base didn't use those systems anymore, and Unity also gave a long period for people to transition after warning on planning to get rid of them.

For the soon to be legacy input thing, IMO they could hide the old input mapper menu entry if the old input system isn't selected from the player settings (just to avoid confusion) but it probably doesn't harm them much to keep the actual system around for years to come. After all, majority of existing assets on store rely on it on some way or another, they'll not just break them or peoples projects relying on the old setup without a good reason.

edit-> if you look at the player settings, you can already pick between the old and new input system.

 

TBH we don't yet have a concrete plan for deprecation of the existing input system. For now, both the new and the old system are there and it's up to you to choose which one you want to go with. Once the new system is at a point where we can rightfully say the old one is entirely obsolete, we will think about how to get rid of the old system but that'll still be a while and even at this point, there's still multiple ways this may pan out. An API-compatible reimplementation on top of the new system could be one way but at this point we don't know for sure which way this will go.

So, in short, if you don't have the package installed (and the player setting switch flipped), Unity will simply continue to do input the way you're used to.

Might indeed be. The downside to keeping it around is that we now have two parallel input paths in C++ that each platform (and there's something in excess of 11 separate backend implementations of that by now) has to serve. Keeping those intact and maintained does take quite a bit of resources. Longer-term, it'd be quite beneficial to be able to cull one of those paths.

Yup, that's indeed one of the major problems of touching UnityEngine.Input. My hope is that we can keep the API alive and every project working just fine while underneath we can switch implementations so as to allow us to cut a whole bunch of C++ code. But I have no idea TBH whether that will work out that way. Could well be that in the end, we'll have to maintain both paths for a good long while.

 

I'm sure you'll have to keep it for quite a while, yes. Once all GUI stuff defaults to using the new system, and programming for the new system is easier and more flexible than the old one (as well as stable and seemingly bug-free), there won't be any need to keep the old system around.

You could also mask some parts of the new system behind reimplementations of the old API for the simplest cases, like basic mouse and keyboard input (movement, clicking, key down/up). Gamepads and more exotic devices should be required to use the new system once it reaches stability.

 

Are you inplementing presurre support for Wacoms pen tablets? As wel as pen rotation?

That would be something very high on my wishlist, mainly for use in the unity editor.

and when would this be ready?

 

On Windows (and I believe iOS) it's working today. There's pen pressure, tilt, and even twist support. OSX side still has to catch up.

 

Can you also make it work with the unity terrian paint tools?
so that its possible to paint with pressure sensitivity in the editor

 

There's someone on the terrain team looking into that and I'm sure it'll come but TBH I don't know what exactly the status of that is ATM.

 

Now since 2018.3 is officially out I am going to ask the lovely question about possibly timelines for the input being added in as a package manager. Been installing the stable build from the github repo and would like to know if we have an estimated time frame for it being put into package manager.

.

 

We're working on it ATM Our hope is to have the package from next week (probably 0.0.15-preview but maybe we'll make the jump to 0.1-preview now that we're working on stabilizing) on the production server.

 

Dang that was a fast reply.

Thank you for the update. I been loving the progress of the input system. The input system and 2d lights have been my most welcomed feature.

 

Hey everyone,

With 2018.3 being out now and because of us getting into trouble with trying to port our native changes between three different Unity versions, we've decided to drop support for 2018.2 after all. We do intend to keep supporting 2018.3 even when 1.0-preview comes out at around 2019.1 as 2018.3 is the LTS version for this year.

Hope this isn't terribly inconvenient for anyone.

This transition also gives us access to some stuff that only landed in 2018.3. Like, for example, we're working on getting proper project settings in place for the input system. Here's a totally-work-in-progress snapshot:

 

If you've settled on 2018.2 for whatever reason, you probably like things stable and weren't experimenting with new input systems in an important project. It's been so long in the making that I wouldn't even mind if it's 2019 only.

 

I think this is a good option. Don't make the mistake of supporting too many things and having to split focus in the wrong areas. Most people will go to 2018.3 for new shader, ECS, new prefabs, and C# 7.3 So, most people probably won't stay in 201.2 unless they are far into a project.

 

Hey guys, nice to hear some news from you!
Are you trying to solve a touch delay problem on mobile and multitouch event system with UI team?
This is a very big omission.

 

Hi @TimNedvyga, could you provide a few more details regarding the problem? If it's being discussed elsewhere on the forum, just a link will do.