Oculus Touch thumbstick inputs

[shadow7483147]

Hi, I've started trying to setup the controls for my ship but there's a couple hangups in the process: Do I have to continually grab onto the joystick to be able to use the POV switches? I'd like to be able to relax my hand when out of combat. Secondly, is there a way to get separate POV from the left or the right thumbsticks? Finally, using the thumbstick is way too sensitive and tends to "hang" onto an input for a split second. Changing the deadzone in the SteamVR binding didn't seem to affect it.

Edit: The ability to hold down an input in the edit menu for multi-button input might be nice. For example, holding the thumbstick clicked+POV left or right might be a nice previous/next tab switch. And the control would be defined in Elite Dangerous' control scheme, rather than in the VR cockpit app. Editing the ED controls xml file to use joystick buttons as modifier keys works as expected.

Edit2: So in summary, there's an idea for having different sets of buttons depending on whether the virtual throttle or joystick is gripped or with nothing being gripped, and of course separation of left/right button sets. Currently the Virtual Cockpit acts as a HOTAS controller inside of the HMD following the schema for VTOL VR, rather than the HMD's controllers being the HOTAS, and this is fine and intended. There are still other higher priorities that need to be tackled first; thruster 3DOF and reverse lock.

Otherwise, the thumbstick magnitude being instantaneous for Oculus Touch controllers is recognized as a bug.

The request for the edit panel to accept modifier inputs was probably a visual bug as well, since the selection box stays on what you've selected after you've clicked on it. Trying to use both hands on the edit panel at the same time will result in them fighting eachother for input over the panel. Not a related issue to this thread, though.

Edit3: Solved! Go to the bottom of this thread for more details.

[dantman]

Do I have to continually grab onto the joystick to be able to use the POV switches? I'd like to be able to relax my hand when out of combat.

Yes, the POV switches are on the joystick itself.

If you're fine with grabbing the controls but just have a hand strain issue with Oculus Touch's grip buttons. You could go into the SteamVR Input and swap the grip buttons from "Grab (Hold Only)" to "Grab (Toggleable)" that will make the grip button behave like the one on the Vive controller. i.e. You can quickly tap the button to grab onto the joystick but not need to keep holding the button.

Secondly, is there a way to get separate POV from the left or the right thumbsticks?

In the future I may add a POV to the throttle. However I haven't yet because there are a bunch of other features (thrusters and reverse lock) I have to implement that may conflict with thruster POVs before I have an idea of the best way to do thruster POVs.

Finally, using the thumbstick is way too sensitive and tends to "hang" onto an input for a split second. Changing the deadzone in the SteamVR binding didn't seem to affect it.

Do you mean the cockpit joystick? The joystick does have a deadzone I'm thinking of getting rid of.

For example, holding the thumbstick clicked+POV left or right might be a nice previous/next tab switch.

Moving a thumbstick while it's being pressed doesn't seem like it would be a very comfortable interaction to me. Also seems like it would be easy to get unintended inputs.

[shadow7483147]

Thanks for the quick response!

Do you mean the cockpit joystick? The joystick does have a deadzone I'm thinking of getting rid of.

Ah, that explains another quirk I found then. The deadzone needs to be defined on ED's end in my opinion, yeah. The cockpit app is just the program that passes the axis from the controller orientation to the game/vJoy, since the app is the virtual joystick.

Edit: Since there's a visual indicator for the throttle's deadzone, maybe it is not the best idea. Maybe you can make both options available with a deadzone slider in the edit menu.

But no, even a tiny millimeter-sized offset from center on the thumbstick will trigger the menu's arrow key inputs, or POV inputs.

For example, holding the thumbstick clicked+POV left or right might be a nice previous/next tab switch.

Moving a thumbstick while it's being pressed doesn't seem like it would be a very comfortable interaction to me. Also seems like it would be easy to get unintended inputs.

