Input System Update

Seems to only be available in 2019.2+. I was looking for something that would work for 2019.1+. Thanks anyway.

 

I can think of two workarounds:

Code (CSharp):

1. // Use PackageManger.Client (from 2017.3)
2. var req = UnityEditor.PackageManager.Client.List(true);
3. // ... wait for request to complete
4. var info = req.Result.FirstOrDefault(p => p.name == "com.unity.inputsystem");
5.  
6. // Read the Json yourself
7. [Serializable] public struct CustomInfo { public string version; }
8. var json = System.IO.File.ReadAllText("Packages/com.unity.inputsystem/package.json");
9. var info = JsonUtility.FromJson<CustomInfo>(json);

Or you can use reflection to call the FindForAssetPath method in 2019.1. It's on the internal class Packages and called GetPackageByAssetPath.

 

How would the new Input System work with DOTS? Is there any additional setup required to move from MonoBehaviours + legacy input to ECS + new Input System?

 

AS you removed the roadmap & timelines from Github, what's the Unity release in which new system finally lands in?

 

According to their Unite Copenhagen roadmap from Sept 25, "New Input System 1.0" lands in 2019.3:
https://drive.google.com/file/d/1h4u_vHmm6ISxwn6-NAlcwOsuvVqb4iyK/view (Slide/page # 59)

 

Is there a recording of the New Input System talk that was at Unite Copenhagen? I didn't see it in the Unite Copenhagen 2019 YouTube playlist.

 

I heard 1.0 preview for 19.3 and verified for 20.1

 

CONGRATULATIONS !!!!!
https://blogs.unity3d.com/2019/10/14/introducing-the-new-input-system/

I lurk here, and have followed this for a while. Good job getting an official release. You guys are awesome.

 

Im little worried after I saw it's codegen solution. Is it possible to add controllers and configure their input at runtime?
Like in simulation racing games, where game doesn't have predefined input devices, and they can be added in configuration, with mapping buttons to actions, even changing filtering, dead zones etc.

 

It is.

You mainly define the Actions and default devices. You can remap any Actions as you wish. You also can define custom devices. But you really need to install it and check the examples (they are on the package manager page) so see it for yourself.
The codegen is for you to not mess up something during development (like Input.GetKey("sihft")) and so on. And also not having strings make it a little bit faster and more prone to garbage.
You can define custom layouts to your heart's content.

 

We had a mishap internally that led to us ending up with a video tutorial using the code-generated workflow rather than PlayerInput (which does not involve code generation and has a much lower getting started cost). This (unsurprisingly) left a number of users with the impression that the workflows of the new system are very technical.

We are in the process of creating and releasing an updated video tutorial based on the workflow described in the Quick Start Guide. There is also information and a demonstration of the workflow in the talk from Unite.

And yes, like @Lurking-Ninja says, all the things you mention are possible.

 

We recently implemented the Input System for one of our assets (sci-fi ship controller) and it was neither difficult or overly technical. The new Input System is well thought out and covers many scenarios that the old one didn't. It is consistent and was also easy to implement with touch screens.
v1.0.0 preview 1 seems very solid and is certainly worth looking at if anyone is just starting out with a new game or project. If devs tried earlier versions, like we did, and walked away, now is the time to come back and take another look.

Unity, it's been a while in coming, but we think it has been worth the wait.

 

Have there been any examples of dealing with multi playerInputs, UI systems and how to manage the multi event system along with the uiinputmodule? We've begun retrofitting the new system into our game and are getting to the point where we be dealing with UIs and it's a bit muddy at the moment. Thanks!

 

Unfortunately, we don't have a sample for that ATM. Overall, I'd say our samples have proven quite inadequate so far and spending some time there is on the list. Here's my personal list ATM of what I'd like to see happening.

1. Add simple touch sample.
2. Simplify SimpleDemo to really be simple.
3. Add sample for local multiplayer setup including UI.
4. Add sample for rebinding UI.
   
5. Add EditorWindow sample.
6. Add sample for input recording and playback.

 

One thing that got me during the setup process was not setting a default Map (Player/UI) on the player input component, that prevented input. I think there should be warning log or message on the debugger when no Map is enabled at the moment. The idea of input debugger is really genius and I think you should use it more for this kinds of trouble shooting.

