PlayerInput Control Scheme Priorities

Unity Engine
1

I am trying to specify the order in which a PlayerInput should activate its’ default control scheme.
Ideally, I’d set the default control scheme to “Any” on the PlayerInput, and on startup a “Gamepad” control scheme would be tried, followed by a “Touchscreen”, “Mouse” then a “Keyboard” if no other scheme could be activated.

There are two issues I’m running into.
1. Setting the Order in the UI:
There doesn’t seem to be any way to specify the order of Control Schemes via the UI. I can change the order inside the .inputactions file manually but given the order in this file DOES determine the order of the control scheme array handed around in PlayerInput I’d expect a way to manipulate it in the UI.

2. Control Scheme Scoring:
When a control scheme is “scored” the same as another, the order described above matters as the first control scheme with that order will be used as you’d expect. If a later control scheme has a higher score however, that control scheme will be picked over the earlier. This is fine so long as the scoring is.

In my case I’m having trouble understanding how I’d indicate that my generic “Gamepad” control scheme - that meets requirements due to an “XboxOneGamepadMacOSWireless” device being present - should take activation precedence over my “Mouse” control scheme - which meets requirements due to a “Mouse” device being present?
At the code shown in the above link currently, my “Mouse” control scheme is scored a 2, while the “Gamepad” is scored 1.333~. This is because the “Gamepad” device (XboxOneGamepadMacOSWireless) is actually MORE inherited (therefore MORE explicit) than the “Mouse” device (Mouse). So the way scoring is performed currently, the closer a DEVICE is to being generic, the greater it is scored.

TLDR: If I were to plugin an unbranded generic HID gamepad, my “Gamepad” control scheme would be activated before my “Mouse” scheme.
With an explicitly supported Xbox gamepad however, my “Mouse” scheme (and the UI legends that go along with it) is activated before the “Gamepad” scheme.

2

To me, the concept of scoring one “type” of control scheme to another quickly loses meaning given the changing context of the application in question. Even if the scoring was flipped, and you gave more precedence to the “XboxGamepad” control scheme than the generic “Gamepad” control scheme, it doesn’t mean that either’s score compares in any way to a “Fightstick” or “Flightsim” control scheme.
In a fighting game I’d absolutely want a “Fightstick” control scheme to be activated before a “Gamepad” scheme whereas in an FPS I’d obviously want the “Gamepad” scheme (if they were the only two available options).
This would be independent of how explicitly supported the Fightstick device is compared to the Gamepad.

3

Yup, agree that picking between control schemes that are in fact not related provides little controls and is insufficiently covered by the scoring which indeed is rather irrelevant in this case. The scores can sufficiently well figure out whether device X is more or less specialized than device Y but beyond that, it doesn’t say much.

ATM the only two control mechanisms (other than the fiddly ordering of control schemes) is to set the starting control scheme appropriately or to manually force-override the default mechanism using SwitchCurrentControlScheme.

We have some ideas how to greatly improve the control scheme editing in the action editor and expose better controls over the order in which things are being tried.

1 Like
4

No worries. For now I’ll set the starting control scheme. If the action editor changes aren’t ready by then, for production I’ll manually set the .inputactions file and use a modified InputControlScheme class (commit here) that, if a match has been found, skips further schemes if they don’t contain the same basic device requirements as the current best matched scheme.
At a glance, do you see any issues arising from how that added condition is written?