question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

VRControllerState_t EVRButtonId and k_EButton no longer work, can't read ProximitySensor.

See original GitHub issue

Since you’ve switched to the action system we can no longer detect if the user took the headset off their head. (in addition to other info)

It seems that the following stuff no longer works, and the scripts that used to have this logic, like “SteamVR_TrackedController.cs” have been removed. It might be that the C++ backend no longer provides these correctly? But the following no longer works, for any type of button or stat:

bool success = OpenVR.System.GetControllerState(controllerIndex, ref controllerState, (uint)System.Runtime.InteropServices.Marshal.SizeOf(typeof(VRControllerState_t)));
ulong prox = controllerState.ulButtonPressed & (1UL << ((int)EVRButtonId.k_EButton_ProximitySensor));

The only “alternative” is to use OpenVR.System.GetTrackedDeviceActivityLevel(0) == EDeviceActivityLevel.k_EDeviceActivityLevel_UserInteraction, but this is useless because the headset could be rolling on the floor for 10 hours and the app would think there was a user playing the game the whole time ffs. We require to run aspects of apps only while human eyeballs are inside the headset.

k_EDeviceActivityLevel_UserInteraction = 1, means a union of either headset movement or prox sensor is true. And there’s no way to poll just the prox sensor. The unity builtin UnityEngine.XR.XRDevice.userPresence == UnityEngine.XR.UserPresenceState.Present is the exact useless thing. Not to mention it takes like 15 seconds for k_EDeviceActivityLevel_UserInteraction to become 0, and only if the headset has been sitting 100% still (read: not bumped by anyone/anything or held in one’s hand).

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:17

github_iconTop GitHub Comments

1reaction
zitecommented, Oct 19, 2018

For now you could manually create a headset binding file with the binding:

Create a file named binding_vive_pro.json in the root of your project directory (next to the actions.json. In the file put the following:

{
   "alias_info" : {},
   "bindings" : {
      "/actions/default" : {
         "sources" : [
            {
               "inputs" : {
                  "click" : {
                     "output" : "/actions/default/in/[YOUR ACTION NAME HERE]"
                  }
               },
               "mode" : "button",
               "path" : "/user/head/proximity"
            }
         ]
      }
   },
   "controller_type" : "vive_pro",
   "description" : "",
   "name" : "Default configuration for vive pro",
   "options" : {},
   "simulated_actions" : []
}

Then open your actions.json and scroll down to where it lists “default_bindings” and add one for the vive_pro:

{
    "binding_url" : "binding_vive_pro.json",
    "controller_type" : "vive_pro"
}

If that’s your last item in the list make sure there’s a comma after the closing bracket above it and there is no comma after it. json is pretty picky about that.

0reactions
zitecommented, Jan 31, 2019

Now in the latest release on the asset store.

Read more comments on GitHub >

github_iconTop Results From Across the Web

No results found

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found