John Dowson

@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

@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

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 ?

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

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

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

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

Yes, but it is a different sim, and I have no idea what the issue currently is - previously it was due to the WASM not starting, which looks to be due to the strange permissions issues you are having. Are these now solved after a re-install? Did you try renaming the Community folder as I suggested? I really cannot help you if you do not tell me what you are trying and at least answer my questions - I have no idea what you have done and what the current state is... Is the WASM now running? Is an FSUIPC_WASM.log file now generated? Do you still have the same permissions issues? I am still waiting for this information and to see a log file if available....if the WASM isn't running, then you need to determine why, and if it the permissions are still an issue.