Feedback on the system

We’ve been using Unity as a studio for around 6 years, and until now we’ve been using InControl.
We thought we’d try the new system for our latest project, but it’s not been working out well.
We thought it might be useful to share our internal list of pros and cons in the hope that it’ll help to improve it!
Would love to know if there’s anything here that we’ve got wrong or can be clarified!

PRO:

  • The serialisable InputAction is quite nice - means we can make our own mapping ScriptableObject that works quite nicely right now.
  • It’s more official. It’s the future? Maybe?
  • Maybe lower overhead than InControl (which has a lot of code and takes 1ms per frame). But I haven’t actually measured what Unity’s system does so may even be worse!

CONS:

  • Bug where keys get left in a “triggered” state, e.g. when switching application while a key is held down
  • It’s mildly less convenient to use “triggered” and “ReadValue()” tha the InControl approach (but once wrapped below it’s only a few lines of code so not such a big deal).
  • No concept of “active device” based on what was last pressed. Currently we update the UI to show gamepad controls if there’s a gamepad plugged in at all even if you’re not actively using it.
  • No way I’ve managed to find of actually knowing if a device is actually a gamepad. Right now I’m just checking if it has “Gamepad” in the internal name, which will probably fail for some devices.
  • Maybe worse device support? MFi controllers don’t work on Mac. Xbox One controller only works on Mac using GitHub - 360Controller/360Controller: TattieBogle Xbox 360 Driver (with improvements). (Though I’m not sure how that compares with InControl)
  • Prevents the legacy input system (Input.GetKeyX) working, which makes prototyping far more time consuming.
  • Seems to prevent UI input from working, even with InputSystemUIInputModule.

Just to add some more eyes, I think half of the CONS mentioned are stemming from device support. From what I’m seeing, the way to check if something is a gamepad (or anything) is yourDevice.description.deviceClass (yourDevice being an InputDevice). The only issue I have with it is…uh…it doesn’t work xD. It works for “Mouse” or “Keyboard,” but 2 controllers I have, this property comes up blank (I personally check for “Controller,” “Gamepad” or “Joystick” if checking for devices.

The input system itself seems unaware of its own confusion here. If you call Gamepad.current (which is supposed to get that active device, by the way, I think that might actually work), for example, it catches the devices I plugged in, yet has no description, so I don’t know what it’s going by. However, I’m not saying it should, because it also seems to pickup the dodgey joystick controllers.

I’m not sure there’s a way to really get everything, some of the controllers I have are cheap noisy boards that have been repurposes to make a classic controller.

I haven’t had an issue with the UI input, though, only thing I could say is be sure the Actions being used are either yours/the default ones as desired.

We’ve switched back to InControl. I’m sure some of our issues are down to our misunderstanding of the system but it seems to offer so little compared to InControl that it’s just not worth taking the time to learn. We’ll have another go for the next project, with luck it will have improved.

Yeah don’t blame you. Just adding what I could to the topic. Half what I’m saying up there is confirming issues. It’s well-admitted that the new system is not mature/accessible yet. The assets make sense from a studio standpoint, I just try to avoid them, personally, as in some cases like open-source projects.