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!

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.

As the first step, I enabled logging of Extras and Events. During one of the following flights, all my FSUIPC controls became unresponsive, while FSUIPC was running and responsive. I don't remember having something like that happen in the past year or so. And it wasn't even a long flight. The log seems to indicate that SimConnect stalled or choked. Exiting and restarting FSUIPC resolved the issue and I could continue the flight. Next step: I'll set the ini parameters you suggested. (The attached zip contains the log.) FSUIPC7-unresponsivecontrols.zip

I don't have more information than that. I attached a log and my ini. I'm using Win10 (21H1). Here's what the Windows Event Viewer has to say: Faulting application name: FSUIPC7.exe, version: 7.3.0.4, time stamp: 0x627e7a6a Faulting module name: FSUIPC7.exe, version: 7.3.0.4, time stamp: 0x627e7a6a Exception code: 0xc0000005 Fault offset: 0x00000000000e6053 Faulting process id: 0x1508 Faulting application start time: 0x01d86f8689880ebd Faulting application path: C:\FSdata\FSUIPC7\FSUIPC7.exe Faulting module path: C:\FSdata\FSUIPC7\FSUIPC7.exe Report Id: 5a89a13f-f377-4d63-a510-bccb372c2b35 Faulting package full name: Faulting package-relative application ID: How can I provide more useful information? My workaround: I just restart FSUIPC when this happens. Cheers, Marc FSUIPC7-crash.log FSUIPC7.ini

Thank you very much, John!

I spent quite a bit of time reading and re-reading the relevant parts of the Advanced User manual, searching through forums etc., but I can't seem to wrap my head around the concepts. Here's where I am: I have USB controllers with loads of switches, buttons, levers, and rotary encoders. They all work, but, so far, I can only assign them to the subset of functions available in FSUIPC, and many of those don't work as expected (no doubt Asobo is to blame for this). Here's where I would like to be: I would like to be able to assign all my controls freely to specific buttons or knobs on, for example, KAP140, GNS530, or G1000. A couple of forum posts which are about a year old discuss using MobiFlight (or, at least, MobiFlight's WASM module) together with FSUIPC as the solution, but I can't figure out whether that's still the way to go... is it? We do have FSUIPC's own WASM module now, is that meant to replace the need for the MobiFlight module or does it do something else? Is there a relationship between Lvars and SimConnect events? Do they mirror each other? Can I achieve the same results using either? Or is manipulating Lvars a backdoor, circumventing the use of the actual button in the sim, by changing the state of add-on internals, and thus not what I want to look at? Please make my brain hurt less.

The provided reg file didn't quite do the trick, but after cleaning out all the VID/PID keys from the two registry folders (and there were quite a few, most of them historical cruft), FSUIPC does not complain about duplicate GUIDs any longer. \o/ (Also, this was when the yoke stopped getting two separate GUIDs.) I reassigned my custom joystick letters and all four devices are behaving perfectly in the FSUIPC Axes and Buttons dialogs. Thank you for pointing me in the right direction!

John, thank you so much for your help. I totally realize that, by helping me with a corrupt registry, you're, once more, going above and beyond anything that could be expected. 💗 I'm familiar with regedit, just point me to the keys that need to go. 😄 FSUIPC7 - Copy (2).log FSUIPC7.ini