Input System Update

Is the 2 year delay on the nonexistent "new" input system the reason for the "old" documentation being labeled "legacy"?

https://forum.unity.com/threads/correct-way-s-to-handle-input-docs-contradictory.524240/

 

I think that note there in the docs has lost connection to what it actually refers to. It clearly talks about drawing methods for UI textures and images but there's nothing like that in sight. Looks like a documentation bug. I'll raise it with the documentation team.

There's no relation there to the input system.

 

Heh, not much Only that there's some good people working on it.

 

I'm a new user. That documentation sent me searching for newer input processes. That's how I found this thread.

I'm still no wiser.

Please:
What is the current correct way to handle input?

 

I’m starting a game project that will only require two normal gamepad inputs, but it will probably last for at least a year or longer.

Should I start with this new input system or stick with the old one? How difficult will the conversion be?

I’m looking at the Github but it hasn’t been updated in months...

Also, I’m very reluctant to buy an input asset, because who knows if they will update for this new input system.

 

I don't think switching input systems will be hard. You should have one script or a state machine consisting of a few scripts to handle input, which controls other things via their public methods. The new system will just (eventually) get easier setup for common controllers, so you will have the option to know about different button styles (Xbox, PS or other button names).

I've been using the ancient and open source OInput until relatively recently. I think it can still be massaged to work, if all you want are the two most common gamepad styles. It has what you need to create remappable input configuration. Adding more controllers shouldn't actually be too hard either - I added a FireTV config which reportedly worked fine.

 

For general, non-UI input, it's the UnityEngine.Input API you've found in the docs. There's information in the manual here (check child pages) and here. Also, there's useful material in the tutorials.

My personal recommendation would be to not wait and to get going now with what's there.If you're sticking with stock Unity input functionality, switching later should be quite straightforward, should you choose to. Input code likely won't have a massive footprint in your code and some of the new APIs are very close to what UnityEngine.Input is giving you.

IMO developing a game is hard enough without having to wait for and catch up with emerging tech. Unity's current input system does leave a good deal to be desired but then, lots of good games have shipped with it successfully despite its shortcomings.

That's the master branch Check the develop branch for ongoing development. Master is kept runnable with the preview build (which by now is indeed several months old).

 

THANK YOU!!

 

Well, since hot swapping is what I mainly want (I use a wireless Xbox pro gamepad which goes to sleep often), I thought I'd give it a try with the development branch as you pointed out, only I get this when I drop the zip in my project:

I'm trying out Unity 2018.1.0b13 installed via Unity Hub. I saw a change note about it being setup as a "package" now, but when I open the Package Manager window, I don't see it even if I click All. I also found an import custom package option in the File menu, but it only accepts .unitypackage files and there's no such file in the zip I got from downloading the development branch off Github.

EDIT: Seems I still need to use the custom b1 download, even though b13 is out? That tells me that no, I should absolutely not use this input system yet... :/

 

Yeah, the preview build should have received a custom version number and not appear to be a 2018.1 beta build. That was an oversight on my end. Sorry about that. The fact it has a 2018.1 beta version tag is a side-effect of how we version trunk.

2018.1 does not support the new input system and cannot be used to run the project found on GitHub (neither the master nor the develop branch).

 

Thank you for the reply. So, reading the thread a page back, it seems I have to wait until 2018.2 until I can try the new input system in a serious project?

Because, if I come across a bug I can't figure out, and it's not an official Unity beta version, there's no way I can know if the bug is due to the beta, the input system or a purchased asset, is there? I mean, I can't report it anywhere, and people outside of this sub-forum won't be sympathetic to me posting things from a weird custom Unity version either, will they?

That's a damn shame, because this example alone completely sold me on it:



