Oculus Rift: Detects in win7 compat (steamVR), but then no menu navigation (no controller detection)

[flavourous]

From #14.

elite runs through oculus native by default, therefore we dont get detected:

setting "win7 compatibility mode" forces elite to run thought steamVR, however, occulus controls are gone (can even be seen in controls presets) which means the menus cannot be navigated by controller thumbsticks:

Happy to help.

[dantman]

We have a menu mode implemented when you turn it on. When we can switch to SteamVR Input API (#14) these controls should be available to the Touch joysticks as well.

[flavourous]

Ok, sounds like the input api will give us unified events across different controllers. That would be much easier for sure.

Got the build debugging, and I've spotted the joystick events coming through on EVRControllerAxisType.k_eControllerAxis_Joystick, but the intervals are a bit different.

I think I want menu mode event loop on all the time, including the first menu etc. I'll have a play and see what I can come up with.

I'll gladly welcome any tips/suggestions you might have.

[flavourous]

I have a fork over here https://github.com/flavourous/elite-vr-cockpit/tree/feature/rift with some fixes for rift, I can open you a PR if you're interested. Namely what I can remember:

• Switch between different button/direction handling depending on VRDevice
• Map joystick to up/down/left/right for rift
• Tweaks to button presses, hooking to keydown and keyup directly rather than using down-delay-up, which are dropping keypresses for me.
• few extras: ControllerButtons, menu mode toggle on controller and alternate right hand bindings

[dantman]

@flavourous Sorry, most of that I really want to implement in a different way.

• Hardcoding Rift mappings still leaves WMR users out. And it's a rabbit hole of manual mapping for every platform. Especially when this input system is deprecated. I want to switch to the officially recommended SteamVR Input API (SteamVR Input API and support for non-Vive wand controllers #14). Then mappings can easily be made for Vive, Touch, WMR, and Knuckles.
• I also do not want to enable Unity's OpenVR XR runtime. Unity runs as an application instead of an overlay, which usually results in messy things like SteamVR treating it like a game and closing other things to render an empty void instead of acting as an overlay.
• I do want to change the key handling so menu click/joystick presses hold the key while the button is down, see Vive Touchpad Navigation Inconsistent #64. Maybe even also for holo buttons. But I think I'll implement it slightly differently. It looks like too much verbose boilerplate has been added to key invocations. And I'm not sure what is with the hardcoded numpad bindings.
• Also I'm not sure what is going on with the menu mode toggle binding. It looks like it's bound to secondary fire on the touch in a way that'll toggle menu mode when you try to fire your secondary weapons. The menu shouldn't be needed so often it needs a controller binding. In fact ideally the menu controls would activate automatically just like every other control. Unfortunately ED doesn't give us that info. I'm hoping I can get someone to add that minor addition to the Status.json in after we reach the 1.0 targets (Menu mode should be automatically activated #75).
• What are the panel focus holo buttons for? Panels focus when you are looking at them.

[flavourous]

No problem @dantman, your overlay is awesome - I just wanted to be able to play it on rift, even when I got the menu navigation working there were these other few things I had to change to make it playable as I played through the game.

• SteamVR inputAPI: Totally agree, just wanted to be able to play on rift this weekend rather than some point in the future. Maybe I can look into SteamVR Input API and support for non-Vive wand controllers #14 ...how does it work? Do you expose the thrust/6dof/joy as bindable axes to it? What about menu navigation/controller input when not grabbing those things?

• When running under SteamVR, the game does not pick up my controllers at all. Nothing. Can't bind anything in the controls menu unless it is mapped to a key/vjoy using your overlay. Is this normal?

• I guess the XR runtime is the OpenVR.xxx stuff? Could use a config.json in the app dir with mode='oculus', weirdstuff='on' etc instesad

• I've tried to copy your code style with the keyup/keydown stuff, the events from ActionsController were already there. Allowing elite to deal with the up/down events itself does fix the flakyness for me so it's probabbly the right thing to do. If you let me know how you want to implement it I can change it and break it off into a smaller PR. Note: pressing both "appmenu" buttons to reset view breaks this philosophy, and the combo doesn't even work here on my rift, should we reset in another way instead?

• Numpad buttons. As I said, I can't map my controllers without going through your overlay and mapping to key/vjoy. Left stick works for menus, I map the right stick to next/prev panel and next/prev page for working with the ui.

• Menu mode toggle. It's actually really annoying, I need to have menu mode active to interact with the panels, which I need to do all the time. I'd like to have one hand on a stick and the other doing menus (e.g. docking request whilst flying). Maybe this and the numpad stuff belongs better in the ActionsController so that it's "always on"? But it would need to be overridden when grabbing a stick for that hand. Menu mode if off when you are grabbing the stick, which is the only way to fire your weapons.

• I turn off the panel auto focus, it's too flaky for me. Plus I don't want to lose focus just because I glance at something else. Personal taste I guess. Perhaps the available mappings could go into that side by side config.json if this is a problem?

There's a lot of stuff here - I can split it into new/existing issues? Looks like:

• Rift menu navigation: This issue
• Flaky keyup keydown stuff: Vive Touchpad Navigation Inconsistent #64
• Menumode stuff Menu mode should be automatically activated #75

[dantman]

• Maybe I can look into SteamVR Input API and support for non-Vive wand controllers #14 ...how does it work? Do you expose the thrust/6dof/joy as bindable axes to it? What about menu navigation/controller input when not grabbing those things?

The primary barrier is ValveSoftware/steamvr_unity_plugin#108, getting the plugin to fully work for overlays. After that I create a list of various actions like Grab, TrackpadPress, TrackBtnPress, and so on... I think I've got a post it with notes somewhere. Or a partial idea in an abandoned branch. Then those actions are mapped to various actions instead of specific buttons being mapped. I'll also probably be adding an action set for menu mode and some Menu{Up,Down,Left,Right,Select,Back,PrevCategory,NextCategory} bindings so that it's possible to put different bindings on different controllers.

In-cockpit stuff like the 6DOF/throttle/joystick controls are not exposed to SteamVR Input. Instead we essentially expose basic actions and input like "What is the position of the hand", "Grab the object", "Pinch the object", "Pull the trigger", "Press a large trackpad", "Press a tiny trackpad", "Press a joystick", and so on. Which can then be bound to different buttons on various controllers. "Grab" can have three different actions to represent the 3 different styles (button press like on Vive, hold like on Touch and the Knuckles capacitance, and pinch like on Knuckles). Vive can bind the trackpad to the current large trackpad POV style, WMR and Knuckles can bind the small trackpad to a simple button press and drag POV, and Touch and Knuckles and bind the joystick to a Joystick style POV axis.

Then in the overlay we listen for things like an abstract "Grab" action instead of listening for the state of the grip button.

• When running under SteamVR, the game does not pick up my controllers at all. Nothing. Can't bind anything in the controls menu unless it is mapped to a key/vjoy using your overlay. Is this normal?

I don't know. I haven't exactly tried using a controller in awhile. And ED is already quirky when it comes to bindings in the first place.

• If you let me know how you want to implement it I can change it and break it off into a smaller PR.

I'm actually in the middle of a new key interface and action press handling system.

Note: pressing both "appmenu" buttons to reset view breaks this philosophy, and the combo doesn't even work here on my rift, should we reset in another way instead?

The double-menu is needed since menu is also secondary fire and one can be held down for that reason. It's also how other games do it. When the SteamVR Input API is available I'll have two separate actions for reset so on Touch you can try to bind it to a single extra key (hopefully the Oculus equivalent of the application menu button on one controller can be bound in SteamVR Input). Or I'll have one instantaneous binding and use coords to implement the hold 2 menu buttons behaviour (if coords are capable of doing it).

• Menu mode toggle. It's actually really annoying, I need to have menu mode active to interact with the panels, which I need to do all the time. I'd like to have one hand on a stick and the other doing menus (e.g. docking request whilst flying). Maybe this and the numpad stuff belongs better in the ActionsController so that it's "always on"? But it would need to be overridden when grabbing a stick for that hand. Menu mode if off when you are grabbing the stick, which is the only way to fire your weapons.

Menu mode isn't for interacting with panels. Menu mode is exclusively for interacting with the game's main menu and esc/pause screen so you can start the game and set control bindings. It outputs fundamental keypresses (arrow keys, space, escape) that ED understands in menus even when you don't have UI navigation keys bound to anything. It unfortunately had to be a toggleable mode because ED does not tell us when a game menu is opened; even though it's happy to tell us when you go from the System map to the Orrery view, when the ship lights are on, and when the music changes.

To interact with panels you bind the game's UI navigation bindings to the POV(s) on your joystick. The UI navigation bindings override whatever else you have bound to a POV when a panel is focused. So you can happily have say POV1-RIGHT bound to both "Next Target" and "UI Right" and it'll just work.

Basically you treat the joystick just like a real HOTAS and bind POV buttons the way you would bind them on a real HOTAS to control the cockpit's panel navigation.

• I turn off the panel auto focus, it's too flaky for me. Plus I don't want to lose focus just because I glance at something else. Personal taste I guess.

Ok. I guess it doesn't hurt to add some control button assets for those ship functions. Should double check there are good icons for them.

Personally I've actually had the exact opposite problem. I've had an accidental keyboard number key press focus on one of the panels leaving me unable to control my ship even after looking away at the panel. After that it was a mad fumbling with the keyboard to try and regain control.

[flavourous]

Basically you treat the joystick just like a real HOTAS

This didn't even cross my mind, I'll try it now but I bet it just works. Although I think the hats are only listened to when you are grabbing the throttle or joystick?

...list of various actions like Grab, TrackpadPress

I think I get it, user maps their controller to generic controller actions out of game with a config file, and then the generic actions get mapped in game like normal, you just have a big selection in edit mode to bind. I guess e.g. a POV hat action will be able to be bound differently for menumode, not grabbed, and specific to the grabbed throttle/joystick?

I'm actually in the middle of a new key interface and action press handling system.

Second reason for splitting keyup/down is so that holding the pov/stick down will continuously scroll instead of one at a time, but I look forward to your patch!

Hardcoding Rift mappings still leaves WMR users out. And it's a rabbit hole of manual mapping for every platform. Especially when this input system is deprecated. I want to switch to the officially recommended SteamVR Input API (#14). Then mappings can easily be made for Vive, Touch, WMR, and Knuckles.

In light of this actions stuff I will change my rift/vive specific stuff to large touchpad/joystick directionaction inputs, maybe configurable from one of the config files...I think this'll be more ready for the actions stuff, but I won't know until I look at that SteamVRInput stuff. Not sure if that helps.

I did read through ValveSoftware/steamvr_unity_plugin#108, seems like there will be a long wait or an overlay fork of thier project. Any advice? I understand not wanting to merge in further hardcoded input mappings, but making that fork is going to be tricky...I could post a release on my fork for rift that you could point your rift users to when I get it tidied up, but I'm not sure if you'd be cool with that.

[dantman]

This didn't even cross my mind, I'll try it now but I bet it just works. Although I think the hats are only listened to when you are grabbing the throttle or joystick?

Yes, you interact wit the panels while holding the cockpit's joystick.

you just have a big selection in edit mode to bind

In-overlay the generic actions are listened to by code to take actions. The mapping of controller button to generic action is done in SteamVR's interface.

I did read through ValveSoftware/steamvr_unity_plugin#108, seems like there will be a long wait or an overlay fork of thier project.

Honestly the necessary changes are extremely minor. If someone made a PR it would probably take awhile for Valve to get around to it, but it wouldn't be a big deal.

It's on my "Priority Issues" project list right after the map controls.

[flavourous]

Ok that makes sense, but I'll add something so I can use panels when not grabbing the cockpit sticks for myself, because otherwise I'll be crashing my ship while im in panels :D

That config screen looks cool, how do you get to it in SteamVR?

[dantman]

It's in the settings menu:
https://steamcommunity.com/games/250820/announcements/detail/3809361199426010680

Ignore whatever SteamVR has for the overlay for now. It'll be redone when I integrate the SteamVR Input API.

[flavourous]

I've tidied up the rubbish i wrote for picking up my rift controller on flavourous/elite-vr-cockpit/feature/riftJoystickForHat, and look forward to #14. I didn't even know that steam config screen existed, it looks really good!

Picked up your PressManager stuff - that's got the direction buttons working well in menus.

You were right about binding hats to menu keys for navigating the panels, but It does indeed cause "ship navigation issues", I guess you shouldn't text and drive! :D There's also no hats on the virtual thruster stick for binding to panel tab/page buttons. I'll create another issue around panel navigation - feel free to close this one in favor of #14.

Thanks for taking the time for all the chat and feedback, long thread here!