airforce2

Quick question--if I use ipc,writeLvar in a Lua script to write to an Lvar that does not presently exist, is a new Lvar created or does it just ignore the write? If not, is there a mechanism in FSUIPC to create a new Lvar in a Lua script or macro? Regards Bob Scott

To close the loop on this, I've flown over 20 flights now with the ButtonScanInterval setting at zero--no more crashes in WideFS. Regards Bob

John; No, this is the first use of WideClient on this laptop (and WideServer on the MSFS machine, as I've moved MSFS off to a different computer). I've now had several successful flights after changing ButtonScanInterval from 20 to 0 in the .ini file. I have had several different HID controllers connected to the client laptop previously, but there are none presently connected, and the Windows "Devices and Printers" dialogue in the control panel shows none. It's a little early to declare victory, still--I'll keep the logging on for the time being. Thanks Bob

John; I'm having a devil of a time trying to keep WideClient running. I have it on a Win 11 laptop, for use with Pilot2ATC connected to MSFS running FSUIPC 7.3.20 on a Win 10 desktop. I have used it successfully for years with FS9/X/P3D--this is my first attempt connecting to MSFS. I am getting mostly silent CTDs where WideClient just disappears. Many of the crashes show C0000374 heap corruption errors at offset 0x000ec67f. One today, a memory access violation, was trapped by WideFS. I have attached a file with the event log entries from a bunch of these crashes, as well as the log file from the event where the crash was trapped, and my WideClient.ini file. Most of the crashes showed nothing in the log file after WideFS starts and connects (no end-of-session summary etc). I've tried redownloading, uninstalling & reinstalling, UDP vs TCP, integrated ethernet vs WiFi vs a discrete USB ethernet adapter, elevated priority, run as admin, and have run sfc and dism to rule out Windows system corruption. It keeps doing the same thing--it runs for a while and then crashes with a silent CTD. Regards Bob Scott WideClient.ini WideClient - Copy (2).log Crash Event Logs.txt

Argh...I think I had several folders open and I must have copied the wrong path for the executable into the post. Anyway, I have no opinion on which folder should be considered the "main" FS folder, but was just trying to understand why that folder was chosen, given that it differs from the old convention. Still trying to get my head around how a round FSUIPC fits into a square MSFS hole, so to speak... Cheers Bob Scott

OK John, thanks. Can you shed some light on why the ...\Packages folder is being identified as the main sim path? In the past that main path has always been the folder where the sim's executable resides. That's the folder I had shared (located in "C:\Users\xxxxxx\AppData\Roaming\Microsoft Flight Simulator" on a Steam MSFS installation). Cheers Bob Scott

Hi John/Pete; I've just noticed that offset 3E00 is reporting the server's local path to the MSFS packages folder on a WideFS client rather than the full UNC path (e.g. the path reported on the WideFS client is "C:\MSFS\Packages\" where it should be "\\HUD\MSFS\Packages\"). I'm using FSUIPC 7.3.7 and WideFS 7.160 -- as I understand it, when WideFS is connected the path in 3E00 should be the full UNC path to the folder on the server. Cheers Bob Scott

This sounds like maybe the USB port powering down...check in Device Manager and make sure all your USB HID devices and hubs do not have "Allow the computer to turn off this device to save power" enabled. This option gets turned back on regularly without asking me when Windows updates on my machines.

Seeing the same thing here. Works for a while, then MSFS becomes unresponsive to inputs via FSUIPC. I bring up the FSUIPC axis assignments window, which shows the axis inputs still moving, but the sim isn't getting them. In the log, there are hundreds of TransmitClientEvent failed! messages. Edit: This was using the default C208 Caravan.

Just saw this...will give it a try. Thanks!

Awesome!! Thanks

OK, fair 'nuf. Thanks Bob Scott

John/Pete; I've looked and cannot find any mechanism to allow programmatic control of FSUIPC's auto-save feature. If it already exists, would you please point me to it? If not, it'd be nice to have the ability to send an FSUIPC control to stop/start autosaves as set up in the FSUIPC menu. There are times, like on approach, for example, where it'd be nice to be able to have a LUA script disable auto-saves (e.g. below 5000' AGL) to prevent the auto-save stutter. Cheers Bob Scott

Hi Pete/John; I've been trying to get OpusFSI to run using the FSUIPC Run= facility, and I kept getting an error=2 when I tried to run it with a command line parameter per the documentation. The advanced user doc says: "If the program needs command-line parameters these can be included by enclosing the whole value in quotes, so that the space(s) needed don't cause problems." It appears that guidance is in error...if the space and command line param are placed inside the quotes, it appears to be trying to use the parameter as part of the file name. If I use: Run1=READY,KILL,AM=XC0,"X:\OpusFSI_v5\FSISERVER.EXE" the program runs, but in its default (P3D) mode. To run it in FSX:SE mode, it needs the command line parameter " STEAM" appended to the command line. But if I try to run it with this line: Run1=READY,KILL,AM=XC0,"X:\OpusFSI_v5\FSISERVER.EXE STEAM" I get an unable to run line in the log with error=2, which I understand is a file not found error. If I add the command line param after the quotes, as below, it loads as intended, in FSX:SE mode: Run1=READY,KILL,AM=XC0,"X:\OpusFSI_v5\FSISERVER.EXE" STEAM Cheers Bob Scott

Thanks Pete. I've been experimenting with it, and it's behaving rather unpredictably...with an airliner cruising at FL320, 310 KIAS and 492 KTAS, I write a 32-bit value of 300 to 0x0558, and the airspeed tape jumps...up(?) If I read IAS from offset 02BC soon after the write, I see values approximately 30 KIAS higher than written. I'm refining a utility that I use for repositioning the aircraft to skip ahead on a flight plan, and just moving the jet often results in a temporary but severe over/underspeed condition at the new location due to the difference primarily with winds, but also OAT and local pressure. It appears that correcting the current Z-axis body velocity for the delta in headwind component between old/new location and writing that back out to 3090 works better than using the IC facility. Cheers Bob Scott