FSUIPC7 hangs when waiting for a lua event and MSFS in main menu

[LeoSchoonbroodt]

Hi John,
Have a flight logged with examples of this FSUIPC7 hanging

Started MSFS and when in main menu selected another Aircraft (Schweizer) as seen at 144297 BUT ipcInit.lua doesn't execute the plane change

Did some screenshots of Taskmanager, FSUIPC window and Console and as you can see from taskmanager FSUIPC is at more than 10% and this for minutes long
while the CPU is barely around 36%.

Only when lost focus to MSPaint for saving a screenshot suddenly ipcInit executed the planechange

Then when starting a flight at 731234 FSUIPC  all looked normal until Checking for Aitcraft lua's which did not load.
I also have seen this several times with older versions.

After waiting for 118 seconds i loaded the Schweizer.lua manually from a Buttonbinding in the ini file and as this worked, it's an indication that
FSUIPC is alive, but (maybe doing other tasks until interupted???)
From there on everything looked correct but i finnished to save the logs.
btw i provided an exit in all Aircraft luas when Plane parked and OnGround because if not autostarted it will also not be killed.

Above description happened several times last days 
and fwiw i got the feeling the problems always happen if FSUIPC is idle for some time 
but that's only a feeling.

For completeness i also included the ipcInit.lua, the Schweizer.lua and the Schweizer.ini

Leo
 

FSUIPC SLOW.zip

[John Dowson]

I have moved your post to a new topic, as this is not related to the topic that you originally posted in.

Why are you running luas when MSFS is in the main menu? FSUIPC7 only fully functions when you have an aircraft loaded and the camera system is out of the menu system.
The ipcInit.lua should only be used for any one-off initialisation you need to perform, it should not wait for events.

6 minutes ago, LeoSchoonbroodt said:

Started MSFS and when in main menu selected another Aircraft (Schweizer) as seen at 144297 BUT ipcInit.lua doesn't execute the plane change

It won't. Why do you want to do this?

7 minutes ago, LeoSchoonbroodt said:

After waiting for 118 seconds i loaded the Schweizer.lua manually from a Buttonbinding in the ini file and as this worked, it's an indication that

Are you doing this outside of the main menu? FSUIPC7 should not process button assignments when MSFS is in the menu system.

Things have changed quite a bit moving from FSX/P3D to MSFS, especially with the new menu system. FSUIPC7 is really designed to work with an aircraft loaded and ready-to-fly, and you should not be doing much, if anything, with FSUIPC7 when MSFS is in the main menu.

If the auto-luas are not started, then that would be an issue. If that is the case, can you please show me log files for this.

 

[LeoSchoonbroodt]

Hi John,

Problem of WASM stop still present, see logs.

My other problem (FSUIPC-Window not accessible), still present, but only when in main menu, during Flight this is accessible normal.
Have seen that FSUIPC_WASM.log contains about 5000 lines "[ERROR]: Ignoring request to update LVARs as updated internally" for a short flight.

Although it's logged to an SSD drive could that be the culprit of FSUIPC-window not accessible? and when so, why then only in main menu?

 

Leo

Logs.zip

[LeoSchoonbroodt]

And another one, have the feeling it's getting worse instead of better.

Another question, how can i disable WASM logging?
I tried by setting it to Disable in the FSUIPC_WASM.ini in the persistant storage and in the modules fsuipc-lvar-module folder, but that seemed not to work as can be seen from the logs.

Logs.zip

[John Dowson]

1 hour ago, LeoSchoonbroodt said:

Problem of WASM stop still present, see logs.

  The log file shows that the WASM ran and exited as expected.

However, it does look like you have a WAPI client set to update Can you please set
    LvarUpdateFrequency=0
in all of your WAPI clients, including FSUIPC7. Allowing the WAPI to request lvar updates was something I thought would be useful, but this is really of no use and you should let the WASM update and push-out lvar updates, I will remove this option at some point.

