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
- ScrollView elements are not restored to their original positions after removing a Layout Group with Undo action
- "Assembly with name already exists" errors are thrown when two packages with different technical names resolve to the same namespace
- A Select Scene Entry is added to Undo History when Deleting while a Scene is selected in the Hierarchy
- The Add Component Menu's back arrow accumulates phantom levels when the Menu is repeatedly opened into a Category and closed without selecting
- Advanced dropdown stops applying the Search Filter while the search text remains after clicking the header back Button during a Search
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.