Input System Update

I'm seeing this error pop up after i updated to 0.9.4



Seem like the DefaultInputActions might have "ScrollWheel" not set to "Pass-Through"

It's not stopping me, but it pops up a lot when i'm navigating the editor while in play mode

 

Can reproduce the problem. Looking into it. The control doesn't seem to be unaligned on the device so looks like a bug in the HID fallback code.

Thank you for pasting the descriptor.

Could you post me a screenshot of the full control tree as seen in the input debugger? (if necessary, two separate shots)

Yup, we missed that one. Fix incoming and should be in 0.9.5.

 

Sure, here's the full tree. (with a tiny visual edit: alternating BG line colors for easier readability)


Aside, I found out through the github that "Run in Background" was apparently removed from the new Input System some months ago. Are there any plans to bring it back, or is that it?

 

any tips on explicitly assigning the controllers unity recognizes?

I found playerInput.controlScheme, but idk what to set it equal to.

IE: if unity recognizes 10 game pads, and you wanna assign 2, you can say

Code (CSharp):

1. PlayerInput playerInput;
2.  
3. void SelectGampad(string s){
4.   playerInput.controlScheme = s;
5. }

And run that script on 2 players, changing s so they both don't have the same controller. The string getting passed through of course being the name of the Control Scheme you set in the (input actions) window. I looked at the documentation and none of it makes any sense to me. I'm hoping somebody here can explain it simply, if possible.

 

Thanks for this! Had to build my own device layout. Little tricky to figure out offsets and bit sizes, but all working now

 

Can't find a way to enable InputSystemUIInputModule.
Pulled lates 'develop' branch, replaced Standalone Input Module on EventSystem object, but no reaction for mouse clicks on buttons at all.


Also I have a player with PlayerInput component, but UI InputModule field in it I left blank.


My actions look like this:


Though the debugger still showing all UI actions bound to User#0, instead of being separate actions:


Disabled legacy Input system, handling updates only in Dynamic Updates.

Do I need to change anything on buttons itself, to handle new Input System clicks?
Do I need to add PlayerInput to the UI objects?

UPD: temporarily disabling PlayeInput on Player object fixes the UI, buttons become clickable. Setting UI InputModule field to 'EventSystem' object doesn't help though. Both PlayerInput and InputSystemUIInputModule configured to use same Actions asset.

 

Hey @rizu, could you give this PR a try and see if the G25 Racing Wheel comes out alright? There's one more thing with HID axes that I have on my fix list but at least the X/Y control of the device should hopefully come out alright now and there shouldn't be an exception anymore.

 

Thanks, I'll try to test that first thing tomorrow if all goes well, I can also try to find older Logitech Momo wheel and test that one as well as you'd expect logitech to use similar setup for it and also try some old directinput gamepad I got). Btw found the PR: https://github.com/Unity-Technologies/InputSystem/pull/806

 

@Rene-Damm actually couldn't wait, so tested my G25 with this. Now the device is found properly by the input debugger + I can bind all buttons and axis on the wheel itself, I don't have gear stick or pedal attached so will test those later. I also quickly tested my old Logitech Rumblepad 2 (DirectInput gamepad) with and without the PR and I think this PR broke the right analog stick on it, is this what you meant by the earlier comment on HID axes?

Without the PR, I get analog inputs on both sticks, after it I get nothing on right thumbstick when I try to bind it (left thumbstick, buttons and dpad do register on both). Logitech Rumblepad 2 Device Description here from latest develop branch where things still worked (without this PR).

Edit: With the PR, I DO get events on the input debugger for the right stick, it's just not registered anywhere else (and input debugger doesn't show the stick itself or it's values like it does for the left stick).

Edit #2: since the HID axis issue is probably expected on the version I tested, I'll wait until the further additions arrive before hooking up the pedals (as they need additional axis anyway).

 

@rizu Doh, sorry for forgetting to actually link the PR

Thanks for giving it a shot. The HID axis issue should be fixed now in the PR. Was a stupid oversight on my part. Fixed and new test in place.

Gave it a shot and it looks like it's coming out alright. Right analog stick axes should be coming through fine again.

