Fragtality

Ah! Yeah found it to be more reasonable to have it that way ^^ I'll cross-check with Run in the meantime 😉

Hmm, the ini reports "UpdatedByVersion=7400b" and the changes.txt reflects the new Parameter. Everywhere I look tells me I have the Bravo-Version 🙂 FSUIPC7.ini FSUIPC7.log FSUIPC7_prev.log

Hmm, I see no Difference with the new CONNECTED compared to READY - the Programs are only loaded after Read to Fly was pressed 😕

I don't know why the Forum always chooses that unfortunate Picture 😅 PilotsDeck (should) also works with a free Copy of FSUIPC. Like with FSUIPC itself, some Functionalities do not work (like sending Lua Events or the FSUIPC-vJoys). Some StreamDeck Profiles come with Lua-Scripts, so a registered Copy is recommended 😉

Looks promising after a quick Test, Thanks! 🙂

It does not response any more (Windows displays even "No Response" in the Windows Title) That is interestingly still active, but seems to be stuck in a Loop. (Like in previous Logs) Logs.zip

- Starting the Addons: STKP, vAmSys, FsHud, SimLink. - Starting MSFS - Starting a Session - Wait some Seconds (I wait for the little "bump" that happens when WorkingTitle2GSX resets the Fuel of the Plane, so at that Point FSUIPC still must have been running) - Activating FsHud (you need to hit "Continue" in its GUI after Ready-to-Fly was pressed for it to really start doing something) - Apps like PilotsDeck or WorkingTitle2GSX loose the Connection to FSUIPC and its UI does not react (it happens nothing when I click on the SysTray Icon) Uhm, yeah, sure? I mean when I'm told to collect Logs of FSUIPC freezing, I surely won't quit the Sim with Alt+F4 after I reproduced the Error 😉 I did go back to the Main Menu and exited the Sim first, and after that killed FSUIPC via Task-Manager. Well, fits to the Issue I'm seeing, I'd say. It freezes and does not mind to unfreeze again 😅 When I click on the SysTray and the normal Menu does not show up / the Window does not open, I'd say I'm sure ^^ Why the FSUIPC Main Window? Should I have had it open or what? It does not open when FSUIPC starts and I have no Need to have that. What "logging console window"?! Wilco. To clarify: I reproduce the Error, and as soon as it is triggered collecting the Logs without doing anything more in or to the Sim, right? Others see a lot, I see a reasonable Amount of Addons for a Power-User 😜 No, did not consider and will not consider. I don't see a Problem in that Ressource-wise. Flying the Fenix represents the most-demanding Workload, and the Sim and my PC don't have a Problem with that. My Fenix Tools are only two: Fenix2GSX and FenixQuartz. They don't do anything actively after Connection until the Fenix Binaries are actually loaded. The FenixBootstrapper comes from the Fenix it self. I can't tell you why it spawns so many Sessions. I'm not sure either. It's not that I command that somewhere deliberately. I have two Tools opening an FSUIPC / WASM Connection through the C# Client (PilotsDeck and WorkingTitle2GSX) - maybe that's why? What these Programs do can not be done in FSUIPC. I can't tell you why GSX/Couatl is listed twice there. Maybe that is just part of the normal Behavior. As far as I can tell it restarts itself when returning to the Main Menu. Maybe the two Instances we see are a Symptom of that?

Here the new Log Files Logs.zip

Yes, the Issue is now that FSUIPC7 hangs. It not just the UI, also Applications connecting to FSUIPC loose their Connection. Yes. Since both FSUIPC and GSX are started via EXE.xml, both always run together. Well, everytime I want to start a normal/real Flight-Session with a 787 Aircraft (respectively when FSUIPC runs the WT787 Scripts). Like stated, GSX runs always. But when attempting such a Flight, I start other Addons too (like STKP, FlightTrackers, AI/ATC Tools) Nope.

Here'ya go 🙂 Sounds fair, thanks! 😄 FSUIPC7.log FSUIPC_WASM.log

Here the Logs with Events and Lua Plugins in addition to Trace! There is no Problem currently, that is right. But as I wrote, the "bugged READY" was a great Workaround to Auto-Start GSX when it had Issues. So that "PROC" Option could be a useful and general Tool for Applications which have Problems to be started when the Sim is non-read or semi-ready. Also: starting Programs which can't do anything meaningful yet (because SimConnect won't be ready soon) is not exactly perfectly reasonable also 😉 Yes, there is Delay and I'm using it also. But what is the Value which would work in any Setup? In my Setup even 60 is too less. Maybe for others it would be too much. (Background: my new Installer for my Tools can setup Auto-Start via FSUIPC for the User. So I'm thinking about what Delay if any would be appropriate as a general-for-any-Setup-Value) But yeah, there is no real Problem (currently). I just would find it more elegant to being able to auto-start a Program when SimConnect is ready to process. 🙂 FSUIPC7.log FSUIPC_WASM.log

