LeoSchoonbroodt

Hi John, Sorry had not much testing time lately. Tested today with V7.3.3 as you asked and the ini parameter UseAirLocForHvars=No worked. I included the FSUIPC_WASM.log. Thanks for repairing it. FSUIPC_WASM.log

Hi John, unfortunatedly had only limited time today but did one test with UseAirLocForHvars set to No and the Airbus H145.hvar. Hvar file was not loaded also not when i executed a Wasm reload via lua. I included the WASMFSUIPC_WASM.logFSUIPC7.logFSUIPC_WASM.inifor you. Setting the UseAirLocForHvars parameter back to Yes and using the Hvar file with a subset of the folder name worked well. I also did some tests with starting FSUIPC when MSFS was running and always got the -------------------- Starting everything now ---------------------- message when starting, but forgot that you mentioned that MSFS should be in the main menu, sorry about that. Could do some more testing tomorrow, for me the problem is solved because i am using a subset of the folder name now for my Hvar files. Leo

Hi John, Did some testing today with logging set to Debug, and found, on my system it is always looking to the folder name instead of the title in the aircraft.cfg No matter if i put the UseAirLocForHvars to No, to Yes or leave it out at all in the FSUIPC_WASM.ini in my Community\fsuipc-lvar-module folder I always deleted Persistant storage folder as to be not hindered by any cached values. I have the folowing Folders: hpg-airbus-h145 hpg-airbus-h145-civ hpg-airbus-h145-mil and the folowing Titles Airbus H145 Luxury Liery 1 Airbus H145 Civilian Livery 1 Airbus H145 Military Livery 1 With version 1.14 i used the Airbus H145.hvar which worked for all three planes now with version 2.3 i have to use hpg-airbus-h145.hvar which works for all regardless of the UseAirLocForHvars setting. So looks like it is always looking for the folder name. Did not yet test with restarting FSUIPC while MSFS still running because i always wanted a clean start. if you want to i can test this tmorrow because today i run out of time.

Hi John, My Hvar files are in the Community\fsuipc-lvar-module/modules folder. No change other than upgrading to 7.3.2 Only when i found Hvar files not loaded anymore i put the UseAirLocForHvars first in the FSUIPC7.ini, later in the FSUIPC.WASM.ini and set it to No, but both with no result I tried the FSUIPC_WASM.ini in the modules folder and in the persistant storage work folder, both with no result. Have to test a little bit more tomorrow, it started working after several restarts of MSFS. Have to structural investigate tomorrow because i copied around and renamed the Hvar files so much that i lost focus about what i changed. Keep you informed, thanks

Hi, Yesterday i Updated my FSUIPC version from 7.2.14 to 7.3.2 and now it doesn't load my Hvar file anymore. I hae read about a new ini parameter UseAirLocForHvars but have no idee where to place it and what the values should be. Aleady tried the FSUIPC7.ini file and also the WASM.ini file with values No and Yes but without success. Please can anyone help, because i make heavily use of Hvars and my plane is unflyable this way. Also tried to restore previous version but then it starts complaining about WAPI version conflict Thanks, Lo

Only the ones you suggested, removing the ipc.exit() and ipc.sleep from the terminate event function. Leo

Hi John, Just to keep You up to date, NO problems encountered anymore. Will report back if anything changes. Leo

Hi John, Sadly, Not OK anymore after todays first flight, entering the main menu, FSUIPC7 exited while MSFS still running. Didn't notice until i after having dinner started a new flight and discovered that my lua wasn't executed (cockpit did not initialise). Send you the FSUIPC7.log and the Windows Application event log text. Last entry in logs states that FSUIPC7 is waiting for the the lua to process the termination event. All this does is closing the Com Ports, sleep for 500 ms and then execute an ipc.exit() But included the lua file anyway in case you want to verify what's happening during this event. Must have about 7 or 8 flights that worked fine last days. EDIT: Next flight, same result, send those logs too. Will restart MSFS to see if that solves it. Very strange, so many good flights and then 2 fail after each other. Restarted MSFS and had a flight without problems, don't know if this has something to do with it. EDIT 2: Just realise, today is the first day i used AirForcePlayer, a program to simulate Force Feedback on my MS Sidewinder 2 FFB Joystick. It's a program that uses the MS DirectInputAPI, don't know if it's something but will test tomorrow without it and the day after with it to see if it's making a difference. Leo FSUIPC7_exited on return to main menu.log Windows Application log FSUIPC7 exit.txt JS145.lua FSUIPC7_exited on return to main menu-2.log Windows Application log FSUIPC7 exit-2.txt

