Fragtality
-
Posts
147 -
Joined
-
Last visited
-
Days Won
11
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by Fragtality
-
-
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) -
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.
-
9 minutes ago, John Dowson said:
Also note that you should set this in the FSUIPC_WASM.ini file located in the WASM persistent storage location
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 -.-
-
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 😅
-
1 hour ago, John Dowson said:
Could you try the attached version please: FSUIPC7.exe
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 😉
-
4 minutes ago, John Dowson said:
I can't see how the GSX_AUTO script can affect things, and I have had it running here together with your other 2 scripts for several hours without issue.
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.
17 minutes ago, John Dowson said:There don't seem to be any exceptions logged from a SetClientData call. Are you sure there wasn't a later log file (e.g. SimConnect4.log)?
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.
25 minutes ago, John Dowson said:So, sorry, but I am at a loss what is causing this issue, and not sure what to advise or how to investigate further at the moment. I really need to be able to reproduce this issue to investigate further...
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 😕 -
1 minute ago, John Dowson said:
Sorry, are you saying that you now don't get the error when the GSX_AUTO script is not running?
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)
-
25 minutes ago, John Dowson said:
In an unrelated issue, you have a missing joystick:
Yeah saw this, but did not really mind to fiddle with the ini since I did not miss any Bindings 😅
51 minutes ago, John Dowson said:How long? Its been running here for > 30mins without an issue so far, and the Auto script is also running, and I have assigned buttons to toggle the flags, and can't reproduce the error whatever I do. So this does seem peculiar to your set-up somehow...
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. -
1 minute ago, John Dowson said:
What are these programs that you are also running:
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.2 minutes ago, John Dowson said:Can you try with those disabled to see if that makes a difference please.
I'll try later!
2 minutes ago, John Dowson said:And this change occurred when you set trace logging? If you go back to Debug or Info logging, does iiiit revert to previous behaviour?
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.
-
Here with LogLevel set to Trace.
Don't really need to trigger any Function in the Auto-Script. It now manifests shortly after loading into the Session.
-
16 minutes ago, John Dowson said:
How do you trigger these functions? By setting a flag (1-8)?
Yes, I'm sending a LuaToggle to FSUIPC (through the C# Client)
But as the Logs show it can also manifest itself just by restarting the Sync-Script. At the Point where I triggered the LuaToggles the Log was already full with the mentioned Error.
-
Don't know if it was different with previous Versions, I created these Scripts / started on the Plane only with .23.
Note on the Logs: I loaded in and realized I had the Lua Functions using execCalcCode commented out in the Sync Script. Therefor I uncommented them and restarted the Sync Script.
-
No, it was the same with .23 - updating to .24 neither improved nor worsened the Situation.
I'll give it a try!
-
I get the mentioned Error in the Log when using Scripts containing ipc.execCalcCode Calls.
I have one Script (WT787_AUTO) using event.flag so that I can trigger specific Functions from Outside (e.g. Increasing the Baro when pressing a Button on the StreamDeck). Here the execCalcCode Function is used to trigger H-Vars.
The other Script (WT787_SYNC) is using event.timer to run several execCalcCode Calls which create/update L-Vars from serveral different A-Vars Sources (in the Lines of "if that A-Var and that A-Var are true set the L-Var to zero").Everything works fine at the Beginning, but when I trigger the Functions containing execCalcCode Calls (Auto-Script) I get this 'Error setting Client Data Calculator Code' Message for every execCalcCode Call in every Script. Even Restarting FSUIPC then does sometimes not help anymore. Seems like a weird Timing-Issue. I already tried to reduce the Number of Calls and use some delay (via ipc.sleep) between them with no Success.
Note that I use this AUTO/SYNC Script Approach (one for triggering certain Buttons, one to generate/compose Values) on other Aircraft too and never saw this Problem - BUT there I don't use the execCalcCode Function.
I'm aware that there is this H-Var/Event File Business and the myOffset File - I deliberately don't use that.
-
The second Box is not titled "Default Name" 😅
Tbf I never had much Focus on this Default-Functionality since I had the Focus on implementing something that can switch to the fitting Profile for the current Plane. To have it fallback to some Default was just something I added along the Way.
Looking at it now, there are certainly some Edges that could be polished. Alone having a dedicated Default Profile in the first Place is a bit redundant and thus confusing. All (imported) Profiles are equal in the End so the Profile with "Default" in its Name could be used for one specific Plane where else a Profile "GA Planes" could be set as Default.
So I think in the Future I get rid of these empty Default Profiles and the Need to configure it by Filename. Some sort of Checkbox beside each imported Profile to mark that it as Default does the same Thing and should be easier to configure-
1
-
-
-
2 hours ago, ark1320 said:
BTW, I don't see anything in your PilotsDeck instructional ReadMe that address the path entry and format needed in the second box above when setting up a default profile.
Only partly true:
2 hours ago, ark1320 said:Just seeing an actual filled in example will clear things up for me. So if I were to use your PilotsDeck-DefaultPlus profile as my default profile, exactly what would the entry in the second box below look like if my Profiles Subdirectory with the PilotsDeck-DefaultPlus profile is located at:
Yeah, it is a bit of an oversight on my Part tbf, that I did not filter out the Default Profiles there.
Since they use the same Mechanic and have the same Requirements to to be "switchable", they are also listed with the other "buildin" Profiles there. So you could theoretically also map FSUIPC Profiles to that Profile. (Can't remember - maybe I deliberately did not filter them out to allow for greater flexibility) -
12 hours ago, ark1320 said:
So if the name of my default profile was Default AC AP I would enter something like this in that box:
C:\Users\Al\Documents\Al's Flight Simulation\MSFS 2020\StreamDecks\PilotsDeckProfiles\Default AC AP
Nope, that it also incorrect ^^
First, it need to be forward slashes.
Second, I left the Path-Prefix in the GUI too differentiate more clearly that you are entering a StreamDeck Profile (File) Name in there and not a FSUIPC Profile Name. Did not work out well in your Case 😅It is not a Sign that you would have freedom of Choice here.
The Default Profile, like any other (StreamDeck) Profile, has to be installed through StreamDeck when PilotsDeck should be able to switch to it.
That is a Limitation of the StreamDeck API/Software. Plugins are not allowed to switch Profiles, except the ones which come with the Plugin. So we need to "trick out" the API in believing your Profiles came with the Plugin.So it is the same Workflow as with your other Profiles:
- You have to place your "Default AC AP" Profile in the Profiles Subdirectory
- You have to run import
- You have to (re)install all Profiles
- Then you could enter "Profiles/Default AC AP" as the new Default-Profile (for the given SD Type) -
1 hour ago, ark1320 said:
And was I correct that what goes in the box below the Default Name box would be FSUIPC aircraft profile names (or substrings of the profile names)
No.
What goes below "Default Name" is the Path and Name to the StreamDeck Profile to be loaded when no match to a FSUIPC Aircraft Profile could be found. Hence it is Default.
IF the Checkbox "Use Default" is enabled. Otherwise it will switch nothing when there is no Match.The FSUIPC Aircraft Profile's Name goes in the Box below your custom Profiles - so PilotsDeck knows when it should be loaded.
-
Looking at some of your Questions, it would be advisable if your read about it first under Advanced Topics.
An own custom Default Profile needs also to be installed through StreamDeck like every other Profile too. Then, theoretically, it should be possible that you enter your custom Profile there. Given you had enabled the Checkbox.
What is the Motivation in the first Place anyway? You could just configure/customize the installed Default Profiles to your Needs.
Note: I would advise you to make a Backup of your Profiles (including the Defaults when changed) when playing around with that Feature.
-
*Version-Bump*
Versions 0.7.11:
- Installer: added Argument to disable MSFS Checks
- Installer: "Pump" Check improved ( #33 )
- Installer: Updated Dependencies to the latest available Versions
- Fix for Calculator L-Var Template not working with L-Vars ending on L
- Improved Calculator L-Var Template and Value Manipulator: An additional Reset Value can be configured. When the Variable is equal to the defined Limit it will be set to the Value of Reset
- Updated to StreamDeck SDK 6.1 (now the new Minimum)
- Updated Libraries
-
1
"Error setting Client Data Calculator Code" when using execCalcCode
in FSUIPC7 MSFS
Posted
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.