Bug Regression in 1.1.0-pre.5 - Keyboard input ignored with multiple bindings

I think I've found a regression in 1.1.0-preview.3 (relative to 1.0.2). It is also present in 1.1.0-pre.5.

I updated to 1.1.0-pre.5 (originally 1.1.0-preview.3) to include this fix:
https://issuetracker.unity3d.com/is...binding-are-attached-to-the-same-input-action

However I now have a new problem - for my bindings which contain both a steering-wheel pedal binding (e.g. throttle or brake) and a keyboard binding (e.g. "W" for throttle, "S" for brake), the keyboard bindings no longer work when the pedal inputs are exactly zero.

I.e. if I press or hold "W" expecting to provide throttle input, `throttleAction.ReadValue<float>()` returns zero, unless I provide a very small amount of input on the throttle pedal (i.e. it is non-zero). The pedal input seems to always work.

With 1.0.2, it didn't matter, and either control would provide input regardless of the other's state.

EDIT: bit more info, I'm putting together a proper bug report now:

• The Input Action is of type Value, Control Type Axis.
• The pedal binding is for the accelerator of a G29 steering wheel which goes from 1 to -1 when depressed (released value is 1).
  
• There is a Normalize Processor on the Action, Min -1, Max 1, Zero -1, and the pedal binding is Inverted - this is to make the accelerator pedal go from 0 to 1 when depressed.
  
• The keyboard binding has no extra Processors.

With Input System 1.0.2, this results in the read value going from 0 to 1 in proportion to the pedal being pressed further, or 0 to 1 immediately if the key W is pressed. The value read is 0 if neither input is active.

With 1.1.0-preview.3 & -pre.5, the pedal works exactly as before, but the W key only produces a value of 1 if the pedal is depressed at all. E.g. a slight pressure on the pedal (to give a value of, say, 0.1) allows the key W to result in a 1, but no pressure on the pedal (basically 0) prevents the key W from doing anything at all - pressing W results in 0.

I can easily jump between 1.0.2, 1.1.0-preview.3 and 1.1.0-pre.5 and see the behaviour change between each - it's 100% reproducible.

EDIT2: seems I can't create a new issue in the Issue Tracker, so I'll copy/paste what I was going to send here:

1. What happened

Upgrading from Input System 1.0.2 to 1.1.0-preview.3 has revealed a regression in behaviour.

For bindings which contain both a steering-wheel pedal binding (e.g. throttle or brake) and a keyboard binding (e.g. "W" for throttle, "S" for brake), the keyboard bindings no longer work when the pedal inputs are exactly zero.

I.e. if I press or hold "W" expecting to provide throttle input, `throttleAction.ReadValue<float>()` returns zero, unless I provide a very small amount of input on the throttle pedal (i.e. it is non-zero). The pedal input seems to always work.

With 1.0.2, it didn't matter, and either control would provide input regardless of the other's state.

* The Input Action is of type Value, Control Type Axis.
* The pedal binding is for the accelerator of a G29 steering wheel which goes from 1 to -1 when depressed (released value is 1).
* There is a Normalize Processor on the Action, Min -1, Max 1, Zero -1, and the pedal binding is Inverted - this is to make the accelerator pedal go from 0 to 1 when depressed.
* The keyboard binding has no extra Processors.

With Input System 1.0.2, this results in the read value going from 0 to 1 in proportion to the pedal being pressed further, or 0 to 1 immediately if the key W is pressed. The value read is 0 if neither input is active.

With 1.1.0-preview.3 & -pre.5, the pedal works exactly as before, but the W key only produces a value of 1 if the pedal is depressed at all. E.g. a slight pressure on the pedal (to give a value of, say, 0.1) allows the key W to result in a 1, but no pressure on the pedal (basically 0) prevents the key W from doing anything at all - pressing W results in 0.

I can easily jump between 1.0.2 and 1.1.0-preview.3 and 1.1.0-pre.5 and see the behaviour change between each - it's 100% reproducible.

2. How can we reproduce it using the example you attached

Look at the Cube object in the Hierarchy. You may need to change the G29 binding (Z axis) to something else if you have an analog controller. Keep the keyboard W binding as the second binding. If you replace the G29 binding, make sure you add an Invert Processor if you need to - with Input System 1.0.2, 1.1.0-preview.3 or 1.1.0-pre.5 the analog controller should result in a 0 output when idle, and a 1 output when fully actuated.

Start with Input System 1.0.2 installed.

Now run the Scene in the Editor and observe the Console log when you press the W key, or actuate your analog input. It should display a console message with a value between 0 and 1, such that when no input is provided, the value is 0, and when the key W is pressed, the value is 1, and when the analog input is actuated, the value is somewhere between 0 and 1 inclusive.

Now update to Input System 1.1.0-preview.3 or -pre.5 and repeat.

You should notice that the key W does not result in a value of '1' being generated in a reliable way. You may see that it does work initially, but once you touch the analog controller it will no longer work, unless the analog controller is slightly actuated. Sometimes it will work but that is because the analog controller isn't quite exactly zero.

Switch back to 1.0.2 if you need to and you'll see that the original behaviour is restored.

Therefore I believe this is a regression that has happened sometime between Input System 1.0.2 and 1.1.0-preview.3.

 

Attached reproduction project.

 

I am also able to reproduce this with 1.1.0-pre.5, using the same reproduction project (update Input System to 1.1.0-pre.5).

I will update the thread title accordingly.

 

As per the inquiry here: https://forum.unity.com/threads/input-system-introduction-and-links.903905/
You should submit a proper bug report: https://unity3d.com/unity/qa/bug-reporting

It also allows the QA to help you out after they examine your case. It's possible that it is just a setting problem. (I currently can't run your test project to find out because this isn't my Unity-capable device)

 

Yep, I submitted a bug report on 21st July, it's currently unacknowledged. I updated this issue since I don't have a lot of confidence that Unity will fix it, maybe someone else here has come across it before, or can also reproduce it.

 

To update this, Unity have since acknowledged the bug. Here's what one of their engineers had to say:

They go on to acknowledge that they believe the issue is on "their" side and it will take some time to resolve.

They provide a workaround to inject processors directly into the controls so that they are "seen" by

EvaluateMagnitude

rather than ignored.

The workaround involves removing the processors from the action itself, and then creating a Layout Override:

Code (CSharp):

1.  
2.     private void Start()
3.     {
4.         // Add an extra Control to the G29 layout
5.         InputSystem.RegisterLayoutOverride(@"
6.    {
7.        ""name"" : ""HID::Logitech G29 Driving Force Racing Wheel Override"",
8.        ""extend"" : ""HID::Logitech G29 Driving Force Racing Wheel"",
9.        ""controls"" : [
10.            { ""name"" : ""z"", ""processors"": """", ""parameters"": ""scale=true,scaleFactor=-1,normalize=true,normalizeMin=-1,normalizeMax=0,normalizeZero=-1"" }
11.        ]
12.    }
13. ");
14.  
15.         action.Enable();
16.     }
17.  

They also suggested I could declare a full device layout in code, similar to:

https://github.com/Unity-Technologi...stem/Plugins/DualShock/DualShockGamepadHID.cs and https://github.com/Unity-Technologi...tSystem/Plugins/DualShock/DualShockSupport.cs

However I wasn't able to get very far with this. The former (Layout Override) workaround worked for me.