Input System Update

@Rene-Damm - I've thrown a bunch of new issues onto the github, with an updated min repro project. Seems like 0.2.6 may have broken a few things related to button actions, as PressAndRelease no longer works correctly with or without the continuous flag set.

 

Hey everyone,

Quick general update here.

We've recently released 0.2.6-preview. Starting with that version, we're no longer compatible with 2018.3 and have moved on to 2019.1. It's something we really would have liked to avoid but unfortunately, with the timing not working out the way we hoped it would, supporting the 2018.3 LTS release became unfeasible :/

Overall, in this final phase, we haven't made progress quite as fast as we were hoping. A number of things that we didn't anticipate showed up and some stuff took longer than expected. The usual stuff in the last 20% of a project We've added additional manpower and things are looking good. We'll probably slip a bit with our initial target delivery date, though.

Aside from fixing bugs and problems all around, we're still in the process of finalizing the workings of some of the mechanics and some of the UI. Especially for actions. Some random WIP stuff: control picker structure is confusing and unclear so we're trying to come up with something better. Key naming and binding is confusing when physical and logical keyboard layout don't match (i.e. with anything other than a US keyboard layout) so we're trying to take steps towards something better (@ZoidbergForPresident) and we're probably not there yet. We're thinking of making the "initial state check when enabled" behavior a toggle setting on actions with the default being for it to be off (@Heimlink).

If you're using PlayerInput

Code (CSharp):

1. // Find player (if any) paired to gamepad #0.
2. var player = PlayerInput.FindFirstPairedToDevice(Gamepad.all[0]);
3.  
4. // Go over devices for each player.
5. foreach (var player in PlayerInput.all)
6.     foreach (device in player.devices)
7.         /* ... */;

If you're using InputUser directly

Code (CSharp):

1. // Find user paired to gamepad #0.
2. var user = InputUser.FindUserPairedToDevice(Gamepad.all[0]);
3.  
4. // Go over devices for each user.
5. foreach (var user in InputUser.all)
6.     foreach (var device in user.pairedDevices)
7.         /* ... */;

 

Thanks @recursive. And yup, seems like indeed the refactor of action stuff has introduced a couple of problems. We're digging into them.

 

I'm a bit confused with the GitHub road map. It says:

0.3-preview - Touch

- Documentation

- Move to 2019.1

Yet the current release version is 0.2.6 and it already requires 2019.1+ (based on GitHub page)
Also, it says that the release version should come with 2019.2 which probably will be out this summer but the GitHub branch seems to be nowhere near completion.
Can you guys update the roadmap info in Github readme?

And another question,
We're planning to start our new project once the 2019.1 is out of beta. We want to use the new input system. I understand that it's still in preview but it has matured quite a lot, so do you think it is safe to use it? The project will take a year at least, will input system be ready by that time? Also, are you expecting any drastic changes to the codebase which might break things?

Thank's in advance.

 

Yeah, the move to 2019.1 happened sooner than expected. Or, the touch work is happening later than expected. The latter is what has kept us on 0.2.x for now. I should update the roadmap.

Reaching verified status with 2019.2 is still the goal.

IMO it depends a bit on what you need from it. Some parts are more usable than others. Touch is lagging behind so a mobile only title may be a bit of a bumpy ride ATM. Gamepad and desktop should allow for a generally decent enough ride at this point.

The plan is for it to be.

No, nothing of that kind is expected at this point.

 

So the solution we finally settled on looks something like this. Basically, when you go into "Keyboard", it has an extra level where you decide whether to bind by key location or by mapped character. Also, when binding by location of the key, any discrepancy between the US reference layout and the local keyboard layout is pointed out in the control picker. And when binding by mapped character, of course the binding sticks with where the character is found on the player's keyboard layout (so binding to M binds to wherever M is on the player's keyboard; and if it isn't anywhere, it binds to nothing).

Does this make sense from your point of view?

 

Hi,

Thanks for everyone's hard work on this new system, looks really exciting!

