John Dowson

Your ini shows you have 3 controllers: The U is the axis, but which controller was it from? If that keeps registering before you can move the axis you re trying to assign, this usually implies that the axis is jittering, i.e. sending values when not being moved. Click the Ignore Axis button to ignore this for the current assignment session. After you have done this, your other axes should (hopefully) register with movement. I see you are also not yet using the JoyLetters facility. You should really be using this - just change the AutoAssignLetters ini parameter value from No to Yes (or assign your own letters - see the documentation if you want to do it this way). Ok, let me know. Cheers, John

Sorry - you are using Windows 11. Please set that option. John

As you are using profiles in separate files, I also need to see your FSUIPC6.ini for your DA40 profile. Can you also check that you do not have your toe brakes assigned in MSFS (are you using an empty MSFS profile for your rudder?) or in SPAD.next. I can see the left brake movement in the log you attached, but not the right brake. Did you activate the right brake? If so, it seems that it is not assigned. The left brake logging shows some movement, and it looks like this axis needs reversing, which you need to do in the calibration tab (that you cannot see, for some reason...). I can also see in your log files that your USB devices were scanned again soon after the initial scan: Not sure what provoked this scan - did you open the FSUIPC UI? I see that you have set the DirectAxesToCalibs ini option in your [General] section. Do you need this set? And if so (if your devices are writing to the offsets for calibration), then you will need this set to All for toe brake calibration: So, try with removing that ini parameter, if not needed, or set to All. John

The timestamp is the first number of the log line. What was the last line logged when the error you see was displayed? Knowing the offset that is giving this problem may help the developer of the AflAgent client program determine what the issue is - did you contact the developer of this program? The last offset read (from the log you posted) indicates thet your 3rd party client was trying to read offset 6FFF. This offset is in an area (6F00-6FFF) that is reserved for XPUIPC use (i.e. for X-Plane), to avoid clashes, and is not actually used in FSUIPC7. Are you sure the client you are using is working with FSUIPC, and is not XUIPC specific? Also, did you exit MSFS/FSUIPC, or did FSUIPC close as it thinks that MSFS has closed? Your log indicates that FSUIPC7 exited very soon after the read request to that XUIPC offset: Are you using Windows 11? If so, please also add the following to the [General] section of your FSUIPC7.ini file: DisableMSFSMonitor=Enum John

What was the previous version that you were using? There were very few changes between this and the previous version, and nothing in the area in which you have issues. Do you have the same issue in P3Dv4.x and P3Dv5.x (your install log indicates that you have both)? The FSUIPC6.ini file you posted is also empty - no assignments whatsoever. I can see that you have also installed FSUIPC6 under your Documents folder. There seem to be issues these days installing under a Windows protected folder, such as Documents or Program Files. Can you please install in a different location (e.g. C:\FSUIPC6) and try again. First manually run the FSUIPC6 uninstaller, either from your installation folder or using the windows app management panel. Then install into a different location, moving any files you need to keep (such as your .key and .ini) to the new location. Then try again and report back. Thanks, John

Not sure what you mean by 'interface' in this context. What did you use in FSX? Is the 'interface' not the same? John

Hi Bruno, Not sure. You can try: 1. Activating logging for events and open the logging console. Change the ranges in the UI and see what events are logged. If so, try using them. 2. If that doesn't work, try listing lvars (using the provided control or the provided log lvars.lua script) to see if any look applicable. Again, try changing the range in the UI to see if any applicable-looking lvars change when you change the range. If so, you can try assigning to those lvars (using a macro or lua script). 3. If there are no events/controls or lvars, you can try with mouse macros. John

