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.

You also need to wait for everything to load before trying to do anything - it takes time for things to load (depending on your settings). Your log shows you are trying to operate far too early.

That log is confusing me, as it again shows that the lvars were not received. However the image you previously posted showed that he lvars were received and available. Forget about the duplicate WASM menu. That is not important and will be fixed in the next release, and will not cause any issues. If you now have your original issue (presets not working), then we are back to square one and I need to see both your FSUIPC7.log file and FSUIPC_WASM.log file (with Debug logging enabled) from the same session. Finishing for the day now. I may look over the weekend, but probably will be Monday. Please review my previous posts on this matter, i.e. check the WASM isn't crashing, etc John

This was possible in 7.5.1 but should have been fixed in 7.5.2...but I can see the cause (there was a problem with the fix!). I will correct this in 7.5.3. This will only happen if the initial simconnect connection times out, but is nothing to worry about. John

...and if you restart FSUIPC7 do you see the same?

Strange...will check that over the weekend - can you attach your FSUIPC7.log file please. But it shouldn't matter much - looks like the WASM is now installed correctly and working. Have you tested?

Ok, then this would indicate some serious issues with your PC, either software or hardware... Ok, that would make sense. I would also run some full hardware checks. Your issues are very strange and I can't remember seeing anything like this before, so it would indicate either a windows issue or a hardware issue. Are you overclocking? Let me know how it goes... John

So it must be MSFS2024 that is starting FSUIPC7 with elevated permissions, and so I would expect that MSFS2024 itself is running with elevated permissions. But if that is the case, I do not understand why it cannot start the fsuipc WASM module. This is very weird and I do not understand... When it uninstalled, did it remove the fsuipc-lvar-module folder and all its contents? If so, then you certainly have write privileges on that folder, so I do not understand why you cannot edit the files in there, or change permissions. Maybe...One last thing to try.... Can you rename your MSFS2024 Community folder? If so, do that (e.g. Community-old), and then create a new Community folder and copy the contents across (as a standard user). Can you show me the UserCfg.opt file for your MSFS2024 installation as well please, and your InstallFSUIPC7.log file. Otherwise I am out of ideas, and maybe a complete uninstall/re-install is necessary. Are you using the Steam or MS Store version?

Also, please check and compare the Security permissions on your Community folder and fsuipc-lvar-module folders. It seems that your issue is certainly permissions related but I have no idea what could have caused this - it is certainly nothing that the FSUIPC installer does. It does nothing with permissions. You must at least have permissions to Read and Read & execute (and maybe more) for either Everyone or Authenticated Users. This is what mine look like: Windows is getting stricter on permissions with each release. But I am no expert in this area I am afraid, and if your issue is with permissions then it is specific to the set-up of your PC, which you will need to investigate. You can always try editing the permissions so that at least you have read and read & execute access to those folders and sub-contents.

This would only be useful for a handful of users and is not something I will look into, sorry - I have far too much to do this year already. It is pretty quick and easy to cut and paste the lvar names from the log, so that will have to suffice for now. So the lua isn't being killed? What changed? Can you leave it running please, at least to see if it works or gets killed - that is if you want me to look into this. Yes, this has been reported in several other threads. Note that: 1. Debugging lua plugins will make them run far far slower. 2. It seems that lua scripts run a lot slower (by a factor of 8 or so) when FSUIPC7 is started by MSFS. Try exiting FSUIPC7 and re-starting manually. 3. You can usually get better performance from lua scripts by using the LuaAffinityMask ini parameter to move lua execution off of core 0/1. This also applies to FSUIPC using ThreadAffinityMask. I use: ThreadAffinityMask=xFC LuaAffinityMask=x100F00 But there are online tools to calculate affinity masks based upon the number of cores you have (and if you use hyperthreading) Regards, John

it does not. As I said, please just start FSUIPC7 manually - does it run with elevated privileges? When you run MSFS2020, does FSUIPC7 run with elevated privileges? FSUIPC7 and the FSUIPC7 WASM are distinct - FSUIPC7 does not start the WASM, that is running (or should be) inside of MSFS. Can you edit the FSUIPC_WASM.ini for MSFS2020? Do you see the FSUIPC_WASM.log file for MSFS2020? Have you followed my advice? And again, screenshots are useless. No point attaching them unless I request them (which is hardly ever).