John Dowson

That is very strange....I've really no idea what is causing this....Does it also occur if you start FSUIPC7 (without MSFS) and then exit? Yes, no problem! Yes, they are both quite minor. There is nothing I can do about the exe.xml file not working (as it is in the correct format and in the correct place), so you will need Asobo support for that one. This has also been reported before and I couldn't determine why for those cases, so advised to switch back to the old method (i.e. starting FSUIPC7 from the MSFS.bat file, as you now do). I'm not sure what else you can try...I think I'll have to build a special version for you to try with more logging added to the shutdown sequence to see if I can determine where this error is coming from. I'll post an updated FSUIPC7.exe for you to try tomorrow. Cheers - and good night! John

So the EXE.xml is in the linked folder? It should still work - it is quite a standard set-up, I have MSFS also installed on a separate drive. I think you need to raise a support request for Asobo for this, sorry. Ok, thats helpful but also very strange as that means it occurring after everything else has closed down.... Me too! Can you try disabling/unchecking the 'Exit with FS' option. Then when MSFS closes FSUIPC should stay open. Once MSFS has closed, give it a few seconds and then exit FSUIPC. If you do this, do you still get the error, and if so, when?

Nope, still no error for me....very strange....

Ok - I haven't tried with Alt-F4, I'll do that, but presume its the same as closing by quiting thw MSFS main window. Does the same happen when quitting MSFS from FSUIPC (using the MSFS -> Exit oprion)? Doesn't the logging pause when the pop-up error is displayed? Is that displayed before or after the console log window closes? The Exe.xml looks fine. From what folder is it located? Presume you have a MS Store version, and it is under C:\Users\Peter\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache, no? You could try switching to using the SimConnect document type rather than Launch (as I have seen that this is used quite often). Please change your EXE.xml file to the following: If that doesn't work, I have no idea why MSFS is not picking this file up and auto-starting FSUIPC7, sorry. Ok, thanks. What about when exiting MSFS from FSUIPC7? Also, can you let me know when this pop-up error occurs, and what happens when it does. Does the FSUIPC7 window/icon and console window disappear before this message is display, or after? I'm going to try closing with Alt-F4 now to see if that makes a difference....

No, still can't reproduce this error.... Could you activate logging for Extras on FSUIPC, and also activate Debug logging in the WAPI by adding this line to the [WAPI] section of your FSUIPC7.ini file: LogLevel=Debug Could you also have the logging console open when you close down (Log -> Open Console), and let me know what the last message logged is when that error appears. Send me the log and let me know when the error occured. Once thats done, you couldalso try switching to updating lvars from the client (if not doing that already), by adding this line to the [WAPI] section of your FSUIPC7.ini file: LvarUpdateFrequency=6 (that is for 6 updates per second). You should also disable updates from the WASM by setting the following in your FSUIPC_WASM.ini - either in your Packages folder, if you have an FSUIPC_WASM.ini file there, or under the fsuipc-lvar-wasm folder (in your MSFS Community folder) if not): LvarUpdateFrequency=Off This is just to help me track down where the issue lies. It could be a timing problem with SimConnect when closing down (and probably in the WAPI code). Thanks.

Exiting from in a flight or from the MSFS main menu? I have tested using your scripts with the FBW dev and stable and still cannot reproduce. Are you updating lvars from the WASM (the default) or from the client? I'm updating from the client at the moment - I'll switch to using the internal WASM update mechanism (the default) to see if the issue lies there....

You are not starting your luas from the [Auto] section - are you starting them from your ipcReady.lua file? If so, can you please also show me that file as well. Its probably better to start them from an[Auto] section, but it still should not give that error - although I don't know if this is related at the moment. Also, can you try with the FBW stable (and maybe development) version, to see if that makes a difference. Thanks.

I've now added com ro my tests, opening it in each of the 3 luas, polling the com in the poll loop, and closing the com connection in the event.terminate function. This is the log I get when I go from flight back to main menu: And here is the log from exiting MSFS/FSUIPC7 when in a flight: So it seems that all the event.terminate functions are being called in all situations.

Could you show me your FSUIPC7.ini and your 4 lua files (FCU_Speed/Hdg/Alt/VS.lua) and I'll see if I can repeat here. If I can't reproduce, we can try adding extra logging to track down where this is occurring. Its nothing to worry about though, as FSUIPC7 will be exiting anyway. Does it occur every time? Are you using the stable od dev version of the FBW A32NX?

No - thats the changes.txt file that I provide... But this is exactly the same log that you previously posted. Did you not read my last comment? i.e. update to the latest (and only) supported version and try again, and show me the new log file if you get a CTD, together with all Windows Event error logs.

You can try mapping the lvar to an offset and then using the offset spoofing facility, located at offset 0024. This will replace ('spoof') the parking brake offset to the value of the lvar. There is also an example lua script provided that shows you how to use this facility, called liar.lua.