In a sense? It takes a fair amount of force to push down on the thumbstick to click it. More force than a Vive touchpad, I would believe, if my Steam controller is anything to go by. It's also about as hard to push down as my Thrustmaster throttle as well. It's not of huge consequence since the thumbstick is only being used as a directional POV, the precision you would get from a lighter grip on the stick amounts to no use here, and my specific use case (UI panel tabs) is only done in short bursts every few minutes.

This could be generalized to any possible joy button combo, eg. A or X + thumbstick left, so it isn't just thumbstick clicking.

[dantman]

The deadzone needs to be defined on ED's end in my opinion, yeah. The cockpit app is just the program that passes the axis from the controller orientation to the game/vJoy, since the cockpit is the virtual joystick.

I added the deadzone a long time ago. I thought the joystick would be more prone to unintentional input than a physical joystick and it would make controlling harder. And I didn't know much about ED's deadzone or expect users to configure it at that time. I did consider making the deadzone configurable when I finally had an options page.

But that turned out not to be the case and one combat player likes the more precise controls. So I'm considering removing the deadzone.

But no, even a tiny millimeter-sized offset from center on the thumbstick will trigger the menu's arrow key inputs, or POV inputs.

Actually I think you're right about that. I'm not actually using a magnitude in the joystick handler. The Index thumbstick worked perfectly fine without any magnitude and I'm not sure what kind of magnitude would even work for everything.

The deadzone however in the SteamVR bindings you would of course expect to solve this. So that not working does sound like a bug. Though perhaps a SteamVR bug that needs to be worked around in some way.

Moving a thumbstick while it's being pressed doesn't seem like it would be a very comfortable interaction to me. Also seems like it would be easy to get unintended inputs.

In a sense? It takes a fair amount of force to push down on the thumbstick to click it. More force than a Vive touchpad, I would believe, if my Steam controller is anything to go by. It's also about as hard to push down as my Thrustmaster throttle as well.

Clicking is fine of course. The issue though is how easy it is to move it while still holding the button down. Or how good it is for the joystick. Isn't that the kind of action that broke many Index thumbsticks?

[shadow7483147]

Isn't that the kind of action that broke many Index thumbsticks?

Probably! Games like CoD use this control for sprinting and I don't expect Valve (or Oculus) products to have nearly the same build quality as Sony's dualshock, but regardless, holding down a momentary button whether it's a thumbstick or a mouse button may likely kill it. Had a mouse die in Overwatch playing Orisa a while back. I'll just use the trigger as the modifier instead of the thumbstick then. It's only one less degree of control.

Edit: I've gone back on this and went with using the clicker as a modifier anyway. That's 2 and a half modifiers, one for each available finger on the sticks. This should provide a fully ready HOTAS supplemented by the ingame cockpit buttons. It's made with one-handed control in mind for simple actions such as requesting docking permission, but requires you to hold the throttle for more intensive activities.

I kinda like how you have to grab the stick to control UI now, weirdly enough? It's sort-of a physical element in the game you need to use in order to interact with it.

Would be funny if there was a hand model that flashes at you telling you to grab it if it's not held. (HL:Alyx hand hinting)

I will still need to write the XML file to test these modifiers, but judging from how the last one went, it should be alright.

Edit 2: Test complete. Surprisingly, modifier stacking works exactly as you'd expect it to (ex. ctrl+shift+key vs ctrl+key or shift+key). However, any key used as a modifier cannot be used as a button input, otherwise the input will override its ability to be a modifier. Posting the binds here shortly.

[shadow7483147]

Oh hey, one more thing I can add now that I think about it. I was trying to find a way to bind POV2 to the thumbstick but realized this was probably just the Vive's "scrolling" feature, again similar to the Steam controller's trackpad.

I was interested in the idea of having the thumbstick trigger several button presses every half second while it was held in a direction, instead of inputting once every time it changes direction, but apparently that's not the case here.

In that way it could act like how the Oculus and SteamVR dashboards emulate a mouse scroll wheel.

[dantman]

Oh hey, one more thing I can add now that I think about it. I was trying to find a way to bind POV2 to the thumbstick but realized this was probably just the Vive's "scrolling" feature, again similar to the Steam controller's trackpad.

