John Dowson

If you have any problems, let me know and I can maybe assist if you let me know which aircraft you are using (CRJ I presume - from Aerosoft?)

Ok. But note that offset 3367 is a byte-oriented offset. So the value in each bit is a different door. So, a value of 100 is 0b1100100, so that is doors exit3, exit6 and exit7. Write the appropriate value (for the doors you want to control) from the relevant lvars. i.e. if different doors are different lvars, they are distinct bits on the offset.

I have already explained how to do this.... What don't you understand?

No! What this does IS to write the value to the lvar offset...well, not exactly, what it does is that when ANYTHING (almost, see the description for offset 0024) reads that value, it will read the spoofed value. Just try it!

You can adjust for this in the lua script. Once the lvar value is read, just change it to the correct value in the lua script before writing.

No, you cannot do this. You can 'spoof' the value in that offset to the lvar value if thats what you need to do. I have recently posted a lua script on how to do this for the Parking Brake offset in this post: If you want to spoof the value of offset 0x3367 to the lvar L:DOOR_MAIN_DOOR_POS, take the lua from that thread and adjust as needed. Then check the other issues I mentioned.

Several things...! First, check that the lvar exists - is it listed when you list the available lvars (Add-ons->WASM->List Lvars menu option)? If so, good. If not, the lvar doesn't exist, or has not been registered with FSUIPC. If the latter, you could try reloading the lvars after load (using the Add-ons->WASM->Reload menu option). If thats the case (i.e. the lvar is created AFTER FSUIPC requests the lvar list), then you can increase the LvarScanDelay WASM ini parameter (just noticed the name is missing in the Advanced User Guide - I will correct). Then, you are specifying that the value should be written to offset 3367 (or trying to...). This is NOT a user offset. For lvars, you need to add them to free user offsets (e.g. starting at A000 or 66C0, etc). And no spaces between the size an offset address (or though this may be allowed, I forget...but it IS NOT as specified to use, so best not to include spaces). Also, check what the value of that lvar holds - if its an integer (unsigned), then use UW, if signed, use SW, if just a flag (0 or 1), use UB.

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