geoffda

Thanks so much! It might be worth adding some documentation around that. I see it in the AAO Specific RPN Commands section, but that is the only place it is mentioned and none of the examples use it. Anyway, thank you again for your quick response.

I'm trying to implement looping behavior in an AAO MSFS 2024 script. Here is what I've got in the editor: :loop·\n 49907·(>K:ROTOR_BRAKE)·\n (WAIT:100)·\n (L:SWITCH_499_A,·number)·0.5·>=·if{·(GOTO:loop)·}·\n However it doesn't appear that the GOTO ever executes. Here is what I'm seeing when I watch the script: Call: 49907 (>K:ROTOR_BRAKE) Pr2: 49907 (>K:ROTOR_BRAKE) Call: (WAIT:100) Call: BLK:C:\Users\xxx\OneDrive\Documents\LorbyAxisAndOhs Files\Scripts\af3ad8fa-1b30-4c2f-8d4c-f584da6af864,(L:SWITCH_499_A, number) 0.5 >= if{ (GOTO:af3ad8fa-1b30-4c2f-8d4c-f584da6af864|loop) } Pr1: 0.711 0.5 >= if{ (GOTO:af3ad8fa-1b30-4c2f-8d4c-f584da6af864|loop) } Pr2: (GOTO:af3ad8fa-1b30-4c2f-8d4c-f584da6af864|loop) The above watch seems to confirm that the predicate is true (which is what I'm seeing in the behavior window), so the GOTO presumably should execute. If I unroll the loop, I get the behavior that I expect, but I would prefer to use the loop along with a precise termination predicate. Interestingly, C:\Users\xxx\OneDrive\Documents\LorbyAxisAndOhs Files\Scripts is empty, so I'm wondering if that has something to do with my problem? Does anyone know what I'm doing wrong? Thanks!

Second that. My transfer of databases didn't go quite that smoothly, but I was able to make it work. In my case, restoring the backed up database appeared to work, but when I reopened AAO, none of my configs were present. What I noticed when looking at the configs in %USERPROFILE%AppData\Local\LORBY_SI\LorbyAxisAndOhsMSFS24 was that ConfigDatabase_MSFS2024_1.xml had been updated, but ConfigDatabase_MSFS2024.xml had not. Deleting the empty config and copying/renaming the 1st config appropriately solved the problem and I now have all of my MSFS 2024 configs moved across.

You ar the best! Thanks again. I'm guessing you will have made quite a few people happy due to your efforts here. It would have never occurred to me to combine the two bindings like you did.

Thank you so much! That did the trick! How on earth did you figure that out? EDIT: Looks like I need to dig into what you are doing with the MSFS Input Events...

Yeah, I forgot to mention that I tried putting a detent on the lowest value as well. That didn't work. Thanks for having a look.

I tried binding to the "Flaps Handle" sim axis, as well as the FLAPS_SET Flight Control Axis, but neither of those worked at all--that is, neither would trigger the VC flap lever to move. From the code, it looks like AXIS_FLAP_SET is correct; the input event seems to expect values on the range of -16384 to 16384.

In AAO if I bind my Honeycomb Bravo flaps axis to AXIS_FLAP_SET on the iFly 737 MAX8, the flap lever will move through to full extension properly, but then it won't retract beyond the Flap 1 detent. iFly is using the Asobo ASOBO_HANDLING_Flaps_Lever template, so they aren't doing anything wierd. The flaps are definitely set at 1 even though the lever on my controller is fully up. The VC lever is at the flaps 1 detent, the flap gauge shows flaps 1, and that can be confirmed in the external view. The sim sees HANDLING_FLAPS at 12.5% when it should be 0. It is possible that the value might briefly go to zero and then bounce back, but I can't be certain. It definitely isn't oscillating. If I make the same binding directly through MSFS, the flap lever behaves properly. The raw input that AAO says it is sending at the end of the axis is -16383 which is correct. When entered manually as p1 for AXIS_FLAPS_SET in the event debug window and executed (p0 is the previous flap lever position), the flap lever correctly moves to up. Since the bind works correctly in MSFS, I'm thinking that the problem is likely in AAO. I would assume if it were a software bug in the aircraft or a hardware issue, I'd be able to reproduce it with MSFS binds. Presumably, something that AAO is doing is causing the mouse rect for the lever to send incorrect input when the lever is at the end of the range. Anyway, I'm at a loss as to how to figure out why AAO is behaving differently. I didn't need to do anything other than set the bind in MSFS to make the lever behave, but I've tried deadzones and curves in AAO anyway. Nothing that I've tried worked. Any idea what might be going on or what further debugging I might try?

You are absolutely right! Looking at the XML, they are using different LVARs for animation versus input. Thanks for calling that out.

Wow, this is really a different implementation...If you just map LVARs, you won't hear the sounds. Wwise sounds are handled via separate LVARs that you can find in the sound.xml file. Here is an example of a script to press aileron trim left: 0·(>L:VC_AILERON_Trim_SW_VAL,·Number) 1·(>L:WASMVAR_iFly737MAX_AileronTrimSwitch,·Bool) With the script to release the switch 10·(>L:VC_AILERON_Trim_SW_VAL,·Number) 1·(>L:WASMVAR_iFly737MAX_AileronTrimSwitchRelease,·Bool)