Input System bugs

[Rene-Damm]

Thank you for the detailed feedback. Very helpful.

@Rallix

I guess the major problem I have is not being to able to register any input in WebGL build. It’s working fine in the Editor, the build reports something like:
The devicemotion events are blocked by feature policy.
The deviceorientation events are blocked by feature policy.
This is in Unity 2018.3.8f1, so judging by this thread , would it be working if I switched to the current 2019.1 beta?

Could be you’re getting caught by one of the annoyances with WebGL gamepad support. One problem we have there is that the only way to get standardized gamepads (i.e. so you know that the button you’re targeting is really the one you mean) is if they follow the “standard” mapping as specified by the W3C standard. However, in my own (limited) testing I found that it very much depends on the browser, platform, AND gamepad whether you’ll get a gamepad with a mapping or a gamepad with no mapping at all.

For gamepads that do not come with a standard mapping, we would have to supply specific layouts for specific browser+platform+gamepad combinations. Not sure we’ll ever go there. Remains to be seen. Definitely a nightmare. ATM we have none of those.

What this means is that currently a gamepad on WebGL will only come out as a Gamepad in the new input system if it uses the “standard” mapping. If not, it’ll come out as a joystick. If desired, it should be possible to bypass that like so:

// Nuke definition of WebGL joysticks.
InputSystem.RemoveLayout("WebGLJoystick");

// Turn any WebGL gamepad into a Gamepad.
InputSystem.RegisterLayout<WebGLGamepad>(
    matches: new InputDeviceMatcher()
        .WithInterface("WebGL")
        .WithDeviceClass("Gamepad"));

@Rallix

The other big trouble I had was getting the horizontal movement axis working regardless of whether a keyboard or a gamepad is used. In the setup as seen above, the keyboard axis value went (correctly) from -1 to 1, but the gamepad was inverted (1 to -1) – I’m not sure why.
I tried a number of things, from switching the positive and negative key, adding processors (like Scale: -1 or Invert), swapping min/max values… which either didn’t really do anything or made the negative side always return zero.

What’s the gamepad and platform? Think we had some where it was coming out incorrectly and have fixed it recently.

Looking at your setup, I’d expect it to work. However, you wouldn’t necessarily need an axis composite there. An alternative is to just bind to the gamepad stick’s X axis.

@Rallix

I had problems with the “Hold” interaction, too – it immediately returned “performed” no matter what time I set up.

There was a bug with startTime and duration on actions which probably caused this. Was fixed in 0.2.6.

@Rallix

One thing is that it doesn’t remember you overwriting the default value, but another thing (shared by interactions such as Scale etc.) is that I wasn’t able to enter a decimal value.
Isn’t this another problem with ‘decimal comma’ which the whole Package Manager seems to be currently having (case 1125027)?

Hmm, interesting. We have to look into that. IIRC the code here is neutral to locales meaning that it’d have to be a period not a comma. In the UI, we should probably convert for presentation on the fly. Made a note.

@Rallix

Generating a new script file always produces a (harmless) error:

Haven’t seen that. I think this shouldn’t happen on 2019.1 anymore, though.

@Rallix

Doublicking a name (action map, action) to edit it while another name is already being edited at the moment results in only being able to write a single character at a time. Simply, losing focus doesn’t close the currently editable field.

Confirmed. Will fix. Logged ticket here.

@Rallix

And right-clicking when editing doesn’t change focus either, so you might accidentally end up deleting the wrong thing

The action editor and inspectors recently received a major overhaul that landed in 0.2.6. This is fixed as far as I can see.

Since the overhaul, we do have some error occasionally popping up when using context menus in the action error. We’re looking into that.

@Rallix

“Waiting for input…” kept returning “scroll [Mouse]” no matter what I actually pressed.

Yup, known issue with the mouse. Setting a type on the action so that the mouse scroll wheel isn’t taken into account should help work around it in some cases.

@Rallix

The last one – again, I’m not sure why but when restarting a level (= reloading the active scene), most buttons stop working, but strangely, jump seems to be working fine.
As far as I know, there’s nothing persistent (“Dont Destroy On Load”) in the scene, so when reloading, it should probably work the same as when entering the playmode for the first time.

Ok, that is curious. We’ll have a look.