FIX: Fixed unexpected control scheme switch when using OnScreenControl and pointer based schemes (ISXB-656)
#2023
Conversation
…nd pointer based schemes
| var devices = firstPlayer.devices; | ||
| bool deviceFound = false; | ||
| // skip is the device is already part of the current scheme | ||
| foreach (var device in devices) |
There was a problem hiding this comment.
I'm less confident with that part I choose to switch to target device in all case but maybe I just only try to move away from a pointer device. 🤔
There was a problem hiding this comment.
Yeah I started to think the same, that maybe the design error here is, first of all auto-switch with on-screen controls, but also that on screen controls rely on pointer instead of touch. Of course pointer is convenient when working in the editor but generally it feels like touch should be the underlying input here... In editor its possible to simulate touch from mouse so problem can be solved anyway....
|
Will check today |
…ith-onscreen-components
There was a problem hiding this comment.
Only commenting for now since I need to let this sink in a bit. I wonder if there is another solution where OnScreen controls would consume touch but not pointer? I am not sure you considered this. In general, this is one more example of auto-switch causing problems.
| Move(mouse.position, new Vector2(100f, 100f)); | ||
| InputSystem.Update(); | ||
|
|
||
| // The controlScheme shouldn't have changed |
There was a problem hiding this comment.
I remain confused regarding why this would be expected... I guess the current problem is that OnScreenStick and OnScreenButton is using pointer instead of touch so this leads to ping pong in editor setting. Still given how things currently work don't we define auto switching as being triggered by input on related control schemes? If this scenario is about on screen sticks it feels like what would make sense would be for the on screen controls to turn of auto switching since it makes little sense to have onscreen controls and auto-switching combined?
| var devices = firstPlayer.devices; | ||
| bool deviceFound = false; | ||
| // skip is the device is already part of the current scheme | ||
| foreach (var device in devices) |
There was a problem hiding this comment.
Yeah I started to think the same, that maybe the design error here is, first of all auto-switch with on-screen controls, but also that on screen controls rely on pointer instead of touch. Of course pointer is convenient when working in the editor but generally it feels like touch should be the underlying input here... In editor its possible to simulate touch from mouse so problem can be solved anyway....
Description
When using an OnScreenControl with default Control scheme with a Move Action it will trigger a Cancel event on every frame since if will autoswitch back to pointer device when the user made an input and the OnScreenControl will switch back to the emulated one.
ISXB-656 The "Cancel" event is registered every frame when the Move action is used
Changes made
Added an instance counter to OnScreenControl to know if there is an active one.
Added a check in player autoswitch filter to prevent switching to pointer scheme when using an OnScreenControl
Changed OnScreenControl to automatically switch to a scheme that use the emulated device to prevent some remaining interaction when is was previously using a pointer.
Testing
added test and tested on customer project
Risk
I added the auto switch to target device in the OnScreenControl but I'm not sure if it's the right condition.
For now it's only on the first control if it's not part of the current player device.
But it may be better to just move aways from pointer devices in all case 🤔.
(or remove that part of the change)
Checklist
Before review:
Changed,Fixed,Addedsections.Area_CanDoX,Area_CanDoX_EvenIfYIsTheCase,Area_WhenIDoX_AndYHappens_ThisIsTheResult.During merge:
NEW: ___.FIX: ___.DOCS: ___.CHANGE: ___.RELEASE: 1.1.0-preview.3.After merge: