John Dowson

Try the attached lua. You will need to auto-run by adding it to your [Auto.xxxx] section in your FSUIPC7.ini file (where xxxx is the name of your A320FBW profile) - see the Advanced User Guide if you don't know how to do that: A320ParkBrake.lua Note that this lua will continually run. I have added a sleep delay of 100ms, so it will check the lvar and update the offset 10x per second (roughly). which is probably overkill. If you have any resource issues, maybe better to add the lvar L:A32NX_PARK_BRAKE_LEVER_POS to an offset, then use the lua event.offset function to only spoof the offset when the lvar value changes. Should be relatively easy to do that (given the lua I have provided), but if you want to do this and have issues let me know and I can assist.

Yes - for any Linda problems you should ask on the Linda support forum: https://www.avsim.com/forums/forum/429-linda-support/ I'm sure @Scotfleiger will help you identify your issue.

You need to update to LINDA 3.2.6 or later - see https://www.avsim.com/forums/topic/573578-linda-326-p3dv5fsuipc6-compatible-17-aug-2020/ John

Btw, you can also use the same file for any aircraft with a G1000. Simply make a copy and give it a name that is a substring match to the aircraft name (with the .hvar extension, of course). You can also add and edit hvar files while MSFS/FSUIPC7 is running. To reload the hvar file once created or edited, use the Add-ons->WASM->Reload menu option.

Just took a look and the following hvars work in the stock G1000 in the DA62: H:AS1000_PFD_SOFTKEYS_1 H:AS1000_PFD_SOFTKEYS_12 You can test these (before assigning to them) using the Add-ons->WASM->Execute Calculator code.... menu option. To activate a hvar, enter (for example): (>H:AS1000_PFD_SOFTKEYS_1) To assign to these, you need to make the hvars known to FSUIPC7, To do this, drop the attached hvar file below into the modules folder of the lvar WASM module (located under your MSFS Community folder). With this installed, you can test then test these using the Add-ons->WASM->Activate Hvar... menu option. To assign to them, you need to create a macro file (*.mcro) or lua script. Details on how to do this are in the Advanced User Guide. DA62.hvar (NB. I have only added the hvars for the G1000 to that hvar file - there may be others you can use)

I'll take a look over the weekend and provide an updated lua for you to try.

You can do this using Compound Button Conditions. See the Advanced User Guide, P20. Note that there is also a lua solution for fast/slow turning of rotaries that only have one button in each direction. See the example script Rotaries.lua, provided in the Example Lua plugins.zip (in your FSUIPC7 Documents folder). You should be able to use that, or adapt to your needs.

It is to prevent autosaves during approach, but I'm sure that it could be adjusted to only enable on approach if needed. However, it is only for FSX and P3Dv1-3 - at least thats what it states, but I don't know why it wouldn't work in P3Dv4 & 5. I haven't tested or looked in detail, but maybe some of the offsets it uses are no longer populated/available in P3Dv4/5.

Note there are actually two controls, one to toggle auto-save on/off (auto save must be activated), and another to trigger an auto-save.

I haven't noticed this on my dev system, but I think I have auto-save disabled there. I will check this later. Note that this has always been an issue with more complex add-on aircraft (e.g PMDG), but has not really been an issue before with stock aircraft. Unfortunately I have just removed v5.1 from my systems so cannot compare to that, but I can check the times against my 4.5 installation. Note also that all FSUIPC does is call the SimConnect SDK facility to save the flight, so if there is an issue it is with the SDK and I won't be able to do much, except report to LM. I will let you know. One thing that has been known to cause such issues is anti-virus software, scanning the saved flight file as its being saved. You could check this and add an exception to the saved flights download folder to prevent this. I see Pete has also just replied....

One thing you can try to verify that it is FSUIPC7 crashing (or not, as the case may be) is the following: - start FSUIPC7 manually before you start MSFS - uncheck the option 'Exit with FS' - start MSFS. If you have MSFS set to auto-start FSUIPC7, this will generate an error which you can acknowledge and then ignore - Fly until you get your CTD #When you do that, does MSFS CTD and FSUIPC7 keep running, or does FSUIPC7 exit/crash? If the latter, it is a problem in FSUIPC7 and you should show me your log file. If the former, FSUIPC7 is not crashing but exiting normally as MSFS has crashed, and this needs to be reported to Asobo.

Sorry, but disagree on what? I am still waiting to see your log file from v7.2.0 that you still have not provided. I cannot help you until you show me this file (from when you say FSUIPC7 crashed). Once I've seen that, we can go from there. But any updated version will not necessarily fix your issue, as we do not know where it lies or what is the cause at the moment. It is strange that you ask for help but do not want to provide me with the information so that I can help you with your issue.

No problem with that. Ok, then as suspected the error is being displayed by windows after FSUIPC has exited but before the process has finally stopped. I'm afraid that there isn't anything I can do about this.

Can you try with the attached version please. This will not solve your problem, but will provide additional logging so I can track down where/when this error occurs, although I suspect it may be happening outside of my control.... With this version, can toy please check the contents of the FSUIPC7.log file when you get the pop-up error, and before you acknowledge it. I would like to know what the last message you see in the log is, before you acknowledge the pop-up error message. Thanks. FSUIPC7.exe

This is normal. Many aircraft continually send some controls, which are different for each aircraft. You can use the DontLogThese ini parameter, either in the [General] section of your FSUIPC7.ini, or in your [Profile.xxx] sections. Better to use this in the Profile section as the controls are different for eeach aircraft. Please see the Advanced User Guide for details.

No. And please refrain from hijacking unrelated topics. As the 7.2.0beta has now been released, I am closing this topic.

I'm not sure any additional logging is going to help. There are quite a few reports of this error on google. Some things to try: - if using an in-game overlay (e.g. GeForce experience, etc), then maybe try disabling that - check you are up-to-date with the latest windows updates - update your .Net framework - run the system file checker (run the command sfc /scannow from an admin command prompt) - check your windows Virtual Memory settings Have you always had this error or is this something new? If new, do you know when it started (i.e. after a windows update, an MSFS update, or an FSUIPC7 update?)

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.