-
Notifications
You must be signed in to change notification settings - Fork 328
FIX: Fixed unexpected control scheme switch when using OnScreenControl and pointer based schemes (ISXB-656)
#2023
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
8987971
a77e182
fd41d65
cc25550
2291d3e
058aab1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,6 +2,7 @@ | |
| using Unity.Collections; | ||
| using UnityEngine.InputSystem.Layouts; | ||
| using UnityEngine.InputSystem.LowLevel; | ||
| using UnityEngine.InputSystem.Users; | ||
| using UnityEngine.InputSystem.Utilities; | ||
|
|
||
| ////REVIEW: should we make this ExecuteInEditMode? | ||
|
|
@@ -34,6 +35,14 @@ namespace UnityEngine.InputSystem.OnScreen | |
| /// types of device layouts (e.g. one control references 'buttonWest' on | ||
| /// a gamepad and another references 'leftButton' on a mouse), then a device | ||
| /// is created for each type referenced by the setup. | ||
| /// | ||
| /// The <see cref="OnScreenControl"/> works by simulating events from the device specified in the <see cref="OnScreenControl.controlPath"/> | ||
| /// property. Some parts of the Input System, such as the <see cref="PlayerInput"/> component, can be set up to | ||
| /// auto-switch <see cref="PlayerInput.neverAutoSwitchControlSchemes"/> to a new device when input from them is detected. | ||
| /// When a device is switched, any currently running inputs from the previously active device are cancelled. | ||
| /// | ||
| /// To avoid this situation, you need to ensure, depending on your case, that the Mouse, Pen, Touchsceen and/or XRController devices are not used in a concurent | ||
| /// control schemes of the simulated device. | ||
| /// </remarks> | ||
| public abstract class OnScreenControl : MonoBehaviour | ||
| { | ||
|
|
@@ -208,13 +217,45 @@ protected void SentDefaultValueToControl() | |
| InputSystem.QueueEvent(m_InputEventPtr); | ||
| } | ||
|
|
||
| // Used by PlayerInput auto switch for scheme to prevent using Pointer device. | ||
| internal static bool HasAnyActive => s_nbActiveInstances != 0; | ||
| private static int s_nbActiveInstances = 0; | ||
|
|
||
| protected virtual void OnEnable() | ||
| { | ||
| ++s_nbActiveInstances; | ||
| SetupInputControl(); | ||
| if (m_Control == null) | ||
| return; | ||
| // if we are in single player and if it the first active switch to the target device. | ||
| if (s_nbActiveInstances == 1 && | ||
| PlayerInput.isSinglePlayer) | ||
| { | ||
| var firstPlayer = PlayerInput.GetPlayerByIndex(0); | ||
| if (firstPlayer?.neverAutoSwitchControlSchemes == false) | ||
| { | ||
| 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. without isolation it's hard to reliably filter touch event with ugui event. |
||
| { | ||
| if (m_Control.device.deviceId == device.deviceId) | ||
| { | ||
| deviceFound = true; | ||
| break; | ||
| } | ||
| } | ||
| if (!deviceFound) | ||
| { | ||
| firstPlayer.SwitchCurrentControlScheme(m_Control.device); | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| protected virtual void OnDisable() | ||
| { | ||
| --s_nbActiveInstances; | ||
| if (m_Control == null) | ||
| return; | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know it's a valid use case to keep auto-switching with onscreen control.
If we are afraid of side effect we could add an opt out parameter to allow autoswitch when there is an on screen control.