Overall, from what I see so far, the HID fallback is doing a decent job now. There's still devices where it screws up because the HID descriptors are in part simply bogus but oh well. My hope is that over time we find some workarounds to deal with the cases but hopefully, what's there now does a decent enough job for a 1.0.

 

I saw the additional commit on github and tested input system with it. Now both Rumblepad 2 thumb sticks work on this. Also tested this on my Thrustmaster TX servo and it works, altho some axis have weird mapping (I get bunch of options on the listen if I hit brake pedal). This is probably easy fix on the custom HID device tho.

I'll try to hook up the pedals to my G25 next and go get my Logitech Momo wheel from the storage to test that one as well (these are all the Direct Input devices I have around here).

 

Checked the momo wheel with pedals, everything showed up just fine

For the ref if these help anything, here are all the device descriptors from all my direct input devices:
Logitech Momo Racing
Logitech G25
Logitech RumblePad 2
Thrustmaster TX Racing Wheel Ferrari 458 Italia Edition

 

As for input rebinding, I just tried the tank demo (which didn't work out of the box on github btw). Just like the listen feat on manual binding, I was expecting something like this on the tank demo as well:


these all are using the same input device (Thrustmaster TX), Gas and brake are it's gas and brake pedals, fire is right paddle shifter and turret is left paddle shifter. Everything basically maps using different style descriptions for the buttons/axis here now, which is not something you'd want to see so I guess there's a lot of manual work involved trying to clean these up so that you can actually put this type of menu on your game.

While I could fix this specific device using custom HID mapping, I can't possibly do that for all PC input devices and I doubt this device is some exception here so some better solution needs to be done.

For example, I'd rather get just button 1,2,3 etc for buttons and Axis X, Y , Rz etc for the rest if it's unknown device, rather than some generic guesses what these things might be (as they are totally wrong by their descriptions anyway, stick/Y [Joystick] doesn't tell me that it's my wheels brake pedal, or that Trigger [Joystick] is my paddle shifter button).

Edit: I think I can still filter these manually myself, so it's not a showstopper, just something to be aware of.

Also worth noting that that tank demos rebinding menu kinda breaks once you bind input that's not 0 value on idle. In such case the menu focus moves unless you hold the pedal on the middle position after you've put binding for such axis . On many steering wheels, you get either inverted axis or full range for the pedals, this Thrustmaster wheel is one of them (each pedal has -1.0 to 1.0 axis where -1 is pedal up, and 1 is pedal down).

 

There's a change to InputControlPath.ToHumanReadableString() that's going into 0.9.5 which is meant to address this. We'll probably still have to tune some of the display names in the system but ToHumanReadableString() will produce much nicer output now.

The TanksDemo rebind screen will probably switch over to that.

 

I seem to be missing CallbackContext in the Event Invokations. Did I forget to enable something? Thx!

 

Given the workaround and looking at the shot, it seems that there's a problem in the initialization order which results in none of the UI actions resolving successfully to controls. Could you give this a try again with 0.9.5 when it comes out? There's some PlayerInput fixes in there that hopefully resolve the issue. If not, we'll have to dig deeper.

////EDIT: Actually, now realize you said you're using latest develop. So you probably already got the fixes I mentioned and they didn't solve the issue. Could you file a ticket on GitHub for this? (in case you haven't already)

Can reproduce on 2019.3.0b1. It's fine on 2019.1. We'll have a look.

////EDIT: After further testing, I see the same problem even with other Unity Events. E.g. if I add a uGUI Slider, it's onValueChanged event seems to be similarly broken. Looks to me like something in 2019.3 got busted there. We'll go raise it internally.

 

Been looking at this today, I can't seem to find any nice way to get the rebind to point to just:

- device + button or axis

This is super bare bones requirement IMHO though. Right now it looks like I'm forced to get some abstractions for some rebinds (which doesn't hint at all which device is being rebinded) and some of the rebinds do get the device specific ones (like seen on my example image). Looking at current code, it feels like this is something that should be changed on the input system's side as I don't see the device data on the bindings itself nor I see a way to cherry-pick the found binds myself (in manual listen option, I can see multiple selections where last entry is usually the one I want - but sometimes it doesn't even give this device specific option at all - and now the rebinding picks the first option). If I missed some obvious way to do this, please tell me

I haven't yet tried this with multiple xbox controllers at once, does the current binding setup make a difference between two simultaneously connected identical controllers (realistically we are now talking about xbox 360 or xbox one controllers)? I need this for split-screen mode but haven't yet tested what happens as I need to find my two wireless x360 controllers first.

 

Yo, seem to be a problem with WSAD inputs (with right mouse button) being sent to Game view while Scene view is being navigated in during play mode. Any fix?

 

Is this system already ready to be used for Touch Input?

 

Just wanted to note that I'm still encountering this in 0.9.5. I was slightly hoping that the new HID axis fixes might affect my own HID device issues, but I wasn't that lucky.

 

You'll have to do some manual massaging of strings to get it in that order but as of 0.9.5 doing

Code (CSharp):

1. var str = InputControlPath.ToHumanReadableString(myBindingPath);

Should give you a string in the form of "<control name> [<device name>]" with the individual names matching display names as best as the system can figure it out. Note that this is an entirely static process ATM. It only takes the registered layouts into account and won't look at devices currently in the system. Also, because of the flexibility of the control path language, the method won't always manage to figure out nice names.

But say you have a binding for "<XInputController>/buttonSouth", you should get a string of "A [Xbox Controller]". And if you pass OmitDevice, just "A".

Pretty sure there's still quite some way to go to make this adapt flexibly to a lot more scenarios but the basic mechanics should hopefully be covered. Past 1.0, the mechanism and out-of-the-box setup hopefully sees some more maturation.

The binding paths will not usually reflect this except if there's an override to a specific device -- something the system will not create by default (the thinking is that device pairing is more flexibly/easily handled on top of actions rather than by changing binding paths).

If non-EditorWindow code receives input with the game view not being focused and with "Lock Input to Game View" turned off in the Input Debugger options, that'd be a bug. Would like to know more details in that case.

Suggest giving it a go and seeing how it fares for you. Bindings for touch should work as should the new EnhancedTouch module that aims to provide a better touch polling API compared to UnityEngine.Input.touches.

Yeah, the fixes were all to the HID fallback which in your case is bypassed.

Took a look at the screenshot you supplied but unfortunately nothing jumped out. If all the controls in the input debugger work as expected but not elsewhere, would be good to have a repro project in some form.

 

I had no idea "lock input to game view" even existed. I simply queried current keyboard and that's all. I guess that would be a nice element to add to the documentation in a visible way.

It is also IMHO not intuitive for that to be a debug option. I can see why you did it but the default input behaviour in Unity would probably want that on by default, or at least solve the tools/game/testing overlap in a documented or more visible way.

It's a new-user gotcha with no clear indication it was occurring or where to fix it

Also it didn't fix it:

My code:

Code (csharp):

1.  
2. var kb = Keyboard.current;
3. if (kb.aKey.isPressed)
4.  

etc... absolutely noting else in input is touched other than creating the asset for it in project settings.

Unfortunately I have to enable "Both" as input option because HDRP crashes due to it's sad and ill-contrived debugger that I can't get rid of. Not sure if that's a problem.

It's annoying though because I use WSAD to test my little man running around in scene view, but unlike regular Unity input, it just doesn't capture the SCENE view unless I click it repeatedly and do some chanting or something (so I can move editor camera to a new location to observe bugs or behaviour as you do).

*note* : I do have game view and scene view windows open visible at all times. Is that a problem?

 

The tank demo already uses that exact same code you just posted: https://github.com/Unity-Technologi.../Assets/Scripts/UI/ControlRebindingUI.cs#L132

And it provides results I posted here. I can't ship with setup like this as my target audience will face the same totally wrong names for mappings on their wheel controllers and less than ideal setup for the gamepad even, I need some way to clean this up as otherwise it's just going to give poor impression of the whole setup.

I'll see if I can figure out some way to modify the actual input systems rebinding code to provide the results I need (I looked at the API and couldn't see any way I could fix this without digging in deeper in the actual package side). But I also need to consider that other 3rd party input systems do this nicely out of the box already (which is something you'd expect from Unity's new input as well ).

