All Activity

@Luke Kolin Here's another version that also logs to an Ext window. This takes 10 seconds to initialise with 528 lvars. John LogLVars.lua

yeah i was pretty sure as nothing on the web or forums..thank you so much for your prompt reply. Stefano

@Luke Kolin Please see the attached script. Note that with 4423 lvars available, this takes 69 seconds for the initial scan of all the lvars, and is the same when FSUIPC is auto-started or manually started. There were no fundamental changes to the lua interface in FSUIPC7, just some additional functions were added (and access to lvars changed), so I don't understand why lua runs so much slower in FSUIPC7. I will look into this again when time permits. John LogLVars.lua

Just took a look at the lua script and it is incredibly inefficient.... Why are toy loading all lvars, and then checking for matches in the scanLVARS function? It would be so much more efficient if you: 1. Did the check on your matches and exclusions when you load the lvars. You can store matching lvars in a table if you like but this really isn't needed. 2. When you get get a match, simply add an event on that lvar which will get called when the lvar value changes 3. Log the lvar value change in the event.lvar callback I suspect that that the script was previously being killed because it is either running out of memory, but more likely it is taking far too long and you are restarting the script (by pressing the key again) and the currently running script is being killed (logging should show this!).

Read the documentation! Its the same as a write, but write to offset 0x0D70 with one colon, not two, e.g. ":ASD_SWITCH_EXT_POWER" Then read the value from the offset you wrote to 0x0D6C (0x66C0 in this case). John

Thank you for your support. This is the code that worked for me: #include <iostream> #include <windows.h> #include "FSUIPC_User64.h" #include <iomanip> using namespace std; int main() { DWORD dwResult; if (FSUIPC_Open(SIM_ANY, &dwResult)) { std::cout << "Connected to FSUIPC" << std::endl; double newLvarValue = 1.0; // The value you want to set // Step 1: Write the new LVAR value to user offset 0x66C0 if (!FSUIPC_Write(0x66C0, sizeof(newLvarValue), &newLvarValue, &dwResult)) { std::cout << "Failed to write new LVAR value to offset 0x66C0" << std::endl; } // Step 2: Write the offset address (0x66C0) and format specifier (0 for double) to 0x0D6C DWORD param = 0x066C0; // 0x66C0 offset + format specifier (0 = double) if (!FSUIPC_Write(0x0D6C, sizeof(param), &param, &dwResult)) { std::cout << "Failed to write parameter to offset 0x0D6C" << std::endl; } // Step 3: Write the LVAR command "::ASD_SWITCH_EXT_POWER" to 0x0D70 const char lvarCommand[] = "::ASD_SWITCH_EXT_POWER"; if (!FSUIPC_Write(0x0D70, sizeof(lvarCommand), (void*)lvarCommand, &dwResult)) { std::cout << "Failed to write LVAR command to offset 0x0D70" << std::endl; } // Step 4: Process the writes if (!FSUIPC_Process(&dwResult)) { std::cout << "FSUIPC process failed" << std::endl; } else { std::cout << "LVAR write command sent successfully" << std::endl; } FSUIPC_Close(); } else { std::cout << "Failed to connect to FSUIPC" << std::endl; } } Could you help me read an LVAR? @John Dowson

According to the docs, this should be DWORD param = 0x066C0 From the docs: As this lvar looks to only have values 0 & 1, you could also use a boolean/unsigned byte. You can check/verify that the lvar value is changing by listing the lvars (Add-ons->WASM->List lvars) [specific lvar logging facilities are also provided but probably overkill for this], and you can check that setting/changing the lvar value has the required effect using the Add-ons->WASM->Set Lvar menu item to change the lvar value. This will always log "LVAR ASD_SWITCH_EXT_POWER updated to: 1" regardless of the value of the lvar as you are just reading the value from the offset that you wrote the value of 1.0 to. You would need to write a read lvar request to offset 0x0D70 to get the actual value of the lvar. John

Please use the FSUIPC7 / MSFS sub-forum for all issues & questions on FSUIPC7 / MSFS2020 / MSFS2024. I have moved your post. No, this is not possible I'm afraid - there is nothing provided in the SDK that allows external control of the weather mode. John

That is interesting! Are your devices now recognised correctly by FSUIPC now (and no CTD)? Similar to the issue described here: https://techcommunity.microsoft.com/discussions/windowsinsiderprogram/how-to-remove-oem-drivers-causing-memory-integrity-problems-/3955127 ?