POV2 is a binding there for controllers which have inputs that are capable of representing multiple axis. Which is basically everything except Oculus Touch (and now Cosmos and the newer HP Reverb g2 controllers). The Vive trackpad can represent 2 axis with the large trackpad using swipe or edge scroll. And the Valve Index controllers and older WMR controllers both have both a trackpad (POV1) and a joystick (POV2) allowing for multiple POV inputs.

I was interested in the idea of having the thumbstick trigger several button presses every half second while it was held in a direction, instead of inputting once every time it changes direction, but apparently that's not the case here.

I'm not sure what you want that for.

In that way it could act like how the Oculus and SteamVR dashboards emulate a mouse scroll wheel.

Are you referring to UI navigation? Most of ED's menus have their own repeat functionality when the UI direction bindings are held down. They go faster when you hold down longer and they seem more reliable than attempting to emit multiple press events (which ED may miss causing a button press to be skipped if I send them too fast). That's why I specifically updated all the button presses (except trackpad swipes) and joystick directions so that when they are held down, the vJoy button sent to ED is held down for as long as you are holding the button down. So if you hold down a button with a UI binding ED will see you holding the button and trigger its repeat behaviour.

[shadow7483147]

Are you referring to UI navigation?

That and other controls, such as UI tabs and power distribution. While a majority of the UI does repeat while the button is held on its own, a select few cases don't. Either way, it's nothing anyone should be concerned with, not to mention ripe with binding conflicts.

Edit: So in summary, there's an idea for having different sets of buttons depending on whether the virtual throttle or joystick is gripped or with nothing being gripped, and of course separation of left/right button sets. Currently the Virtual Cockpit acts as a HOTAS controller inside of the HMD following the schema for VTOL VR, rather than the HMD's controllers being the HOTAS, and this is fine and intended. There are still other higher priorities that need to be tackled first; thruster 3DOF and reverse lock.

Otherwise, the thumbstick magnitude being instantaneous for Oculus Touch controllers is recognized as a bug.

The request for the edit panel to accept modifier inputs was probably a visual bug as well, since the selection box stays on what you've selected after you've clicked on it. Trying to use both hands on the edit panel at the same time will result in them fighting eachother for input over the panel. Not a related issue to this thread, though.

[shadow7483147]

Alternative solution: Why not express the thumbstick as an axis instead of a POV in vJoy? Elite already handles axis +/- as button inputs well.

With SRV driving in mind this will allow the cockpit joystick's tilt to drive the vehicle, while the thumbstick aims the turret. Among other things.

Edit: If it’s possible, the other overlays can be mapped to the same axes as the joystick, so as to not make a ton of vJoy device axes. It seems a little silly having a whole separate axis for the galaxy map and zoom, when these overlays are never used simultaneously.

[dantman]

Alternative solution: Why not express the thumbstick as an axis instead of a POV in vJoy? Elite already handles axis +/- as button inputs well.

There aren't enough axis to do so. They also kind of loose meaning as far as naming. If I do any axis stuff on thumbsticks it's probably going to have to be mapping to an existing axis (e.g. mapping a throttle axis to the same thruster axis the 6DOF controller uses if you want to use a thumbstick axis for thruster control).

With SRV driving in mind this will allow the cockpit joystick's tilt to drive the vehicle, while the thumbstick aims the turret. Among other things.

Is there a turret axis binding? Last time I tested you controlled the turret with the SRV joystick by switching to the turret. I don't recall a bindings to control the turret while driving.

Edit: If it’s possible, the other overlays can be mapped to the same axes as the joystick, so as to not make a ton of vJoy device axes. It seems a little silly having a whole separate axis for the galaxy map and zoom, when these overlays are never used simultaneously.

Separating the joystick and galaxy map axis was done intentionally to fix a bug I had when they were the same that was otherwise unfixable.

ED has a large delay when it updates Status.json. As a result when you switch from the cockpit to the galaxy map the galaxy map is actually open and accepting input for a few seconds before the overlay knows you're now in the galaxy map instead of the cockpit. As a result the overlay ends up sending joystick axis for a few seconds while ED is accepting galaxy map axis.

