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.

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!

I did not. I did now, and they all had Power Management turned on. But if the hub went to sleep, wouldn't that affect all the devices connected to the hub? That would include my keyboard and yoke, they're all connected to the same decent (as in: not cheap, German engineering 😄) USB hub. I turned off Power Management for all the hubs now (because I don't know where in the "hub hierarchy" the external hub actually resides). Oh, good point, I should've said "between flights", because I don't know when FSUIPC actually stops doing things. It crashes silently, I only notice the controls not working after I start a new flight, and the FSUIPC icon in the toolbar vanishes when I move the mouse pointer to it. Yesterday, I set all four options you suggested, including "StopWAPIInMenu=No", and I'll have to do some flying now to see whether I experience another crash. I don't think I'm using the WASM, I followed the steps to install the "stuff from Mobiflight" and that worked for what I was trying to do. Just so I know where we're going: are we trying to find out how to avoid the crash, or are we collecting information so we can identify the issue leading to the crash? Either one works for me, just want to know what the focus is on.

I will do that if the "unresponsive controls" issue happens again, if that's okay with you. I know that this log grows very rapidly on my system because of the yoke software, see below, so I'd rather not write it for every flight I do, unless it's really necessary. Yes, I'm using Little Navmap and the FSEconomy SimConnect client, but I think by far the most stress on SimConnect is created by my force-feedback yoke which reads and writes a couple of variables at a high frequency; it's not assigned to FSUIPC or in-game axes, instead it directly sets AILERON_POSITION etc.

Result of the power management pass: some devices don't have a Power Management tab, some devices have a Power Management tab but the "Allow…" option is greyed out, some devices have the option but it's turned off. For the remaining devices that have "Allow the computer…" turned on, I look at "Hardware Ids" and google the VID to find the manufacturer (I don't know of another way to identify the device). This way I identify keyboard and mouse, an USB stick, components of my VR headset, the Xbox controller (I only use that for games, not for simming) and, indeed, the Thrustmaster Warthog. I disabled the Power Management for the Thrustmaster devices, and left it unchanged for the rest. So, one of the affected devices (the Thrustmaster Warthog throttle) had power management enabled, but it was disabled for the other affected device (my custom throttle quadrant based on a Bodnar interface). To be honest, from my perspective, this feels like a fluke, some random mishap designed by the universe to confuse the actual issue. I have not encountered this situation in a long time (many, many FSUIPC7 versions ago), I fly almost daily, and it feels unlikely that the problem was triggered by enabling logging for Events and Extras, which is the only thing I changed as I'm trying to get more information about the (frequent) FSUIPC7 crashes this thread is actually about. 😄

Hey John, I appreciate your input. Here's how I read the log: 579s: I start taxiing 945s: I'm airborne (tap the brakes, retract gear, engage AP) 1242s: The log stops recording events for SOME reason Some time after that I pass TOC and I'm trying to set cruise power, but I notice that all my FSUIPC-driven controls stopped working (Warthog throttle, custom throttle quadrant, I think I forgot to check the CH pedals). My yoke is on the same USB hub as the other devices, but it uses its own driver software and is still working. So it's probably not the hub that triggered the problem. It's only been a few minutes since I last touched my controllers, so I can't see why Windows would have turned them off. I do a lot of "unattended flying" for FSEconomy, sometimes not touching anything for an hour or more, and the controllers don't usually stop working. At this point, I check whether FSUIPC has crashed, but I still get the menu when I click on the FSUIPC icon. I exit FSUIPC using the menu, rename the log, start FSUIPC again and continue the flight with working controls. Not sure how all this would add up to power management issues. I've been on Win10 21H1 for the longest time ("never change a running system"), but I'm updating to 21H2 now and when that's done, I'll go through all the USB HID devices, making sure that power management is still disabled.