John Dowson

Yes, but that maybe because you have TimeForLuaClosing=5 still set, which is the time betwwen these messages: 90688 Waiting for lua threads to process termination event... ... 95688 Lua threads being terminated: The com.close is done hbetween these log messages: 90688 LUA.1: Shutting down USB device hnd=1 ... 91328 LUA.1: USB Device disconnected So is taking roughly 0.65 seconds. You can try reducing the TimeForLuaClosing back to 2, or maybe even try 1. Also, for such issues, its also a good idea to enable logging for 'Extras', as this will then log the thread that is producing the message. Most shut-down issues are thread & timings related. The thread is still being killed later though, which is a bit strange, but at least the com has closed so this isn't an issue. However, I did reduce another timing that may have caused this - I will increase again slightly when I release this. Thanks for you help on this, John

Then it sounds like either FSUIPC was not installed correctly or it is not auto-starting with MSFS. First, try starting FSUIPC7 manually by double-clicking the FSUIPC7.exe. If it runs ok you will see a splash screen and then the icon will appear in your system tray. If it doesn't run, you should get an error, and if thats the case you need to re-install the VC++ redistributables. Instructions for this can be found in the README.txt that is in the zip you downloaded. If FSUIPC7 runs when you manually start it, there is a problem with the auto-start. If thats the case, I need to see your InstallFSUIPC7.log and your EXE.xml, whose location can be found in the Installation log.

No, not necessary. Please try the following instead: FSUIPC6.dll

and also try this one (and show me the log): FSUIPC6.dll

The file name has to be a substring of the aircraft name/title. The full aircraft title is "TBM 930 Asobo", so TBM930 doesn't match - you need the space, so use "TBM 930.hvar".

You can read/write to offsets using the free version. If you want to assign to them, you need the registered version. So that is fine with the free version. and this would require the registered version.

No - no way to currently access lvars via simconnect. I don't know Air Manager - can it access fsuipc offsets? If so, your best bet is probably to write the lvar values to free/user offsets, and then read them back from Air Manager using the offsets. If Air Manager doesn't use FSUIPC, then I'm not sure how you can do this - maybe using files, but that would probably be problematic as well as rather slow...

and also please try this one (same ini settings): FSUIPC6.dll I would like to see the logs for both dlls please....

Could you temporarily re-enable your event.terminate and try the attached dll please (with TimeForLuaClosing=5 set), and show me the log file after closing: FSUIPC6.dll

Yes, thats the new warning I added in 6.1. I would use this for now (i.e. no event.terminate), and I'll look into why that lua delay isn't working and get back to you.

Yes, looking at this now... Did you try this?

Interestingly, I checked my INI and the parameter was already there... set to 2. Yes, interesting... Ok. After you have done that, could you re-enable and change that parameter to something quite large, say 5 (seconds) to see if that makes a difference, and show me your log file afterwards (or the closing extract) so I can see if that has any affect. If not, I will look into it....

👍

You could also try increasing this parameter (with your event.terminate active): You can try increasing that....looks like this is maybe set to 1 in your ini (?), as from your log: Only a 1s difference between those messages....

Possibly. But please try first without closing down first - just comment out your event.terminate call.

Not sure that will do much as its the com.close thats the issue. As I said, first try commenting out the event.terminate (which will prevent the event.cancel and com.close being called).

Hi Luke, I'm not sure its failing - I think the com.close call is taking to long to finish and the script is being killed from the closing thread... Yes, there were some changes, but these were to increase some waits to give more time for the com threads to close down correctly. Was it working in the previous FSUIPC6 release before these changes? If you don't know, could you try (I can give you the previous dll if needed). Was that the complete log you posted? If so, then it does look like FSUIPC didn't shut-down correctly, which would prevent P3D from closing. It could be killing the thread when its in com.close that is causing the issue. Try commenting-out the event.terminate call, and see if terminating the thread without this is more reliable.

I can confirm that using the lvar for this works. I can't get the MF events NO_SMOKING_ON, NO_SMOKING_OFF & NO_SMOKING_AUTO to work though. Has anyone got these working via FSUIPC7, and if so, how?

You can can continue to use FSUIPC5 if you wish. Just download and install the latest version - 5.157.

Just use the latest version available then - 6.1.0 You shouldn't do that really. As I said, to uninstall, run the uninstaller. Deleting the dll will stop FSUIPC6 being loaded, but P3D will still try to load it, but will fail. And there is no need to uninstall if re-installing. As I said, just use the latest, v6.1.0

Which version of FSUIPC are you using - FSUIPC5 or FSUIPC6? If using an unregistered/unlicensed version, I suggest that you use the latest version, FSUIPC6. However, if you have an FSUIPC5 license, continue to use that (or you can get an FSUIPC6 license at a discounted price if you prefer). To uninstall, if using FSUIPC6, you can run the uninstaller that will be in your FSUIPC6 installation folder. If using FSUIPC5. simply remove or rename the FSUIPC5.dll to prevent it being loaded. However, there is no need to uninstall. Just download the latest installer and run that - that will automatically uninstall your current version and replace with the latest (and if you switch from FSUIPC5 to FSUIPC6, FSUIPC6 will replace your FSUIPC5 installation). For the latest versions of each product, see www.fsuipc.com, or the Updated Modules -> Download Links section of this forum.

There is an lvar for this: XMLVAR_SWITCH_OVHD_INTLT_NOSMOKING_Position This accepts the values: 0 = On 1 = Auto 2 = Off The MobiFlight events listed previously use this lvar.

I am not sure this is possible yet. The switch is working (in the FBW mod at least) but does not emit any events, and the Cabin No Smoking Alert Switch Toggle event has no affect. I also can't see any lvars/hvars for this switch either. However, looking at the MobiFlight WASM events document (see https://docs.google.com/spreadsheets/d/1jTXlcHaJWx0B7TB63Pmma7bKwpxsxXJO6EJ3ECt7zpc/edit#gid=172455454), I can see these events: NO_SMOKING_ON NO_SMOKING_OFF NO_SMOKING_AUTO so that looks promising! However, these events don't appear in my MobiFlight event file, but I haven't updated this in quite a while. So I would suggest trying these fist - or maybe asking over on the MF forum to see if they are actually implemented. To use with FSUIPC, you would also need to add them to an event file to make them accessible from the assignments drop-down. There i another post in this forum on how to do this if not familiar with MobiFlight events. I'll update my MobiFlight WASM today or tomorrow and take another look once done. John P.S. Are you using the vanilla A320 or an FBW mod? If the former, I suggest you update to use the FBW stable mod instead.

Yes, sorry - of course it should be '=Set' - updated.

So john, any progress on turning on leds on goflight modules ? I haven't and wasn't planning on looking into this. But, as Pete says, please look at the GoFlight library.