Gamepad triggers for inertial forward/reverse?

[Rangoon]

I travel for work, and I was hoping I could play this on my laptop. I do other flight simulation with it, and I do bring a set of pedals. I just can't bring my usual HOTAS along. I have an XBOX Elite game controller. I am just trying this to see if it's even bearable to use this thing, but I can't sort out the throttle and/or inertial forward/reverse. I have right stick for rotational axes and left stick for strafing thrust. I would like to use my right trigger for forward inertial thrust and left for reverse (and throttle when in IDS). I can't seem to do that. I can set one trigger up as strictly forward throttle, but that then doesn't seem to also control only forward thrust if I am in inertial mode (it'll work as throttle, then up entering inertial mode, it goes into full reverse until I press the trigger).

What is the best solution for longitudinal thrust in my case? Or is setting one trigger to throttle really my only option. I can't even get throttle to work using one for forward and the other for reverse. If I set full range, then it treats the trigger like a centering axis. Is there some way to get it to treat both triggers as one centering axis for example? I guess it would average out the two inputs?

Thanks!

[Vice]

It might be tricky with variable input from them. A utility like XPadder might allow for changing input in custom ways. You could also optionally set the axis signals to the relevant button inputs to see if you can set it up that way. You'd need to map all 4 inputs, throttle up and down plus inertial forward and reverse to their respective button inputs in the Key/Button Configuration menu, but that may allow for an input scheme that would work.

[Rangoon]

Thanks for the suggestion. It does kind of work. The analog triggers then are reduced to buttons, right? I don't seem to be getting any analog element; it's either on or off. If that's the case, I may change to the shoulder buttons or something, then use a trigger as strictly forward throttle. At least then I have some basic analog control plus digital on everything else.

I'd rather not dig into XPadder, as I'm limited on time and I am prone to going down rabbit holes and getting lost for a week at a time. Wish I could afford that here.

Any other thoughts on this? If nothing else, I think this is workable to at least give it a shot.

EDIT: It actually doesn't work as I had hoped, in that the analog trigger as throttle overrides the button for throttle forward. So I can't get my throttle to set above 1 when trying to go forward with the same button I'm using for inertial forward. It sure would be nice to have an analog forward axis and an analog reverse axis, which should then work for both inertial and IDS. But it appears there is no way to do that at the moment. I will probably just try all four as buttons then. What would be even better is if I didn't travel and was home with my proper simpit all the time!

[Vice]

Buttons might be most feasible then. The control system is designed around a centered bi-directional principle for full range and inertial forward/reverse axis control, rather than separate mono-directional.

Would the Xbox Elite app help? According to one of their promo videos here below, it sounds like you can specify a range of input/output, including deadzone. I'm not familiar with that device or its software, but I thought I'd pass it along.

[Rangoon]

I can check that out, thank you.

However, I stumbled onto something else. VR controls using touch controls like VTOL VR appears to be implemented! I knew I was going to check out the VR mode, but assumed I would have to use another input method. But so far, this looks promising! I am pretty used to VTOL VR controls, so as long as I can use my left thumbstick as horizontal and vertical thrust, I think this plus VoiceAttack may be all I need.

And the VR looks incredible so far!

[Rangoon]

I am trying to wrap my head around the vrsetup.txt instructions, but I am a bit confused. Can I please ask a couple of questions to get me pointed in the right direction?

I would like to use my pedals for yaw, but use the right controller as pitch and roll. I see the paragraph at the end about "You can use the 'ContRSwtch' and 'ContLSwtch' button..." but they are both set to 2 by default. I'm not sure how to set this to get the right hand to be pitch/roll and the left hand to be only throttle (not also yaw, as it seems to override my pedals).

EDIT: I am using an Oculus Rift S with touch controls. I would like to set the left stick to vertical and horizontal thrust, and set right stick fore/aft to be the inertial thrust forward and reverse axis. Is there also a way to make the left hand throttle full range? It may not be the right choice, but to try it, is there a way?

Thank you!

[Vice]

The VR control system is quite separate from the rest and is probably more limited in its options by comparison. But if I am understanding what you're describing correctly, here are some options:

