Fragtality
-
Posts
147 -
Joined
-
Last visited
-
Days Won
11
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by Fragtality
-
-
On 3/21/2024 at 5:05 PM, John Dowson said:
I am not sure what or if anything can be done about this at the moment, but I will take a look after the SU15 release.
Well then don't put any Effort in it - after some further Testing I won't use the L-Var in Question anyways. Basically another "My Way or the Highway" GSX Design Decision I won't pursue further 🤷♂️
-
4 hours ago, John Dowson said:
By the way, how are you exiting the lua script - are you killing it manually (i.e. LuaKill), or is it being killed automatically as the flight has ended? In case of the latter, it may be that the connection to the FS has been terminated before the request to update the lvar can be sent.
Maybe try adding an ipc.log call after the request to set the lvar - does this message get logged?For testing I used a button with LuaKill bound.
Yeah tried that - the Log-Message did not appear either
37 minutes ago, John Dowson said:I can see the problem (windows messages sent from terminating lua processes are not being processed) but am not sure what can be done about this at the moment.
I will look into this further after the SU15 release.
Alright, sounds good!
If it helps anything, it would already help for that Use-Case if one Call to ipc.execCalcCode would come through (can set the L-Var via that also) -
I currently have a Use-Case where I absolutely need to set a L-Var (to allow User Interaction again) when my Lua Script exits.
So my function called by the event Library is an Oneliner with ipc.writeLvar - but it seems the Time is not enough for this one L-Var to be set before it is killed. Even tried via ipc.execCalcCode without success. -
16 minutes ago, John Dowson said:
As I said before, there is no access to B-vars directly - you have to hack the xml files to add an lvar (and timer) to control a B:var - I have showed how to do this in other posts, and there are also examples on the MF Hub-Hop site (e.g. see the details for the preset TBM930_BLEED_AIR_AUTO). Even calculator code cannot be used to trigger a B:var directly (although I have seen some AAOs snippets that try to do this....)
However, there seems to be a close relationship between B:vars and Input Events - in fact, B:vars ARE Input Events (see https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm) - but maybe not all B:vars are available as actual Input Events (or via the Input Event interface).
So, I prefer to use the term Input Events rather than B:vars, which you can access via the GUI for assignments, via offsets, and also via Lua. So any FSUIPC client can access them via offset 0x7C50. Please note that the prefix FSUIPC uses for Input Events is 'I:' and not 'B:'.For the actual B:vars themselves, there is not and never will be any direct access (e.g. via calc. code) as far as I am aware, and you will only ever be able to use these via the corresponding Input Events interface. I have also read somewhere (in the Asobo forums) that future MSFS releases will provided access to more B:vars via the Input Event interface, with the aim to provide access to all - at which point the distinction becomes irrelevant!
All a bit confusing really....
Thanks for your Explanations!
-
On 12/15/2023 at 11:31 AM, John Dowson said:
Bvars are input events (as far as I am aware - or closely related). The latest release of FSUIPC7, 7.4.0, enables direct assignment to Input Events.
Other than that, there is no direct access to B-type variables, and you cannot use them via calculator code. You can alter the xml files to allow b-var control via lvars, But I think that it would be better to look at the available Input Events before you consider this. There is a post somewhere where I showed how to do this.
John
Can the B-Vars only be used via the FSUIPC GUI? Or can they also be used by FSUIPC Clients (e.g. PilotsDeck) or Lua-Scripts?
-
48 minutes ago, ark1320 said:
I just wanted to confirm I updated PilotsDeck correctly.
Al
Hmm, that is something you don't need to worry about when using the Installer 😉
But now you know when you want be extra sure 😅
-
1 hour ago, ark1320 said:
Hi,
How can I check to see what version of PilotsDeck I have installed?
Thanks very much for the update,
Al
In your StreamDeck Software
Settings > PluginsWhy would that matter anyway?
-
*Version-Bump*
Version 0.7.12 Released.
Installer:
- Improved: UI does not hang while doing the Installation Steps
- Added: Automatically installs/updates .NET 7 and MobiFlight WASM Module
Plugin:
- Improved: Continuous Input (e.g. turning an Encoder) does not block the Displays being updated
- Changed: Poll-Time decreased to 100ms (the Plugin will poll the Sim / update the Displays more often)
- Libraries Updated
-
1
-
Oh, never combined them. I used either DELAY or CONNECTED - but good to know ^^
-
YES! 😃
Okay, I only quickly fired the Sim up and did not really looked when exactly the Programs where started. BUT, when the Sim was in the Main Menu, the Programs were started.
-
Totally strange ...
Still the Programs are only started after Ready to Fly was pressed. This time it even forgot to start one Program (Fenix2GSX).
But it can start the Programs without Problems with the old READY before and now with DELAY=60 🤔 -
2 minutes ago, John Dowson said:
Your log also shows lots of other errors which are rather worrying.... There is an SDK update with the latest release to SU14 last night/today. I am currently in the process of updating to the latest SDK and will make a new release when done and tested, hopefully tomorrow.
Uh oh 🤔
Using "Run" does not work either. Programs were only started after Ready to Fly was pressed.
-
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 🙂
-
5 hours ago, John Dowson said:
The next beta release, 7.4.0b, which will be released tomorrow, will allow for an additional parameter for [Programs] section entries: CONNECTED. This will delay the start of programs until FSUIPC is connected to MSFS (via SimConnect) and has received the initial data to populate the offsets.
John
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 😉
-
3 hours ago, John Dowson said:
Ok - that log shows that there is an issue with the lvar values lock/mutex:
That lock us never obtained. This looks to be due to successive config updates being received before the previous one is fully processed. Hopefully this is corrected in the attached version.
Any issues, can you attach the log file again - maybe two copies, one the file when you get the hang, and again after you have killed/stopped FSUIPC7. Thanks.
John
Looks promising after a quick Test, Thanks! 🙂
-
15 hours ago, John Dowson said:
Can you test with the main window open - I would like to know if the UI responds when you get this hang/freeze.
It does not response any more (Windows displays even "No Response" in the Windows Title)
15 hours ago, John Dowson said:You access the logging console via Log->Open Console. This shows a real-time view of the FSUIPC7.log file. I would like to know if messages are till logged after the freeze, so keep that open.
That is interestingly still active, but seems to be stuck in a Loop. (Like in previous Logs)
-
43 minutes ago, John Dowson said:
Can you explain exactly what happens please, and what you do....
- 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)51 minutes ago, John Dowson said:The WASM log file indicates that you went back to the main menu:
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 😉
53 minutes ago, John Dowson said:Did you go back to the main menu, and if so when? Before or after FSUIPC stopped responding or was killed?
I did go back to the Main Menu and exited the Sim first, and after that killed FSUIPC via Task-Manager.
54 minutes ago, John Dowson said:It looks like it just stays like this until it is killed. Are you sure there is no response from the UI? What is the message in the FSUIPC7 main window when this happens? If you keep the logging console window open, is this still logging messages, and if not what is the last message logged?
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"?!
58 minutes ago, John Dowson said:And the WASM log looks like it has been uploaded AFTER MSFS has exited. When your issue occurs again. can you attach all files before you do anything else, so I can see the contents when the issue occurred.
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?
1 hour ago, John Dowson said:You also have a lot of stuff running using simconnect connections:
Others see a lot, I see a reasonable Amount of Addons for a Power-User 😜
1 hour ago, John Dowson said:Not sure why you are running so much Fenix stuff when you are not even using that aircraft - have you considered moving this out of your Community folder if not being used, and not running any additional software for that aircraft if not being used? Easy to do with the MSFS Add-on manager.
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.1 hour ago, John Dowson said:Note sure why you are using/running the WASMClient either - twice! You really don't need this - everything that does can be done in FSUIPC.
And you seem to be running 'Couatl' twice...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?
-
3 hours ago, John Dowson said:
Also please switch back to WAPI Trace level logging, and show me the files again, including the simconnec.log (it will be quite large and will need zipping/compressing, and still may be too large to attach....).
Here the new Log Files
-
56 minutes ago, John Dowson said:
Can you confirm that the issue now is that FSUIPC7 seems to hang, and that there is no response from the UI?
Yes, the Issue is now that FSUIPC7 hangs. It not just the UI, also Applications connecting to FSUIPC loose their Connection.
58 minutes ago, John Dowson said:If you kill and restart, does it then work?
Yes.
58 minutes ago, John Dowson said:Do you only get this issue when GSX is running?
Since both FSUIPC and GSX are started via EXE.xml, both always run together.
59 minutes ago, John Dowson said:How frequent is this issue, both when GSX running and when not?
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)1 hour ago, John Dowson said:Do you see any events (warning or error) related to this issue in the windows event viewer?
Nope.
-
9 hours ago, John Dowson said:
Can you show me a log when you get a hang using the following version, where more logging has been added: FSUIPC7.exe
Just use WAPI Debug level logging, not Trace.
Here'ya go 🙂
9 hours ago, John Dowson said:I will consider adding the extra option to run programs, but I do not know when I will have time to look into this - it will go in the backlog/to-investigate list.
Sounds fair, thanks! 😄
-
Here the Logs with Events and Lua Plugins in addition to Trace!
11 minutes ago, John Dowson said:If there is no problem, why add another option? Everything is already very complicated as FSYUPC can be started in carious sim states, I would rather not add additional functionality for no perceived benefit... And this functionality has been around for many years and this hasn't been requested before, so I doubt it is that useful...
Would this be to delay the starting further (until simconnect is ready)? If so, why not just add a delay?
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. 🙂
-
Of course the Freeze happened again when I decided to do a normal Flight -.-
event.terminate - not able to set Lvar
in FSUIPC7 MSFS
Posted
Sure, I mean it is an interesting Problem nonetheless! 😃
Just wanted to inform you that this one Use-Case from one User already died because stubbornness 😅