Oh and I don't see that [Xbox Controller] tag with the tank demo rebinding on xbox one controller either, it always picks the generic [GamePad] option instead of showing the [Xbox Controller] one, which is part of but not the whole problem.

I don't get it tho, I don't feel I'm asking for too much here, I'd just want some ID of the device I'm binding with and the button number or analog axis without any fancy names. This is super bare bones and should be something devs should get instead of trying to abstract this in some hardcoded setup which is more likely to fail (like happens here now).

Do note that I get the generic approach for other than desktop computers as you have less things that may go wrong then.

 

Just to be more clear: I have no issues with fancy names on xbox, ps etc controllers, they are nice but I'd also not want some abstractions drawn from the hat when the actual device is not known.

Right now I get Trigger [Joystick] for one wheel button, device specific Button 2 for another, I get device specific Rz on one axis but stick/Y [Joystick] on some other axis. For user, this appears as a totally random thing.

 

Hi there I have been looking everywhere for a solution on how to do local multiplayer for gamepads with the new input system.. I'm currently in the middle of a school project so it's really important! So far I have found a way to store all the current gamepads in a list using Gamepad.all; but I don't know how to assign one player to one instance of my action map could someone please help! It is greatly appreciated thank you!!!

 

Hi everyone. I've started to do some stuff with the new input system. So far it worked fine for things like mouse and keyboard actions etc.