(Also, I'm having problems even in 2017.1 with alt-tabbing getting an input axis stuck without even a gamepad connected, and the 3Dconnexion SpaceNavigator getting recognized as a game input device when it is not.)

 

It seems I need three different Unity versions to try three different experimental, externally downloaded systems. Hope you can merge these so I can stick to just one beta version of the editor and a package for each subsystem.

 

The first wave of platform backends will likely be available in public builds starting with the 2018.2 beta. While gamepad support should be pretty usable at this stage, overall things are still under active development and in various stages of completeness.

Even for gamepad support, we do have a number of open tickets. Gamepad.current, as used by the script above, for example, is not protected against noisy devices ATM so if you have a PS4 controller plugged in, it'll always push itself to the front due to the gyro spamming data into the system. Stuff to finish.

The .2 beta phase is going to start relatively soon. At this point, I recommend simply ignoring the preview and waiting until .2 goes beta. It's not going to be an overly long wait.

Over time, processes and features around this will get better. We're still in the early stages of a bigger shift here.

For input at least, the requirement for a separate build should soon go away. There's no question that it's a painful one.

 

Hello, we are all waiting 2018.2 beta (me at least )

 

@Rene-Damm, can I expect there will be this New Input System added to Package Manager in 2018.2?

 

@Rene-Damm Sounds like great news, thanks for keeping us in the loop.

 

Eventually, yup. The very first step we want to take is to ensure that everyone can run the project from GitHub with a normal, public Unity build and try things out. After that, we'll be working towards having a package available. At first, that'll probably stay on a separate package repo for in-development packages for a while and go through a number of iterations.

Our aim is to gradually bring things online and ramp things up. We're not yet at a point where we can jump on stage and with great fanfare say "hey, here's the new input system, have a go at it and expect things to be all nice and shiny".

 

Are there any plans of having the new input system available as a package under the 2018.2 beta? Knowing full well that this is beta-quality tech, it'd be highly appreciated to be able to update the input system as soon as patches and fixes come out instead of waiting until the 2018.3 beta for things to stabilize.

 

Yes, we intend to have a package available sometime during the 2018.2 beta cycle. It'll still be preview and in some areas probably not even beta-quality tech, but it'll be a package

 

And after that is it gonna be integrated as a built-in module or remain an external package? because I thought the legacy Input system is gonna be deprecated.

 

I'm sure legacy will be deprecated when the new thing is stable, working and complete. Deprecating existing input before it even knows anything beyond bog-standrd Xbox controllers isn't a great idea, in my opinion.

 

Dumb question, but will this new Input system work/be integrated with ECS? Not sure if answered previously.

 

The way this works in Unity is in the process of changing. Short answer is, it will remain a package. There is a native part of the system that's a built-in module but the C# system will remain in a package. However, a certain set of packages for Unity will be considered part of Unity's stock functionality and receive the respective treatment so in the end, from that POV it doesn't really make much of a difference where the data/code is pulled from (package server vs single installer).

Eventually, yes. However, that's still some time away. We likely won't be thinking about deprecating the old system before we can rightfully say the new system has obsoleted any reason to use the old one (which I think will have to be backed by analytics showing that users indeed come to the same conclusion). Which is about stability/maturity as much as about functionality. Until we get there, users should have the choice of going for one or the other.

Short answer, yes.

Long answer, we're looking at it but it's not yet clear what exactly it will look like. In the initial release, we will likely not have APIs expressly targeting the use with ECS. But it's in the works.

 

When you're talking about deprecating the old system, how much of it are you talking about?

I think that keeping Input.GetKey/Down/Up for KeyCodes shouldn't go away, simply because it will always be faster for prototyping than anything set up for virtual bindings. The Input Manager can die in a fire and we'll all be better off for it, but I'd really not want to lose the ability to start up a new project, download no packages, and still check if space was pressed this frame.

Unity should still work with no packages installed, right?

I've also done (and will do) Unity beginners workshops and such, and the fewer windows I have to tell the students to open as a part of the process, the better. Being able to say "there are better ways to do input, but for now just write Input.GetKeyDown(KeyCode.W) to move forward" saves a lot of friction when teaching Unity.

 

To me, that falls under the same category of obsoleting all reasons to use the old system. If the new system does not provide a way in which it can be used with effort roughly equivalent to or less than that required in the old system, then the new one hasn't fully obsoleted the old system yet.

Eventually, we do want all the code paths from the old system in Unity's core gone. ATM we have a situation where platforms actually have to support two different input systems at the same time. That's not a sustainable situation. One has to go.

We could provide compatibility for the old APIs by re-implementing them on top of the new system but to me, that has little value. There is no way this re-implementation is going to behave exactly like the old system which means that while existing code will compile as before, its runtime behavior will change.

IMO the effort is better spent on making sure a new system indeed does obsolete any need for the old one. Including 'soft' features like ease of setup. And we do have a distance to go there. Which is why for now, we're not touching the old system.

Over time, individual Unity features will likely move more and more out of the core and into packages. So in that sense, no, it would not work without packages installed. However, it's on Unity to make this a seamless process rather than "I'm starting a new project and oh gosh, first I have to select 10 packages out of a menu of 100."

Yup, makes sense. And I agree that in the move towards enabling more granular configuration and composition in Unity, we can't lose touch with ease of use and accessibility.

 

Forgot to mention, this in particular is actually already working in the new system. There is a zero-setup code path supporting equivalent APIs to the ones you mention.

Code (CSharp):

1.  
2. Keyboard.current.aKey.isPressed/wasPressedThisFrame/wasReleasedThisFrame
3. // Or
4. Keyboard.current[Key.A].isPressed/wasPressedThisFrame/wasReleasedThisFrame
5.  

The basics should be covered. Some of the state queries supported by the existing system we don't have equivalents for yet (see here).

 

Well, I've read up on progress and it all sounds very nice!

I have two questions, all related to the great diversity of PC controllers (I love weird controllers!):
-Who will create templates (Unity? Devs? Users? All?)
There's always a weird/unknown controller around that players will want to use. I have a few ideas on this regards but your choices already strangely mirror mine, so I'd like to hear more on this.
-Will controller hotplug be supported? (index-independent binding):
This is an issue in many games, where you have to plug the controllers in the same order you had them when you bound them, and configuring a "visitor" controller is a bad idea for this reason.
-Will I be able to use more than one device for a single player?
This is useful for sims, where you'll be pluggins several function-specific devices.

Thanks, this all sounds pretty good so far.

 

Indeed, there's certainly way more variety out there than Unity could hope to cover internally.

So right now, there isn't a fully formed solution yet. The system itself is open to allow everyone to set up devices and have them appear as "native" as any existing support. IMO that's the minimum requirement. Beyond that, I think it'd be great to source user-created device support in some form. What that could look like in practice still needs to be figured out, though.

Sidenote: we've renamed the "template" concept to "control layouts" as the term "template" has led to confusion.

Hotplugging is supported but device->user correlation can still be a challenge on systems that have no inherent support for associating devices with users.

For example, if you have two identical Xbox controllers plugged in on Windows, you can query their XInput userIndex from the API but if on the next run, one of the controllers has changed USB ports, there's no guarantee that the ordering of the controllers is still the same. And XInput won't give you serials or any other means of identification. So, in short, stable identification of specific pieces of hardware can be challenging depending on OS and hardware.

On systems that have stable user identification, we're working on exposing proper device->userId association. Some early work is already in (InputDevice.userId).

There's no restriction on what kind of configuration you use the available set of devices in. Whether you split them up across several local players or whether you combine several to be used by a single local player is up to you.

 

Asset store packages??

 

I've seen some mention of haptics for gamepads...will the new Input System also have native haptic vibration support for VR controllers?

 

Yup, packages (though the new thing rather than the old asset store package format) will probably be part of the solution in some form. Maybe a separate package where we collect user-created device support that we don't have the means to give the same kind of QA as the support in the core package. At this point, we're still a good distance away from this becoming something to figure out.

ATM we have simple rumble support for XR controllers (on the same level as simple rumble support for gamepads). I expect that over time, this will get a little more sophisticated.

 

Im so excited for this new input system, I havent been able to get it to run on my 2018.1 beta tho so not sure what the new changes are but I figured (as you're still developing this) here's my biggest issue with the current input manager.

There really has to be a unified gamepad input for different types of controllers. The current input mapper has different input names for the same buttons of different controllers (X360/Ps4), add that to the fact that there's no good way of identifying which controller is being used. The only way I've found is Input.GetJoystickNames which doesnt really help with that. I've been trying to figure out a smooth way of creating my own unified input that works with both 360 and Ps4 controller at the same time but I cant find anyone talking about this and I'm not experienced enough to figure this out all by myself.

Will the new Input Manager be included in the 2018.2 beta and do you think this new Input system will be featured in the official Unity sometime soon? Really looking forward to testing this out!

 

How is touch best handled on iOS? @Rene-Damm

This doc says it's out of date: https://docs.unity3d.com/Manual/script-TouchInputModule.html

and that it's replaced by this: https://docs.unity3d.com/Manual/script-StandaloneInputModule.html

But that doesn't mention touch, at all.

I want just two touch zones, left and right of the screen. Flipper controllers for a pinball game, so low latency is important. Where/how do I read up about how I'm supposed to do something like this in Unity?

 

As the docs says:
Note: TouchInputModule is obsolete. Touch input is now handled in StandaloneInputModule.

The thing is that now you only need the StandaloneInputModule and it will already handle everything, including the ones that were previously handled by the TouchInputModule.

To do what you want, you will want to take a look at the EventTrigger: https://docs.unity3d.com/ScriptReference/EventSystems.EventTrigger.html or one of it's interfaces.

 

I've been reading through all this stuff, in an endless loop for a few days.

And even mention, in my post, that I'm aware of this obsolescence, and the need to use StandaloneInputModule.

HOWEVER... nothing in those docs, nor in the page you've linked to, mention anything about handling touch.

So how do I handle touch with this StandaloneInputModule? Or where do I read about using it for touch?

Sorry to be so borish. I'm going around in circles without finding anything.


other than this, which I have no idea how to use:
StandaloneInputModule.ProcessTouchPress

 

It's kinda burried, but if you see the docs for PointerEventData, you'll note that it says "Event payload associated with pointer (mouse / touch) events".

So all of the EventTrigger stuff (as mentioned by @brunocoimbra) that's named something-pointer will work with touch inputs as well as mouse inputs.

 

I can't even get mouse events to generate this, or to call anything.

Is there a list of the processes involved, somewhere? I must be doing about ten things wrong.

 

PMing you to derail thread.

 

Not necessarily soon but eventually. For now, the new input system will remain something that needs to be explicitly opted into and installed (though it'll be made easy through the package manager). But yup, the road is towards becoming a standard feature of Unity.

Heh, yeah, the fact that you can plug in an Xbox controller on OSX, Windows, and the Xbox and it'll look different on each platform and also look different than a DualSchock plugged in on the same platforms is quite annoying. I recommend taking a look at InControl if you're looking for a solution that works in Unity right now. Patrick Hogan has done a great job tackling the inconsistencies and problems in the existing gamepad APIs.

Thank you @Baste and @brunocoimbra for jumping in and helping @Deeeds.

 

Will the new input system allow handling input while the game window is not focused? I played some games that had that, and found it convenient so I did not have to alt+tab to do something else while the game is running on a multi-monitor setup with a controller. Ideally it would be an optional feature that could be disabled. It's not really important though, so it's fine if it's too much work to add. The new system looks really nice though and I'll probably use it either way.

 

Interesting idea. I made a note in the backlog. And yup, would probably be good to have it as an additional switch that when "run in background" is on, allows you to enable input capturing when in the background. Something along those lines.

ATM platform backends respect input focus so yeah, ATM the setup you describe isn't possible.

 

Hey everyone,

The first beta of 2018.2 is now available for download at https://unity3d.com/unity/beta-download. You should be able to run the develop branch at https://github.com/Unity-Technologies/InputSystem/tree/develop with that beta. We will switch the master branch and remove the old preview shortly.

Please note that there's still bugs and problems and everything's pretty much still work-in-progress. One fix in particular didn't make it into b1 and will be in b2 -- this causes some input devices (e.g. gamepad on Android) to do nothing as the system incorrectly thinks they are disabled. Overall, usability varies a lot by feature. The gamepad stuff is starting to be quite usable. Keyboard is mostly usable, too. Touch needs work. Actions need tons of work. Etc.

Anyway, have fun and of course, please do let us know what you think

 

Very great news to hear that the new mythical input system finally is available to properly run! Will definitely give it a try by porting my current project to it! (might not be the brightest idea but versioning control FTW!)
Just a quick question: Is rebindable controls a thing yet? Haven't paid too much attention recently and to the commits.

 

I'd say it is half a thing It's the "input actions" thing which is usable to some extent (the demo scene has a simple setup) but there's a number of things missing (not the least of which are proper UIs) to make it a viable feature for a full game.

Ah and if we're talking being able to have proper rebinding UIs for user-controlled rebinding, that's still missing some parts, too. So overall no, not yet.

 

So I gave it a quick go and it feels promising and I could definitely see how I could work with this. But I just need to ask; What is wrong with the mouse? Using Mouse/delta feels absolutely awful! I really hope that is going to get fixed, at least before it shows up in the package manager! The feeling is a bit hard to explain, but it's like it knows where it should go and then slowly lerps over there.
Also, is there currently a way to make something like the axis in the old input manager using the UI interface, or by code for that matter? I couldn't figure anything out in my few minutes of testing. Might have to rewatch those videos again before I give it another go!

 

I think I need more details Wrong where? In the demo scene? Is it that the mouse is having a lot of lag?

One potential culprit here is the mouse sensitivity stuff. What's there ATM leaves a lot to be desired and needs another pass before it's useful.

Check out Assets/Demo/DemoControls.inputactions. You can set up bindings in the inspector (if you don't mind a temporary, programmer-art-kinda UI, that is).

Unfortunately, the videos are somewhat dated by now and there isn't much on actions. ATM we still have very little in terms of documentation/tutorials/etc.

 

Is this a potential privacy/security issue if handled incorrectly? Particularly given the recent privacy issues publicized from other public companies, the sound of "background processes that are capable of monitoring your device inputs" sounds especially troubling.

 

Sorry to leave you hanging! Night time and work happened.
Regarding the mouse: As I mentioned, it's a bit hard to describe. But it certainly has some kind of lag. It feels some "rigid". Like, once you start moving slightly up and left, for example, you can't change it until it has reached that point. I got the same behavior when using the demo controller and when setting something up myself. Compared to the controller, which is smooth and exactly how you expect it, it's very weird feeling.

And regarding the axis thing, I left out an important aspect: Axis with keyboard controls. Like W being forward, D being right, etc. Is it possible to do something like that?

 

I think Unity isn't necessarily the right gatekeeper here. If the OS allows doing this kind of thing, I think it's fine for Unity to allow using it. My guess is this alone will confine it to oldskool desktop OSs. But certainly something to keep in mind.

Cool, thanks Filed a ticket and will take a look. Pretty sure it's the mouse delta handling simply not being up to snuff yet.

ATM this can only be done in hackish ways where you have a "Move" action bound to 2D controls (like gamepad sticks) and "MoveLeft", "MoveRight", "MoveUp", "MoveDown" actions bound to keys.

We're working on an extension of the binding system to be able to create "composite bindings" so that you can, for example, bundle up two buttons into a 1D axis configuration and four buttons in a 2D vector configuration. There's a test but the implementation is incomplete. When this is finished, you'll be able to have a single "Move" action yielding a 2D vector and bind that to pretty much arbitrary inputs.

 

What is the installation procedure now? Still a custom build of the editor or? Is it integrated in the new version of Unity Hub somewhere? Has it become a package yet?

(Perhaps noteworthy, I found it a bit surprising that the guy in charge of Unity Hub, an official Unity tool, had no idea that the new Input System was distributed via a custom Editor build, and didn't really have full support for this in the Hub...)