Search Issue Tracker
Fixed
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
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
Resolution Note (fix version 2.3.1):
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.