John Dowson

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.

No, those offsets are only populated from simvars received via SimConnect. I can reproduce this issue now but do not understand it. I will look into it and get back to you. It also looks like FSUIPC7 isn't auto-starting luas when FSUIPC7 is started and MSFS is running but in a paused state. I will also look into this.

Use the Log -> Offsets menu option, giving the offset addresses and the code U32.

Yes, I know - I am looking into it... One thing you could/should do is delete the contents of the [General] section in your FSUIPC7.ini file and let that get rebuilt, as some of the values need updating. Once you've done this (and ran FSUIPC7 at least once), change back the following parameter: I will look into the offset value issue, when I get a chance...

@Mugz Before I add those new simvars, could you check offset 0C4C (Nav1 GlideSlope Flag), which should be TRUE if the GS is active, and false otherwise. Maybe also check the value in 0C4D.

But the log you posted shows that the offsets you are logging held 0 So, is this the correct value? If so, there is no issue with 'read wrong offset value if load in mid-flight', but the crash is an issue. Could you maybe try disabling the WASM module and test again, to see if that is causing the crash. I will also test here to see if I can reproduce. Also, please show me/attach your FSUIPC7.ini file.

The log file is in your FSUIPC7 installation folder. If you do not know where that is, you can use the File -> Open Installation Folder... menu option. If you cannot see the log file, you have windows explorer set to hide known extensions. If this is the case, please see the Addendum in the Installing and Registering FSUIPC7.pdf.