aurel42

While people in the MSFS forum are complaining about having to spend all that time setting up their controllers, once I got MSFS2024 running, I fired up CLS2Sim (for the Brunner yoke) and FSUIPC, acknowledged the "CrashIO" dialog (haven't seen that for a while), disabled the default layouts MSFS had picked for the devices it recognized, and went flying. I'm sure I'll find problems in time, but having working controls within a minute, that was, for me, the highlight of this launch day. ❤️ FSUIPC ❤️

Gotcha, I'll reorganize the LUA scripts. So what's the theory what happens to FSUIPC when it becomes unresponsive? A race condition in the code that handles the lua threads, resulting in a deadlock? It might be cliché, but ofc this worked flawlessly before. But it's been almost a year since, maybe I lost a couple of % of performance somewhere, maybe I've become more reckless twisting those knobs. Thanks for your advice!

Thanks for your quick response, John! According to the FAQ entry, it wasn't a WASM crash, because there's an "END OF PROGRAM" line. There are ERROR messages in the WASM.log, but judging from the timestamps, they happened when I shut down MSFS. Find the log attached. tbh, when it happened today, I ragequit. 😄 When I turned the rotary encoder to increase the selected altitude during climb and the numbers didn't change, followed immediately by the familiar bing sound, telling me that FSE had cancelled the flight, I just exited to the main menu and shut down MSFS. Since I had at least FSUIPC and the FSE client in an unresponsive state (both were still stuck after MSFS was gone), I restarted Windows to get rid of the processes, and I fired up X-Com to vent my frustration killing some aliens. 😄 If I experience the issue again, I can try to kill FSUIPC using the task manager and restart it to verify whether the WASM module is still working. I'll also make sure to test all my knobs, dials and axes to see if only the ones using scripts or presets are affected. FSUIPC_WASM.log

Hey John, I've seen this issue multiple times, it usually happens like this: I start MSFS and FSUIPC via MSFSAddonsLinker. I set up and start a flight in the LJ35. If I'm lucky, I can complete the flight. If unlucky, FSUIPC will become unresponsive at some point (ie. all FSUIPC-powered controls stop working, clicking or double-clicking the tray icon does not open a menu or the FSUIPC window). This seems to happen always right around the time when I try to change the selected altitude of the AP. In the LJ35, I'm using four LUA scripts to change the altitude, this is the "lj35_alt+1000.lua": --Increment Alerter by 1000 alerter_value= ipc.readLvar("L:ALERTER_DIGITAL") -- get current value in altitude window alerter_value_new = alerter_value + 1000 -- add 1000ft to altitude from window if alerter_value_new > 60000 then alerter_value_new = 60000 end ipc.writeLvar("L:ALERTER_DIGITAL", alerter_value_new) -- update window altitude altsel_mode = ipc.readLvar("L:MODE_ALTSEL") alerter_digital=ipc.readLvar("L:ALERTER_DIGITAL") -- get value in altitude window if altsel_mode == 1 then -- check if necessary mode is on ipc.control(66124, alerter_digital) -- update sim, window altitude into AP_ALT_VAR_SET_ENGLISH end I fly on FSEconomy using the FSE FSUIPC client. When FSUIPC becomes unresponsive, the FSE FSUIPC client aborts the flight, displays an error dialog telling me that the connection to FSUIPC has been lost, and then becomes unresponsive as well (ie. can't close the error dialog, can't interact with the main FSE FSUIPC client window). I suspect it has to do with the LUA scripts, but I can't be sure. According to my logs, I've done dozens of successful flights in the LJ35 from January to May 2024, I haven't flown the Lear since. I never experienced any issues like this back then, only now when I started flying the Lear again recently. Log attached (as usual I removed my license information). I'm not sure I'm willing to put much effort into testing and debugging this on my side, considering the imminent release of MSFS2024. IF the launch is smooth and the new version is reasonably stable and free of showstopping bugs, I'll probably spend my spare time exploring the campaign. Nevertheless, if I can provide any additional information regarding this issue, please let me know. FSUIPC7.log

That was easy, much appreciated! I know how to handle axes in the future.

This is from the FAQ section of the Piston Duke manual. I've never used LUA to handle an axis. Anyone got a ready-made solution for me? (While I was looking for a solution, I came across a forum post saying that the range for the L: variable is actually 0-1, not 0-100.)

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.