FSUIPC crashed (7.5.5a - beta version)

[John Dowson]

Looks like the SimConnect connection hung, almost certainly due to MSFS hanging. I don't thing this is anything to do with FSUIPC7 or the the FSUIPC7 CTD.
If this continues, we can also try SimConnect logging, but I would put this down to MSFS for now. If it was an FSUIPC issue, it should not affect MSFS - but MSFS issues will certainly affect FSUIPC.

I don't see any error messages relating to the input event 'AS530_GPS_Outer' - did you correct this? Or was it that this was just not used?

Could you switch to using the attached exe please. This contains a few minor logging updates/improvements.

John

FSUIPC7.exe

Edited Friday at 03:05 PM by John Dowson
Attachement replaced

[kaha]

I didn't use 'AS530_GPS_Outer'

Ok, I'll use the new .exe.

[kaha]

FSUIPC didn't respond on my last flight. Of course, for testing reasons, I maximize inputs to provoke a possible crashcrash. So this time no inputs were possible anymore but it didn't freeze. I had to use tMenu File->Exit to end it. I restarted it and everything was normal again.

Here's the log file.

 

FSUIPC7.zip

[John Dowson]

There is certainly something strange with that build, as indicated by the strange characters in the lua log messages, which indicates a corruption somewhere when multiple threads are writing to the log. I will check this and provide an updated version, maybe later but probably tomorrow or Monday.

John

 

[kaha]

On 9/4/2025 at 12:44 PM, John Dowson said:

Would be better and more efficient to also have that script auto-ran and modified to use event.param. Your assignments would need to be modified to use LuaValue instead of just Lua. As you have lots of assignments to this. would be easier to just do this by editing the ini - just change "CL16:R" to "CL16:V".

John

The problem with this is that the value doesn't change. It's a trim value, so pressing the button repeatedly it will always send the same value. But event.param is only triggered if the value changes.

Karl

[John Dowson]

2 hours ago, kaha said:

The problem with this is that the value doesn't change. It's a trim value, so pressing the button repeatedly it will always send the same value. But event.param is only triggered if the value changes.

Yes, I'd forgotten about that. This is on my list to investigate as it should really trigger when you send the same value multiple times. I will see if I can also fix that as well.

John

[kaha]

In the meantime I autostart the script and use "CL16:R". Should still be better than not autostarting the script?

[John Dowson]

1 minute ago, kaha said:

In the meantime I autostart the script and use "CL16:R". Should still be better than not autostarting the script?

Thee is no point auto-starting the script if its not waiting for an event - it will just run and exit, and maybe adjust the trim when not needed.

But please try the attached version. As well as the logging issue (hopefully) being fixed, this should allow repeated LuaValue calls using the same value.

John

FSUIPC7.exe

[kaha]

Great, thank you, I'll test it.

Karl

[kaha]

Looking good. Logfile attached.

Karl

FSUIPC7.zip

[John Dowson]

The only anomaly in that log is when trying to set/execute an input event that doesn't exist:

Quote

...
    92563 [Buttons] 85=PP,0,CIFUEL_VALVE,1.000000
    92563 **** Cannot execute empty Input Event
...
  1148578 Button changed: bRef=0, Joy=5 (P), Btn=0, Released
  1148578 [Buttons] 86=UP,0,CIFUEL_VALVE,0.000000
  1148578 **** Cannot execute empty Input Event
...
  1318375 Button changed: bRef=0, Joy=5 (P), Btn=0, Pressed
  1318375 [Buttons] 85=PP,0,CIFUEL_VALVE,1.000000
  1318375 **** Cannot execute empty Input Event
...
  7838813 [Buttons] 86=UP,0,CIFUEL_VALVE,0.000000
  7838813 **** Cannot execute empty Input Event
  7839219 Button changed: bRef=0, Joy=5 (P), Btn=0, Pressed
  7839219 [Buttons] 85=PP,0,CIFUEL_VALVE,1.000000
  7839219 **** Cannot execute empty Input Event
  7839625 Button changed: bRef=0, Joy=5 (P), Btn=0, Released
  7839625 [Buttons] 86=UP,0,CIFUEL_VALVE,0.000000
  7839625 **** Cannot execute empty Input Event
...

 

[kaha]

John, I have a question concerning LuaValue. I have an autoloaded script that handles my throttle and mixture axes. I use "Send to FSUIPC offset" for those axes and in the script I use event. offset.

