Forum Discussion
bknoth
8 years agoExplorer
Issue with version 1.27 and SDK v1.26
Our systems auto-updated to version 1.27 last night. Calls to ovr_GetInputState() now produce values for m_inputState.IndexTrigger[0] that are always 0 no matter how the trigger is positioned. We're using version 1.26 for the SDK (I haven't seen a newer version). Has anyone else seen this problem?
Thanks,
Bruce
21 Replies
- ramezanifardHonored GuestHi Bruce,
the same problem here. I can't read the buttons anymore. The only thing that still works is "inputState.Touches". It shows what button is touched, but is super sensitive to touch. - bknothExplorerLuckily, we had a computer that had not auto-upgraded. We copied the Oculus program files folders from that machine (1.26) to a machine that had auto-upgraded to 1.27 and the latter machine worked again. We had a critical demo to pull off and that was our work-around.
- bknothExplorerPlease post if it does resolve the problem. I'm not well-versed in Oculus development and I'd appreciate knowing if this problem's been solved. Thanks.
- MikeFTrustee
Florayne45 said:
Others who have been developing for Oculus devices- has this been a common occurrence in the past? Automated updates breaking your production environment? Definitely makes me hesitant to continue supporting this platform if it isn't going to be reliable.
Big time, we've had several important demo's derailed because of a last minute update forced on us.
When things work it's great but the uncertainty of when an update hits and what it might break is a big problem - mouse_bearRetired SupportHello everyone,
Our engineers are aware of the problem and are currently looking into a solution.In the meantime, a workround is to press the Oculus button to enter the Universal Menu, then press it again to return to the game. The buttons should work then. - Just thought I'd join in, the same issue has stopped my AutoOculusTouch project from working. It uses ovrInit_Invisible as it's intended to run without the headset worn at all. But all button and trigger values are zero unless rendering is performed and the headset is being worn. Wearing (or triggering the sensor) without rendering or rendering without wearing both result in input stopping (tracking continues to work though).
- CloudhopperHonored GuestI work with Bruce who initiated this thread. We have just built two new rigs with fresh software installs. I attempted the workaround posted by NinjaGaijin, without success. I have copied the non-updated Program Files/Oculus directory from a working system, and turned off automatic updates, but this solution will not work with our customers. Please @NinjaGaijin, this has been an issue since June 19.
- AnonymousAny news on a fix for this problem?
- Anonymous
I am running SDK V1.29 and that problem is still there.
My application has 2 VR modes, when I switch modes, I first get out of VR and get back in with a new ovr_Initialize and a new session (ovr_Create). To get the ovr_GetInputState to work again in the new session, just having the headset on is not enough. You then need to remove the headset and put it back on again! This make for awkward demos when I want to show both modes to a client...
The Oculus button work around does work, but after all, it is a work around... A real solution would be better.
- CloudhopperHonored Guest@imperativity We are preparing a build for a customer to be delivered later this week. Has there been any progress on enabling successful reads of the Touch trigger state from the SDK? I have been unable to update any of our development systems since June, and we are still running 1.26 which is the last system that worked. How is it that many systems (like UE4) are able to read the triggers, but the SDK can't?
Quick Links
- Horizon Developer Support
- Quest User Forums
- Troubleshooting Forum for problems with a game or app
- Quest Support for problems with your device
Other Meta Support
Related Content
- 2 years ago
- 10 months ago
- 2 months ago