- The controllers are assigned optional flight control modes with predefined inputs. One flight control mode puts joystick inputs on one controller while the other assigns throttle inputs (so in the VR scene, it's like putting one hand on the joystick and one hand on the throttle).

- The ContR/LSwtch directives set a button for selecting the control input mode for each controller. So the number '2' assigned it by default is the second button on each controller. This function only changes the control mode.

- The ContR/LMdCap directives will lock each controller to a particular mode. So when you enable a flight control mode, it will automatically route to '1' for joystick or '2' for throttle as you define in these lines. So to lock each to a mode, enter '1' for the right hand value to use for joystick input and '2' for the left hand value to use for throttle.

- For the joystick flight control mode (right hand in your example), you can set a value of 2 to the 'Controller' line to select roll for left/right controller movement, rather than yaw.

- For full range throttle control, you'll need to enable the mode while in-game. I haven't tested this, but you should also be able to set throttle control to any axis on any device in the configuration menu, then check the box named 'Full Range' that appears once you've assigned a throttle axis. Then save and exit that menu, enter it again, then unbind the throttle axis you mapped earlier (click on the axis channel indicator, then click on the option for no axis control). This should preserve the full range mode even when using VR controllers and their separate control system (but again, not tested).

- As for stick inputs for each, I'm not sure how that might work out with the Oculus setup. One analogue input is typically assigned to strafe thruster control, yaw or roll on the other (depending on selected control mode).

So I'm not sure how much of that might align with the configurations you've described, but it sounds like some/most should. Anything beyond that may require the use of external software to apply custom signals through a device's axis or button inputs.

[Rangoon]

Thanks for the suggestions. Some of it is working. I did get it so that right hand is only stick and left hand is only throttle. That's definitely an improvement. However, I'm not really sure what changing the Controller line to =2 did. The description doesn't mention anything about what a value of 2 might be, and suggests that a value of 1 just tells the game to detect the presence of vr controllers etc. Nothing about changing the axes of one or the other. Is that the right field to change to set the stick to control pitch and roll rather than pitch and yaw?

Another thing I can't seem to solve is that the yaw input from my pedals only registers when I don't have my left hand acting as throttle. Once I grab the throttle, it ignores my pedals.

The right thumbstick is lateral thrust, which hopefully I can somehow switch to left thumbstick. I would like right thumbstick to either act as assigned buttons or as inertial throttle. It doesn't look like there will be a way to do that.

One more thing I am trying to sort out is why my hand no longer seems to roll (or yaw), but only inputs pitch. Maybe reloading the game will solve that.

Is there any further development planned for vr and vr control? VTOL VR has done a fantastic job coming up with an intuitive, effective, and immersive vr controller input scheme. I think it the same system would be excellent here, if that example proves useful at all.

EDIT: I do see now that Controller=2 changes right hand to roll. What was throwing me off is I was expecting to be able to roll my forearm (pronate/supinate) in order to get the roll (as in VTOL VR) rather than have to translate it left and right. It's very natural to be able to leave the hand resting on the leg and then simply roll it fore/aft, left/right to make inputs.

And the full-range throttle trick does work perfectly. This definitely seems to be how it's meant to be, too. Now, re-grabbing the throttle has it automatically positioned in the middle (at throttle value zero) rather than being force-jumped to the middle of the range from zero to full. That feels much more intuitive.

All that said, I guess without being able to use pedals, none of this really matters. And would really need to be able to change the thumbsticks and ideally use a rolling movement on the right hand to control roll. The VR scene is amazing. But I don't think I'll be able to come up with a proper control scheme for either the Xbox controller or the Oculus controllers. I really look forward to trying this out in my home simpit in VR with the full HOTAS setup, as this game is meant to be played. So hopefully come November I'll be able to come back and check it out. I sure enjoyed playing Evochron Legacy in the past. It's been a long time, but no other space sim holds a candle to the excellent flight model in Evochron. It feels so good to be able to do what you're supposed to do in spaceflight. So I will be back when I'm not so hamstrung by my travel kit. And/or if there is a more robust implementation of the vr controller support. I understand why it's not a priority.

[Vice]

Yes, 'Controller=2' is the value to use to swap the axis assignment from yaw to pitch on the joystick mode controller. That's not very clear in the instructions, so I'll write that in more detail for the next planned update.

If there is an active input from a controller for throttle (with roll assigned to the stick), then the yaw input will feed data from the controller, overriding other input. The VR control modes are an entirely separate and dedicated control mode that the GCS will listen to when enabled. Much like setting the flight control mode to Keyboard, Mouse, or Joystick. The game moves things over to the selected device input and adapts those signals for values the GCS can handle for consistent flight control (so they don't conflict nor result in different ranges). There currently isn't a way to disable one selective input from one device in a particular flight mode while simultaneously applying the same input from another device in a different flight mode (outside of multiple USB joysticks/gamepads/controllers using the 'Joystick/Controller' flight mode where that kind of arrangement can be done).

Although I'm not certain it would work, you can try at least mapping the axis inputs from the pedals to button inputs. There is a keyboard/button override in place for those inputs since all they return is on or off, rather than potentially using a conflicting variable value or range. It would at least provide yaw control on the pedals and it is tapered, so you could use a duration based input approach to limit the yaw. It wouldn't be the ideal option, but 'should' still work. I may explore such control schemes later, but blending/mixing mismatched control inputs from different non-standardized devices across separate flight control modes would not be an easy prospect. At least, not with the standardized way things are set up across 4 unique control modes and several input formats.

There isn't a way to swap strafe thruster control. That may be something I can evaluate as part of the effort as well. It would be useful to have an option like that.

Not sure on the roll/yaw issue. Maybe that channel just got lost or something else is overriding the input somehow (key or button mappings might counter something like that, if one or more is persistently active).

I may need to set a month or two aside to try and focus on what options might be feasible along those lines. It has been something on my list to check into for a while, but I've been extremely busy with a bunch of other goals, reports, and requests. So it keeps getting pushed back, lol.

[Rangoon]

Thanks so much for your help here, and I have decided not to give up just yet. I did edit my post above, stating that I figured out what was going on the with roll axis in the right hand. It makes sense now.

I understand it's a whole new dimension to implement this other control scheme. Again, if it's helpful, VTOL VR does allow separate physical pedals as input for yaw while also using the vr controllers for all other axes. I'm not implying it's an easy task, but at least we know it's possible to intermix the two technologies.

For now I will hopefully get used to the left thumbstick as my analog yaw (and I will check out the pedals as yaw buttons option you suggested). It would be great if the fore/aft axis of that left thumbstick could also be used for throttle set (and inertial thrust), but I can get by with VoiceAttack for that function, presumably.

There are so few buttons on these Oculus controllers, so I'm still a little concerned that they won't be feasible. I have a short list, which should barely fit, especially if I ditch one of the "pointer mode" buttons. Checking that out next.

[Vice]

I understand it's a whole new dimension to implement this other control scheme. Again, if it's helpful, VTOL VR does allow separate physical pedals as input for yaw while also using the vr controllers for all other axes. I'm not implying it's an easy task, but at least we know it's possible to intermix the two technologies.

Any input can be intermixed, it's not really a question of can, but of how in code. I'm sure the control systems between the two games are very different. It's more a matter of reworking/modifying an existing codebase that was never originally designed to take input from VR controllers and work that into a system with ranges and value sets designed for HOTAS, gamepads, mouse, and keyboard devices all in individual dedicated flight modes with individual dedicated input signal handles. Deciding what to prioritize and/or ignore and how to do so while also disabling other inputs on other devices selectively is a big part of that challenge. Manageable in a common flight control mode, not so much between different ones.

There are so few buttons on these Oculus controllers, so I'm still a little concerned that they won't be feasible. I have a short list, which should barely fit, especially if I ditch one of the "pointer mode" buttons. Checking that out next.

Yeah, VR controllers aren't really a good fit for the game overall, imo. There are just too many control options, many of which are important, to try and work into devices with only a few buttons/inputs. The holographic menus that appear when in a point mode can help provide access to those important options, but it requires pointing and clicking which isn't always feasible in a battle or under pressure. And trying to press a key on a keyboard can be pretty challenging when your view is blocked by an HMD. HOTAS + VR is a much better fit overall, both for tactile reasons and for available control options.

[Rangoon]

HOTAS + VR is a much better fit overall, both for tactile reasons and for available control options.

Hear, hear.

I do find myself very comfortable with the hands-as-controllers part, and so far find flying around very satisfying that way (in Evochron, XP11, VTOL VR, AeroFly FS2). Lacking the tactile aspect isn't much of an immersion breaker for me really. I fly helicopters for a living IRL, and I really don't think about physically manipulating those controls. Especially when hydraulics are involved, things are often so butter-smooth that it's really just mind-action, not mind-feel-move-action. Some controls on some helicopters can be uncharacteristically cumbersome. Depends on how they are rigged (or which mechanic rigged them lol). Like a Bell 206B/L collective is smooth as silk, a UH-1H is just a little stiff, while a Bell 212 with "dual hydraulics" can be very stiff by comparison (that one is still a mystery to me). So sometimes I feel the controls. But having a VR controller physically sitting in my hand and having it glide around without any resistance is basically what I'm used to IRL. Especially a cyclic. Bell 47 does have some odd feedback behaviors, or an R22, or an MD-500 with its force trim, but virtually everything else I've flown you hardly even know there's a physical linkage in the cyclic. It's just your hand moving through space while it happens to be making contact with a grip.

Some issues I'm coming across still:

1) taking my left hand off the throttle means I also lose access to the thumbstick for yaw. The problem I foresee with this is that I think taking my hand off the throttle and then setting a throttle position via VoiceAttack means I won't be able to yaw. So then putting my hand back on the throttle means losing the throttle setting and having to manually position it.
2) taking my right hand off the stick means losing access to the thrusters
3) "-2" as a button value seems to assign both thumbstick press and the "x" button (left controller) or "a" button (right controller). If I remove the -2 value, both go away (meaning it's not that the -2 is one of them and somehow the other is being assigned elsewhere). I cannot seem to discretely assign those two buttons. It's both or neither.
4) IDS via controller button doesn't seem to work (but I am testing in the basic movement tutorial and it occurs to me now that that is probably disabled).