Using this code as your instructions just added a FSUIPC_Read function before Close: #include <iostream> #include <windows.h> #include "FSUIPC_User64.h" #include <iomanip> using namespace std; int main() { DWORD dwResult; if (FSUIPC_Open(SIM_ANY, &dwResult)) { std::cout << "Connected to FSUIPC" << std::endl; double newLvarValue = 1.0; // The value you want to set // Step 1: Write the new LVAR value to user offset 0x66C0 if (!FSUIPC_Write(0x66C0, sizeof(newLvarValue), &newLvarValue, &dwResult)) { std::cout << "Failed to write new LVAR value to offset 0x66C0" << std::endl; } // Step 2: Write the offset address (0x66C0) and format specifier (0 for double) to 0x0D6C DWORD param = 0x66C00000; // 0x66C0 offset + format specifier (0 = double) if (!FSUIPC_Write(0x0D6C, sizeof(param), &param, &dwResult)) { std::cout << "Failed to write parameter to offset 0x0D6C" << std::endl; } // Step 3: Write the LVAR command "::ASD_SWITCH_EXT_POWER" to 0x0D70 const char lvarCommand[] = "::ASD_SWITCH_EXT_POWER"; if (!FSUIPC_Write(0x0D70, sizeof(lvarCommand), (void*)lvarCommand, &dwResult)) { std::cout << "Failed to write LVAR command to offset 0x0D70" << std::endl; } // Step 4: Process the writes if (!FSUIPC_Process(&dwResult)) { std::cout << "FSUIPC process failed" << std::endl; } else { std::cout << "LVAR write command sent successfully" << std::endl; } // Step 5: Read back the value from 0x66C0 to confirm the change double readBackValue = 0.0; if (FSUIPC_Read(0x66C0, sizeof(readBackValue), &readBackValue, &dwResult)) { FSUIPC_Process(&dwResult); std::cout << "LVAR ASD_SWITCH_EXT_POWER updated to: " << readBackValue << std::endl; } else { std::cout << "Failed to read back LVAR value" << std::endl; } FSUIPC_Close(); } else { std::cout << "Failed to connect to FSUIPC" << std::endl; } } This results in : Connected to FSUIPC LVAR write command sent successfully LVAR ASD_SWITCH_EXT_POWER updated to: 1 But the switch in the simulator doesn't change, I am sure that the switch named ASD_SWITCH_EXT_POWER as I use SPAD.next to get LVARs. Is there is something I am missing ? Thanks In Advance. @John Dowson