I always recommend that you try before you buy - you should initially have tried with the trial license, available at the top of this forum. Depends. Some people find MobiFlight easier to use. You can also use the MobiFlight WASM events via FSUIPC using event files. They are included in your EventFiles sub-folder. Instructions on how to use can be found in other posts on this forum - I will create a README.txt (when I get time!) and include this information at some point. Otherwise, you can use the MobiFlight hubhop preset list (see https://hubhop.mobiflight.com/#/list) to see what the preset is doing, and then use that to determine what assignments to use in FSUIPC. For the FLC, the MobiFlight preset for this is WT_CJ4_AP_FLC_PRESSED, which, looking at that preset's implementation, uses the hvar H:WT_CJ4_AP_FLC_PRESSED, so to use/assign to this you would first need to add that hvar to a hvar file for the CJ4 (to make it known to FSUIPC), and then add it to a macro and assign to that macro. See the Advanced User guide for details. There is also the preset WT_CJ4_FLC_ON, using the lvar L:WT_CJ4_FLC_ON which can be used to determine the state of the FLC (read-only). To engage the speed, the MF preset WT_CJ4_AP_SPEED_PRESSED uses the (read/write) lvar L:XMLVAR_AirSpeedIsInMach to switch between IAS/mach. You will see the control that you assigned to that button. To determine what is happening, you need to activate the AP button in the UI to see what is logged, and try to mimic that in your assignments. Unfortunately, this only helps if the aircraft is using standard MSFS events (i.e. those known to SimConnect/FSUIPC) and doesn't help if the functionality is operated using lvars and/or hvars (and maybe events). But that MF preset list is a great source of information on how to control such functionality. You are in the correct sub-forum, the FSUIPC7/MSFS sub-forum. Not sure what you want to delete, but maybe because your posts were not approved yet as you are a new forum member. Should be ok now. John

Hi Andreas, For the time being, please try the attached version. This is identical to the current released version, but I have removed the requests for the FUELSYSTEM PUMP SWITCH / ACTIVE simvars with indices 7 and greater. I'll make this applicable on a new ini file parameter in the next version. I'll maybe allow this to be profile specific and also specify the max index number to request (or the number of pumps available). John FSUIPC7.exe

That sounds like a digital on/off axis, which is (usually) a registery issue. There is an FSUIPC FAQ entry on how to fix this - it was written for Saitek devices but also applies to other controllers - see Hmm, that does sound strange.... Ok - good luck and please do let us know how you get on, or if you need any asistance once you have calibrated with the TCA software - you need to do this first before assigning/calibrating in MSFS or FUIPC. Cheers, John

I am not sure what you mean here... Please do not confuse MSFS profiles (controller specific) with FSUIPC profiles (aircraft specific). Tjey are completely separate. We recommend creating an empty profile in MSFS for your controller if assigning in FSUIPC7. However, there is no problem mixing and matching assignments between MSFS and FSUIPC7, but make sure that you do not have duplicate assignments (i.e. assigning a button or axis both in MSFS and FSUIPC7) as this will cause issues. And, if mixing and matching assignments, please remember that the MSFS profiles are device specific, and the FSUIPC7 ones aircraft specific. Profiles can generally be used for groups of aircraft, as aircraft types tend to use the same controls (or at least used to!). So you could have a single prop profile (maybe default), maybe a turbo prop profile, a jet profile, a 2/4 engine prop profile, etc. More complicated aircraft, such as the airliners, tend to require their own profile as the controls/procedures can differ significantly. And the problem with auto-detecting is that reverse thrust works very differently in different aircraft, so you really need to configure this for each type of aircraft, or even specifically for a given aircraft. Not heard of VKB before - looks interesting. However, probably is a case of 'grass is always greener', as you say. I would have though that there would be more information and help available for the TCA quadrant, as this has been around for a while now and is a relatively common piece of kit. Good luck! Cheers, John P.S. Another problem, especially with reverse thrust, is that Asobo or FBW (or both) seem to keep changing how reverse thrust works in various aurcraft...I tend to get support requests in reverse thrust issues after each update, e,g, see

Ok - thanks but no need.

Yes, they should be https for the download links in this forum - some were, some weren't - I will update them. However, the www.fsuipc.com server is still not set-up for https. Something I've been meaning to do for a couple of years now but not gotten around to...I'll try and remember to do this sometime soon when I get time. Thanks, John

Ok, thanks for letting us know. I have had other reports with Avast causing issues, but previously when downloading FSUIPC7. Strange it does this now when FSUIPC is running. I'll see if I can raise a support issue with them. Could you get around this by allowing an exception for FSUIPC7 in Avast? John

Yes, there seems to be a problem with the latest build of 4976 - please use the older 4976 build posted above while I investigate this. John

This looks like an old issue that hasn't been fixed, but maybe there is a different may to activate reverse thrust now in the A320 (and A320nei). I'm pretty busy at the moment but will take another look at this later this week and report back. John

Great - and no problem. Happy Flying! Regards, John

I believe this still works in MSFS2020 for some aircraft, but not all, and not for complex add-ons that implement there own (electrical) systems. Setting this option will keep the MSFS simulator variable ELECTRICAL BATTERY VOLTAGE (held at offset 0x2834) either at the same level or will decrease at a lower rate (depending upon the value set). I haven't used this feature for a while but will check this in a few stock aircraft in MSFS2020, but I cannot check this in ProSim. Maybe @Pete Dowson can comment, as he also uses ProSim (but with P3D/FSUIPC6). John

Hi David, If it is greyed out is it also checked? If so, then the aircraft is already assigned to a profile. If not, then make sure you have MSFS running with an aircraft loaded and ready-to-fly. So you are assigning using MSFS and not FSUIPC? Sorry, but I cannot help you with that. If assigning in FSUIPC7, we recommend using an empty profile for your controllers in MSFS, at least initially, although you can mix your assignments between MSFS and FSUIPC7 if you need to. Setting up the TCA does seem quite problematic - there have already been various threads on setting up the TCA with various aircraft. The configuration will be dependent on the aircraft being used, so if setting up in FSUIPC make sure that you use profiles. And also make sure that you have calibrated the throttle first - see https://ts.thrustmaster.com/download/accessories/manuals/TCA_Quadrant/TCA_Quadrant-Throttle_Calibration.pdf Here are a few other posts on setting up the TCA which may (or may not!) be helpful: John

No, that was correct - sorry I misnamed it. Yes, worrying... I will check the changes made, and also I will see if I can reproduce here - I guess I have to register for a VATSIM account to do this, no? John

Hi Glyn, As I said, everything must be running at the same privilege level. If you are running MSFS with Admin rights, that will run FSUIPC7 (and FS2Crew) with Admin rights, so you need to run Pilot2ATC with Admin rights. To do this, go into the Compatibility Properties of the Pilot2ATC.exe and check the box 'run this program as an administrator'. John

Not sure, but I don't think so. The provided ones will be overwritten and so will lose any changes, but new ones added should be preserved (the uninstaller will attempt to delete the folder but this will fail if it still has files inside it). Although maybe better to add such files to the WASM persistent storage location instead. John

By doesn't work, you mean the LvarScanDelay ini parameter has no effect? The log file you attached seems to indicate that it was loaded correctly, and the Debug level logging was set: Are you saying that you don't see any lvars until after you Reload? If that is the case, are you sure you are not just trying to list the lvars before they have actually been loaded (i.e. longer than 45 seconds after the aircraft was loaded)? If you think you are having issues, can you also please activate Debug level logging in the WAPI (and also keep activated in the WASM) and send me both your FSUIPC7.log and FSUIPC_WASM.log files. John

Hi Ross, Yes, that helps enormously, thanks. I will take a look at this next week. Could you also please try the attached dll to see if the same problem exists in this version. This is also version 4.976, but is the original build before the VS toolsets were updated. Thanks, John FSUIPC.dll

Hi Andreas, Are you using the stock A32NX or the FBW mod? And by 'debug mode console', do you mean the MSFS dev mode one (and not the FSUIPC logging console)? I cannot see any such errors in the FSUIPC7.log file. Yes, these are for two new indexed variables that I have added to offsets: FUEL DUMP ACTIVE FUEL DUMP SWITCH requested for indexes 1-16 (as the 747 has 16 individual pumps). Requesting a variable that doesn't exist (or if the index is out of range) should result in a SimConnect error reported in the FSUIPC7.log file, which I don't see. And I don't know why you are continually seeing these messages. The simvars are only requested once, most probably on a 6Hz period (although I would need to check). Later: Ok, I can see those error messages, both in the stock A320 and the FBW A32NX, and also in some other aircraft (e.g. 787), but not all - seems to only affect aircraft that use the new fuel system variables. This only seems to affect the MSFS console window - no error messages are logged (or received) by FSUIPC7. Not sure what to do about this at the moment. It seems only to be an issue with these messages being logged in the console window and not much else. I'll report this to Asobo to see what they say. I am not sure why these variables are being continually logged either, as they are only requested once. I will report back if/when I hear anything from Asobo. I don't like making previous versions available, and only the latest released version is ever supported. I don't mind making the previous release available upon request, if there are issues with the newly released version (and while these issues are being investigated), but I won't be making previous releases permanently available. John