John Dowson

Ok, then what you need to do is spoof the offset value with the modified lvar value. Just take the lua script I previously told you about and linked the post where available, change that script to use the offset you want to spoof, i.e this: local spoofOffset = 0x0BC8 -- Parking Brake offset, unsigned word (2 bytes) to this: local spoofOffset = 0x3367 -- Exit Open offset, bit per door (1 byte) Change the variable to read your lvar: ... local pBrakePosition = 0 ... pBrakePosition = ipc.readLvar("L:A32NX_PARK_BRAKE_LEVER_POS"); ... to ... local doorMainState = 0 ... doorMainState = ipc.readLvar("L:DOOR_MAIN_DOOR_POS"); ... Then you can apply whatever transformation on that value you require to write/spoof offset 3367. If it is as you say, its very easy to assign a new local variable to the value you want to set, based upon the lvar value, then adjust the ipc.writeStruct statement to your requirements. Hopefully that should give you enough information to do what you require.

Maybe an example will help you.... Door 1 is bit 0, so to open just that door, you would set bit 0, i.e. write 0x1, or just 1. Door 2 is bit 1, so to open just that door, you would set bit 1, i.e. write 0x2, or just 2. Door 3 is bit 2, so to open that door, you would set bit 2, i.e. write 0x4, or just 4 If you write 0x3, or just 3, that is 0b11, so that would open doors 1 and 2 (bits 0 and 1 set). So, as I said, if you write 100 (in decimal), that is in binary 0b1100100, which is: - door 1 closed 0b1100100 - bold is bit 0 - door 2 closed 0b1100100 - bold is bit 1 - door 3 open 0b1100100 - bold is bit 2 - etc To change single doors, you need to read the offset value as it is, then change the bit (using the lua logic library) for the door you want to control. You should or the original value with the bit flag you want to set, or and to clear. I understand this may sound advanced for your understanding, but it really isn't that difficult. If you can tell me exactly want you want to achieve (i.e which aircraft and, if applicable, which mod, and which doors) then I can maybe help you further if you have issues. John [Note some folks call bit 0 bit 1, which is confusing. But you can usually tell by context]

An offset is just a memory starting address. You also need to consider the size (1 byte in this instance) and the data that it holds (bit-oriented flags for that offset address). I'm sorry, but this is not the place for a tutorial on these concepts - there is google (or other search engines) to help you with basic understanding, And I'm sure its the same in xplane/xuipc. You just need to understand the concept of bit-wise flags. Its really not that difficult. Try by re-reading what I have explained. And, if you still don't understand, just do it by example: log the offset values for the different states, and write the value for the state you need when necessary....

And the solution? Always helpful if other users have the same problem and come across this topic, so please post what resolved your issue.

Each door is a separate bit (i.e. a 0 or 1 value) in offset address 0x3367, which is 1 byte, thus holding the state for 8 doors (Exit1 to Exit8). You need to write the byte value (i.e all 8 doors) to the offset, and each bit in that value will control doors 1-8 (or those that actually exist)

No! That is, sorry, just rubbish. 0x prefix indicates hexadecimal. 0b binary. 0x3367 is the offset address, which is 1 byte, 8 bits. We are talking about bits here... Sorry, but you are obviously not computer literate. Please just follow my advise....

No! Please re-read my posts.... It is a 1 byte offset, but each bit in that byte represents a value, 0 or 1, depending if the door for that bit is open or closed ....you seem to be posting many messages before I can respond...I suggest you read my posts and digest first....

Be aware: 3367 1 This byte shows doors that are open, one bit per door: 2^0 = Exit1 … 2^3 = Exit 4.

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....