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)

Old thread, but I'm encountering this very problem on Windows 11 and it looks like the issue has to do with MCE using the wrong paths for things. There are going to be two "Documents" folders for anyone using One Drive and syncing (as I am). One will be under \Users\<user name>\Documents and the other will be under \Users\<user name>\One Drive\Documents. In my case, the Multi Crew Experience folder is getting created under Users\One Drive\Documents, but Process Monitor shows that the Simbrief integration code in mce.exe is expecting it under \Users\<user name>\Documents. When it tries to create the .dat files, that fails because the path doesn't exist. If I manually create the Multi Crew Experience folder there, I get a bit farther--the .dat files get created, but then I'm stuck with "Waiting for Simbrief data". The dat files are being read, but for whatever reason, the flight plan isn't actually loaded. I suspect that there is a problem in the way MCE is obtaining paths to the Documents folder since the Simbrief integration is generating the local path, but the rest of the MCE code seems to use the One Drive path (which is probably a redirect).

Thanks for the clarifications. I will adjust accordingly.

Hi, I'm creating some custom checklists for the PMDG 737-800, but some things aren't working. Here are my first three checklists: _____________________________________________________________________________ Preflight [ ] Pilot, flight attendant briefings -- Complete [ ] ACARS -- Initialized, Connected [ ] Flight Deck Windows -- Closed, locked [ ] Oxygen -- Checked, set one hundred percent //3 [ ] IRS selectors -- Nav [ ] Pressurization -- Set, auto [ ] Auto throttles -- Armed [ ] Altimeters and flight instruments -- _ inches set //3 [ ] Speed brake lever -- Down detent [ ] Parking brake -- Set, pressure normal [ ] Engine start levers -- Cutoff [ ] M R D, gear pins -- Checked, onboard _____________________________________________________________________________ Before Push [ ] Seatbelt signs -- On [ ] Fuel -- Planned gate _ onboard [ ] Fuel pumps -- _ on, crossfeed closed [ ] Hydraulic pumps -- Checked, on [ ] Doors -- Closed _______________________________________________________________________ After Start [ ] Generators -- On [ ] Probe Heat -- On [ ] Anti-ice -- _ [ ] Recall -- Checked [ ] Autobrakes -- R T O [ ] Flight controls -- Checked In the case of the Preflight checklist, the first item is incorrectly read as "flight briefings." In the case of the Before Push checklist, once I reply to the "Fuel pumps" challenge with, say, "mains on, crossfeed closed," the FO then replies, "Now said Hydraulic pumps, doors, now said Before Push Checklist complete, now said." The FO never waits for a response to the last two challenges. In the case of After Start checklist, when I respond to "Anti-ice" with "off," I get "check that item again, would you?" even though anti-ice is off. If I say on, I get the same response, so it seems the FO is getting incorrect information. Is there some way to just preven the FO from trying to verify this as a workaround? Any idea why these behaviors are occuring? Thanks!

For anyone else encountering something like this, the Num Lock key needs to be on for the binds to work correctly for extended keys. In the case of the End key, when Num Lock is off, it gets treated as the Num Pad 1 key--which is the default MSFS bind for up elevator trim.

PM Sent.