In lua, you can use the event.offsetmask function to trigger a function call when the required bit in the offset changes - see the FSUIPC Lua Library document for details in using this function. In the attached version below, v7.2.1c, I have added the following simvars to offsets: - AUTOPILOT GLIDESLOPE ARM at offset 0x0C7B as a 1 byte flag (unsigned byte) - AUTOPILOT GLIDESLOPE ACTIVE at offset 0x0C7C as a 1 byte flag (unsigned byte) Please let me know if these are working or not, and for which a/c. Thanks, John FSUIPC7.exe

I set up a simple test with 3 luas auto-started, each with an event.terminate function registered that just logs a message when called. When going from a flight to the main menu, this is what I see logged: So, the event.terminate function was called in each script, and each thread was killed after TimeForLuaClosing (2 seconds). So this all seems correct to me. When exiting MSFS from a flight, either from MSFS or from FSUIPC7, I see the following logged: This log shows that the event.terminate function was again called in each script, but there was only one 2s delay (the TimeForLuaClosing ) before all lua threads were killed. Note that these tests were done with a slightly modified version (with additional logging) of the 7.2.1b version I posted yesterday, and I am not using the com library, which can take a while to close down successfully. I can add some com handling and repeat my tests if necessary. So, could you try again with the attached version, and let me know what happens (best to attach your full logs) when you leave a flight to go back to the main menu, and also when in a flight and you exit MSFS/FSUIPC. Thanks. FSUIPC7.exe

Can you not configure the FSUIPC offsets that are used by the acars tracker program? Maybe raise a support request for this to see if this is possible. I can't really consider updating how FSUIPC7 handles the parking brake offset for a single add-on, especially when its still only a development version. I could maybe consider how to handle this in the future, if/when it moves to stable, but I would not consider looking into this while its still in development.

You can map the parking brake state lvar to a free user offset (e.g. 0xA000) using the lvars-to-offsets facility, released in v7.2.0. You would then need to configure the acars tracker program to use that offset instead of offset 0x0BC8 - if you can do that. Offset 0x0BC8 holds the simvar BRAKE PARKING POSITION .There is also another simvar called BRAKE PARKING INDICATOR , but this is not currently held in any offset. If this is updated for the A320 FBW, I could also add that to an offset. However I doubt this is available/populated as the they are using lvars for this now, but I will take a look when I get a chance...

That is a log file from the 5th June. It is incomplete, so looks like FSUIPC7 did crash. However, you are also using an old and now unsupported version of FSUIPC7 - the current (and only supported version) is v7.2.0 - can you please update. Once updated, if you experience your crash again, please show me the log file from the crash + any (and all) error from the Windows Event log + a description of what you were doing (i.e. what were you doing with the MCDU?). Thanks.

Please remember that you should NOT manually edit or change the [LuaFiles] section unless you know what you are doing. This is generated and maintained by FSUIPC and should not be manually edited.

I am confused. First you say I can close the topic, then you say the terminate function is only being called once, which means this is not closed and I need to look into it. I will look into this tomorrow. No point posting again until I have looked into it and can reproduce. ...oh, and please remember, I cannot do anything with pasted log extracts. Always attach your full log, and not just paste log extracts.

Note the delay is specified by this ini parameter (in the [General] section) - you can try reducing if you like: TimeForLuaClosing=2

No, I don't provide support via PM, so please raise a new topic. Please include your FSUIPC7.log file, preferably with Lua Plugin logging enabled if the crash is related to your lua plugins - or does it crash without those running? Anyway, raise a new topic with all the information you have about the CTD, and I will take a look tomorrow.

As mention in one of you other topics, I have removed the flag that was used to only allow the event.terminate call to be performed once. I've also attached that version (7.2.1b) here: FSUIPC7.exe I'm not sure if this is the final solution though, as I think this will add a delay to terminating all lua scripts, event if they do not use event.terminate. I will look into this further tomorrow.

Ok thanks. Yes, I removed a flag which was set to only call the event/terminate once. So I can close/lock this topic now, no? We should investigate the FSUIPC7 crash, but can you raise a new topic for this please. I'll comment on the event.terminate on the other topic you raised for this.

This version better (still 7.2.1b though): FSUIPC7.exe

@Mugz Please try the attached version, 7.2.1b: FSUIPC7.exe

I have found the issue. The problem is that before writing the received value to the gear position offsets, FSUIPC is checking offset 060C, the IS GEAR RETRACTABLE offset. This is 0 (i.e. still unpopulated) when the gear position is received, so FSUIPC is setting the gear position offsets to 16383. I will fix this and post you a new version to check either later today or more likely tomorrow morning. I have also found an issue with luas not starting when you start FSUIPC7 and MSFS is already running but in a paused state. This will also be corrected.