John Dowson

@Grendel and @Blake Buhlig I got the gear lights working by making the following changes: - Change the initialization of GearIsRetractable variable (line 211) to GearIsRetractable=ipc.readUB(OFFSET_IS_GEAR_RETRACTABLE); NB. It would be better if all of the offset variables were initialized this way, as you won't get the correct value unless event.offset is called (i.e. when the value changes). - You could also add the following at the end of the script: event.offset(OFFSET_IS_GEAR_RETRACTABLE,"UB","offset_event") However, as this value doesn't change (it should be fixed!), this isn't really needed once the GearIsRetractable variable is initialized correctly. John

The gear lights don't seem to be working with that script, at least not for me with the G36. I will take a look when I get a chance. Make sure you are actually running the lua by adding it to the [Auto] section of your FSUIPC7.ini file, e.g.: You should at least see the PARKING BRAKE light work.... Also, the lua file should be in your FSUIPV7 installation folder - you should see it listed under the [LuaFiles] section of your FSUIPC7.ini (do not add it manually there - it will be added automatically when detected).

FSUIPC5 is always available from the download section here, and also in www.fsuipc.com. It is only the license that is no longer for sale. But if you have already purchased a license, you can always retrieve your license details from your SimMarket account. However, you should really move to FSUIPC6 if you have a license for that, and resolve your Linda issues with that version. FSUIPC5 is still supported (for P3Dv4.5), but is closed for future development.

@Dan A A trial license is now available here: Fir all future license requests, please use that topic. This topic is now closed/locked.

Please find a trial license for FSUIPC7 attached below, valid until 1st December 2024. Just save this key file to your FSUIPC7 installation folder and you are good-to-go. Note that trial licenses are NOT validated by the FSUIPC7 installer. John FSUIPC7.key

Sorry, looks like some hidden/control characters got inserted into the script. Try the following one: A320ParkBrake.lua

Strange. When this happens, do you already have the FSUIPC icon in the task bar (i.e. is the main window already open and/or iconised?)? Or does it move from the system tray (where it usually sits) to the taskbar? Do you have the console window open (with this open, there will also be an FSUIPC icon in the task bar)? Maybe try with the FSUIPC7 console window open (with FSUIPC in the system tray), to see what (if anything) is logged when this occurs

If that is the case, then it sounds like the lvar values are not being updated. But in your second post, you have different values for pBrakePosition, so is this problem resolved? There will not necessarily be a parking brake event as the A/c is using the lvar. Did you try logging the parking brake offset to see what the value is when the lvar value changes? Maybe try that,. Looking at offset 0BC8, the description says: Parking brake: 0=off, 32767=on Currently the script is just writing the value of the lvar, which is 1 for on. You therefore need to adjust by adding: if pBrakePosition == 1 then pBrakePosition = 32767 end (after you have read the lvar value and before you vall ipc.writeStruct). Updated script attached. A320ParkBrake.lua

Try: ipc.writeStruct(0x0024, "1UW", spoofOffset, "1UW", 1, "1UB", doorMainState )

@Dan AApologies - forgot to do this, will be first on my list tomorrow... John

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.