Adjust asymetric input handling when only one controller is available

[JackTheFoxOtter]

Is your feature request related to a problem? Please describe.

Earlier today when the battery of my right controller died I noticed that my configured controls somewhat soft-locked me. Specificially, I was unable to open the dash or properly move & turn with one controller (tank controls).

My settings are as follows:

• Left controller sideways movement mode: Strafe
• Right controller sideways movement mode: TurnAndMove
• Use Facet Anchors: On
• Toggle Controller: Left

When my right controller disconnected, I encountered the following issues:

• I could no longer turn around, only strafe (I was expecting to be switched into tank controls)
• I could no longer open my dashboard, only toggle my facet anchors

Describe the solution you'd like

I would like a priority system for asymetric controller mappings that ensures that the more important functionality always takes priority when only one controller is connected.

When only one controller is connected, it should should:

• Always open the dash instead of toggle facet anchor states via the menu button
• Always allow turning and moving (tank controls) via the joystick

Describe alternatives you've considered

Making the fallback settings for single controller mode configurable independantly. That said though, since both not being able to turn and not being able to open the dashboard severely limits the ability to interface with Resonite (no menu means I couldn't even change those settings in-game), I think enforcing fallbacks that keeps the platform operational makes more sense.

Additional Context

Ensuring the game remains fully operational in single-controller mode is also an important accessibility feature. Some players only have access to one controller. There's also #541 which points out another restricted functionality when only using a single controller.

Requesters

No response

[shiftyscales]

This issue is also adjacent to #2309 which focuses on bugs in the current implementation which does not correctly set the opposite controller to turn and move when the user only has one locomotion hand available.

Seeking input from @Frooxius.

[Frooxius]

We could add something like this. E.g. if we detect that controller is gone, we consider it fully blocked, which will remap some of the functions.

But I'm not sure if this would be the default behavior or not. Usually when that happens to me I just plug the controller in, which is easiest way to resolve this without any extra engineering effort.

[shiftyscales]

I think it should be a default behaviour, @Frooxius - as highlighted in the initial issue- this is also an accessibility concern, e.g. if a user only ever has a single controller/hand to use.

Likewise- it's been a common experience for me to have a controller die, and my charger is across the room- so even if I plug it in to charge- I won't have it turned on/won't be using it until such point as it is charged enough.

I see this behaviour as being unobtrusive- it ensures that Resonite will always have all of its core functions/UI accessible for whatever reason a user has only one hand available to them- if they turn on their second controller- the controls could just resume their usual configuration/bindings.

That's actually an issue I've also run into since the introduction of the facet anchors- commonly I would use the hand-near-head gesture to open my dash on my right controller whenever the left controller was dead- but now I have no means to open my dash if my left controller is dead.

Previously where possible I've also worked around this issue manually by temporarily switching my handedness in the settings so I have turn and move on my remaining controller.

[TisFoolish]

Shifty is right, for a lot of people plugging in a controller and still using it isn't feasible. They might use magnetic cables which won't stay connected during normal use, their controllers may have a charging stand instead of regular cables, or where they can charge them is just outside of their usual playing area. Personally i use the first option as a way to prevent the USB-C ports from breaking on my index controllers

[shiftyscales]

Related to the above- SteamVR also gives a warning about using controllers while they are plugged in- it is not advised, and can lead to damage of the charge port.

Specifically- SteamVR warns: "Please unplug controllers during gameplay"

[Frooxius]

My main thing here is that the use cases and approaches are slightly different for things. There's an overlap, but it's a bit different from accessibility.

Say someone has difficulty using the controller at all - we need to make assumption there that they might not ever be able to use it from the beginning.

But for this case, that assumption doesn't hold - they use both at the times (or most of the time).

What this means is when we think about solutions and things, there's a subtle, but important difference between the two.

[shiftyscales]

I think I see what you mean @Frooxius - and yeah, the opposite can also be true, e.g. the user has access to both controllers / has them both powered on, but can only fully use one. So the presence/absence of controllers in of itself is not an indicator of the users' physical ability.

There is definitely overlap though as you indicated.

I am curious if you have any other thoughts / input on how best to handle things for those other cases of a user not ever being physically able to fully utilize at least one controller.

In future, support for custom device drivers / action mapping would ensure that users would be able to make/use a control scheme that meets whatever needs they have. We could even extend that further to account for use of eye / face tracking as an input method potentially.

But I imagine for now- there's probably things we can do in the shorter term to improve support / accessibility with our existing supported input types.