John Dowson

When FSUIPC7 starts, you should see a splash-screen displayed for a few seconds which tells you it is running. If you don't see that, then it hasn't started. When it is running, it will be n your system tray and you can open the main window from there, or use the (default) hotkey combination of Alt+F. If it is not running, try starting it manually to check it is installed correctly and working, i.e. double-click the FSUIPC7.exe in windows explorer. If it does not run, you may need to update/.install the correct VC++ redistributables - see the README.txt for details. If it is not auto-starting with MSFS (and you have selected to install an auto-start component), see the following FAQ entry: John

Your ini file shows that you have assigned your throttles to the Y axis on your Saitek Pro Flight Quadrants (devices D and E): But the images you attached show Throttle1 assigned to the Z axis. Therefore the images and ini files don't seem to match. (Also, please make sure that you have exited FSUIPC7 before attaching files). I think what is happening is that when you are moving the axis you want to assign to the throttle, another axis is being detected first. This can happen, and when it does you can either click Clear to start again, or Ignore Axis if the same axis keeps getting detected. Check the In/Out values are changing once the moved axis is detected - if they stop changing (or only change slightly) then a different axis has been detected and you need to try again, Also, why are you using a delta value of 1? That is extremely low and is not recommended - the default value of 256 should be sufficient, so just use that for now and only update if you really need a finer resolution, and reduce in stages (e.g. try 200 first, then maybe 175, etc). But 256 should really be sufficient resolution when you have a 32768 value range. So, I would again delete any axis assignments to throttle (as well as those empty assignments) and try again. Delete these when FSUIPC7 is closed, or when the axis assignment panel is open and click Reload all assignments afterwards. And then re-assign following what I have said. That is ok and how it should be. You are assigning with no reverse zone, so the axis range of -16384 to +16384 is calibrated to the forward thrust range of 0 to 16384, so when the axis is at position -16384 the actual axis value that should be sent is 0.

If you mean the FSUIPC profiles folder, this is only created/used if you are using profiles-in-separate files. This is not active by default and all your profiles are kept in the FSUIPC7.ini file. If you want to use profiles-in-separate files, you have to manually changed the UseProfiles ini parameter setting to Files (as it says in the documentation).

What lvar? Lvars are aircraft specific - check any documentation for the aircraft you are using, or list the available ones. I asked if there was a simvar available for this - I don't know of any, and couldn't see anything in the Asobo documentation. If YOU can find where this information is held, then I can look into adding it. I couldn't find anything when I looked before. As far as I know, this info is only available for AI aircraft with the simvar AI Traffic State, which has the following values: char states[28][32] = { "STATE_WAIT_FOR_ENGINE_START", // 0 "STATE_SLEEP", // 1 "STATE_FILE_FLIGHT_PLAN", // 2 "STATE_IFR_CLEARANCE", // 3 "STATE_PUSH_BACK_BEGIN", // 4 "STATE_PUSH_BACK_CONTINUE", // 5 "STATE_ENGINE_START", // 6 "STATE_PRE_TAXI_FOR_TAKEOFF", // 7 "STATE_TAXI_HOLDSHORT", // 8 "STATE_TAXI_ONTO_RUNWAY", // 9 "STATE_TAKEOFF", // 10 "T&G depart", // 11 "STATE_ENROUTE_AS_FILED", // 12 "STATE_TRAFFIC_PATTERN", // 13 "STATE_LANDING", // 14 "STATE_LANDING_ROLLOUT", // 15 "STATE_GO_AROUND", // 16 "STATE_TAXI_TO_PARKING", // 17 "STATE_ENGINE_SHUTDOWN", // 18 "STATE_SUPPORT_PREFLIGHT",// 19 --> 0 "STATE_SUPPORT_POSTFLIGHT",// 20 --> 18 "STATE_FLY_UNTIL_NEXT_EVENT", // 21 non ATC AI --> 12 "STATE_TAXI_FOR_TAKEOFF", // 22 non ATC AI --> 8 "STATE_TAXI_TO_REFUEL", // 23 non ATC AI --> 7 "STATE_WAIT_FOR_ENGINE_SHUTDOWN", // 24 non ATC AI --> 18 "STATE_WAIT_INIT_CONFIRM", // 25 --> 0 "STATE_SIMPLE_TAKEOFF", // 26 -> 10 "STATE_SIMPLE_FLIGHT", // 27 -> 12 }; Presumably you are supposed to know the state of the aircraft you are piloting....! This could be useful for external programs though - you could ask on the Asobo forums about this.... John