I'm just getting things up and running with Unity 2019.1.0b10 and I'm getting quite a few errors when bringing in the Demo folder from the github repo. Are the demo's working with the latest Unity 2019? I can't seem to see anything working yet.

Import error on the "DemoControls.inputactions" file, none of the demos will run without this.

Also, when setting up a gamepad, there's button in the UI for automatically detecting what input is being triggered. This doesnt seem to work for me at all. I've tried it with a Keyboard, as well as with an xbox 360 controller (windows 10). Also, I didnt see a way to select the left or right stick manually either, so I'm probably missing some important information.

Thanks for any thoughts or directions!

All the best

 

I tried again from a completely new empty project, and some things started working!

There must have been something in my project preventing anything from working, also the UI has a lot of errors or stops working quite frequently. Restarting Unity seems to help.

Not having a lot of success so far. Events arent being called, demos arent working...

Thanks for any ideas!

 

In the future, try just wiping the PackageCache and ScriptAssemblies folders in your Library. This usually fixes weird package change errors/behavior for me.

 

I think this helps yes. Good job. I'll have to look into it myself though.

But just another question, if memebers of the dev team use different keyboard layouts, how will this play out?

Maybe choosing a "default layout" for the project then the dev env would adapt on that depending on the currently used layout?
I dunno, maybe it's a bit much but it'd be like perfect, making the layout less important during dev.

But cool, thanks for looking into this.

 

See my reply on GitHub.

In the control picker, the members would see different hints being displayed when selecting by key location and different options being displayed when selecting by text character. However, it would really only affect the options presented in the picker UI.

We could generate options in the picker for every possible layout or have configuration settings for the layouts that are to be used (as you suggest) but to me it seems that's adding quite a bit of complexity for not a great deal of value.

In case the picker doesn't have a particular option available, you can always switch the path into text mode (that "T" button) and change it to whatever you want.

 

Hello @Rene-Damm ,
Got this error after exit PlayMode
Unity 2019.1.0f1 and InputSystem 0.2.6

