Search Issue Tracker
Fixed in 2.3.1
Votes
0
Found in [Package]
2.2.0
Issue ID
XRIT-52
Regression
No
[Quest 2] XRController.controllerNode keeps using the original controller for interactions when changing it at runtime
Reproduction steps:
1. Open the attached project "ControllerNodeTesting"
2. Open the “/Assets/Scenes/SampleScene” Scene
3. Connect Quest to PC via Link
4. Enter Play Mode
5. Observe “Current” in the Game window and press the Trigger button of that controller.
6. Press the grab button of that controller
7. Press the trigger button of the controller shown in “Current”
Expected result: When pressing the trigger of the “Current' controller the Scene turns green
Actual result: Only the “Default” controller’s trigger turns the screen green
Reproducible with: 2020.3.45f1, 2021.3.18f1, 2022.2.6f1, 2023.1.0b3, 2023.2.0a1
Reproducible with devices:
VLNQA00379, Oculus (Quest 2), Android 10, CPU: Snapdragon XR2, GPU: Adreno (TM) 650
Reproducible on: Windows 10 Enterprise 21H2
Note:
When changing the controllerNode of an XRController at runtime, m_InputDevice is not updated and so the original input device is used instead
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Selection outline is not shown when selecting a high intensity HDR Swatch preset in Color Picker
- Multiplayer Center some labels are truncated permanently even when the window is fullscreen and there is a lot of space
- ArgumentOutOfRangeException error appears when navigating through items in the Component browser
- Multiplayer Center Banner titles are not light-theme friendly and there is a gray panel overlapping with the Unity logo
- Combined Log and Throw Exceptions Function does not show up in Diagnostics Cloud Dashboard when called in Player
Resolution Note:
There was an issue found in the XRController class where if the controllerNode property is changed at runtime, the underlying Input Device was not also swapped over, leading to a disparity between the two properties. The controllerNode is ignored after the inputDevice property is used the first time, with the exception of the device being disconnected, where the isValid state triggers a reset using the correct/updated controllerNode value. This was fixed in XRI 2.3.1 to check if the controllerNode value has changed when accessing the inputDevice property and getting the correct InputDevice in return.