Rather than delete the existing assignments, just create a new (empty) profile for your devices/controllers if you are assigning in FSUIPC. Looks like MSFS2024 handles things differently though. Duplicate your existing profile, giving it a new name (e.g. FSUIPC). You should then be able to clear that profile, or just delete the things you want to assign in FSUIPC, John

What version of FSUIPC are you using? Which update? In FSUIPC7, there will be a Buttons & Switches... entry under the Assignments menu, and in earlier versions there will be a Buttons & Switches tab in the FSUIPC window. If you do not see this, then you are using an unregistered version. Maybe you installed into a different folder when you updated and therefore are now using an unregistered version? Anyway, check your registration. John

Before defining a preset, check that setting these actually works, using the Add-ons->WASM->Execute Calc. code menu item. To turn on, try: 5 (>L:VC_Parking_Brake_LIGHT_VAL) 10 (>L:VC_Parking_Brake_SW_VAL) and off: 0 (>L:VC_Parking_Brake_LIGHT_VAL) 0 (>L:VC_Parking_Brake_SW_VAL) If that works, you can then define your own presets (using the myEvents.txt file) and then assign to those presets.

No problem - I have deleted your other post (but I would have moved it for you if you had not posted again). Not sure what you mean by "Throttle 2 is at the top"...? But your throttle assignments look very strange: You have Throttle2 assigned to both the X and Y axis on one Saitek Pro Flight Quadrant (as well as on your BU0836 Interface device), and Throttle1 assigned to axis Y and Z on the other Saitek Pro Flight Quadrant. I would remove all them and assign again. Do you want to assign both throttles on one device, or each throttle on a separate device? Once you have assigned and it is working, check and make a backup of your ini. Then the next time, if the set-up has changed again, show me that ini as well as the backup.

WideServer should start a few seconds after everything has loaded and started. Can you check your FSUIPC6.ini file to make sure that it is enabled there, - here's mine: And your FSUIPC6.log file should show WideServer starting: If that is not the case, please attach both files and I will take a look. John

I will respond to your DM on the license issue. Yes - any assignments in FSX will apply to all aircraft. FSUIPC uses a concept called profiles to handle different assignments for different aircraft, and these are loaded automatically based upon the aircraft name. Please see the FSUIPC4 User guide, section User profiles for all control settings on page 23. I will DM you on the license issues (probably tomorrow). John

Yes, this shouldn't be an issue. Note that you will need the 32-bit WideClient program from WideFS6 though (but a WideFS6 license is not needed), and not the 64-bit one included with WideFS7. You will need a license for WideFS7 though to validate the WideServer component in FSUIPC7. If your PC is 32b, then you can only run your 32b programs (including WideFS6) on that machine. You should be able to run both 32b and 64b on the 64b machine, which is presumably where the FS and FSUIPC7 are running. John

Pleases the provided documentation - the Installing and Registering FSUIPC7.pdf, , section Invalid Key Problems. All issues with registration are due to: - not entering the correct details, or - not having the required VC++ redistributables installed, or - being blocked by anti-virus software (and its usually the VC++ redistributables). Please also refer to the documentation before posting for support, or check existing support requests. There are many, many reports of this exact same issue... John

@Andre92 Any update on this? Are you still experiencing this memory issue?

For all auto-start issues, please see I have moved this topic to the FSUIPC7 / MSFS sub-forum. Please use this sub-forum for all issues with FSUIPC7. John

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