Code (CSharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. UnityEditor.SettingsProvider.Repaint () (at /Users/builduser/buildslave/unity/build/Editor/Mono/Settings/SettingsProvider.cs:123)
3. UnityEngine.Experimental.Input.Editor.InputSettingsProvider.ForceReload () (at Library/PackageCache/com.unity.inputsystem@0.2.6-preview/InputSystem/Editor/Settings/InputSettingsProvider.cs:348)
4. UnityEngine.Experimental.Input.InputSystem.OnProjectChange () (at Library/PackageCache/com.unity.inputsystem@0.2.6-preview/InputSystem/InputSystem.cs:1690)
5. UnityEditor.EditorApplication.Internal_CallProjectHasChanged () (at /Users/builduser/buildslave/unity/build/Editor/Mono/EditorApplication.cs:242)

 

I Change to new Input system, and UI dont worked. I press mouse to button. No worked, no hovered ((
How fix ui ?

 

Being unable to support 2018's LTS channel sucks, but, THANK YOU for communicating it in clear terms. I'd prefer to know now and plan accordingly, rather than find out after the fact.

Actually, I'd really prefer if every preview package clearly stated:

1. "Planned" target compatibility for 1.0 production release. (2019.2 for Input System)
   
2. "At-Risk", "Unknown", or "Possible" target compat. for 1.0 production. (Maybe 2019.1, now?)
   
3. Explicit non-compat. for production. (2018.x and older now, for Input System.)

But frankly, just knowing item #3 is useful. On that note, where could I send this kind of feedback that would get heard?

For devs looking to adopt pre-production packages, it's far less important that Unity's package teams promise unrealistic version compat. but critical to be able to plan accordingly.

 

how did you fix it?

 

Upgrade to Unity 2019.1.0f1 and Input System 0.2.6. That is working for me.

 

Hey I've started using the Input System for a local multiplayer game. I'm not quite sure how to even get multiple control schemes working without duplication.

What's the best approach for local multiplayer character input setup using the new input system at the moment? Without using PlayerInput as I find it overly big.

 

I've tried using the package on GitHub and I get errors on import with 2018.3.

 

Can you post your errors? There are a couple known errors that have work arounds.

 

So took a bit more of a look at this new input package... the demo stuff from github is a little broken though, so package warnings about "
Package missing for Virtual Reality SDK Oculus. Please add the Oculus (Standalone) package using the Package Manager Window.
Will attempt to enable None instead."

is there a simpledemo where the keyboard/mouse/ generic gamepad ...and some prefabs for decent touch input controls work?

And is there a debug panel? to see live input of key/gamepad/touch inputs?

Another thing I noticed is the workflow of doing the input actions and then saving the asset, where it's compiled and all your scripts used that compiled version.. it doesn't really allow for any runtime setup of controls and actions via that input actions gui, like you wan to edit the 'Fire' actions and add additional keys while the game is running? ....it also just makes workflow a bit janky in the editor.. ie you have your simple movement script component, but instead of having some sort of references to the scriptable object input actions file where you can directly open the input actions gui for it and edit it, you don't get that.. instead you have to go look around/search for it in the project window, then save it etc... I don't mind the compiled setup for build releases... still i might be missing something and it is possible to have what I'm looking for.. but the demo stuff isn't really showing it... hopefully better examples/touch input prefabs we can use coming soon.

Other than I like it and it's enough for me to start using it for keyboard/mouse/gamepad, recently tried rewired and honestly I don't think it would take much effort to make this the better way forward. Just want some better example of touch screen stuff as I couldn't get the OnScreenButtonScene to work.. at least not in the editor with mouse being used to touch the controls.

When is the next update coming? is it getting to complete status soon?

 

Would also be nice to have an example ugui scene that allows player inputs to be changed, one of the generic boiler plate examples that could be dropped in or picked apart for further customization.

 

Since I hadn't heard back about this and haven't seen a fix roll out, I did some quick investigating and have a dead simple way to reproduce it:
- Create a new project (i'm on 2019.1.1f1)
- Turn off "Show Splash Screen" under Project Settings->Player->Splash Image
- Install the the Input System package (0.2.8)
- Set "Active Input Handling" to "Input System (Preview)" under Project Settings->Player->Other Settings (will restart Unity)

That's it! Launch the game and notice that the cursor is stuck as the spinning progress indicator. So really, it seems to be just the combination of those two things: Turn off "Show Splash Screen" and change Active Input Handling from "Both" to "Input System (Preview)". If either Show Splash Screen is turned on, or Active Input Handling is set to Both, the cursor behaves normally.

I guess no one else has those two mutual settings, which explains why no one else responded or has mentioned this issue. Anyway, hope this helps you all on the Input System team to fix the issue.

 

Double checked. This is happening for me as well. After build and startup the game stuck with loading cursor.

It's more likely people does not have full fledged projects with the new input system in the phase of build-hand-tests.
I don't start to build-test my projects until it's getting into the polish state. (Which means I need to test the connections between scenes, menus, etc)
Input system is not in the state of shipping in prod, so it's kinda' understandable no one noticed until you.

 

I read here that there is a polling API for the Input Actions but it doesn't seem to be the case for input preview 0.2.8. Is anyone else facing this issue?

 

@Rene-Damm Is the new Input system independent of frame rate (on mobile) ?

 

There isn't a polling API yet. I don't know if it's just not implemented or completely cancelled - you'll have to ask @Rene-Damm for that. There's at least

InputAction.state

that tells you if an action is cancelled, started, preformed, etc, but you can't directly get the value from an action.
I'd very much like it, since it's much more like the legacy input system which makes migrating much easier.

While I'm on the topic, could it be possible to have an option similar to continuous, but have it fire

preformed

all the time instead of

preformed

and

cancelled

? This would be a minor improvement for sticks, since subscribing to both is a little tedious and annoying.

 

@Rene-Damm Hi, we are starting a new (small mobile) project and I am eager to give new Input System a try. Is it already possible to start using touch input? (I saw you are still working on it, but not completely understood if it is at least possible to start with it). Thanks!

 

Not only does it make porting easier but, in my use case, I want to check if a key was pressed in a certain frame and, if there was a FixedUpdate in that frame, I want to do that after Physics simulation to see if the player was grounded. With the event API I have to keep track of everything using booleans and I even have to setup a coroutine to reset the boolean at the end of the frame...

 

Code (CSharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. UnityEditor.SettingsProvider.Repaint () (at /Users/builduser/buildslave/unity/build/Editor/Mono/Settings/SettingsProvider.cs:123)
3. UnityEngine.Experimental.Input.Editor.InputSettingsProvider.ForceReload () (at Library/PackageCache/com.unity.inputsystem@0.2.6-preview/InputSystem/Editor/Settings/InputSettingsProvider.cs:348)
4. UnityEngine.Experimental.Input.InputSystem.OnProjectChange () (at Library/PackageCache/com.unity.inputsystem@0.2.6-preview/InputSystem/InputSystem.cs:1690)
5. UnityEditor.EditorApplication.Internal_CallProjectHasChanged () (at /Users/builduser/buildslave/unity/build/Editor/Mono/EditorApplication.cs:242)

I'm also getting this error with InputSystem 0.2.10 and Unity 2019.1 and 2019.2 beta.

Update:
Quickest way to reproduce this in a fresh project is to install Input System along with Quick Search, then drag and drop an empty GO from Hierarchy to Project Window (attempting to create a prefab).

 

I'm trying to get things working in 2019.1 with v0.2.10 of the Input System.
One thing I've noticed is that

Code (CSharp):

1. using UnityEngine.Experimental.Input;

needs to be changed to

Code (CSharp):

1. using UnityEngine.InputSystem;

for things to work. And

Code (CSharp):

1. InputActionAssetReference

should be changed to

Code (CSharp):

1. InputActionReference

I think!

 

Has anyone managed to get the latest version of the Input System working? @Rene-Damm it would be great if you could include a simple demo scene of a third person character controller working with the latest version Input System, for reference. Or is there one I've missed? Keep up the good work!

 

You can take a look at my repo.
I try do keep up with the latest preview packages (DOTS and NEW INPUT) . Granted it lack documentation for now but things changes quite fast so it's hard to get things stable enougth to start one. Also the way I do thing migth not be the "right" one but as long as it works for me it's good .

 

Awesome @WAYN_Group . I got it partially working with your repo with just a few tweaks. The keyboard works now but I'm not having any luck with the iOS gamepad (SteelSeries Nimbus) on my mac.

EDIT: getting closer. I've got some input from the Nimbus, but it's being picked up as HID: Unknown Nimbus Gamepad instead of as a Gamepad or iOS gamepad, so doesn't inherit from those mappings. How can I force my Nimbus to be correctly recognised by the Input System?

 

Sorry for now as you can see I only used keybaord and mouse. I did it like that expecting I would only have to change the input mapping using the listener feature to switch to a game pad or other but did not actually test that yet.

 

• May/June 2019: 1.0-preview

errm guys looking at that roadmap... where is 0.3? or 0.4 I'm mostly looking forward to that one actually..

 

Is this template still available? The input system is not correctly recognising my SteelSeries Nimbus, one of the main iOS gamepads.

Cheers

 

I am unable to get the input system to recognize down or left on the joysticks of the gamepad. Is anyone else running into this issue? I am using Unity 2019.1.2f1 and 0.2.10 of the input system. It is like Unity as a whole is not recognizing the input, because even on the listen function in the window, it is not working.

--Update--
Appears to only be the Xbox One controller. PS4 works fine.

 

[QUOTE="While I'm on the topic, could it be possible to have an option similar to continuous, but have it fire

preformed

all the time instead of

preformed

and

cancelled

? This would be a minor improvement for sticks, since subscribing to both is a little tedious and annoying.[/QUOTE]

I too want this. For touch, I want to have state "started" to fire when I put my finger down, and no state "canceled" until I lift my finger. Continuous keeps firing "canceled" whenever I stop moving my finger for a delta/x binding

 

Can you add a comment here: https://github.com/Unity-Technologies/InputSystem/issues/624
I'm trying to get this resolved and figure more comments might help get the issue more attention.

 

@TimNedvyga @Creepgin @Rene-Damm I've also consistently being getting this error. I'm in 2019.2.0b5 using the develop branch of the Input System.

 

@Rene-Damm Any chance you guys could update the docs in develop to include the new touch stuff you guys have added in that branch? Pretty please.

 

So, this project is another dead-on-arrival? When it comes close to the release, dev becomes radio silent, either by the dev quit the job or unable to comply.

When Unity is doing something, everything becomes a Rocket Science and it is a never ending mess. Look how many projects are under the preview. So frustrating and Unity is a cancer causing.

 

The more Unity gives people alpha/beta/preview access, more people complain about unfinished systems. I don't think I'll ever get this, you'd think people would be happy to get early access to feats and be able to give feedback before everything gets finalized.

As for input system, it's development is very much active as you can see on the commits on the github: https://github.com/Unity-Technologies/InputSystem/commits/develop. Do note that there probably won't be much action on regular feats this week as Unity's yearly Hackweek is apparently on now.

And what comes to a lot of things being in preview: package system itself is relatively new, many thing went from release on asset store into package preview which doesn't indicate that Unity just worsened the assets but that it is indication of different level of integration that requires additional QA passes and iterations. Last year when package manager was new, almost every package was in preview. That is not the case this year anymore and there are still many packages to leave preview status during the Unity 2019.x cycle.

If it pains to see the things in preview, just ignore beta & experimental forums and preview packages and be happily surprised when things land few years later And yes, I know input system has been in works for a long time, including starting the work from scratch at some point. Similar thing kind of happened to the UI system and nested prefabs but you can hardly generalize it to everything Unity is doing.

 

I can summarize Unity in 3 words, Incompetent, Lazy, and Stubborn; the worst combination you can find.
I'm not just talking about the new input system but in general. They should stop doing many events that provides very little values, instead, get their acts together and transform.

 

ROFL. You're welcome for the engine of your choice.

 

Unfortunately, I'm stuck for the current project. Wish I can go back revert the choice.

 

Well, I wish you prosper and a ton of clients with the same attitude what you're showing here on the forums.

 

Super n00b question but... i'm currently using the latest build available in package manager (2.10-preview). I'd like to instead use the latest version from the develop branch as it has fixes I want to use. What's the correct procedure to use that instead?

 

either clone the repo or download the branch directly, the actual input package is in: Packages/com.unity.inputsystem and then either:
- give package manager ref to the folder where you have this folder (there's + symbol on the package manager top corner)
- or just copy/symlink com.unity.inputsystem so it exists in your own projects Packages -folder

former adds a file ref to your packages/manifest and latter just works without any manifest changes as Unity is set to poll for local packages on that folder automatically.

 

Hi everybody. Is this worth using yet for a project using Vive?

I'm working on a new Cross-Platform Input Module for AR/VR.

As I got started on it, I became aware of this new Input System. It seems great conceptually, and appears to solve a lot of the issues that have forced me into the Cross-Platform Input-Module business in the first place.

But, I've not gotten it to receive Vive Input, and it seems a little premature maybe to attempt to incorporate this new package into a real project. Then again, I'm unfamiliar with how it works, and it's possible I'm doing something wrong.

I'm using Unity 2019.3.0a5 and a Package generated from the "develop" branch of the GIT Repo https://github.com/Unity-Technologies/InputSystem.git.

I've tried most of the obvious Option Binding options available, which are somewhat nebulous.

In the Input Debugger, it lists the HTC Vive in the "Unsupported" category, but with several Device IDs with the "HTC" Prefix.





I can get mouse and keyboard input, but I haven't been able to register an event for anything generated from the Vive or the Vive Controllers.

Is this worth pursuing, or should I check back in a few months from now?