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
- Getting a deprecated package for JetBrains Rider pop up when opening or creating a project
- [Android] Volume level of the same audio file is different on Samsung Galaxy Tab A8 between 2023.3.0b3 and 2023.3.0b4
- ‘Expected end of value’ warning occurs when a property declaration includes five or more variable references
- Crash on BurstCompilerService::CompileAsync when entering Play mode in a specific scene
- InvalidOperationException when using Game Camera Preview in Scene window with a custom RenderGraph pass
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.