Hopefully some of this will be helpful down the road.

But now I really can't wait to get home again to fly this properly in VR. Such a cool experience. I love seeing the 3D radar sphere in action. Looking around seeing my velocity vector off in some random place over my right shoulder - but somehow much better than when I was flying with TrackIR. I mean the TrackIR part was great, but having that experience in 1:1, virtual reality, just brings it to life. Thanks for making Evochron

[Vice]

Interesting, that does make sense, especially if it's a familiarity with extensive real-world experience. Bit envious of your line of work I've generally flown fixed wing (dad is a professional pilot and flew with him since I was very little), but rotor has always had an appeal. Ok, back to the issues at hand:

1 & 2 - Yeah, those are tied to having the assigned flight mode enabled. Sounds like you're describing switching from a flight mode to the point mode. Or maybe those controllers allow enabling/disabling input in some other way.

3 - That is strange behavior. -2 is supposed to enable the click input on a touchpad or thumbstick, but it wouldn't be the first time that supposed VR control inputs are inconsistent between different device types. There probably isn't the same kind of standard there is with DInput/XInput. Did you try the full range of possible options from -2 to -1 and then from 1 up to the limit on the device?

4 - There may be a mismatch between what is available on Vive controllers versus others. It almost sounds like there are some more possible unexpected inconsistencies.

