Jump to content
The simFlight Network Forums

airforce2

Members
  • Posts

    209
  • Joined

  • Last visited

Posts posted by airforce2

  1. On 7/20/2024 at 2:25 AM, John Dowson said:

    Ah, ok. There is an ini parameter that you can set to increase the delay between re-running luas:

    But it is generally better to re-write such luas touse events...

    Ok, but rather than polling, you could assign your rotaries to LuaValue, with a different parameter for each position, and in your auto-ran lua wait for the position change using an event.param call and handling function.

    Regards,

    John

    John;

      Thanks for all the helpful hints.  Where can I find the documentation for the LuaValue control?  I have searched the manual, advanced user's guide, Lua library, and Lua plugins guides to no avail--there are a couple references to using it in the events section of the Lua library docs, but it's not at all clear to me how.

      So far I've managed four medium-length (1-2 hr) flights in the TFDi MD-11 since installing the test WASM module and re-writing my scripts to avoid rapid-fire spawning of duplicate scripts.

    Cheers

    Bob

  2. OK, thanks John.  I think I might have figured out what triggered this last lockup...the Thrustmaster TCA quadrant speed brake knob is a rotary switch where all but one of the positions of the knob are mapped to a separate switch on the joystick.  When turning the knob a couple clicks, it was triggering the same Lua script rapidly with each press and release sent as the knob passed through the different switch positions.  The script had a sleep delay in it, too, so I think it was trying to run 4-6 rapidly-triggered instances of the script concurrently.

    I swapped it for an autorun script that polls the autobrake switch array a couple times a second and sets the AB only if the knob position changes...have made two flights now without it falling over.  No WASM issues so far since installing the modded module.

    Regards

    Bob

  3. 1 hour ago, John Dowson said:

    Are you using GSX by any chance? Or any other add-ons running with FSUIPC, apart from the aircraft (if thats an add-on)?

    Yes--Pilot2ATC via WideFS, ActiveSky FS, Navigraph Simlink, PSXT (static traffic only), and GSX.

    I just flew the TFDi MD-11F from KIND to KMKE...had FSUIPC stop responding on me during the landing rollout.  It appeared to happen right after activating a switch to turn off the autobrakes, which runs a Lua script that writes to an Lvar in the MD11 panel.  FSUIPC stopped responding--could not bring up the menu from the taskbar, P2ATC no longer showed updates to position, speed etc, and all the Lua scripts stopped working.  I had to terminate FSUIPC7 via the task manager.

    The logs are attached--FSUIPC7.log in particular has a lot of warnings about a WASM-WAPI version mismatch.  The WASM log shows that it terminated normally when the sim was shut down.

    Regards

    Bob

    edit: this was run with the test WASM module you posted up-thread

    crash2.zip

  4. 7 hours ago, John Dowson said:

    Sounds like you are also experiencing a WASM crash.

    Was the FSUIPC_WASM.log file you attached uploaded after MSFS was shut-down? If so, it was definitely a WASM crash. If not, the next time this occurs can you exit MSFS and take a look at the end of the FSUIPC_WASM.log file. If the log file ends with the WASM closing down like this:

    Yes, in fact I couldn't open the log file until after I closed MSFS.  Oddly, though, controls sent via FSUIPC still work after the problem appears--don't they also use the WASM interface?

    Am I good to use the existing manifest file with the new WASM module?

  5. I'm running FSUIPC 7.4.15 and the TFDi MD-11F in MSFS.

    I've had a number of similar failures where Lvars apparently stop being updated.  I use Lua scripts for a number of controls, and those that read Lvars stop working...sometimes they fail at session start, sometimes after a while, sometimes they work OK for an entire flight.  I can still send controls that work, but any script that bases an action on an Lvar value stops working.  To troubleshoot I copied the Lvar value to an offset to monitor it, and when this problem occurs, the Lvars are all reading zero (0.0000).

    After the last occurrence, I shut down FSUIPC immediately and grabbed the logs.  I've attached the FSUIPC.log, and .ini, and the FSUIPC_WASM.ini (persistent) and log as well.  I don't see anything telling in there.  I also attached one of the lua scripts that works at first and then doesn't after this happens.

    I also tried with the WASM module you had posted in the other thread that uses tagged vars--had the same thing happen.

    Regards

    Bob Scott

    temp.zip

  6. 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

  7. 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

  8. 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

     

  9. 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

     

  10. 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

     

  11. 3 hours ago, Bentree said:

    Same kind of issue here, after a while the throttle disconnects.

    Bringing up the Axis tab in FSUIPC7 and moving the throttle seems to reactivate it.

    This is in a Turboprop, in an airliner i have only one engine on the throttle....

    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.

  12. 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

  13. 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

     

  14. 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

  15. I just did a flight in the PMDG 747 in P3Dv4.2 with FSUIPC 5.123e installed, and the FSUIPC option did appear in the P3D Add On drop down menu, but selecting it did nothing.  FSUIPC was still working in the background, though, as my flight controls and several remote apps that work via WideFS continued to operate.  My Lua scripts stopped operating at that point, however.  Oddly, one of the applications that uses the position freeze feature by setting a value in offset 3541 did freeze the acft position, which remained frozen indefinitely until I recoded the program to explicitly write a 0 to the offset upon exit.  According to the docs, the value written to the byte at 0x3541 should decrement every 55 ms or so until it hits zero and unfreezes the sim--that wasn't happening.  I couldn't look at offset 3541 using the logging function because of the aforementioned failure to bring up the menu when selected from the dropdown.

    The FSUIPC.log file shows no signs of trouble...I've included it here in case you want to look.

    Also, when running the PMDG 747 I am getting a consistent and reproducible CTD any time I try to start a program that writes to the simconnect window using FSUIPC...Radar Contact and PF3 in particular do this.  Pro ATC/X, which does not use FSUIPC, works, albeit with the other issues present with keystroke capture new to v4.2.  If I start a flight using the default F-22, start Radar Contact and get a normal simconnect window, and then switch to the PMDG 747, the Simconnect window stays open for the duration of the flight and works OK.  I don't expect you to be able to fix this, but I mention it as perhaps it may lend a clue as to what's happening with FSUIPC, Simconnect, and P3Dv4.2

    Regards

    Bob Scott

    FSUIPC5.log

  16. 20 hours ago, Pete Dowson said:

    I cannot move backwards. If you are content to stay on an old version, then I simply cannot support your use of it. That is all. It is up to you.

    Understood...and I wasn't asking you to go backwards. 

    I was more interested in whether or not there would be some advantage in capabilities to offset what sounds like increased risk (to stability) if using 5.123d over 5.122a for the time being.

    Cheers

    Bob Scott

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.