Now I started to implement some touch controls and I have some issues with it. My current problem is that I can not figure out to get proper values for touchscreen delta. You can see my setup here...

I want to get the touchscreen delta from the 'TouchTest' action. So here is my code:

and here is the output I'm getting

Thus no changes in x and only negative values in the y component.

Am I doing something wrong or is it a known issue? On the other hand, reading out the position works fine.

I am using Unity 2019.2.0f1, Input System package version 0.9.5-preview and my test device is an Samsung Galaxy S9+.

 

I get an compilation error with using scriptable render pipeline core with input system on 2019.b2

InvalidOperationException: You are trying to read Input using the UnityEngine.Input class, but you have switched active Input handling to Input System package in Player Settings.

UnityEngine.Rendering.DebugManager.SampleAction (System.Int32 actionIndex) (at Library/PackageCache/com.unity.render-pipelines.core@7.0.1/Runtime/Debugging/DebugManager.Actions.cs:111)

UnityEngine.Rendering.DebugManager.UpdateActions () (at Library/PackageCache/com.unity.render-pipelines.core@7.0.1/Runtime/Debugging/DebugManager.Actions.cs:168)

UnityEngine.Rendering.DebugUpdater.Update () (at Library/PackageCache/com.unity.render-pipelines.core@7.0.1/Runtime/Debugging/DebugUpdater.cs:18)

 

Is PlayerInput busted in 2019.3.0b2? I'm no longer seeing my actions in the Events section when I have Invoke Unity Events selected. All I can see now are the Device Lost and Device Regained events. Otherwise what could I have done to cause this?

 

Here's a repro project, though it's really just the custom HID identifier + actions, because it doesn't require a scene to reproduce the issue.
https://www.dropbox.com/s/gll8wvf7jgpq4co/HID Input Issue.zip?dl=0

Because this seems to rely heavily on the adapter I'm using (the PS2 variant of MUNIA https://munia.io/), I've recorded a demo video that displays live capture of raw HID data. This is about as much as I can give, besides actually physically sending my adapter to you. (The dev for the adapter graciously provided custom firmware to expose button pressure data over HID, something that the stock model doesn't currently do afaik.)

 

Has anyone successfully used Invoke Csharp events with the playerinput module? I'd like to give that a try because I don't want to use unity events ( want to avoid prefab dragging, would rather do it all in code ) and sendmessages is too limited for our use case. If so, can anyone shed some light because the documentation currently isn't complete enough ( i'm guessing) . Thanks!

 

Out of curiousity, when Unity's Stadia support releases, will the New Input System support Stadia input system? or Unity Stadia will have its own input system?
Thanks.

 

I have a question for when the Input System reaches 1.0 status. When it does reach 1.0 Status what versions of Unity will be supported? I assume when Unity 2019.3 is released that will be supported and I know before Unity 2019 that wont be supported. But I'm not sure as I have only been using it with the latest version of Unity.