Thanks for your support.

What I may do at some point is try some experimental changes to the control system to try and switch various input options on/off. I think one approach that might work, at least for the initial issues you encountered, would be adding the ability to selectively disable specific control inputs on the VR controllers to allow for supporting input from other control devices in other modes. In theory, you would then be able to enable the Joystick/Controller flight mode, map yaw to pedals, then keep the VR controllers enabled in the VR mode, disable the yaw input listener from the VR controller, then control yaw with the pedals. Something like that might be possible with new config options in the vrsetup file. Then if you're interested, I might send some test builds your way to see how they work out for what you're after.

The strange control input responses might be something else and may not have a solution if the library I'm using isn't able to parse specific button signals with the required listening options I have available to me.

[Rangoon]

My work does have its challenges (e.g. so much travel, not enough gaming!), but also can be very fulfilling.

I understand what you mean now about the control mode and how, currently, it's a one-at-a-time situation.

If you do get a test build, definitely feel free to send it my way. I would certainly appreciate your effort on this, and be more than happy to help! If I'm not swamped with work, I'll take a look right away. If I am, I'll reply with some idea when my next downtime might be. July and August are the only months that are usually 100% work. I might as well be on another planet during those months. Otherwise I get short breaks here and there, then mostly off in December and January.

[Vice]

In the effort to draft some plans for new/revised VR control systems, I'd be interested in a run through of what works in relation to the lists below as well as what doesn't work with your Oculus controllers as displayed (basically noting what is different than what these controls are currently bound to input for). Plus, how you would like to be able to swap the axis inputs around.

Since buttons are already swappable (although possibly responsive on more than one input as you noted), this would mostly be for options to move the axis inputs around.

Default VR Controller layouts:

