John Dowson

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.

New one posed, valid until 20th August 2021.

This is very strange - you have a connection to the FSUIPC WASM module so there must be a log file somewhere. Can you try searching for it? If you don't have Everything, I recommend you download and install it from https://www.voidtools.com/ and use that to try to find the location of this file. I need to see this (maybe also with Debug logging enabled, or maybe Trace) as the issue looks to be in the WASM module as no CDA config data is being seen by FSUIPC7. Did you try this? Are you sure you did this? The [General] settings haven't changed.... Maybe also try with FSUIPC7 started before you start MSFS - although it shouldn't make a difference when you start FSUIPC7, it is still worth checking. You also tried to list the lvars a couple of seconds after the WASM connection was obtained. Doesn't matter in this case, but best to wait 30 seconds or so (more if you have the WASM LvarScanDelay parameter configured in the WASM ini) after the aircraft is loaded (or FSUIPC7 started) before you start to use lvars or hvars.

Just took a look at the C208B and I got 95 lvars when spawned cold & dark: So it does sound like something specific to your system. As I said, please try with and without Linda to see if that makes a difference. John

It will be under C:\Users\eliag\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\packages\fsuipc-lvar-module\work (please see the Advanced User Guide, P44.) I'm not sure why you also have an FSUIPC_WASMIF.log file - have you been modifying the FSUIPC_WASM.ini file (if so, please show it to me) or using the WASMClient? Anyway, could you enable Debug logging in the WAPI by adding the following to your FSUIPC7.ini file under the [WAPI] section: LogLevel=Debug Also, please delete everything under your [General] section and let that get rebuilt, as you have a lot of old and no longer relevant settings there. Then, start MSFS and load an aircraft and try again. If you still get 0 lvars, also try issuing a Reload command from the FSUIPC7 WASM menu. Then exit and show me your FSUIPC7.log, FSUIPC7.ini files, and FSUIPC_WASM.log files. I see you are also using Linda. May be a good idea to disable that for the time being (i.e. rename the lua script that start it) while we try and determine why the lvar details are not being received. And how are you starting FSUIPC7 - via the auto-start method or manually?

No sorry, that is not possible. The only thing you can do at the moment is to use different profiles for the C172 based upon the name, using one with the G1000 assignments and the other without. If you want to use the G100 assignments in another aircraft, you can manually copy the assignments in your FSUIPC7.ini to another profile, remembering to change the index numbers if needed. I have thought about this issue, i.e. to have common assignment blocks for AP systems that can be used in different profiles, but there are two many issues to handle. For example, on some aircraft you can change the AP systems on-the-fly (via a flypad or EFB). This means I would have to look into how to determine when the AP systems have changed and update the assignments dynamically, which would be very difficult if not impossible at the moment. Its also difficult to manage such assignments via the assignments dialog (e.g. where to save assignments to - general, profile or common block, when/how to trigger a common block load, etc) You could also use multiple FSUIPC7.ini files(e.g. FSUIPC7-G1000.ini, FSUIPC7-G540.ini, etc) for different AP sub-systems, and rename them to FSUIPC7.ini before starting (or before reloading assignments if already started) to use them. John

I'm not sure without seeing your files your log files - can you show me your FSUIPC7.log and FSUIPC7.ini files, and also your FSUIPC_WASM.log file. Someone has reported that the lvars weren't available until after the engine had started, but I haven't been able to reproduce this. John

But FSUIPC is started by MSFS via the EXE.xml file. Even if you delete/change or don't use the shortcut, FSUIPC7 will still be started by MSFS if the entroes in the EXE.xml aren't removed. To do that, you need to uninstall and re-install without the auto-start component selected. I don't think so, but I don't use MF. By using the EXE.xml to auto-start FSUIPC7, MSFS should start it at the correct time, when it is ready to except the SimConnect connection requests. Anyway, go with whatever works for you! Regards, John