Hi John, Yes everything works as expected no FSUIPC7 hang, no LUA crash, even without the KillLuasOnSimStop=Yes parameter, but have to say that i, because of some work i had to finish, didn't have more than a few flights a day last days. So i decided to wait a few more days before reporting back, also because i know you must have more work to do and didn't want to report "everything OK" before i really am shure it is. As long as you don't hear anything you can asume that i didn't encounter anything disturbing. Will keep you informed when things change. Leo

Ok, glad you found that. Will test the new version this evening, are working now. Will check also on that ini parameter, can't remember at the moment, changed that much lately. Thanks, Leo

Well John, Using your version 7.2.13 Looks like the FSUIPC7 Hang isn't solved by your code. You didn't remove it, didn't you? First flight and ending of MSFS did FSUIPC7 not end with when MSFS exited, had to end it in TaskManager. Second series of flights, at last flight when entering Main Menu I got again an FSUIPC7 hang and had to exit it again with TaskManager Send you the Logs and TaskManager screens. Leo FSUIPC7_does-not-end.log FSUIPC7_HANG-ENTERING _MAIN-MENU.log TESTSEQUENCE.txt

Hi John, You mentioned investigating problems around WASM reload. I do not know if that lua-crash has anything to do with this, as i got this crash on the first flight after enabling WASM reload on non-accessibility of a Lvar, i thought you would like to know this. That's why i say if it is of no value, just disregard it. I have no issues with it, as the lua would anyway be terminated at the end of the flight and doesn't hang FSUIPC7 , just didn't know if this special crash after crash situation would be of any value to know for you. Leo

Hi John, Will test this version this evening and report back. Had yesterday evening again a lua crash after a plane crash. Went back to main menu after about a minute and about a minute after that exited MSFS. No FSUIPC7 hang or message about terminating lua threads Could it be this happens because of an abnormal end of flight? Will investigate this further to see if i can make ir reprocucable. Btw, was the first flight after enabling all WASM reloads for non-present Lvar's again. Don't think this was the cause, because the refresh routines must have run several times before the crash. Will send you the log anyway, because i cannot judge if it is of any value, if it's of no use for the problem you are investigating just disregard it. Leo FSUIPC7_LUA-CRASH_after_PLANE-CRASH.log

Hi John, Hope you get the time and enjoy the recreational flying. Everyone needs some time off for sure. Is it possible that a WASM reload happens when i use Escape key to return to the menu and then resume, because i forgot to save my flightplan for display in Little Navmap? Because that is something i do sometimes. Another possible WASM reload is when i access a Lvar which returns nill, i do a WASM reload. If that could cause it i will comment these out for test. Will further investigate and as you asked, will report if i get a crash that isn't directly after a 'EVENT_HVARS_RECEIVED' message. Will also adjust the WASM.ini parameter LvarScanDelay to 45 seconds. Have nice flights. Leo

Hi John, Using the new release v7.2.12 did not have to wait long on FSUIPC7 crash. First flight, immediately showed my Cockpit didn't display values. On check discovered that FSUIPC wasn't running anymore. Sent you the FSUIPC7 log and the Windows Eventviewer Application log entry. Directly after the crash i manually started FSUIPC7 and halfway the destination airport is still running. Hope logs help to pinpoint the problem. Just in case you need it, also included my lua script. Leo FSUIPC7_CRASH.log JS145.lua Windows-Application-Event-FSUIPC7_CRASH.txt

Thanks John, Will keep you informed of how its going. Leo

Ok, will change the ini file parameter and send you the logfile when it happens again. Got no lua crashes anymore, and the FSUIPC7 crash happened 3 days ago and yesterday twice, so very randomly. Have done at least 15 flights in that time. If it happens more often, i will enable lua debug logging but my experience is that it slows my system that much that it becomes unusable, at least in a way that it misses button presses. I had sometimes to press a button 5 or 6 times before something happens. Would maybe adding a ipc.sleep of a few seconds after opening the Com ports be a solution? Because the crashes always happened immediately after that as far as i can see becuase my arduinos send some switchstates at initialization and there is one that is still not programmed in the lua, so i normally get the message RECEIVED: ZZ696690 NOT RECOGNISED/EXECUTED after initializing the Com ports and here i miss this message which indicates to me that connection is lost before this time. Leo