Controller=1
Joystick (Flight Mode):
Left/Right = Yaw
Forward/Reverse = Pitch
Touch Pad/Stick Left/Right/Forward/Reverse = Strafe Thrusters
Trigger = Cannon(s)
Touch Pad/Stick Click = Missiles
Button 1 = Point Mode Switch
Button 2 = Flight Control Mode Switch
Button 5 = Countermeasures

Throttle (Flight Mode):
Up/Down = Set Throttle
Touch Pad/Stick Left/Right= Roll
Touch Pad/Stick Forward/Reverse = Inertial forward/reverse thrusters
Touch Pad/Stick Click = Afterburner
Trigger = IDS On/Off
Button 3 = IDS Up
Button 4 = IDS Down

Controller=2
Joystick (Flight Mode):
Left/Right = Roll
Forward/Reverse = Pitch
Touch Pad/Stick Left/Right/Forward/Reverse = Strafe Thrusters
Trigger = Cannon(s)
Touch Pad/Stick Click = Missiles
Button 1 = Point Mode Switch
Button 2 = Flight Control Mode Switch
Button 5 = Countermeasures

Throttle (Flight Mode):
Up/Down = Set Throttle
Touch Pad/Stick Left/Right= Yaw
Touch Pad/Stick Forward/Reverse = Inertial forward/reverse thrusters
Touch Pad/Stick Click = Afterburner
Trigger = IDS On/Off
Button 3 = IDS Up
Button 4 = IDS Down

[Rangoon]

I reverted to the default vrsetup.txt file, then tried Controller=1 and Controller=2. Here's what I found, regarding the Touch controllers for Oculus Rift S that I'm using.

First, a few observations:
Trigger and button X (left hand) seem to have the same assigned button number
Trigger and button A (right hand) seem to have the same assigned button number
Button 1 is Y (left and) and B (right hand)
There are effectively no Buttons 2, 3, 4, or 5
The Oculus buttons on each controller act as menu buttons (one is for SteamVR and the other is for Oculus)

As for confirming in the game vs what is intended...

Controller=1
Joystick (Flight Mode):
Left/Right = Yaw | Confirmed
Forward/Reverse = Pitch | Confirmed
Touch Pad/Stick Left/Right/Forward/Reverse = Strafe Thrusters | Confirmed
Trigger = Cannon(s) | Confirmed
Touch Pad/Stick Click = Missiles | Confirmed
Button 1 = Point Mode Switch | Confirmed
Button 2 = Flight Control Mode Switch | this works but it is the other hand's Trigger
Button 3 = IDS Up | Could not find a button that did this
Button 4 = IDS Down | Could not find a button that did this
Button 5 = Countermeasures | Could not find a button that did this

Throttle (Flight Mode):
Up/Down = Set Throttle | Confirmed (while held - if you let go, the throttle drops to zero)
Touch Pad/Stick Left/Right= Roll | Confirmed
Touch Pad/Stick Forward/Reverse = Inertial forward/reverse thrusters | Confirmed


Controller=2
Joystick (Flight Mode):
Left/Right = Roll | Confirmed
Forward/Reverse = Pitch | Confirmed
Touch Pad/Stick Left/Right/Forward/Reverse = Strafe Thrusters | Confirmed
Trigger = Cannon(s) | Confirmed
Touch Pad/Stick Click = Missiles | Confirmed
Button 1 = Point Mode Switch | Confirmed
Button 2 = Flight Control Mode Switch | this works but it is the other hand's Trigger
Button 3 = IDS Up | Could not find a button that did this
Button 4 = IDS Down | Could not find a button that did this
Button 5 = Countermeasures | Could not find a button that did this

Throttle (Flight Mode):
Up/Down = Set Throttle | Confirmed
Touch Pad/Stick Left/Right= Yaw | Confirmed
Touch Pad/Stick Forward/Reverse = Inertial forward/reverse thrusters | Confirmed

As for what I would like to change, other than being able to assign buttons (even repurposing the menu buttons hopefully), I would like to swap the thumbsticks separately from the stick and throttle. For example, I would like to have Controller=2, with the throttle hand thumbstick fore/aft being inertial thrust foward and reverse. And the joystick hand thumbstick controlling strafe thrusters.

I'm still concerned I won't be able to assign enough buttons for those urgent and immediate functions to be effective, so I do worry about you putting time into this and then it just ends up not being a feasible control method anyway. VoiceAttack can do amazing things, but as I get refreshed on how combat works in Evochron, I realize there simply not be enough buttons on these Oculus controllers to work. That's of course a hard limit of these controllers. You gain so much with the pitch and roll axes of the hands themselves, but lose too much in scarcity of buttons.