*** Moved to FSUIPC7 / MSFS support sub-forum *** Hello Using a full cockpit Boeing 737 everytime i need to switch from custom weather to real weather i have to open the upper bar on the main view that actually is on external monitor (i'm using 3 projectors inside the cockpit).. so my question is: will it be possible to assign a key press trough fsuipc that i can assign to a specific switch inside the cockpit that can change the weather from custom to real and viceversa? I tried to search around but i didn't find any tip. Thanks in advance for any kind reply. Stefano

Hi John, Remembering your words " At a certain moment Windows Security showed a Device security error referring to drivers. Wild guess... any oem xyz driver. Found via Taskmanager sorted by driver; Number oem36.inf out of 50 was the culprit. For the records: oem36.PNF & inf removed from ../Windows/INF/... KR Jan

Thanks as usual John for the time taken to explain! I’ll have a look when I next sneak in some sim time, sadly I used up all my weekend sim credit already!

Ah, sorry -- I read this as "C/Program Files/MSFS/", which has certain restrictions, being under the windows Program Files folder. It is crashing when scanning your USB devices. This code has been stable and unchanged for 15+ years, and is in use by thousands of users, and is the same in all versions of FSUIPC since FSUIPC4 (at least). This issue is therefore specific to your system, and I have no idea what is causing this. I suspect an error is being returned on a low-level windows call which isn't being handled properly, and this is then causing a memory access error further down the line. I could probably add more error checking (to prevent the crash), but this wouldn't solve the underlying problem on your system. I know what error C0000005 is and do not need any pointers in how to look into this. And sorry, but I just don't have the time or resources to investigate this any further at the moment. I may return to this later when time permits, but for the time being you will have to try and resolve this yourself. You should at at least make sure that your VC++ redistributables are up-to-date. Download and install the latest combined package (2015, 2017, 2019 & 2022) to see if that helps. John

Hi John, Making Lvar names in FSUIPC insensitive would certainly be helpful when you have time to do it. Thanks very much, Al

Hi John, Looks good... yes .. for running the simulator: Note: Any folder created in C:/ with any name has full access fot System, Administrators and User; so is the folder I created for simulation programs: C/Program Files MSFS/.. The folders that FSUIPC7-installer uses are Allowed by Windows Controller access; the installer. exe is unblocked All conditions as in the README coming with the installer zip are checked and met. It does not matter which kind of hardware is connected on which usb port. The last experiences running FSUIPC7 with 24H2: enclosed filesException code 0xc0000005 explained.txtReport.werReport.wer contains 2 App-crash WER-reports and a text file Exception code; a fact is that fsuipc7.exe crashes always with the same memory address 00000000 00045d61. In the text file you find a link from MS https://learn.microsoft.com/en-us/shows/inside/c0000005 and how they look at APPCRASH situations and resolution. Take into consideration that 3rd suppliers use FSUIPC7 (unlicensed) for e.g. programming their Streamdeck profiles. FlightPanels.io for instance. The use the CONTROL codes to activate (read/write) for all kind of button functions in MSFS24 in those cases where LVARS are not avaliable (they think...). Please have a look and let me know your findings. For now and thanks for your continuous active support. Jan

The case of the lvar names used by FSUIPC is exactly that used when the lvar name is retrieved (in the WASM) by the gauge API function get_name_of_named_variable. These are then used in FSUIPC and are case sensitive. However, all functions/activity on lvars between the WASM and WAPI uses ids and not the name itself. So I could easily make access to lvar names case insensitive in the WAPI (and thus in FSUIPC) by making the WAPI lvar-name-to-id function (getLvarIdFromName) case insensitive. I can update this in the next WAPI update, but I am not sure when this will be at the moment, but there will certainly be one sometime this year. Note that if you use calculator code to access/update lvars rather than the lvar interface, then they will be case insensitive. Cheers, John

Ok, thanks for the update, although there are still a few things that are confusing me on this. For a start, the last image you attached (with the two WASM menus) showed the WASM working correctly (as Lvars had been received). Also you should be able to move the location of the Community folder without issues (as long as you have the same permissions in the new location). My Community folders are under D:\MSFS2020\Community and D:\MSFS2024\Community with no issues. But it looks like your D drive is also the windows installation drive (?), and if that is the case there will be additional security issues when installing under the root of that drive. Anyway, glad its all now working. Happy flying! John

Hi John, Issue solved! I moved the FS2024 community folder to the same root location as FS2020's: D:\Users\XXXX\AppData\Local\Community This likely resolved some permission issues I was having with the previous directory (which I had created myself, oddly enough!). As always, thanks a lot for your thorough support—much appreciated!

One other suggestion: rather than scanning and storing lvar values, why don't you use the event.Lvar function and get a callback when the lvar value changes? I suspect that would be a lot more efficient...

Sorry but I don't have the iFly so cannot look into this. But looking at the parking brake presets, they simply set an lvar value: Parking Brake ON: 7 (>L:VC_Gear_trigger_VAL) Parking Brake OFF: 8 (>L:VC_Gear_trigger_VAL) You can check if they are valid by using FSUIPC's logging facilities. List the lvars (Addons->WASM->List Lvars) and note the value of that lvar with the parking brake on and off - does it match those values (7 for on, 8 for off)? Are there any other lvars that look related to the Parking Brake? If you open the logging console (Log->Open Console), set logging for Events and Input Events, what do you see logged when you engage/disengage the parking brake? If you see any relevant events or Input Events, you can try using them. Otherwise, the following tutorials explains how to determine what to use for any given switch/button: MSFS2020: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ MSFS2024: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2024-model-behavior-dialog/ Also, please note that ALL provided presets are provided by the community driven effort led by MobiFlight (see https://hubhop.mobiflight.com/presets/), and any issues with presets should be addressed to MF via their Discord server, on the msfs2020 or msfs2024 channel, depending on the version you are using. John

In my experience Lvar names are not case sensitive in XML coding. But when used in Lua scripts with commands such as ipc.writeLvar("L: Name", value) or ipc.readLvar("L:Name") they are case sensitive, I assume because when enclosed in quotation marks they are treated like strings. This caused me a problem lately in MS2024 because in the XML code for an aircraft, the developer accidentally (I assume) was not consistent case-wise with some of the Lvars names. As a result my Lua scrip, which used Lvar read and write commands like the above, did not work as expected. So I'm posting this in case it helps someone in the future. What I eventually noted was in the Lvar list that the FSUIPC7 wasm provides, a few of the Lvar names had a different case then in the section of XML coding I was trying to access. Perhaps the wasm Lvar list "uses" whatever case the first Lvar it comes across is using -- don't really know. The Lvar list did not include both case variations of the Lvar name. It would be convenient if commands like ipc.readLvar( ) were not case sensitive, but that may not be possible. In my case, I had to use ipc.execCalcCode(" ") to get around the case issue because the Lvar names are not case sensitive in the XML CalcCode. If something above is not correct, or there is a better solution to this case sensitive Lvar issue, please let me know. Thanks, Al

I am having quite limited success with assigning presets on the iFly, for example the Park Brake preset doesn't work, neither does APU start, and I can only get one of the runway turnoff lights to work. I have no issues with any other aircraft using Mobiflight presets. Has anyone else run into problems with this aircraft and any advice? I am not a FSUIPC technical expert but I have managed to use aircraft specific presets for years with no trouble and this one is bugging me! Thanks

Please attach your ini with the logs, as already requested. Please update if you find anything, but this is very low priority (for me!) and I just don't have time to look at this in detail at the moment as I have far to much to do. I will investigate further when time permits, maybe in a few weeks time... John

Installing under Program Files is not recommended and can cause issues to to windows permissions. Looks good? Why do you say that? Looks exactly the same to me, with FSUIPC7 crashing on start-up when scanning for your devices...