John Dowson

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

It does not install that way, unless maybe you ran the installer with elevated privileges, which is not necessary and not recommended. But it is very difficult to understand what is happening when you do not respond to my questions. Are you running MSFS with elevated privileges? If you start FSUIPC7 manually, does it run with elevated privileges? Please follow my advise and then report back and attach files so that I can see what is happening (not screenshots).

I have moved this topic to the FSUIPC7 sub-forum. Please use this sub-forum for all FSUIPC7 support.

I have moved this post to the FSUIPC7 sub-forum. Please use this sub-forum for all FSUIPC7 support.

It also may be easier to use macros, which are another method of sending multiple controls/events. Save this attached file to your FSUIPC7 installation folder (before running FSUIPC7, or restart FSUIPC7 after installing): FSLA321.mcro Then start FSUIPC7, and assign your buttons/switches to FSLA321: Nose Swtch Up - to move the switch up FSLA321: Nose Swtch Down - to move the switch down You can then add other macros to the same file to control other switches. I have added Strobe and Beacon. John P.S. The Beacon switch controls seem to act like a toggle, so sending the Up when in Up position moves the switch down, and vica versa. So you only actually need one macro for this switch. Just FYI.

First, please don't embed your comments in quoted text - it makes if difficult to read and is just not necessary - put them outside please (as I do!). This is strange, but I do not think it is being blocked anyway as it is running - not sure why it says that in the properties. Also, please only attach files AFTER exiting FSUIPC7. No, you misunderstand me.... Are you using an XBox 360 game controller (gamepad)? Sometimes these are fake and can cause issues - if so, they can be ignored, And you cannot use these directly with FSUIPC - you need to install additional free software to use these with FSUIPC. That shows two copies running, which is vary strange and shouldn't be possible.... This does nothing but add extra logging. The JoyScan.csv file you attached is empty. This is worrying and is probably the cause of your issues, although I do not know why this is reported: Have you installed any specific drivers or additional software for your devices? If so, please uninstall any drivers and let windows install default drivers, and do not use any additional device software when using FSUIPC as this can interfere. Also please check that if they are USB2 devices they are connected to a USB2 port, and if USB3 they are connected to a USB3 port, and that if using a hub make sure the devices are properly powered. Can you also please just test running FSUIPC for the time being, i.e. no need to run MSFS. Just start FSUIPC7 manually without MSFS running for these tests, and ALWAYS exit FSUIPC7 before attaching files. Please do the following: 1. First uninstall any specific drivers for your devices if you are currently using any vendor supplied drivers. 2. Run the windows registry editor and take a back-up of your registry. 3, Unplug your devices. 4. Download and run (i.e. double-click) the following file: removeDevices.reg This will remove the current registry entries for your devices. 5. Reboot. 6. Delete your FSUIPC7.ini file. 6. Reconnect your devices, making sure they are connected to the correct ports, if possible (i.e.USB2 to USB2, USB3 to USB3). 7. Run FSUIPC7. Once it starts, exit and then show me / attach your FSUIPC7.ini, .log and .JoyScan.csv files. 8. Run FSUIPC7 with elevated privileges/as Admin, and again show me / attach your FSUIPC7.ini, .log and .JoyScan.csv files. John

This is nothing to do with "programming". It is assigning to the logged FS control/event with the logged parameter. I don't know why you tried this - that obviously won't work. There is no SDK for the FSLabs and therefore no custom controls. It may be possible to use custom controls, but you would have to determine the control number and it certainly will not be the parameter used via the Rotor Brake control. Please re-read my previous comment as it looks like you did not understand this at all: I said use parameter 72510 as you said this was logged when you use the taxi light switch in the VC. Why are you using 72511 when you said this was 72510? When I move the Nose light switch from Off to Taxi, I see this logged: and moving back, I see this: I am not sure why 2 controls are logged, but assigning to the Rotor Brake control with parameter 72512 moves the Nose light switch up, and assigning to 72511 moves the nose light switch down. So try that. If that works, you can just leave it at that. However, as two controls are logged when you move the switch in the VC, I would replicate this in the assignments. How you do this depends on what you are assigning to. The easiest way, if using a momentary push-button, would be to assign using one parameter for the press and another to the release, with both using the Rotor Brake control. The other way of doing this is overloading (i.e. having more than one assignment on a button) via editing the FSUIPC7.ini file. Assign the button press to the first control, save (press OK), and then open your ini file in an editor. Then open the button assignments panel again in FSUIPC7. Locate the assignment just made - it will look something like this (the index number may vary, as well as the button used) 4=PB,10,C66587,72512 -{ROTOR_BRAKE}- Duplicate this line, and give the new entry a unique index number and change the parameter, i.e. 4=PB,10,C66587,72512 -{ROTOR_BRAKE}- 5=PB,10,C66587,72514 -{ROTOR_BRAKE}- Save the changes, and then in FSUIPC7 click Reload all buttons. You then have two assignments on the same button, but you will not see this in the UI. John

Yes - they were logged when I turned the Captain EFIS ND Mode switch, as I said. You assign to the Rotor Brake control and use 72510 as the parameter - that should then control the taxi lights. I didn't yest/check that as you did not mention that this was for the taxi lights. It is straightforward - whatever you want to assign, operate in the VC, see what is logged and then assign to that. In most cases it will be a Rotor Brake control with a parameter, so assign to the Rotor Brake control and use the parameter logged. John