I I can repurpose the menu buttons (if that's even possible), I basically have:

Trigger
2 thumb buttons
thumbstick button
menu button

The grip button has to be for grabbing and letting go of the virtual controllers. You could get buy with one Point Mode Switch (probably use a menu button) though having one on each hand makes sense.

So, as one example:
Right Trigger = primary weapon
Left Trigger = secondary weapon
Right Thumbstick Button = IDS on/off
Left Thumbstick Button = afterburner
one or both menu buttons = point mode switch
That leaves four buttons. Countermeasures and I don't yet know what is most important. I assume targeting. It is hard to lose the numpad buttons for tansferring shield power, but no way you can make up for it. Hopefully VoiceAttack can do that quickly enough.

At any rate, it's a catch 22, since it's hard to test out button configurations until the whole control method becomes viable enough to fly and fight in the first place. You would have to put in the effort there, so that we can then test whether it's viable. But why put in the effort if it's not viable. So I understand you'd just have to decide whether there's value there.

I will also try a mouse, keyboard, and pedals setup next to see if that could somehow work. Or possibly invest in one of those single-hand game controllers like the ones listed here

[Vice]

Ok, that is very interesting. So the inability to access the options for buttons 3-5 is because the controllers just don't have the buttons. I didn't realize they were that limited.

When in point mode and the holographic menus appear, how do you feel those work for accessing things? To me, having to switch to point mode, then set something like shield array augmentation, then return back to a flight mode would seem time consuming. But some players report they are used to the same kind of thing in other games and can do well with it. If a flight mode is left active, then pointing to the holographic menus is still possible by rotating the wrist, but that's managing about 4DOF on one controller in open space to manage two flight axis inputs and a pointer at the same time :-) Seems kind of tricky.

I don't think it will be too much trouble to introduce flight axis bypasses and channel ID switches, but like you say, I'm not sure it will be of much benefit with the other limitations required by the hardware. The button limitations are probably going to be the most significant restriction. Additionally problematic if specific button indexes return two signals from the device and can't be separated (ie button 2 is also returning the trigger signal). In code, it's literally checking just one index (and in the case of the trigger, its own dedicated command for its analogue input, so not even a button index). I wonder what would happen if you swapped the '-2' value for the trigger check(s) to something like 3 that isn't even available... and if that would then allow button 2 to work on its own without any conflict with the trigger.

The on-controller menu buttons may be proprietary and unable to be swapped to an in-game function (at least with the library I'm using). Such controllers seem to be designed more for FPS games that only need a few buttons.

[Rangoon]

I haven't tried the point control mode much for actually getting anything done, let alone while actively maneuvering with hands on controls. That does seem like it would be really awkward and inefficient, but if others report it's working okay, it may just be a matter of getting used to it. And I noticed in the setup file that you can adjust how the menu itself appears in the scene, so perhaps you can customize that to a personal liking.

One thing about the point control mode: It might be appreciated by others as well to change the point beam angle so that it comes out at a 30- or 45-degree angle pitched forward from what it is now. I have to really tilt my hand forward (toward the floor) to get the beam to come out the way it does in Steam, Oculus, etc. in VR menus. Just a thought.

A lot may also ride on how the controllers behave when you let go of the stick and throttle. I can understand from an immersion standpoint that you don't want axis controls to work (even thumbsticks) when your hands are not on the virtual controls. A couple of thoughts on that:

Maybe it would make sense that when you let go of the throttle, there is a user preference to set where the throttle value sticks. And when you let go of the stick, it is user preference whether the stick input zeros out or remains where it was when you left it. At this time, it's kind of inconsistent. When you let go of the throttle, its value goes to zero. When you let go of the stick, it keeps doing what it was doing, but then goes to zero when you grab it again. I like that it reads a new neutral position when you grab it, so that you can rest your hand on your leg in slightly different places and it will always be considered 0/0 on X/Y. It's quick enough to get right back to whatever input you want. But I almost feel like it's better for throttle to default to the value sticking when you let go and the stick zeroing out. It's really hard to click the grip button to let go while also completely zeroing out the hand axis input.

As for buttons and thumbsticks working when you let go of controls, in a perfect world perhaps some of them would work and others wouldn't. In a game like this, where you're really not trying to match 1:1 with the in-game cockpit (like having HOTAS that mimics an A-10 while you're flying a Huey), having some tolerance there is a good thing. I would almost say all buttons and thumbsticks might as well be allowed to keep working even if hands are not on the controls. You need to be able to take hands off and have the *hands* stop inputting, otherwise you could not point around etc. without also unintentionally steering the craft. You can of course take the position that the virtual gun trigger is on the virtual stick, etc., so you have to be on that stick to use the trigger, and that would be understandable. Again, this argument is just in the interest of tolerance since we have enough limitations as it is. Games like VTOL VR also have a lot that you do with pointing fingers and touching in-game cockpit buttons and switches, so you're constantly on and off the controls other than the most urgent functions you use while your life is in immediate danger. It's a simplified cockpit, but also a simpler simulation overall. It was designed from the ground up with such limitations in mind. It can get away with having a more 1:1 simulation of what works or doesn't work when you take your hands off the virtual controls I think. A more lenient approach may be better here. Something to consider. Things might also be a little different if Evochron did have a VR clickable cockpit vs the point control mode (or alongside it).

[Vice]

Trying to change the pitch alignment of the pointer beam may be possible. Odd how it's different compared to other menus, it's supposed to line up with actual controller/hand alignment and point to the same spot. Guess that's yet another unexpected variation.

That's interesting on mode behavior, both the throttle and the stick should center when released. But maybe there is a lingering value somewhere that is not setting to zero for the stick like it was originally setup to do or a signal is continuing to get sent somehow. I could probably look into some kind of persistency setting.

I'll think I'll explore the axis changes and options first, to see how feasible those might be. If I come up with something along those lines that is testable, I'll likely reach out via e-mail and provide a download link so you can try the changes as things may progress.

[Rangoon]

I'll think I'll explore the axis changes and options first, to see how feasible those might be. If I come up with something along those lines that is testable, I'll likely reach out via e-mail and provide a download link so you can try the changes as things may progress.

Sounds good.

In the meantime, I think I will focus on a mouse/keyboard/controller setup that will get my by for now. I'm having much better and more immediate success so far. May be the lesser of all evils. I also think I will look into picking up a left hand controller since then I can create macros to build in the modifiers I asked about in the other post.

Thanks again for all the help here.

[Vice]

I've been going through the codebase in anticipation of making the big changes for implementing custom axis bindings for VR controllers and could not find any code-side reset of throttle input. Could you check to verify that there is no existing axis binding to throttle that you may have mapped to a different control device that may be centering it when you disable the VR control flight mode? The variable used to hold the value has no reset to center/0, so the only way I can guess that it would self-center when the VR controller is switched out of flight mode is if there is another control device feeding a secondary throttle control signal. From what I can tell, the throttle should remain where it is left when unbinding the VR controller handling throttle control from flight mode.

[Rangoon]

You could be right that at some point that is what was going on. I checked now and the throttle does remain where it was when I let go.

The stick, on the other hand, definitely does keep the deflection that was input when I let go.

Some other observations. When set to mouse input, being in point control mode allows you to pitch and yaw (or whatever mouse mode you have selected) with the pointer. This works in tandem with the actual virtual stick if you have it enabled. Just something to be aware of, something that players can stumble into, for better or worse, but not sure if it's intended. In some ways, this actually felt better to me than the regular VR mode because I could just roll my wrist around and get the results I wanted. I just didn't like the beam coming from my hand going all over the place. Of course also then the thumbstick won't work. But maybe there is an interesting option in there somewhere.

One problem I have with the throttle is that the range of motion too large. I almost want to just use full range because then I can keep my hand in a more normal position while still reaching full throttle. Then if I really want to, I can draw my left hand waaaaay back to get full reverse. But in normal throttle mode, I have to reach so far forward to get full throttle and still pretty far back to get full reverse. It would be nice if that could be adjusted by the user. I don't think it is in other games, but also haven't run into that as an issue in other games. Or maybe that already is adjustable in the setup file?

Another odd thing that was really throwing me off recently, and which came back again just now, is that sometimes, out of nowhere, the right hand fore/aft gets swapped with left/right. And not in a exact way, either. Left/Right clearly becomes pitch, but Fore/Aft doesn't exactly become roll or yaw. It's really hard to explain. This is also reflected in the animation of the stick in the cockpit. I saw this the other day, and assumed it was just some glitch that would fix on a restart or starting with a fresh setup file. Well several restarts later and at this point I can't seem to fix it. The only modifications I've made to the setup file are Controller=2 and the cap functions that tell left hand to only be throttle and right to only be stick. Those are all evident in the game now, but as soon as I fixed the point-control-mode-as-mouse-steering issue just now, this glitch popped up and I can't find any way to fix it.

I did change control modes around to keyboard and back to joystick/controller and restart the game each time, but couldn't fix it.

I also did make sure there were no other axes assigned. The only other weird thing about the assignments is that my pedals (the VKB T-Rudders MkIV) have only one axis. However, as a controller in the game, it shows a multitude (I assume they all do). But what's weird is that it shows axis 4 and axis 6 as being full left while all the others show centered and 5 as being the active axis. When I'm in the button assignment screen, it shows the 4- and 6- indicators all the time. Then, when I move my actual pedal axis, 5 goes to - or + or goes away. 4 and 6 constantly register as - . I assume no harm done since they aren't assigned to anything, but wanted to mention that in case you think it could in fact be problematic. If I open up Windows USB Game Controllers, the rudder axis shows up as X Rotation. X and Y axes show as centered (the crosshair in the joystick box, fixed) while Z Axis shows like a slider that is centered (fixed) and Y And Z Rotation show as sliders fully left (fixed). Just in case that's useful in some way.

[Vice]

Some control modes will likely be allowed to overlap. There can be times when a custom arrangement on modes and inputs may want to be blended by a player (I've run into this before with certain view control options and input devices for a few players). So I generally consider leaving such options in the hands of the player and they are welcome to disable or changes modes as they might want to.

Yes, you can adjust the range of movement input with the 'ContMovScl' value. Try changing that value to something like 0.5 and see if that provides a range of movement you might prefer. If that adjusts in the wrong direction, try 1.5.

The axis input swap sounds very strange. I'd suspect that there might be some other axis bindings linked to some other control device that may have come alive when you disabled the mouse point flight mode. But since you changed modes and it didn't affect anything, that wouldn't likely be it. Since the VR controllers are pretty fixed (unchangeable at the moment), I'm not sure how those signals could otherwise be swapped, unless there was literally a swap at a hardware or driver level. So some other external signal was one possibility that came to mind. Are any of the reverse axis values in the vrsetup.txt file perhaps enabled? A flaw in one of those invert options might have some kind of affect.

Indeed, as long as the pedal axis signals aren't mapped to anything, they should have no impact.

[Rangoon]

I will try again tomorrow perhaps (though work may get in the way of things the next few days). The only reason I don't think it was an Oculus or Steam VR error is that the pointer still works fine. So it's detecting the controller movement just fine, but wires are getting crossed between there and the game somewhere.

So maybe a system reboot, start from a fresh setup file, and see what happens. Hopefully I can at least pick up on the exact moment it goes haywire. It seemed this time like it was when I changed the control method from mouse to joystick. But in the past, I hadn't yet even tried mouse control input, so it wasn't that exactly the first time it happened. Hopefully can detect a pattern soon nevertheless.

[Rangoon]

A couple other things crossed my mind. I don't recall if I asked this already, but why would the thumbstick buttons and A/X buttons be merged here when not in any other game? I only mean to clarify that this is not an Oculus thing to merge them, but more like a faulty ruleset you were given or something where every other brand of vr controller is standardized except Oculus.

Also, in your default layout, no buttons are attributed to the throttle hand.

Are the missing 3-5 also supposed to be distributed across both hands somehow?

Thinking out loud here....
-2 is thumbstick press (and A/X)
-1 is trigger (digital)
What is 0 supposed to be?
1 is point control mode switch on both hands (as it is in the setup file)
2 is the grab button (I misunderstood your meaning earlier and thought flight control mode meant IDS on/off, but this is in fact correctly the flight mode switch, i.e. stick, throttle, off - very sorry for the confusion there)

In the setup file, IIRC, none of the L/R settings seemed to work properly to actually assign the L vs R hand buttons. Whenever I had tried to assign things that way, they did not work as expected for separating the two controllers. I tried a few things, don't recall exactly what, but nothing in that regard was getting me the results I had expected.

ContL/RInert=-1 for both does assign IDS on/off to the throttle hand trigger.
ContL/RCanon is also default -1 for both and does assign primary fire to stick hand

I should try again to split out L and R values and see if I can figure out what was or wasn't working with that.