Input System Update

I am writing this list here because this is not a suggestion or a feature request, but a "must" for an input system.

1. Ability to set mouse position
2. Minimum input delay and if delay of some sort is inevitable, make it so that the delay itself is consistant.
3. Allow UI object drag to be matched to the cursor (I don't mind the actual method as long as there is a way to drag UI without that elastic band effect)
4. Allow runtime configuration of keys and all
5. Ability to set cursor graphics bigger than 16x16 (or was 32 x 32?) while hardware accelerated. This alone could solve number 3.

 

Awesome to see this starting to take shape! Is this currently working with Rift Touch and Vive?

 

The XR team is working on hooking up XR support for a release concurrent with the other platform backends. Having the new input system support all headsets and VR controllers already covered by Unity is high up the list.

 

Yes a how-to: lets say 2 controllers parallel active and navigating over 2 different grids in 2 different canvas.

To make multiple inputs possible I followed this blog-entry and was finally able to achieve that. The only thing left was adjusting it to my systems and avoid that one player could accidently move/interarct in another active UI. (due to auto navigation)
http://blog.pastelstudios.com/2015/...ultiple-event-systems-single-scene-unity-5-1/

but it seems that someone already solved the current issue in 2017.3 by himself in this recent post https://forum.unity.com/threads/solved-multiple-eventsystem.512695/

But I'd still could imagine that a lot of people might run into this.

Thanks for the good work you did already and for the response, though!

 

Is something like this what you have in mind?

The Cursor API will likely stay unchanged for the initial release but even beyond, I have doubts this one will prove doable. Hardware accelerated cursors are subject to restrictions that are outside of our control (that 32x32 size restriction isn't Unity's but rather goes back to the OS/GPU). We can try to mitigate the negative effects of using software cursors (stuff like minimize lag, make unaggregated mouse deltas available) but I think the wiggle room we have with the problem is limited.

My guess is a good drag&drop feel will continue to largely depend on good framerate and low input latency.

Interesting. We haven't yet started writing the input module to integrate the UI system with the new input system but when we do (coming up fast on the list), I promise we will take a look at this.

Thanks @wuzibu

 

Can't agree more! There is no game or application that I know of that "solves" this problem anyway.
Either you make the best of the 32² space (world of warcraft just takes the item/skill icon and adds a little triangle to the top left), or you have to just have to deal with the delay (for example when you are dragging windows).

The only thing I know is DWM.exe on windows which does some black magic to make window-dragging seem super-responsive. But maybe that's just some trick...

Also, latency issues are very much reduced when you have: an actual build (not editor) + exclusive fullscreen (not "windowed-fullscreen"). The editor in play mode has some pretty large lag, but that is to be expected and not a real problem at all. Same thing for audio delay by the way in the editor I have a measurable 300ms lag, in a standalone build I get the optimal <50ms just like other games and applications.

 

Is there any chance that we could see ISX downloadable via Package Manager in 2018.1? (Even if it's experimental or from https://staging-packages.unity.com)

 

We're looking into getting a package up on staging soonish but unfortunately it won't be compatible with 2018.1 as the native changes haven't landed yet (the preview build we did was still based on a custom branch). But... we're getting close

 

Will the native changes land somewhere in the 2018.1 beta cycle or are they more likely to be in the 2018.2 beta cycle?

 

Heh, given our past failings (see first post in thread), you can probably tell I'm squirming in my chair a little What I can definitely say is that they won't be in 2018.1. We're working hard on landing after that.

 

That's fine. I'd rather y'all take the time and get over the hurdle than rush it. The other 2018.1 features have kinda taken my active interest at the moment, so you're safe for now as far as I'm concerned.

 

2018.1 proper could be a month to 6 weeks away, so 2018.2 beta isn't a long wait now. If the input system is ready for testing I'd say that's a better target for testing

 

I was just now very close to either trying out SlimDX or starting to writing by own native input, but I'm very relieved to read this post. I probably will still do my own eventually but I'm very glad you guys have supported this kind of flexibility.

EDIT: I should probably note what I'm referring to, which is the ability handle the input stream manually and process a history of input (with time stamps) as opposed to only having access to aggregate state.

If someone could provide an example of how to "tap into the event stream directly" I would be quite grateful.

 

So still no idea when this will drop? I have a sneaky suspicion it will be 0.1 seconds after I cave in and spend my already over-stretched budget on InControl or Rewire.

 

If you decide to break, Rewired is fantastic. Unfortunately it doesn't play well with .NET 4.6 support at the moment.

 

I've done everything I can to make things work including quite a few obtuse workarounds for bugs. Unity has fixed a number of the major bugs in .NET 4.6 preventing it from working properly, but they've just regressed and broke it again in the 2018 beta.

Edit: The issue has been fixed in 2018.b6 on Windows.
OSX issues related to non-functioning dllimport operations have not been re-tested.

 

ATM the API works like this:

Code (CSharp):

1. InputSystem.onEvent +=
2.     eventPtr =>
3.     {
4.         // eventPtr is a wrapper that internally refers to unmanaged memory containing the event
5.     };
6.  

The plan is to have more than just a callback-based API. We want the ability to gather and process events at a point that is determined by the caller. Something we want to have for actions as well.

The above API has the advantage of sitting right in the system's event processing loop. You can mark the event as handled, for example, and the system will skip it automatically.

While the eager dev in me wants to shout "WAIT FOR US" or something like that, the more rational part in me would say, if this is something you need solved NOW, don't wait for us. InControl and Rewired are proven and battle-tested solutions. Even if we hit the next Unity release full force with the new stuff, fact is we're still sitting on something that will have to undergo a phase of stabilization and maturation. Of course also largely depends on the timeframe you're operating in. If you need to ship within the next six months, I'd say the new input system isn't a good bet to make.

 

Hello @Rene-Damm

[Question 1]

Right now I'm working on keybinding for my game and as you might know, there's some bugs when trying to get mouse input when using Event.current & inputString.

Is ISX going to fix that?

[Question 2]

Since ISX is going to be provided via Package Manager, do you know if ISX is going to be split into Touch package, Keyboard & Mouse package, Controller (X1/PS4) package or is it going to be just 1 package? let's say that a person which creates a mobile game only imports Touch package into the project to save up application memory/editor build time/performance. Have you been thinking about this concept?

Thanks.

 

In terms of fixing existing input paths for IMGUI and the old input manager, no. But in terms of providing a working solution within the new APIs, that's definitely the goal.

What are the problems here? TBH I'm not aware of the problems here with Event.current & inputString. Could you elaborate a bit?

The plan is to ship as one package for now. If we split it up, thoughts so far have been more along the lines of splitting off the action part from the devices&controls&event layer.

But yup, we've been thinking about that concept. The system is already split into several different DLLs with a platform-independent core and then a number of plugins that add support for specific devices.

This stuff is still pretty early in its inception but what I'm envisioning is being able to determine exactly what device support goes into a build. I think this will become even more important when we get to the point where devices are no longer just code but also come with assets (images&models) that might be included in builds.

As an example, there is a plugin for XInput controller support here. This should automatically be disabled on all platforms where it is irrelevant. For the code, it'd be easy to just tie that to the build settings of the .asmdef files. But once we have data like controller and control images in there as well, we need more than that.

 

[FIXED]

 

To get what keycode is pressed in the current system, the only really viable solution is to iterate all of the enum values and check them one by one.

 

I think that can't be expected to work. Key presses and text input aren't tightly coupled like that. Key presses may result in no text input at all, or may result in text input only after multiple key presses, and multiple key presses in quick succession will accumulate in inputString (the 2 key problem you've run into).

While the APIs are different, you'll have the same problem in the new system. Key presses and text input are two separate input paths. To print all key presses, you can hook into the event stream and filter for state events on the keyboard. Unfortunately, finding which key has been pressed has no nice API yet (the event contains a snapshot of the entire keyboard state) so ATM it requires iterating over all keys.

 

I want to suggest one thing. For new features and APIs I see that Unity now is following some high adopted code formatting conventions like properties starting with uppercase.

https://github.com/Unity-Technologi...ssets/UnityARInterface/Scripts/ARInterface.cs

https://github.com/Unity-Technologi...ipeline/HDRP/Decal/DecalProjectorComponent.cs

But I see that Input team it's not:

https://github.com/Unity-Technologies/InputSystem/blob/master/Assets/InputSystem/InputManager.cs

Can you follow them like your coworkers? Can you speak internally (all teams) so you all do it the same way? It's really confusing.

 

But I don't understand why you can't make that switch for ALL new features, it's the right moment to do it. Later it will be difficult without using API updater and it will be more work for you.

 

Don't worry, this is covered The switch in our conventions is something that's only just happening in Unity. We have some code already following the new (Microsoft) conventions but most is still following our old ones (like the input system does). Just yesterday our scripting team passed me a document with over 2100 change requests mostly to update the naming. New code going forward will follow the new conventions.

So yeah, this is the effect of us developing more out in the open. In olden times, you wouldn't have seen this intermediate step of evolution in the input system code.

 

Ok, thanks.

I'm glad that you are adopting that conventions.

In the future it should be easier to accept pull requests on Unity github repositories.

 

Hi there. Great news indeed. One thing I don't see covered so far (maybe overlooked it) is the number of supported axis/buttons. The current system fails with several input devices like Logitech G29 for example because of the to few supported buttons/axis. Is this going too be changed aswell?

 

Yup, there's no limit built into the system. A device just adds whatever controls it needs.

Controls are not indexed with a global "master enum" like KeyCode in the old system.

 

Wait, are you discarding the great readability of KeyCode.Joystick7Button8?

What a shame! Whatever will we do?

 

Hello!

I am making a multiplayer arena fps with Forge!

I came across this awesome discovery looking at inputs regarding getting up to 4 players onto split-screen for Multiplayer. I saw the concept video!! Looks like it could be possible!!

I figured out I would player input it and handle the scripts, and add spawning/server disconnection in the extra input, does that sound like a reasonable possible idea to do with the new input system?

At its current state is it ready enough to pull of my idea (paragraph above this one)?

Thank you!!
Xalo

 

AWESOME!

 

Technically, it should work even in the preview version but we haven't gotten around to building a proper demo and giving it proper testing so my expectation is that in practice, it's broken ATM. However, for release we'll be making sure local multiplayer usage is working properly. The setup is likely going to require more code than a single player setup (at least in v1 of the system, you will likely have to manage player<->device association yourself) but the foundational APIs should be in place.

 

Is there a eta on when this will be done?

Thank you!!!

 

We're not yet "officially" committing to an initial release (still labeled "preview") in 2018.2 but that is what we're working towards. There's uncertainty around what level of platform support we'll have and uncertainty about what functionality we will manage to finish. Also, there's uncertainty around what other systems in Unity that currently depend on the old input system we will have support for.

In short, still a lot of unknowns but things are progressing well.

 

@Rene-Damm Thank you!!!

 

I just need to ask this. By looking at the commits it seems only one person is doing this; Rene-Damm. Is this the case? Are you the only one working on this? If so, why? Can't Unity afford to give you a coworker in this?

 

Please make local multiplayer a breeze

 

Heh I can see how it looks that way Especially from the commit history in a repo where I've made myself be the only person with direct write access (PRs are going in but they are less visible than the noise I make)

Right now, aside from me, there are 5 programmers involved to varying degrees on various platforms. There's people working on QA and UX. There's a UI programmer scheduled to join. And there's a PM (hey Victoria) without whom this ship would probably be dead in the water just about now.

It's not a one-man effort even though my face is the one that keeps popping up in every corner.

 

Ah, that's nice! Seemed kinda weird if there would only be one person working on this. But good to know that there are multiple talented people behind this!

 

The initial release will probably only manage "doable" rather than "breeze" but "breeze" is the eventual goal

 

Nice to see that you are working on this! I am making an asset to simplify some of the more "mundane" tasks of making a game and time came for me to address input, local multiplayer, and control mapping. I started to design my system to abstract actual controls from player input and then I came a cross this preview feature =) I see above (and in the roadmap) that an actual launch date/Unity version is uncertain.

Would it be reasonable to expect that the core fundamentals of the preview will remain or may it change significantly? I am trying to decide whether to release my system and/or support the preview.

 

At this point the expectation is that the devices, controls, and event stuff will remain mostly unchanged. There will be some volatility in the API (and eventually a move out of UnityEngine.Experimental.Input) and some added capabilities here and there but overall, this part of the system should remain relatively stable and dependable.

The action part of the system will likely see quite a bit of change still. Even the data format on disk for input action assets may still change. The UI will certainly change quite a bit. The API is likely to see several shifts.

In other words, directly dealing with devices will expose you to limited change. Using actions to abstract you away from going to devices directly will expose you to considerably more change.

Hope that helps a bit in the decision.

 

I'm so glad that this is finally happening. For years on end I had two complaints about Unity: the input and the terrain system. I'm happy to see that one of them is being worked on and will hopefully be fixed soon.

Does your solution also include concepts for allowing the player to re-map controls at runtime? Or is this still something the game developers have to do themselves on top of the input system? (disclaimer: I didn't download the preview, sorry if this is already answered there)

 

PolyBrush is kinda, sorta a solution for the terrain problem

It's always confusing when you've got several builds with the same numbers. How many current beta builds are there of Unity now? Will the latest one just work with all the experimental things you have now, including the input system? Is the one in the hub actually the latest, and how do I tell from inside the editor which of the two b12s I have, for example?

 

Terrain is being worked on too

Yup, bindings are fully accessible/changeable/overridable at runtime. The entire action stuff can be made up / changed on the fly. We still have some way to go with the rebinding APIs so that it becomes very easy to implement a binding UI and get reliable rebinds from the right type of controls and without noise interference. But we're getting there. The basics are already in place.

Yeah, sorry about that. Should have changed the version number on the preview before building it but frankly didn't think of that. Fortunately, this is going to not be an issue going forward as you'll be able to just use normal Unity beta builds instead of having to download separate input system preview builds.

 

So can we hope for b13 the week after the holidays?

 

Heh no, the 2018.1 line won't get the native stuff.

 

Wh What what.. what do you know