Hey Lorby!

 

Discovered an issue when using "Adaptive" key repeat feature. Wondering your opinion on whether you think an enhancement is in order, or whether users should just be wary when using certain scripts.

I have a TM Warthog throttle which has a thumb switch for speedbrakes/spoiler. In the forward position (the position you'd use to close the spoilers), the switch physically holds itself forward.

 

When you use this script with "Adaptive" enabled:

(A:SPOILERS HANDLE POSITION, Number) 0.0 > if{ (A:SPOILERS HANDLE POSITION, Number) 0.1 - } els{ 0.0 } 32767 * -16384 + (>K:AXIS_SPOILER_SET)

...leaving the spoiler switch in the close position eventually results in the adaptive feature crashing AAO because it cascades requests at a extremely high rate and never stops. 

Would it be possible to have the "Adaptive" feature check whether the axis has reached its min/max and stop sending the requests to prevent crashing AAO? It also results in overloading MSFS with requests...took me a while to figure out what was going on.

Anyway, thanks for reading. Let me know if I didn't make sense.

 

 

 

Edited April 5, 20224 yr by jstnj

You are causing an endless loop - there is not a lot that AAO can do about that. To avoid "out of range" errors, use the "min" and "max" RPN commands in your script. Your script has to handle range, AAO can't do it for you.

The core issue here is using repeat with a button that actually locks in place and never gets released. That IMHO is not how this should be used. There is no way to tell the repeat logic that it should stop at some point - it doesn't know what you are doing with it, nor does it care. There could be a million different use cases that would all require different criteria - in implementation and for the user to figure out. That is not an "enhancement", this is a massive effort in implmentation and later in handling. And it would still be possible to cause the same issue any other way.

IMO you should do this differently, for example with automated scripts. So that the button movement doesn't control the script itself, and you don't use repeat. Instead the button sets a local LVar to -1, 0 or +1 and that tells an automated script to either move the spoilers up or down or not at all. And when the script runs "out of range", you reset the LVar back to 0.

The automated script would looks something like this: (not tested, off the top of my head)

(L:SpoilerDir)·0·!=·if{·(A:SPOILERS·HANDLE·POSITION,·Number)·0.0·>·if{·(A:SPOILERS·HANDLE·POSITION,·Number)·(L:SpoilerDir)·10·/·+·}·els{·0.0·}·32767·*·-16384·+·0·min·16384·max·s0·(>K:AXIS_SPOILER_SET)·l0·0·==·l0·16384·==·or·if{·0·(>L:SpoilerDir)·}·}

Edited April 5, 20224 yr by Lorby_SI

1 hour ago, Lorby_SI said:

You are causing an endless loop - there is not a lot that AAO can do about that. To avoid "out of range" errors, use the "min" and "max" RPN commands in your script. Your script has to handle range, AAO can't do it for you.

The core issue here is using repeat with a button that actually locks in place and never gets released. That IMHO is not how this should be used. There is no way to tell the repeat logic that it should stop at some point - it doesn't know what you are doing with it, nor does it care. There could be a million different use cases that would all require different criteria - in implementation and for the user to figure out. That is not an "enhancement", this is a massive effort in implmentation and later in handling. And it would still be possible to cause the same issue any other way.

IMO you should do this differently, for example with automated scripts. So that the button movement doesn't control the script itself, and you don't use repeat. Instead the button sets a local LVar to -1, 0 or +1 and that tells an automated script to either move the spoilers up or down or not at all. And when the script runs "out of range", you reset the LVar back to 0.

The automated script would looks something like this: (not tested, off the top of my head)

(L:SpoilerDir)·0·!=·if{·(A:SPOILERS·HANDLE·POSITION,·Number)·0.0·>·if{·(A:SPOILERS·HANDLE·POSITION,·Number)·(L:SpoilerDir)·10·/·+·}·els{·0.0·}·32767·*·-16384·+·0·min·16384·max·s0·(>K:AXIS_SPOILER_SET)·l0·0·==·l0·16384·==·or·if{·0·(>L:SpoilerDir)·}·}

Thank you sir! will give this a go. All of that makes sense to me.

I may have another idea, but that is a code change too (so if it works, it will be in the next version of AAO). I will look into adding a "max repeat" parameter where you can set the maximum number of repeated actions that make sense for this button. After that it will just release itself. 

And I just realized that when using min and max you don't need to query the variable at all, because the code limits the value anyway.. So that if/els around the calculation of the value to set is unnecessary.

AAO 2.29 will have a "limit" option. With that you can tell the app that the repeat should stop automatically after X actuations.

On 4/6/2022 at 3:26 PM, Lorby_SI said:

AAO 2.29 will have a "limit" option. With that you can tell the app that the repeat should stop automatically after X actuations.

Thanks Lorby, responsive as always 👍

9 hours ago, jstnj said:

Thanks Lorby, responsive as always 👍

If you want, send an email to the support address with your proof of purchase, then you can have the 2.29 to try it. That should solve your particular issue.