1 hour ago, LeoSchoonbroodt said:

My other problem (FSUIPC-Window not accessible), still present, but only when in main menu, during Flight this is accessible normal.
Have seen that FSUIPC_WASM.log contains about 5000 lines "[ERROR]: Ignoring request to update LVARs as updated internally" for a short flight.

Although it's logged to an SSD drive could that be the culprit of FSUIPC-window not accessible? and when so, why then only in main menu?

You need to get rid of these errors before we look at anything else.

56 minutes ago, LeoSchoonbroodt said:

Another question, how can i disable WASM logging?

 You cannot disable completely. You need to stop those errors.

I moved your comments from the beta release thread to here where they belong. Please use this thread for your issues, as they are nothing to do with the latest beta release.

John

[LeoSchoonbroodt]

1 hour ago, John Dowson said:

  The log file shows that the WASM ran and exited as expected.

However, it does look like you have a WAPI client set to update Can you please set
    LvarUpdateFrequency=0
in all of your WAPI clients, including FSUIPC7. Allowing the WAPI to request lvar updates was something I thought would be useful, but this is really of no use and you should let the WASM update and push-out lvar updates, I will remove this option at some point.

You need to get rid of these errors before we look at anything else.

 You cannot disable completely. You need to stop those errors.

I moved your comments from the beta release thread to here where they belong. Please use this thread for your issues, as they are nothing to do with the latest beta release.

John

John if i look in the logs then i see 

   647719 23128  [ERROR]: SimConnect_RequestClientData for lvars failed!!!!
   647828  7668  [ERROR]: Error setting Client Data Calculator Code [-1073741648]: '(A:TRANSPONDER STATE:1, number) (>L:TransponderState)'

if i then Disable and re-Enable the WASM again via the Add-ons-menu, (see 658563 and 920828) everything worked again.
in the last FSUIPC7.log i had to do this twice, after which all calculator code worked again and I could normally end my flight.
This indicates to me that the WASM stopped and had to be started again which was the original bug you repaired or do i see this wrong?

The only WAPI client i have is FSUIPC, i dont use any other modules that query the FSUIPC_WASM and the setting in the FSUIPC_WASM.ini was -2, so once every 2 seconds. But i will try  with LvarUpdateFrequency=0 

Will report back to you after that.

 

[LeoSchoonbroodt]

Hi John,

Used as sugested LvarUpdateFrequency=0  but no change.
Started MSFS and created flight from KLAS to KLAS, so far all good.
BUT after: 185250 10080 Lvars/Hvars received - checking aircraft autos....  nothing happened anymore so i had to load the Aircraft lua manually again
via a buttonmapping in the ini file.
After that everything seemed to work correct up to 1161516  4548  [ERROR]: SimConnect_RequestClientData for lvars failed!!!!
Also the 5 second regular check for transponderstate by using DataCalculatorCode failed, for me an indication that WASM was not running anymore.

So i had to Disable and re-Enable WASM again through the Add-on menu after which everything worked fine again.
Also noticed that the FSUIPC_WASM.log again had almost 6000 entries of  [ERROR]: Ignoring request to update LVARs as updated internally  
So nothing changed so far i can see.  This is something from the last versions as i had this never before and my configuration didn't change.
Will try another flight but now with another Aircraft although i don't see how thwt could help but doing nothing is also no option.
Hope this will help to pinpoint the problem.

EDIT Sorry, just see that i  i set the LvarScanFrequency=0  instead of the  LvarUpdateFrequency=0  My mistake, so forget about this post,
will try another one with correct settings

Leo

Logs.zip

[LeoSchoonbroodt]

John, tried with LvarUpdateFrequency=0  and now the FSUIPC_WASM.log doesn't contain those errors and i got no errors indicating WASM stopped in the FSUIPC7.log.  Especially did for a short flight with an Aircraft that makes a lot of Lvar reads. So far so good.

