John Dowson

I don't understand why you keep messing around so much with your devices and creating such a mess. Looking at you registry, you have all these entries: and the log file is reporting duplicate ids: You need to do exactly the same as I suggested the last time this occurred - clean your registry and update the GUIDs to the new ones on your assigned JoyLetters, and remove the other entries. Sorry, but I just don't have time to look at this in any more detail at the moment (and I am on holiday from the 2nd - 7th April). I can help again sometime later next week, but I am just too busy to look at this in detail at the moment. Go over the last post and try and understand what you did to resolve it the last time. Report back after the 8th AApril if you require further assistance.

Ok, that probably changed with the SU1 update - that offset holds the version number (major*10 + minor) as received from the FS. I will update the documentation to reflect this. Thanks for reporting. John

Before buying, try the trial license in the first post in this forum. This also includes a trial license for WideFS7. It will expire after tomorrow, but I will update in a few days (and you will need to download and install again). Always better to try it first to make sure it suits your needs (as no refunds available!). Cheers, John

Ok, thanks for the update. That is strange though, especially as those controls are being sent so early.... I will look at the Sim Rate offset 0x0C1A when time permits, as this is still documented (and implemented) for FSX (same as in FSUIPC4) and will almost certainly have changed... Anyway, glad that is now solved! Regards, John

FSUIPC5 is for P3Dv4 only, not FS2020. Only FSUIPC7 works with MSFS2020. Do you mean offsets 0x9002 and 0x9006? Those offsets are not (and never have been) used by FSUIPC itself. Looking at the code, offset area 0x9000 - 0x93FF has been allocated to "Nico Kaan for Lekseecon(Level D 767, 757)". I have no idea who this is or what these offsets are supposed to do - they were allocated way before my time. All I can tell you is that they are not used at all by FSUIPC. John

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