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
- Crash on ShaderLab::ShaderState::ApplyShaderState when entering Play Mode and calling ShaderWarmup.WarmupShaderFromCollection with a shader that has dynamic_branch
- Crash on operator delete[] when a serializable structure in the System namespace is serialized by a MonoBehaviour
- [macOS] forward and backward mouse buttons are recognized as middle mouse button
- NavMeshModifier.OnEnable/OnDisable gets progressively slower when called repeatedly
- "System.Net.CookieContainer" throws an "ArgumentException" error when using a non-UTF-8 machine locale and hostname
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.