Didn't think about testing if the FSUIPC-window was normally accessible in the main menu but will certainly test this tomorrow.

Still wondering how these errors suddenly happen as the LvarUpdateFrequency has always been 6Hz in my configuration, but for now it works.
Thanks for your help, hope for happy flying hours again

cheers,

Leo 

[John Dowson]

Your issue is that you had lvar updates set both in the client (FSUIPC) and in the WASM.

You did NOT experienced a WASM crash. The WASM is embedded into MSFS and is started with MSFS and closes with MSFS. You had issues with the WAPI, which is the API that FSUIPC uses to connect to the WASM.

What you have now done is switch of lvar updates in the WASM and are using FSUIPC7 to request lvar updates. This is not a good idea and could get issues in the future with this configuration. Please do the following:
   - Go back and set LvarUpdateFrequency=6Hz (or to VisualFrame) in your FSUIPC_WASM.ini files (both of them, if you are using both)
   - open your FSUIPC7.ini and remove the LvarUpdateFrequency from the [WAPI] section

This will switch lvar updates back to the WASM, which is the better and recommended configuration.

[LeoSchoonbroodt]

Hi John,

Your advice was exactly to the point.

I switched the WASM  LvarUpdateFrequency  back to 6Hz and removed it from the [WAPI] section of FSUIPC7.ini and now all works as before.

No inaccessible FSUIPC7-window or very slow responses anymore and no Error entries in the FSUIPC_WASM.log.

Don't know when this double LvarUpdateFrequency is put into the [WAPI] section of the FSUIPC7.ini but it could only be me who did it, just can't remember when and why.

Anyway, thanks for your help, going to enjoy my flights again 😂

Leo

[LeoSchoonbroodt]

Sorry John,

Only just now i see your other questions from Yesterday so i will try to answer them here

Why are you running luas when MSFS is in the main menu? FSUIPC7 only fully functions when you have an aircraft loaded and the camera system is out of the menu system.
The ipcInit.lua should only be used for any one-off initialisation you need to perform, it should not wait for events.

The ipcInit.lua just monitors Planeselection change and updates an offset that is monitored by a wideclient, but i could move this to another lua started by ipcInit.lua but i don't see the difference.
The only thing this Wideclient does at this moment is display the many  functions of Switches of my cockpit for the selected Aircraft (which are different for each Aircraft) to give the possibillity to set switches as they should be for this Aircraft before the Aircraft is loaded and the Auto lua starts and reads those switchsettings.
Especially important for warmstarts as you can imagine if switches are in wrong positions, the Aircraft may shutdown.
I could reprogram the Wideclient lua's to monitor the offset "3D00" and would not use ipcInit.lua anymore, but it always worked this way.

 

Are you doing this outside of the main menu? FSUIPC7 should not process button assignments when MSFS is in the menu system.

Yes, i can manually load the Aircraft lua only when the Aircraft is loaded and do this when the "Checking for Aircraft auto's" doesn't load the lua which sometimes happens. The buttonmapping is in the profile file for the Aircraft which is only loaded once the Aircraft loads.
Also used this in the past while developing the lua's to reload a modified lua after making changes without always having to go to the main menu
If it happens again that the auto lua isn't loaded i will attach the logfiles.

But again thanks for your help with the above problem.

Leo

[John Dowson]

If things are working, keep it that way. Just be aware that many things won't work when MSFS is in the main menu, and especially when booted to the main menu as many FSUIPC threads will not be running and are not started until an aircraft is loaded and ready-to-fly.

6 minutes ago, LeoSchoonbroodt said:

do this when the "Checking for Aircraft auto's" doesn't load the lua which sometimes happens.
...
If it happens again that the auto lua isn't loaded i will attach the logfiles.

That certainly shouldn't happen, but I think there were some situations where this could happen in the past but these should have been corrected. So, if you do get this again, please show me your logs.

Regards,

John