Is this ok or should I better use LuaValue and event.param?

Karl

[John Dowson]

Stick woth writing to the offset and using event.offset.Thats the standard way to use axes values in a lua script.

[kaha]

John, something strange happened this morning. I was about to test the C-130 Beta by Blackbird and after starting up normally and everything working FSUIPC suddenly got unresponsive for some time. It didn't crash, but after it responded again some inputs didn't work. Looking at the log it turned out that it had terminated my autostarted scripts. Buttons again worked. This happened at 348594 in the log file.

Should I account this to the beta version of the Hercules?

 

Karl

FSUIPC.zip

[John Dowson]

12 minutes ago, kaha said:

I was about to test the C-130 Beta by Blackbird

The aircraft name logged was "Dirty 30 Short Configuration" which seems very strange...

14 minutes ago, kaha said:

FSUIPC suddenly got unresponsive for some time. It didn't crash, but after it responded again some inputs didn't work. Looking at the log it turned out that it had terminated my autostarted scripts. Buttons again worked. This happened at 348594 in the log file.

What actually happened in MSFS at this time? Your log indicates that FSUIPC killed the lua scripts as the camera state changed to 32 (which is an undocumented/internal camera state).

In MSFS2020, the 'plane in parking state'  variab1e is used to determine when a flight is ended and luas need to be killed (as well as performing other tasks needed when an flight is ended). But this is not reliable in MSFS2024, and so an additional check on the camera state was added specifically for MSFS2024, and when certain camera states are received, FSUIPC thinks the flight is ended and will stop the luas. The camera state values were determined by trial and error, and 32 was one of these (even though the exact meaning of this state is unknown). I will do some more tests on this, but I will remove 32 from the list that determine a flight has ended. I have done this in the attached version.

John

FSUIPC7.exe

[kaha]

Right, that's the name.

[kaha]

I didn't do anything wired when this happened. I'll try to reproduce.

[kaha]

[John Dowson]

6 minutes ago, kaha said:

I didn't do anything wired when this happened. I'll try to reproduce.

Just wondered what you saw when the camera state when to 32. Anyway, I have removed this now in that last exe.
There is another camera state of 36 that will also cause luas to be killed which might also need removing. As I said, I will do some testing later today - I haven't looked at this since the latest SU update and these things tend to change on each release...

John

[kaha]

I used my normal camera views that I always use. Nothing special.

[John Dowson]

39 minutes ago, kaha said:

I used my normal camera views that I always use. Nothing special.

The camera state is not just the views, it is what is displayed in the MSFS main window, so can be Menu, World Map, Hanger, Waiting, etc As I said, 32 is undocumented (internal only) so just wondered why it hit that state when you were (probably) in a cockpit view (state 2). Its not important - just wondered if you had noticed anything in MSFS, apart from FSUIPC becoming unresponsive (as it was killing the luas). 

[kaha]

Ok, I see.

I didn't pay attention if the sim itself got unresponsive like, maybe, pressing Esc. All my inputs, also all camera view changes are bound in FSUIPC.

[kaha]

Something else: Starting with 7.5.5d September 7th I sometimes see the following problem. FSUIPC starts up normally while the sim is still in Menu. After loading a flight it seems FSUIPC cannot connect. FSUIPC is alive, I can show the window. Also the sim is responsive. I then exit FSUIPC, restart it and it works normally. Please see the .log file attached.

This happens with different aircraft.

FSUIPC7.zip

[John Dowson]

This looks to be because you are pressing a button that starts a lua thread far too early - well before the aircraft is loaded and before FSUIPC is fully initialized. This looks to be confusing SimConnect and interfering with the initialization. You should really not be doing anything until AFTER you have pressed the Ready-to-Fly button.

I also don't think this is related to any of the recent changes.

FSUIPC should really ignore such early button presses. Not sure why it is actioning those button presses when they should be ignored. I will take a look to see if I can prevent this.
But you should wait until the aircraft is fully loaded and after you have pressed the ready-to-fly button before doing anything, and really it is better to wait until all lvars have loaded, which will be several seconds after you the cockpit view is loaded.

John

[kaha]

I understand. But I'm not pressing any buttons before the flight is loaded. Maybe some USB devices send some button states anyway?

This never happened before 7.5.5d September 7th.

Karl