LeoSchoonbroodt
Members-
Posts
100 -
Joined
-
Last visited
Profile Information
-
Gender
Male
-
Location
Netherlands
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
LeoSchoonbroodt's Achievements
-
Hi John, From the FSUIPC_WASM.log i can see that it doesn't find the .hvar file for the plane. although they are present in the fsuipc-lvar-module\modules folder of 2020 and 2024. They are NOT listed in the layout.json, but for 2020 that was never a problem. In the persistent storage i find a MSFS2020 and a MSFS2024 folder. Only the MSFS2020 folder contains a the fsuipc-lvar-module folder with only a work folder, containing the attached FSUIPC_WASM.log but no modules folder with hvar files. Is it possible that FSUIPC only looks for hvar files listed in layout.json as that would explain why the 2 not listed therein are not found? Sorry forgot to mention: several calculatorcode executions worked this time but stopped after a few seconds. Leo
-
Yes copied the complete fsuipc-lvar-module folder structure from MSFS2020 community to the MSFS2024 community. It's an aircraft copied from the MSFS2020 community folder and the name isn't changed. Also confirmed because the plane loads and corresponding profile file and lua file are loaded. I will check the persistent storage locations and let you know if that's the case and will enable WASM debugging BTW also ipc.execCalcCode wich i also use a lot for sending Hvars because you stated earlier that it not needs to know the Hvars did not work. Leo
-
Hi John, I have a question, if you copy the WASM module from 2020 community to 2024 community, isn't the minimum Game Version in the Manifest way to high, or do i understand this wrong? I ask because the log tels ne that Lvars are loaded but 0 Hvars while those Hvar file is in the modules folder. All my Hvars used via lua are not working, while they are working in 2020. Leo
-
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
-
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
-
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
-
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
-
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.
-
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
-
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
-
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
-
Hi John, I have a problem that my WASM stops during flight. I have seen it before and cannot be certain it started with this latest version but this time i have it logged with the Extra logging option. Noticed it because i could switch on the wipers via calculator code and some time later couldn't switch them OFF. Looking at the FSUIPC-Console i found a lot of errors indicating that the WASM was not running anymore, so to test this i disabled and re-enabled it via the menu and the errors ceased and all started working again. I attach the FSUIPC7 and WASM logs. Another thing i have seen in the past days is that FSUIPC menu's are sometimes not accessible and FSUIPC seems to hang when in the main menu, and then after some time starts working again, but i have no clean logs when that happened as i tried several things to get it working again which might confuse the matter, but thought to mention it as i am not sure if it's related, If it happens again i also will provide those logs Leo Logs.zip