The reason I ask is I have a Project that I released that I think would benefit greatly with the use of the new Input System as players of my game have asked for keyboard rebinding. And using the old system is kind of hard to do such a thing. And I can't upgrade the project from 2019.1 without breaking all of the TextMesh Pro stuff since I am using an outdated version and it breaks when I update or replace with a new version.

 

Hey, I see "New Input Package" as a feature of the Unity 2020 Alpha.

Does this mean it will not be available for 2019LTS?

 

It can mean many things... like it can be verified package for 2020.1 but it doesn't mean we couldn't install 1.0 on 2019.3 still. It can also mean it'll be default package/default input system on 2020.1.

 

So for people that are going from LTS to LTS, a usable Input package is more than a year away, still, gotcha.

 

Yeah... This is bad news.

Could even be closer to two years than one year (i.e., 18+ months). Unity 20.4 LTS may be released as late as mid 2021, if the 18.4 LTS release is any indication.

I'm pretty bummed about that because the recent blog post saying the new input system was coming in 2019.3 made me think it was going to make it as part of the 19.4 LTS.

 

*looks left*
*looks right*
Is this a late april joke?

 

Just tried version 1.0. Getting a bunch of errors:

Assets/Samples/Input System/1.0.0-preview/Simple Demo/SimpleControls.cs(151,28): error CS1061: 'InputActionAsset' does not contain a definition for 'GetActionMap' and no accessible extension method 'GetActionMap' accepting a first argument of type 'InputActionAsset' could be found (are you missing a using directive or an assembly reference?)

 

A solution is discussed at https://forum.unity.com/threads/1-0-0-preview-now-available.748286/

 

@Heimlink Thanks. I actually figured out how to fix it myself. I was just surprised the 1.0.0 version wasn't better tested / documented before it was released! And I couldn't find an "issue" for it on github, which is where one would usually check to find out if the developers are aware. I prefer to not rely on these hard-to-search forums.

 

It's still a preview so lesser testing is expected. You mentioned docs, is there something in particular that you feel is missing from current docs which are shipped with the package? I mean, it would probably help Unity more to know what users feel is missing on them vs just saying one expected them to be better.

 

I totally understand that it's still a preview. But 1.0.0 sounds like a bit of a milestone version. If Unity wants to make a breaking change since the previous 0.96 release, that's cool... but it wouldn't hurt to 'document' that somewhere, like in the install guide or on a clearly labelled forum thread if you must.

This breaking change is not huge and quite easily remedied. The change also introduces an issue (in the github sense) in that the files previously generated by the input system are not automatically updated. I also think it's worth 'documenting' that in github (Yes, I've done this.)

As for the current docs, I'm always a fan of examples. So I'd like to see more of those.

On a purely selfish note, I wouldn't mind if the Input System team and the Standard Assets Character (preview as well *sigh*) team spoke to each other and made sure their packages work well together, in a flexible way. And I'd like to know how to set up the new Input System with the preview Standard Assets Character, while using PlayerInput. The basics - at least for those wanting to do more than move a tank around.

As for helping Unity to know what users feel is missing... I try and I try! Occasionally I get a response acknowledging my feedback - always courteous, but also letting me know that nothing will be done because the plan is to fix the problem in some upcoming preview package which will overhaul everything.

 

Is there any way currently to stop receiving input updates when the scene is focused? I quickly looked thru the editor and intellisense for anything about stopping inputs in scene view, but didn’t see anything.

If not, i’d love for that to be a check box somewhere. Could be an editor level thing, or maybe a InputAction level thing - where you can can define whether a map can work in the editor, the game, or both.

Idk, but i’d love the ability to have more control if its not already there.

 

Hello, invoke unity events stopped working in your demo and also in my game after update to 1.0. You can't find your InputAction.CallbackContext methods to set events anymore. How do I fix it?

 

It's actually broken since 0.9.4 or 0.9.5....

 

For an editor script, is there any way to get the current installed version of the Input System?

 

You can use the PackageManager API. I suspect the simplest way would be to try loading the package info directly:

Code (CSharp):

1. var info = UnityEditor.PackageManager.PackageInfo.FindForAssetPath("Packages/com.unity.inputsystem/package.json");
2. if (info != null) {
3.     Debug.Log($"Input System {info.version} installed");
4. }