This had the unfortunate and very jarring effect that if you used the joystick POV to select the "Galaxy Map" button on the cockpit panel and happened to continue holding the joystick. Then that joystick axis input could make the galaxy map move drastically off target or zoom all the way out before the galaxy map controls showed up.

[shadow7483147]

Is there a turret axis binding?

Yeah. You just need the throttle axis, steer axis, and the two turret pitch/yaw axes. Right now I have them on the thumbstick POV and it’s some really harsh on/off control, compounded with the sensitivity issue. Or I could just give up steering (and midair thrust control) to be able to control the turret with the joystick.

Or, I could just swap the two and make the steering have on/off left/right thumbstick steer (and also lose midair control)

Super rare case, not gonna happen in 95% of gameplay, but it’s possible with physical HOTAS and you look cool while doing it. It’s what WASD(QERF)/mouse XY was made to handle on a keyboard.

The turret already has some amount of gimbal aim when you’re out of the turret cam though. It only switches to fixed fire while in the turret camera.

There aren’t enough axis to do so.

Eh, yeah. I figured. So making more vJoy devices is out of the question?

[shadow7483147]

Solved, turns out I was using the EliteDangerous64 SteamVR binding window, when I should be binding the Cockpit app's binds.

Set my deadzone here and it's all good now! Just throttle POV left to go later on.

[dantman]

Eh, yeah. I figured. So making more vJoy devices is out of the question?

Technically I could. Of course each one I do means more manual config and more naming confusion (ED uses "JOY-X" for the X axis on all devices so you don't know if "JOY-X" is device 1, device 2, etc). But the biggest problem IMHO is the device order issue. I encountered an unexpected bug before where Windows decided to re-order the vJoy devices. So vJoy Device #1 was device 2 and vJoy Device #2 was device 1. It wasn't immediately obvious and required either rebinding everything or editing the ED config to swap the device numbers. This issue may get even more out of hand if I have even more vJoy Devices and it becomes less and less obvious what device is what in the binding config.

[dantman]

Solved, turns out I was using the EliteDangerous64 SteamVR binding window, when I should be binding the Cockpit app's binds. Set my deadzone here and it's all good now! Just throttle POV left to go later on.

Good to know that's not a SteamVR bug I have to workaround.

In edit mode the "Controls" panel the panel has an edit button which is a shortcut to the overlay's SteamVR Input bindings page in the settings. There's also a button on the desktop view to open it up.

I thought SteamVR didn't include the overlay in the application list at all since it's not published on Steam (I've never seen that item in the list). So I made sure it was easy to open the bindings from the overlay itself.

[shadow7483147]

Hmm. What if I could instead express the gripped joystick/throttle as a modifier? Make it a button whos state depends on whether they are grabbed. The edit panel can set that modifier + Primary/Secondary/Alt, or POVs, when clicked in the edit menu.

That way, it can allow for using the raw inputs on the HMD's controllers, and you would not have to fear of binding conflicts, since the Grabbed modifier button overrides open hand button presses. (Shift+Z overrides Z)

This does require users rebind their controls, though... And I haven't checked how the game handles multiple modifiers. (Shift+z and ctrl+z, but no ctrl+shift+z bound). Realistically, not a single person is going to be using their throttle/joysticks on their cross-hand, I believe.

The virtual axes, of course, will only update when grabbed, and reset when released, so no modifier is required here. (Elite doesn't support it anyways)

Nah, dumb idea.

[dantman]

I'd have to rewrite the whole POV handling code. Which is designed to map POVs on the virtual controls to HOTAS bindings (like a real HOTAS), not map controller buttons to bindings. And things would fall apart if I add thruster axis instead to the throttle, SRV turret axis to the joystick, or the reverse lock to the throttle.

I do have plans for better UI controls. But no plans to let the a/b/thumbstick/trackpad bind to something in the cockpit when you're not grabbing anything.