This is actually one of the things that I have problem with I use ReWired for input. It's really simple and easy to miss, like not having a audio listener in the scene or having 2 of them.

 

Seems like no matter what i do, my input context is only triggering the "Waiting" phase. Anything i'm missing?

Edit: Ahh, on second look of the documentation, it looks like you have to trigger the various phases yourself.

Edit2: One thing that threw me for a long loop was trying to figure out why ReadValue() was putting out a value when I was only triggering Started. I was thinking that it would only send the value when performed was triggered. But using using the built in Interactions, i also see it sending values when you wouldn't expect them to be sent. I'm guessing the only way to properly use interactions is to use the callbacks?

Is it possible to have a ReadValuePerformed()? I guess we could also use .triggered and then read the value as well.

 

So i finally got to work on a repeater interaction and it seems to work for the most part, but i'm running into an issue where when i first press the button, both PerformedAndStayStarted() (one within the timerHasExpired if statement and the one in the ControlIsActuated() if statement) go off. If i change the repeatRate to something like 5, then it works like expected, where the if statement checking for Actuation goes off, then after ~5 seconds, the time expired check goes off. With it at 1 second, i wouldn't assuming a quick tap would set off the timer check, but it does at times. And at 0.5, its impossible to tap quick enough to not trigger it.

Is there something i'm just not understanding about SetTimeout() or timerHasExpired here? Maybe my whole approach is off

Code (CSharp):

1. using UnityEngine.InputSystem;
2.  
3. public class RepeaterInteraction : IInputInteraction
4. {
5.     public float repeatRate = 1f;
6.  
7.     public void Process(ref InputInteractionContext ctx)
8.     {
9.         var defaultActuation = InputSystem.settings.defaultButtonPressPoint;
10.  
11.         if (ctx.timerHasExpired)
12.         {
13.             ctx.PerformedAndStayStarted();
14.             ctx.SetTimeout(repeatRate);
15.         }
16.  
17.         switch(ctx.phase)
18.         {
19.             case InputActionPhase.Waiting:
20.                 if (ctx.ControlIsActuated(defaultActuation))
21.                 {
22.                     ctx.PerformedAndStayStarted();
23.                     ctx.SetTimeout(repeatRate);
24.                 }
25.                 break;
26.            
27.             case InputActionPhase.Started:
28.             case InputActionPhase.Performed:
29.                 if (!ctx.ControlIsActuated(defaultActuation))
30.                 {
31.                     ctx.Canceled();
32.                 }
33.                 break;
34.         }
35.     }
36.  
37.     public void Reset()
38.     {
39.  
40.     }
41. }

 

Correct

