aurel42

That's a welcome surprise! Selecting Presets is much nicer this way, but of course it's a lot of clicking when you're trying to change several assignments, because the tree view doesn't remember which branches were visible/"unfolded". Is that something the toolkit can do?

Not really consistent what they did there, or maybe the renaming is just not fully done yet. But I'm not complaining, I'm sure they have good reasons. I'll keep a copy of KA_* stuff in myevents.txt for the time being (hoping that FSUIPC will handle duplicates in a sensible way) and wait for the events.txt file to stabilize. Thanks for looking into this!

John, the events.txt file included with 7.3.22 is missing a range of events that worked fine before. I heavily used the "generic" autopilot events ("KA_*", e.g. "KA_ALT_DEC") and it seems they're all gone now. Is that a change we inherited from upstream (Mobi) or did something go awry when you created the file? If they're not coming back, I'll copy them to myevents.txt. (edit: Oh, I just noticed the comment, they're not so much "generic" events as they are events meant for the Asobo King Air, but I still use them as defaults that I only override on a per-profile basis, because most of them they work in most planes.)

You're a legend, good Sir!

If there's no easy fix, I would be happy with an option that causes FSUIPC to exit immediately if the WASM or event files are missing. Something like "ExitIfEventsAreMissing=Yes" or "RefuseToLaunchWithoutWASM=Yes"? Chances are that when the FSUIPC module isn't in Community, I don't need FSUIPC running (because I'm troubleshooting something or working on scenery).

Thanks for the explanation, John. I can confirm that I'm on 7.3.21. I did not move or remove "events.txt" or "myevents.txt". But: I recently tried to troubleshoot a CTD caused by a 3rd-party airport scenery, so I launched MSFS a couple of times with an empty or almost empty Community folder. Would you mind checking whether you can reproduce this behavior? have a FSUIPC7.ini using presets temporarily remove the "fsuipc-lvar-module" from the Community folder launch FSUIPC without MSFS running exit FSUIPC check FSUIPC7.ini Before: 328=PD,31,CPKA_SPD_DEC,0 -{Preset Control}- 329=PD,4,CPKA_ALT_FAST_INC,0 -{Preset Control}- 330=PD,5,CPKA_ALT_FAST_DEC,0 -{Preset Control}- 331=PD,7,CPKA_ALT_DEC,0 -{Preset Control}- 332=PD,6,CPKA_ALT_INC,0 -{Preset Control}- After: 328=PD,31,C0,0 -{Custom control: <0>}- 329=PD,4,C0,0 -{Custom control: <0>}- 330=PD,5,C0,0 -{Custom control: <0>}- 331=PD,7,C0,0 -{Custom control: <0>}- 332=PD,6,C0,0 -{Custom control: <0>}- That doesn't seem to be working as intended. Of course. My FSUIPC folder is in my daily Duplicati backup. Restoring the lost settings was just a matter of copypasting a bunch of lines.

Hey Dowson family! 😄 Recently, a lot of my assigned presets (which were working fine before) turned into this: 0=PB,134,C0,0 -{Custom control: <0>}- 1=PB,133,C0,0 -{Custom control: <0>}- 2=PB,136,C0,0 -{Custom control: <0>}- 3=PB,135,C0,0 -{Custom control: <0>}- 4=PB,138,C0,0 -{Custom control: <0>}- 5=PB,137,C0,0 -{Custom control: <0>}- 6=PB,140,C0,0 -{Custom control: <0>}- I'm not sure what I could've done to cause this. Is this a known issue? Any idea what could've gone wrong and how to avoid it in the future? Cheers, Marc

A hardware issue (VR headset being RMA'ed) will keep me from testing in the next two weeks, so even though I did only a couple of consecutive flights (flight - return to main menu - next flight) in the past week, I can happily report back that FSUIPC has not quit on me (that is without "StopWAPIInMenu=No", so basically with the configuration we started out with). I feel it should've crashed at least once, considering how frequently I ran into the issue before. The bug you found and fixed might just have been what caused FSUIPC to crash on my system. Thank you! ❤️

Will do and report in a couple of days.

I've done a lot of short hops in the past couple of days (Misty Flying Club tours), so plenty of opportunity for FSUIPC to crash, but it was stable like a rock. That's with the WASM module, but also with "StopWAPIInMenu=No". Should I try a couple of flights without "StopWAPIInMenu=No" in the ini, or are we good?

I learned: if I want my Lua script to auto-run, I need to start FSUIPC before I start the flight. If I start FSUIPC while the flight is underway, the rotaries don't work. This behavior is documented in the manual ("whenever the current aircraft is changed (or, indeed, first loaded), or a specific named aircraft (or Profile) is loaded"), I just remembered it wrong, so, while I was testing, I often switched between FSUIPC versions with the plane on the runway, expecting the scripts to be auto-run when they weren't. I also learned: Because of the behavior of my brand of rotaries (short pulses), or maybe because of my bad coding, the overhead introduced by DebugLua=Yes will render them almost inoperative, only about one in fifty events registers in the sim while Lua logging is active. You can probably see how I confused myself by upgrading and downgrading FSUIPC, sometimes restarting it while in the MFS menu, sometimes while in flight, sometimes with Lua logging, sometimes without. Sorry! So, yeah, the rotaries behave exactly the same in 7.3.4 and 7.3.6, and they work when a flight is started with FSUIPC running and Lua logging is off.

Still working on figuring out why the rotaries sometimes work and sometimes don't. But, while testing, I noticed that 7.3.4 and 7.3.6 both change "TrafficStallTime=-1" to "TrafficStallTime=1". Is that working as intended?

With the exe you provided, my "lua-driven" rotary switches stopped working. I've enabled lua logging now. I hope to be able to provide more info after another flight.

Since adding "StopWAPIInMenu=No" and, later, removing the WASM folder from Community, I did not experience another crash. I'll reinstall the latest FSUIPC to restore the WASM folder, and then I'll replace the exe with the file you provided, and I'll let you know if it starts crashing again, or, after a couple of days of flying, if it didn't.

Roger!