Of course the Freeze happened again when I decided to do a normal Flight -.- FSUIPC_WASM.log FSUIPC7.log

Hmm. So either I did not found a reliable Way to reproduce the FSUIPC Freeze, or 26g had fixed that. Let's hope some long-term/normal flying Tests show it is the latter 🙂 Yes, you're right - I don't want READY anymore 😅 Even though my Tools don't have a Problem with that (they're designed to be even started before the Sim): Would it be possible to have an additional RunIf Option in the Future - maybe let's call it "PROC" or so. It would start the given Program when SimConnect is ready to process.

Wilco. To be honest, I never had any Problems with READY. In fact it also worked perfectly to start GSX/Couatl as a Workaround for a GSX Bug. I use it for my own Tools (FenixQuartz, Fenix2GSX, WorkingTitle2GSX, DynamicLOD) and it was just perfect. Is there any Chance to get that Behavior back?

It happened again - I think I found a way to reproduce: When I switch from another Plane (e.g. the Fenix) to the 787 (so the Lua-Scripts in Question get executed), FSUIPC will freeze. The Logs attached have not the required Settings. I'll try to reproduce it with the required Settings in the next couple of Days. Btw, is it normal for that Beta-Version that Applications from the [Progams] Section are started when the Session is Ready? Before they where started much earlier (during Sim-Startup) (Note: configured with READY,KILL) FSUIPC_WASM.log FSUIPC7.log

Yep, even with 15 it happens. Will try the .26 Beta the next Days, thanks! 🙂

Did you find a Chance to look into this? Still is an Issue, even with a LvarScanDelay of 10. FSUIPC7.log

You mean %appdata%\Microsoft Flight Simulator\Packages\fsuipc-lvar-module\work ? I don't have a ini in there, only the two log files 🤔

Heyho, it's me again 😅 I sometimes have the Issue that FSUIPC stops working when loading into the 787 (and hence FSUIPC needs to load the WT787 Scripts). The Application hangs, the Systray does not respond (my StreamDeck Plugin also indicates a Connection-Loss). I need to stop FSUIPC via Task-Manager. When I start it again, it all perfectly without any Issue for many Hours (i.e. through a complete Long-Haul Flight). I only could manage to create a Debug-Log of that Situation. When I wanted to Troubleshoot it with Verbose-Logging it suddenly worked -.- FSUIPC7-hang.debug.log

Running stable so far! In Hours sitting in the Sim and doing my Profile (also editing and even restarting the Scripts) it just kept working. Must have been very special Timing on my Side to trigger something that should not happen 😅

That does seem to have solved the Issue! Thanks! 😃 Running with everything enabled (that is with GSX-Script, Programs and the WT787 Sync Script running all Functions) for several Minutes without any Issues. Can Trigger Functions from the Auto-Script, can even restart the Sync-Script. Just works. Have to get back to Work now, let's hope that it stays that Way when I continue working on the Profile this Evening 😉

I share the same Confusion! I mean I create and Update two L-Vars there. The Rest is reading a File, reading GSX L-Vars and writing Offsets - nothing extraordinary ^^ But: do you also have GSX installed and running with that Test? I'm not sure it would do much when GSX is not available 🤔 One Test I might commence: starting the GSX_AUTO Script with the WT787 FSUIPC Profile. I normally have that GSX Script as global Script since it is not specific to an Airplane. Not when I did those two Tests I send you the Logs from. I collected what was there and deleted the SimConnect log before the next one. I did not really test purposely yesterday, but combining the execCalcCode Calls helped for a short Time at least. Maybe you can provoke it by reverting that Change (so each Line is again its own execCalcCode Call). But I understand, it seems like a weird Timing-Problem - which are the hardest to reproduce and troubleshoot 😕

Yes indeed. But also still without these Programs running - so that is the Difference to yesterday. Runs fine for several Minutes now (even when toggling LuaFunctions from the WT787_AUTO Script) FSUIPC7.ini

Yeah saw this, but did not really mind to fiddle with the ini since I did not miss any Bindings 😅 More like < 1 Minute Here the Logs including the SimConnect log. What is Strange: although I tested without GSX_AUTO yesterday already without any Difference (saw also that the L-Var IDs being reported belong to it) it now made a Difference. First I tested without that Script and the Programs and then with the Script but still without Programs and on this second Attempt it appeared within Seconds. logs.zip GSX_AUTO.lua

Except for FenixQuartz, they don't use FSUIPC at all. Quartz only to write FSUIPC Offsets. All L-Var / A-Var / CalcCode is run through the MF Event Module. I'll try later! Don't think it correlates with Logging. By now I'm also not sure that it correlates with two Scripts using execCalcCode. The Sync-Script apparently just goes bad after some Time on its own.