John Dowson

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.

Can we please look at one issue at a time. It is starting to get very confusing as to what your actual issue is... So, lets use this topic for your issue with the the wrong values being reported. So, disable your other luas for now, and lets concentrate on this one issue. And, for this issue, please show me your full log file, where you start FSUIPC7, your script starts, and then the offsets start to be logged. Let it run for a minute or two, then exit FSUIPC7 and show me the generated log file. ...and I don't want Lua Plugin logging activated for this issue. That was for your other issue (i.e. the crash issue) - please disable while investigating this issue .

That log was from your crash - I have asked you to activate logging for Lua Plugins and repeat your test and show me an update log for that issue. The values being logged is a separate issue (and the one you raised this topic for). I see no 'Gear L N R state:...' log lines in the log you previously posted. You are logging the gear state every second - I am interested in seeing the other log statements, to see if these values change once data is received from MSFS. Its easier for me if you can always attach your full log file, rather than pasting extracts (or even the full log).