Interactions do not currently have an impact on values. They have almost complete control over action phases but they cannot currently impact the input values flowing through the action. In the current setup, this remains entirely the domain of processors. (NB: in the future, we'd like to take a look at how this could possibly be opened up to allow for more flexible setups)

So whenever a callback reads a value, that goes straight back to actual input regardless of what interaction is sitting on the action.

Not necessarily. A Press interaction, for example, can be very useful when used with the InputAction.triggered polling API

Looking at the code, the only thing that catches my eye is that the "if (ctx.timerHasExpired)" block probably best goes as an "else if" block in the Started/Performed case block. But even in its current form, I'd expect it to work.

Overall, if the timer goes off *after* you call Canceled(), that'd be a bug. However, my thought is it's probably more likely that the release does in fact come in slightly after. One thing that may help is looking at the timestamp of the release event using InputAction.CallbackContext.time (will have the timestamp of the event) to find how long the press was according to the input data that's available. If the duration is in fact < 0.5s but the timeout still triggered, it's likely a problem of input update spacing vs input collection.

 

Is there any way to use the type safe generated C# file when using

PlayerInput

? I couldn't find anything in the class. Like right now I'm doing:

Code (csharp):

1. inputActions = GetComponent<UnityEngine.InputSystem.PlayerInput>().actions;
2.  
3. inputActions["Primary"].performed += ctx => input.primaryDown = true;

It's not a huge deal in the grand scheme of things, but having the type safety is a pretty nice feature of the new system. I know that it would be stored as

IInputActionCollection

, but I prefer a single cast to using strings.

 

Not yet but it's on the list for after 1.0.

 

What features/updates are coming next?

 

There's no finalized plan yet. During the current stabilization phase, we're mostly just collecting work that should happen next to then figure out after 1.0 when and where that work will happen.

All I can offer at this point is some general notes/thoughts.

• DOTS/ECS support is very high on the list and likely going to be one of the first things picked up after 1.0.
• Deprecation of the old system is likely going to be a slow burn running alongside new feature development.
• We do have a few bigger feature tickets left of which gesture support is likely going to end up being the highest-priority one.
• There's a good number of holes we intend to fill but it's unclear in what order this will happen. There's multi-display and multi-pointer support, for example. But also stuff like actions missing support for dealing with input on UI actions needing to prevent respective input on gameplay actions. All sorts of things.

But yeah, work going forward to a large degree depends on the needs we see which in turn largely depends on how the 1.0 release goes and what things emerge as part of it.

 

I haven't really checked into it, but was input handling on mobile decoupled from fps?

ages ago I did make a post somewhere where there was an issue that if you reduced the target app fps down to 5fps (for battery life reasons), and then you tried interacting with ugui stuff (you might bump target fps upto 30+fps on interaction for smoother animations etc) there would still be a very awkard delay of touch input just simply not registering at all (like touch scroll dragging or even just button presses) until the target fps was actually 30+fps... has this been solved with the new input system?

 

Would also like to see native input support/tooling for handling mouse/touch stroke gestures .. its about time gestures just started being 'a thing' that was easier to implement and support in games.

 

So I tried the test and got this:



I am pressing and releasing the key as fast as i possibly can!

The logs are coming out in pairs, basically at the same time as far as i can see, but they timing says they're 2 seconds apart

The RepeatRate is at 1 currently, and now i can't manage to only trigger the call once.

Edit:

Actually i thought to try another test. What if i also logged Unity's Time.time to see what i got back...



Not even a millisecond has gone by for the engine, but 2 seconds has passed for the Input System already.

But weirdly enough, after the first button press, time progresses normally for the Input System again and the input is repeated at a ~1 second interval like expected.

 

@Ofx360 Bit hard to see what's going on there. Could you file a bug report with the project/scripts attached? Would like to take a look.

 

Hello.
How long (2020.x ?) can we use old input system? I don't want to rewrite my input code for now.

 

i have no idea what changed (other than updating from 2019.2f9 to 2019.2f10), but i reopened the test scene and now everything is fine! Thanks

 

There's no definitive plans there yet.

Our *thinking* ATM is that given how many existing projects and assets are out there that have code tied to UnityEngine.Input in them, ideally we'd not get into a situation where the old APIs are gone at all. One *thought* is to implement the old API on top of the new system as a separate package made available for backwards-compatibility. Doing that is straightforward but there will be some behavioral changes compared to the current implementation so it may not do the trick for everyone.

But it's hard to say at this point where exactly things will go with the old system and what timeline we're looking at.

 

Yea please don't kill it, just if its not too much trouble keep it in there for legacy code.

For example games that are already on the store and just need regular updates without big content changes. you don't want to rewrite the whole input for them.

 

Thank you for your reply. I got it.

 

Ouch. That sounds horrible. So you will hold on this forever bloating the engine for everyone, making easy to make mistakes for the beginners, just because some random people with a two years old project want to upgrade to 2020.LTS and too lazy to invest two hours (and I think I'm too generous here) to move onto the new input system (why do you even upgrade to a new engine version? I guess the usual l'art pour l'art). Since practically there is no huge AAA projects made with Unity and the old Input system I highly doubt that it would take significant amount of time to upgrade to the new system. And in exchange the engine would lose one more old bloat.

The separate package a little bit better, although the question is: does it worth your time to develop it and maintain it?

What I would do is that support the old input until 2020.LTS and then cut the cord. More than enough time to upgrade old projects (although, again, upgrading old projects is a very bad idea at the begin with).

 

No. The intention is to drop all UnityEngine.Input code from the engine.

It's being debated (like I said, there's no definitive plan yet; just thinking and talking) but I think a good point can be made that given the sheer volume of code out there using UnityEngine.Input plus the fact how relatively little effort it would take to provide a basic reimplementation, it'd be effort well spent.

 

The point about such a change making it easier for beginners to make mistakes is stupid.. most beginners will often goto tutorials that are aligned with the type of project they want to make and what is often not updated very fast.... past tutorials.. hell just go look at pluralsight... they can't even keep up with providing tutorials for new technologies because the sh/t changes so damn much, just had such a problem looking at training that was released early this year.. most of it doesn't even work now because MS changed so much before release that the trainer has to go through and re-record much of the series to update code that doesn't even work less than a year later from when it was recorded.

So countless past tutorials,code snippets and training material will become obsolete. Is nothing more infuriating to a beginner at something than to start something only to find the latest version no longer supports the code and then the time involved having to figure out and diverge onto learning something completely different in order to progress with what you originally set out to learn... for a beginner that is often enough reason to look elsewhere.

So yeah I fully agree with this .."I think a good point can be made that given the sheer volume of code out there using UnityEngine.Input plus the fact how relatively little effort it would take to provide a basic reimplementation, it'd be effort well spent." .. it's updated code for a new system to maintain some important backwards compatibility.

 

Please let's not call each other's points stupid. Debate is good and we all have different POVs. Personally, I think a point that "old input is becoming irrelevant" can be made just as well as the point that "old input will stay relevant for a really long time". In the end, it'll likely all come down to finding some good middle ground.

 

Oh well. I was ignoring you, but today's my lucky day, just became curious who called stupid, well, I'm not disappointed.

Okay, so quick recap, why I said what I said, because apparently I need to write this piece down every single time when deprecation, engine update and whatnot come up.

If you were there more where we help out the newbies, you would know that the very first thing we say to them to follow along the tutorials IN THE VERY SAME VERSION of the engine what they were made in. And this is not a coincidence, it is a very intentional advice because they get confused very quickly if they see something different on the screen.
New engine version = different screen. No matter if the piece of thing works or not.
You do not practice tutorials to learn one specific thing. You do that to get comfortable with the engine, learn where is what and get an overall feeling how things work.
Despite the potential deprecation of the old input system, learning how it works in older versions of Unity has benefits, it makes easier to learn the new one as well.

When you're working on a piece of software you should not update the engine under it. If you do, the Input system deprecation is your least concern. If you have some irredeemable problem where you really need to move to new version for whatever reason, the extra one-two hours of work is expected and it's not big of a deal.

BTW, with the coming deprecation of the built-in pipeline, you will get "outdated" tutorials (again it's not that simple) anyways. Backwards compatibility should be only maintained between the same-year versions. Everything else should be open for question and clearing out the old APIs and other debts should have a very big and heavy impact.

More than a year is more than adequate waiting time. (Since 2020.LTS expected in March of 2021)

[Edit: I forgot one thing: every single stuff you develop into an application or you intentionally leave in it cost a lot of resources. You need to support it, you need to bugfix it, you need to make sure every other component is compatible with it, every test runs properly. Ultimately every bloat thing like this throws another wrench in every other systems the teams develop. Obviously sometimes this is nothing, sometimes it's a big log in between the spokes.]

 

Just to throw my two-cents in the whole "keep legacy V. don't keep legacy" debacle; I would say if it were possible to move the legacy input system to its own completely optional package and make the new input system the default -- I would go with that. It seems to me like it would be a pretty decent workaround for those who want to upgrade without changing their old input code while still moving towards Unity's new input system agenda... Without being confusing for newcomers!

A win/win scenario, really.

 

Yeah I'm thinking an optional package would be ideal. Having both UnityEngine.Input and UnityEngine.InputSystem namespaces has to be little confusing to newcomers trying to do the right thing!

 

I'm not opposed to the idea of moving the legacy input into a package.

But I just wanted to point out that, assuming the new input system is developed enough to fully replace it, removing legacy input entirely as of 2021.x doesn't seem very unreasonable to me. This means it will still be in 2020.4 LTS which is expected around March 2021 and will be supported for two years after that.

So in this scenario we're looking at around March 2023 at the earliest before the legacy input is officially dead. That's about 3.5 years from now. And if that's too short of a timeframe then just bump that initial cutoff date by a version or two (2021 LTS or 2022 LTS) and we're looking at 5+ years to prepare.

In the meantime, tutorials are already starting to pop up on how to use the new input system. I think that by the time the loss of the legacy system could become an issue, there will be plenty of new content and tutorials on the new system.

When I was first getting into Unity, the Tornado Twins were a pretty popular resource for learning the ins and outs. These days they are no longer relevant, even though all their videos are still there to potentially confuse new users. Yet you don't see people complaining on the forums about how confused they are and what a terrible experience they've had because they wanted to learn Unity this month and tried to do so through the Tornado Twins videos which are out of date. Instead, people just watch Brackeys videos, or other modern and up to date sources.

 

I'm just wondering can anyone explain what the usages tab in the binding path list is and how I use it? For example in the defaultinputactions under the ui action map there is Submit [Any] and Cancel [Any], but they don't seem to be auto binded to any keys. I've checked the documentation but I don't see anyone about this.

 

We still need to document this properly. Overall, the mechanism is still sort of in its infancy and will probably evolve still.

The idea here is to identify controls by their intended use rather than their names. For example, a given device may have a control that is commonly used to trigger a "submit" style of command. It would indicate that by assigning the "Submit" usage to the control.

Assignment of usages is currently handled at the device level. For example, the Keyboard device by default assigns the "Back" and "Cancel" usage to the escape key whereas Gamepad assigns them to the A/circle button by default.

By having a binding that binds to a specific usage, it's possible to look up controls regardless of what they are called on a given device.

Unfortunately, ATM the only way to see how a specific device assigns usages is to browse through the layouts in the input debugger or look at the code. Ultimately, that should hopefully become clearer in the UI and docs.

 

Ah! Great! That was what I had assumed but when it didn't respond to any of the obvious keys on the keyboard I was confused and decided to ask. Thanks for reply! I think it's a great idea!

 

You may have run into a bug there where bindings that weren't assigned to a control scheme didn't get enabled as part of other controls schemes as they should. This has been fixed on the develop branch and will be part of 1.0.0-preview.2.

 

Ah okay! Again, thanks for the reply!

 

I'm finding InputSystem with interactions to be very inconsistent. I need to capture the cancelled event for a composite binding with a single modifier which works... as long as there is no Hold interaction. Adding the hold interaction allows the action to be performed but the action is never cancelled.

Also, chiming in on the "hold a button down" discussion from a ways back... we need a proper way to know how long a button is being held down if we are going to have hold interactions. Especially if we want to bind those timings to UI elements. I have my own solution that functions but I feel like it should be simple out of the box. I'm hoping this still gets some attention.

 

If the hold isn't canceling when all parts of the composite binding are back to default state, that'd be a bug. Please file a ticket with the Unity bug reporter and we'll have a look.

It's on the list for after 1.0.

 

Announcement: We're dropping the preview label.

As part of the process of the input system becoming a verified package with Unity 2020.1, we're dropping the preview label. This means that we will be releasing 1.0 of the input system shortly.

Note that this does not otherwise impact what we're doing. Same plan. We have a sizable amount of known issues at this point and we will keep fixing bugs and improving docs in 1.0 throughout the Unity 2020.1 alpha and beta cycle. Dropping of the preview label at this point is mostly a technicality in the release process.

In other words, this is not the final package to ship along with Unity 2020.1.

Also, no change in our support for Unity versions. While the package verification process is targeting 2020.1, 1.0 of the input system will continue to support 2019.

 

I don't get it. Why are you dropping the preview label if it's still not ready? Everything I read in this forum makes it sound like the new input system is still in beta at best. And a product in beta with "a sizable amount of known issues" is not ready to come out of beta, IMO.

Why not also drop the alpha or beta label for Unity 2020.1 right now as a technically in the release process while you're at it? You can still fix bugs and improve docs in the meantime until 20.1 launches "for real" later.

Obviously the previous paragraph was not a genuine suggestion. It was just a way to point out the absurdity of intentionally calling something a final release before the actual final release.

You still have close to 6 months (or more) before 2020.1 launches. Please don't mislead people into using the new input system by removing the preview label when it's not yet ready for mainstream use.