Hi John, No lua-crash/FSUIPC7 hang anymore but recently 2 imes a FSUIPC7 CRASH. Both direct afterloading the lua file and opening the comports. Unfortunately i didn't save the FSUIPC7 log from the first one but i have the second one and both windows application event logs, so i send you these hoping you can pinpoint where it happens and the cause of it. Its the version that you send as last, so with the code that prevents a hang when a lua file crashes. EDIT: just happens Again, this time before loading the lua file, i attached 2 files FSUIPC7-CRASH-BEFORE-LOADING-LUA.log and its windows application log. Cheers, Leo FSUIPC7_EXIT-after-Com-init.log FSUIPC7-CRASH.txt WINDOWS-APPL-LOG_FSUIPC7-EXIT-after-Com-init.log FSUIPC7-CRASH-BEFORE-LOADING-LUA.log WINDOWS-APPL-LOG_FSUIPC7-EXIT-BEFORE-LUA-LOAD.log

OK, If the last event is available that should be enough, will experiment. Thanks again.

Ok, thanks John, have a nice evening. Leo

John, I always check the log after exiting to the main menu and if find a lua crash check if FSUIPC7 IS STILL RESPONDING. As i found above result i exited MSFS but i think it was after about 10 seconds. If the times in the log show miliseconds as i think, then that's about what the log shows also? 4763094 - 4752047 is about 11 seconds then? Will keep you informed if i get any new hangs because as you stated, that lua crash really doesn't matter because it was terminating anyway. Still would be nice to know what caused it initially to see if it maybe could give some problems at other places but agree there are probably more urgent things to resolve as the impact of te crash is now solved. Another question, i put several ipc.sleep() calls in my script to not overrun the arduino's. If there is an event during this time, will i miss this, or are the events hold in a buffer? Leo

Hi John, Did yesterday a flight with the second of the above downloaded versions of FSUIPC7 during which i several times manual reloaded the JS145.lua because i got a build from the developer of the H145 Airbus helicopter that has some Hvars fixed that i reported earlier as not working. During this reloads for testing there was never a problem but when finished and returning to the main menu i got a lua-crash but this time without hanging FSUIPC7, so i think your code to prevent this hang is working, I did some flights to test the new Hvar functionality to report back to the developer, all without a problem. Today i get family visit over here so don't have the time to try and replicate te situation and test again and again. Don't think the lua file was the cause because several flights after the crash went well, but to be complete still included the active one in the post, especially because it is changed after the last one i posted. The Plane is a Work In Progress, so is the JS145.lua See if i can find time somewhere to try and replicate the crash. If you have any suggestions what to test to pinpoint this, please let me know. Leo FSUIPC7_lua-crash_NO-hang.log FSUIPC7_OK-1.log FSUIPC7_OK-2.log JS145.lua TESTSEQUENCE.txt

Hi John, Testing yesterday with the first posted version, could not get a crash/hang. Changed a lot of things to try to get a lua crash with no result. At the end i also changed the outcommented display statements to log statemens because it displays info about the execution, all without changing linenumbers of the rest of the JS145.lua. To many things to mention, so i included a TESTSEQUENCE.txt which describes the things i tried and the result and name of the logfile involved. I am testing now with the second version but until now without crash/hang. Will keep you informed about the results. Leo ComPorts.txt FSUIPC7_Disconnected ComPort-7.log FSUIPC7_OK_EMPTY_COMPORTS_RECREATED.log FSUIPC7_OK_with_new_ComPorts-txt_and_Aircraft-change.log FSUIPC7_OK-NEW ComPorts-txt-made.log FSUIPC7_OK-with reconnected Com7-after-previous-CTD.log FSUIPC7-reconnected Com7-then-CTD.log JS145.lua TESTSEQUENCE.txt

John, Did yesterday evening a lot of testing but could not get a lua crash. only thing changed is that i outcommented the GetComPorts.lua But this script was last run on september 16 as i can see at the creation date of the created ComPorts.txt file. Will further test with the provided versions and when i get a lua crash and/or FSUIPC hang i will post the complete log. Leo

John, The JS145.ini is the profile file not the lua file, the lua file was posted in a previous post. The reason this GetComPorts.lua is executed is when the arduino's are plugged to another port which changed the comport of it. The Getcomports.lua is not dormant and was used in a separate file because its only used when i switch hardware which is maybe once in a month or less. I will post it, but i also just comment the call for testing so it will never be called, just to be shure it is not the cause. Post the modified JS145.lua and Profile file JS145.ini too. Leo GetComPorts.lua JS145.ini JS145.lua