Enhanced reverse thrust lever behaviour

[Pils]

Hi Tom/Jan,

I had originally planned to post this as a bug report, but on second thoughts it occurred to me that the current behaviour may be a deliberate choice as a "sim-ism"/affordance to limited hardware/whatever. On the other hand this might be a regression in V1.5, it's been too long since I was using V1.3, as previously mentioned. Feel free to file this as you see fit.

I'll happily be corrected by y'all on any of this, but from what I've been told I believe this is roughly how the reverse thrust levers work irl:

1. The reverse thrust levers are mechanically "locked out" from being moved while the forward thrust levers are above idle;

2. When the reverse thrust lever is pulled up to the deploy/idle position, the reverser "door" is unlocked and starts translating (not sure the exact lever angle this happens);

3. There's an interlock at around 1/3rd of the reverse thrust lever travel that prevents the lever from being pulled any further (above idle) until the door is translated (I read somewhere that the interlock disengages at 60% translation, but that could well be wrong, I'm sure it's in some technical manual y'all have access to);

I did some testing on V1.5 with the basic "toggle reverse" command, which by default is assigned to Shift+/, and from what I can see (without going into datarefs), the current behaviour is as follows:

1. If forward thrust levers are not at idle and reverse is toggled as above, the forward levers quickly move to idle, and it seems the reverse thrust levers move to a position that corresponds to the same relative position in the range of the reverse thrust levers as the forward thrust levers were at the time of activation. For example, if forward thrust levers are at 50% of their range and reverse is toggled then the reverse thrust levers move to 50% of their animation range (ignoring the fact that the lower third or so of their range is "below" the interlock).

2. If reverse is toggled while the forward thrust levers are at idle, the doors translate and the unlocked lights illuminate amber, however the reverse thrust levers do not move.

3. While the doors are still translating, reverse thrust can be increased above idle (for example by moving the throttle axes I have on my hardware throttle), with the corresponding relative movement of the reverse thrust levers in the 3D cockpit.

Having said all that (sorry it's a long post!), my suggestion is to enhance the simulation of the reverse thrust system as follows:

1. Inhibit reverse thrust activation, hence movement of reverse thrust levers above "stowed" position, unless forward thrust levers are at idle;

2. Limit reverse thrust to idle, hence movement of reverse thrust levers past the interlock, until doors are sufficiently translated;

3. Animate the reverse thrust levers in the 3D cockpit to reflect the state of the system.

Having worked with Toto on the Challenger's throttle behaviour I understand the way X-Plane handles reverse thrust can be a bit wacky under the hood (and there's like at least 4 different ways for the user to control it). And I'm not sure how much of the current behaviour is Laminar default, etc. So I appreciate it might not be the easiest thing to override from an add-on.

Thanks a lot for your consideration.

-Pils

Edited September 27, 2023 by Pils

[Litjan]

Hi Pils,

the reverse action is pretty much not changed or scripted by us - it is default X-Plane behavior.

I agree that it would be more realistic to require the user to have the levers at idle first before being able to engage reverse thrust, but I also have to concede that the movement is much more natural in the real aircraft - you can´t really attempt to pull up the reverse levers with the throttle NOT at idle, the force pulling them up and back will automatically move your thrust levers to the aftmost position.

In addition (although this is not a prime concern of me, as my stance is always realism > user experience), we would get a million bug reports "OMG, reverse is broken, WTF!!!!!!!" if we implemented this ;-)

But yeah, you are technically correct!

Cheers, Jan

Edited September 27, 2023 by Litjan

[Pils]

7 hours ago, Litjan said:

my stance is always realism > user experience

That we mostly share, unsurprisingly.

7 hours ago, Litjan said:

we would get a million bug reports

I can definitely appreciate that concern. A compromise would be to at least improve the animation of the levers to reflect the existence of the deploy/idle position and the interlock. I missed having that visual feedback in the 3D cockpit.

Thanks.

[Litjan]

14 minutes ago, Pils said:

That we mostly share, unsurprisingly.

A position that is shared with Tom here at IXEG... however in my position at LR as a technical advisor I find it under assault surprisingly often .

[Bulva]

@Pils    I also missed the reverse lever animation in XP11 when I used the default "hold thrust reverse at max #1;  / #2" command.
If you use the FlyWithLua plugins, you might want to take a look at this tiny lua script of mine that adds a bit of animation for the reverse levers.
You just need to assign commands to your hardware:
- IXEG_REV1
- IXEG_REV2
(for individual engines).
I use this script with my Bravo until professional IXEG animation comes out    ;-)

TB_IXEG_REV.zip

[tkyler]

@Pils

I can say that the throttles / reverse lever operation, in general are a decade old paradigm and have always bugged me a little bit.  As usual a "usability pass' is in order where we evaluate every control / animation and think of better and more robust was to interact with these things.

In the early days, we were limited by several "isms" with X-Plane for sure, but I think we have more leeway now and can use PREFs to cater to differing preferences ...so we'll be looking over this again I'm sure.    I'm looking to animate more controls over time as I 'weave' some of my library animation code from the MU2 back into the IXEG.

-TK

 

[Pils]

7 hours ago, tkyler said:

As usual a "usability pass' is in order where we evaluate every control / animation and think of better and more robust was to interact with these things.

I figured this stuff is on your mind but also figured having a link to a post in your little document can’t hurt.