John Dowson

If the value changes but the lights are not activating, I suspect that they are read-only (or non-active) lvars. Do the standard light controls not work (or the light offsets)? Have you tried logging Evenbts and operating the lights from the UI, to see what, if any, events are logged? If any are logged, you can use/assign to those. Many PMDG aircraft also come with there own SDK which include custom controls for such things, but I don't know if this is available for the MD11 - please check. If not, you could try using Mouse Macros. May also be worth checking on the PMDG forums as well. Btw, which FS and version of FSUIPC are you using?

It is giving you the error: *** LUA Error: C:\Users\Stu\Documents\Prepar3D v5 Add-ons\FSUIPC6\autorecord.lua:16: 'end' expected (to close 'function' at line 3) near '<eof>' This is a problem in the script that Pete posted: else if agl < 450 and aglhigh then should be elseif agl < 450 and aglhigh then With the space, it expects another 'end'. I will correct.

Did you try logging the lvars to see if the values changed? Maybe also worth logging buttons & keys to see what is happening. Which aircraft are you using? It is also possible that the lvars are read-only, and you need to use another method to control.

Ah, sorry - they are assigned to different buttons - 22 and 23. Try using two macro files (as really an lvar should only appear once in a macro file). Use the set control in both, but with a parameter of 1 to turn on, and 0 to turn off. I'm not sure of the behaviour if using the same lvar multiple times, even if they have separate actions. Alternatively, try logging the lvar values once you toggle or set - do they change?

So now you have it set to both toggle the three lights (assignments 6,7,8), and then set them all to off (using the set control with a parameter of 0 on assignments 9,10,11). Try removing the last 3 assignments (the set ones) and just use the toggle controls.

Maybe try running FSUIPC? You should see something in your log - here's mine: John

If writing as SD (signed Double), you need to read as a FLT32. Alternatively, skip the size: 13=A32NX_HYD_BRAKE_ALTN_ACC_PRESS=0x66D5 and read as a FLT64. S32 is a signed 4 byte value and will be an int, SIF32 is a 16bit/2byte integer + the fractional part in 16bits/2bytes. (see P13 and P43 of Advanced User Guide)

They are available from www.fsuipc.com or from the Download Links -> Useful Additional Programs section of this forum. John

Lua scripts are the way to achieve such things in FSUIPC! Check the User Contributions section - there may be something similar there that you can use or adapt for your use. Also, event.intecept() is probably not the function you need, as this intercepts writes from 3rd party applications, not internal FSUIPC writes. You would need to use the event.offset() function on the plane altitude, offset 0200 or 0B4C.

Sure. You can have a lua script monitoring for events using event.intercept() on offset 0x0570, which is the plane altitude. In the handling function, you can read the ground altitude offset (either at 0x0200 or 0x0B4C, depending upon accuracy required) to determine the AGL. You can then test that value and do whatever you like - e.g. send keystrokes to the FS via offset 0x3200, or send controls to the FS via offset 0x3110. John

Did you get any errors? Can you check the windows event viewer please and see if there is a crash report there, and if so show it to me. Problems with installation are usually due to nor having the correct VC++ redistributables installed. Try uninstalling any of the VC++ redistributables you have installed from 2015, 2017 or 2019, and then download and install the combined packages (both x64 and x86) from https://support.microsoft.com/en-in/help/2977003/the-latest-supported-visual-c-downloads. Then try again.

Yes, thats the latest released one, not v25 - I update the version locally when released, so I'm on v0.26. Sorry about that. Yes, sorry - missed that for some reason... Internally, all lvars are stored as 8 bytes. You can define the type/size as needed to hold the values that you want to use and FSUIPC will convert/cast to that size/type. Makes sense to use the size defined by the lvar I guess, but if its,say, a flag (0/1) and is defined as an int, you are better off just using a byte. As you say, the main thing os to make sure that you are reading the offset with the appropriate size/type function for the defined size/type.

👍 But do you need to go through the CDU menu to operate the doors? The specific (custom) events (or lvars) may be the easier way to assign for this.

It uses the wnd library, so you can use the arrow keys to move the window and the ctrl + arrow keys to resize. Give focus to the window first. The position will be remembered, i.e. stored in your FSUIPC .ini file. You can also directly edit the position and size coordinates in the .ini file if you like, but only when the window isn't being displayed.

Look at the FSUIPC Offset status document, or better, in the offset status spreadsheet provided for MSFS/FSUIPC7 (included in the zip download, but not installed in your documents folder*). If you search for 'Free for general use', you will find: 0x66C0 - 64 bytes 0xA000 - 512 bytes I am looking into making more space available for user offsets. * The offset status spreadsheet is a supplement to the offset status document, as I have not had time to update this yet. I am planning on updating this shortly. For now, best to use the spreadsheet which contains the latest info and is continually updated (v26 now) and consult the offset status documentation for the description only. No. You have to enable to use, and the other menu entries are only available once the info on available lvars/hvars has been received from the FSUIPC WASM module installed in the sim. This usually occurs several seconds (or longer, depending on configuration parameters in the WASM that can be tuned) once you have loaded an aircraft and are out of the menus and loaded and ready-to-go. John

No, sorry, I posted the wrong file. Corrected. No. WideClient is used for when running 3rd party FSUIPC clients on a 2nd computer.

Ok, thanks for letting me know. Strange that it worked sometimes though....!

But they are both exactly the same - no point in changing the annotations (the bits between -{...}-) as they are automatically generated. So what you are currently doing with those assignments is setting the Lvar L:LIGHTS_LDG_lT_L_Switch_var to 0 3 times. If you want the other assignments to work on a different lvar, you need to assign them to a different macro entry. If doing this manually (via editing the ini), then the macro line index number is the one after the colon - in your case, its 2 for all of them, so is activating the 2nd macro in your 3rd macro file (CM3), which is the one for lvar L:LIGHTS_LDG_lT_L_Switch_var, as indicated by the annotations. Please read the documentation provided, and the instructions I have already given.

Just work through it - its not that complicated. You are just assigning and then commenting out the assignment so that you can make a new assignment. And when all assignments are done, remove the comments to re-activate. And check the Advanced User guide, P19.

Also, I'm nor sure what those custom controls do, but 70171 is being sent twice on each button (5,6) press and release - is that correct?

Ok, thanks - just wanted to check!

Hi Ray, Apart from switching to using lvars, as suggested by Luke, you could try activating logging for Events and see if you can notice anything different in the log when closing the doors between when it works and when it doesn't. You could also try adjusting the TimeForSelect, but I don't know if this will have any effect as you are using PMDG custom controls (and I don't have any PMDG aircraft to check).

I don't understand this, as the location of FSUIPC7 doesn't/shouldn't matter - unless its installed in a windows-protected folder (i.e. under Programs). Do you have an FSUIPC_WASM.log file now? Just want to make sure of that, and the location.

When you re-installed, you also re-installed the WASM module. Sounds like the previous WASM module installation was corrupted somehow and wasn't being loaded. Do you now see the FSUIPC_WASM.log file?

Btw, are you using any other WASM modules? If so, maybe temporarily move them out of your MSFS Community folder so they aren't loaded for the time being.