John Dowson

This is a known problem with the throttle axis (and maybe prop axis as well) and seems to apply to all aircraft. There are other FSUIPC support requests on this issue and I have reported to Asobo but have not received a response as of yet.

It can do, but also note that updating an offset can also result in a control being sent (Ok-SimE) rather than the simvar being directly updated (Ok-SimC). But really, as an end user, you don't need to know how its implemented. Just use the controls, but if you cannot find a suitable control then try the offsets. It is preferable to use a control/event if available. Yes, it would be nice but not that straightforward. For example, a control may work with one aircraft but not with another. And if a control doesn't work, there is not much we can do about it in FSUIPC - it needs to be reported and fixed in MSFS/by Asobo. Why would you need to send both? You could overload your control to send both (by editing the ini), but then you should add an offset condition (using 0x0609) to only send the required control depending upon the aircraft type. You can repeat each control or not for each of the assignments, depending upon what works. Alternatively, you can use profiles to send the correct control for that aircraft type. It depends on the script. If its using an event, it will run all the time (or until killed), waiting for the event and then calling the appropriate function when received. Some scripts may also run in an infinite loop, and others may simply run and terminate. Note that if they run and terminate, the next time they are called they will be recompiled and ran in a new thread, which adds quite a bit of overhead. Using event based scripts is more efficient. So, its a lot more efficient to have a lua script running (usually from the [Auto] section of the in) and waiting for a button or key press event, rather than assigning the button or key press event to activate the lua.

This seems to be a common misunderstanding. The offset status documents is for the read/write functionality offered by FSUIPC's offsets. The data in the offsets table is populated (mainly) from simulator variables (aka simvars), not controls or events. Where an offset is related to a simvar, this is shown in the offset status document in the third column (column G). Offsets (or simulator variables) can sometimes be updated directly on user request, and others are updated automatically by the model or on sim events (or controls). The read/write status of each offset is also given in the offset status document, together with its previous status in other FSUIPC versions (where it also indicates if the variable is updated by an event 'Ok-SimE' or by directly updating the simvar 'Ok-SimC'). Currently I have not provided a list of the available controls, which comprises of those provided by the SDK together with other controls added by FSUIPC. For the former list, you can use the 2016 list of FSX controls provided in previous versions (and attached to this comment). The FSUIPC added controls are defined in the Advanced User manual, section Additional “FS” Controls added by FSUIP.The 2016 List of FSX and P3D Controls.pdf You could try with Magneto Set, with a parameter of 1 on your button/key press, and a value of 0 on release. But I think that may also time out after a second or two. You could also try with repeat on. However, I think that this is probably how the starters are implemented, with it switching back from start automatically after a short period (or the engine is started).

Btw, is the CTD in MSFS? As FSUIPC7 is a separate process/exe, it shouldn't crash the sim. However, it has been reported that this can sometimes happen when loading a flight with FSUIPC7 (due to known issues with the SimConnect load/save functions) so this should be avoided.

To start with, could you attach your FSUIPC7.log (from after you have experienced the CTD) and also your FSUIPC7.ini file please, both files are located in your FSUIPC7 installation folder. Can you also check the windows event viewer, and see if there is a crash log available there. If so, please paste its contents as well.

@ankh21 Could you try the attached FSUIPC7 build. In this build, I have added a new Control 'Throttle Reverse Thrust Toggle', and a corresponding read/write offset for this at 0x0B4A (1 Byte). To use this new 'throttle reverser' function, you need to assign your throttle axis in FSUIPC to 'Send direct to FSUIPC calibration' and to the Throttle1/2/3/4 controls. Then calibrate with no reverse zone. If you then assign a button/switch/key to this new toggle control (or to toggle offset 0x0B4A), toggling this control will switch the axis between 0-full forward thrust and 0-full reverse thrust, but only when the aircraft is on the ground. FSUIPC7.exe

But your ini shows that you have no axes assignments in FSUIPC:

@katoema Sorry, but I don't understand. Do you have an issue? If so, what is it? I thought you were posting to help with the reverse throttle axis question....

? This was related to registering your WideFS license with FSUIPC7.

Have you tried using the IgnoreThese ini parameter? From the Advanced User Manual:

Btw, FSUIPC needs to run on the same machine as the flight simulator. If you are running client software on a pi to talk to FSUIPC, you would need to install WideClient on the pi to achieve this. And for WideClient to run on the pi, it would need to be running Windows 7 or later.

You can try it. The offset facilities are available in the free/unregistered version (although there is currently a free time-limited full license provided with FSUIPC7-Beta). As well as the offset status document mentioned by Thomas (latest version is 0.7 and is included in the downloadable zip), you can take a look at the documentation for FSUIPC5 or 6, and maybe also the SDK. Documentation here: FSUIPC6_Documentation, SDK here: FSUIPC SDK.

Look in the zip. As well as the ReadThis.txt, there is a test file provided called UIPCHello.c. No vs project provided, just create an empty one and add/configure the FSUIPC_User.h and . lib files and add the UIPCHello.c and .rc files.

@jaybird1nyc Please try the following build where I have corrected the positioning so it doesn't position off screen: FSUIPC7.exe

Btw, what is the position of the FSUIPC main window when you try to open the assignment dialog boxes - is it near the bottom of the screen? If so, try with the main window towards the top of your screen. Thanks, John

It is included in the SDK: FSUIPC SDK

You can use the UIPC_SDK_C library (included in the FSUIPC SDK), or the 64bit version. There is also a version for the MFC framework.

@jaybird1nyc Could you try the attached build please. Run it (doesn't matter if FS sim is running or not). and then open and close the axes assignment dialog (from main window, not directly from the tray icon). Then try to open the button & switches assignments dialog, again from the main window. You will then have to forcibly close FSUIPC7, and send me the FSUIPC7.log file. Thanks. FSUIPC7.exe

It could be that the windows are being "displayed" but some where outside your screen coordinates. As its modal, it will block the main FSUIPC window until its closed. Not sure what would cause this though. And it should also be the same with the Axes assignments dialog if that was the case. Anyway, I'll take a look. I'll post you a version to try with extra logging. No need of the ini at the moment. Yes, it loads, but I don't think it does much (if anything) until the sim is connected and the ready-to-fly flag is set.

It may also be due to a bad driver as it could be hanging when scanning your devices (although it also does this on start-up). You could try downloading and running the HidScanner utility (from Download Links -> Useful additional programs) to see if that reports anything. Also check your windows devices to make sure the drivers registered there look ok.

No, it doesn't show anything. The log is also very small - no need to zip it! Every time? And you say also on previous versions? Did you try accessing those dialogs from the system tray icon (right click and select appropriate option)? I'm a bit flummoxed by this. All that selecting an option does is show a dialog box. I'll look to see if there is any logging I can add if this persists. For now, maybe you could try without loading the PFCcom64.dll to see if that makes a difference - just temporarily rename it. Maybe also show me your FSUIPC7.ini - and try (temporarily) renaming that (a new one will be generated) to see if its caused by some strange content in that file.

Then FSUIPC6 is not installed into your modules folder, With FSUIPC6, you must select the installation folder when you install. Looking at your log file, you installed FSUIPC6 in this location: C:\Users\Andre\Documents\Prepar3D v4 Add-ons\FSUIPC6 You should really choose a different location. That is the default installation folder for a clean install, and is where the add-on.xml file is (always) located. It is better to choose a different folder for the actual installation directory. Your ini file is confusing. Could it be that your joystick ids have changed? These are your devices: 0=Joystick - HOTAS Warthog 1=Mad Catz Pro Flight Rudder Pedals 2=Throttle - HOTAS Warthog You seem to have a throttle axis assigned to your joystick in various places: 2=0Z,256,F,65765,0,0,0 -{ TO SIM: AXIS_THROTTLE_SET }- 2=0Z,256,D,4,0,0,0 -{ DIRECT: Throttle }- 2=0Z,256,D,4,0,0,0 -{ DIRECT: Throttle }- And elsewhere also have ailerons, elevator, propeller and mixture assigned to your throttle: 8=2X,256,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- 9=2Y,256,F,65762,0,0,0 -{ TO SIM: AXIS_ELEVATOR_SET }- 11=2U,256,F,66291,0,0,0 -{ TO SIM: AXIS_PROPELLER_SET }- 12=2V,256,F,66292,0,0,0 -{ TO SIM: AXIS_MIXTURE_SET }- This I don't understand. You have plenty of assignments, although maybe to the wrong devices.... The first thing you should do is activate the 'JoyLetters" facility. See the user guide for details, but to activate just set this in the [JoyNames] section of your ini file and then run P3D: AutoAssignLetters=Yes This will assign letters yo to your devices which won't change, even if the joystick Id changes, preventing problems with assignments when this happens. You then need to review your assignments. I cannot tell which button you have on which device, but you should know this.If you review your ini after the above change, you can switch the device the assignment is made against by changing to the appropriate letter. If that proves too difficult, it may be easier to delete your current assignments and start again. As an example, looking at your general button assignments, you have this: Looking at the first assignment: 1=P2,19,C65603,0 -{FLAPS_DOWN}- This is button 19 on your device 2, which is your throttle. Once you have assigned letters, this will change to something like: 1=PC,19,C65603,0 -{FLAPS_DOWN}- where your joystick id 2 is mapped to the letter C (although the actual letter may be different). If you know that this was assigned on your joystick (which has joystick id 0), then you need to find the letter assigned to the joystick (probably 'A'), so to switch this assignment back to your joystick you would change to: 1=PA,19,C65603,0 -{FLAPS_DOWN}- But really, I think you would be better of starting again. You don't have that many assignments, and they do look rather confusing. For example, you have your ailerons assigned to two different axis on your joystick (in general axes assignments): 0=0X,256,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- 3=0R,256,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- and you have duplicate button assignments but to different devices: To your HOTAS throttle (general buttons): 1=P2,19,C65603,0 -{FLAPS_DOWN}- 2=P2,16,C66079,0 -{GEAR_UP}- 3=P2,18,C65595,0 -{FLAPS_UP}- 4=P2,17,C66080,0 -{GEAR_DOWN}- 5=P2,4,C65615,0 -{ELEV_TRIM_UP}- 6=P2,5,C65607,0 -{ELEV_TRIM_DN}- 7=P2,7,C66277,0 -{AILERON_TRIM_RIGHT}- 8=P2,6,C66276,0 -{AILERON_TRIM_LEFT}- and to your HOTAS joystick:10=P0,12,C65759,0 -{FLAPS_DECR}- 11=R0,15,C65615,0 -{ELEV_TRIM_UP}- : assigned above 12=R0,17,C65607,0 -{ELEV_TRIM_DN}- : assigned above 13=P0,16,C66277,0 -{AILERON_TRIM_RIGHT}- : assigned above 14=P0,11,C66080,0 -{GEAR_DOWN}- 15=P0,10,C66079,0 -{GEAR_UP}- : assigned above 16=P0,5,C65752,0 -{PARKING_BRAKES}- 17=P0,18,C66276,0 -{AILERON_TRIM_LEFT}- : assigned above 18=P0,6,C65861,0 -{AUTO_THROTTLE_TO_GA}- 19=R0,29,C65602,0 -{THROTTLE_DECR}- 20=U0,29,C65604,0 -{THROTTLE_CUT}- Another example, in your 'beach' profile you have Aileron, Elevator and Throttle assigned both to your joystick and throttle: 0=0X,256,D,1,0,0,0 -{ DIRECT: Aileron }- 1=0Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- 2=0Z,256,D,4,0,0,0 -{ DIRECT: Throttle }- 3=0U,256,F,66291,0,0,0 -{ TO SIM: AXIS_PROPELLER_SET }- 4=0V,256,F,66292,0,0,0 -{ TO SIM: AXIS_MIXTURE_SET }- ... 8=2X,256,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- 9=2Y,256,F,65762,0,0,0 -{ TO SIM: AXIS_ELEVATOR_SET }- 10=2Z,256,F,65765,0,0,0 -{ TO SIM: AXIS_THROTTLE_SET }- 11=2U,256,F,66291,0,0,0 -{ TO SIM: AXIS_PROPELLER_SET }- 12=2V,256,F,66292,0,0,0 -{ TO SIM: AXIS_MIXTURE_SET }- All rather confusing!

Thats not up to us. We use what is provided by the SDK. Currently they only provide 2 byte BCD format (4 digits), which is enough for 25KHz spacing, Its the 4byte 32 bit integers (in Hertz) that are currently not available, which is the issue. This is a know issue and has been reported to Asobo - please see The increment value depends on the frequency and frequency spacing. John

I don't know what those files are, but they are certainly not the FSUIPC6.log and FSUIPC6.ini files requested. If you go the the logging tab of FSUIPC6, you will see a button to open the installation folder location. Use that, and send us the FSUIPC6.ini andFSUIPC6.log files from that location please. The files you sent are binary files, and look to be (binary) shell link files. Why do you have these, and what for?

Ok, thanks. But the issue of the default key bindings in MSFS still arises. As you have to have numlock off for MSFS to send the numlock-on keys via simconnect, when you do this, the MSFS defaults for those keys will be actioned on before it is received by FSUIPC7, which may then also act on this if there is an available assignment. So, to work as expected, you will still need to delete the defaults assigned to the non num-locked numpad keys in MSFS. We need to wait for this to be fixed in MSFS really to be able to use both the MSFS non-numlocked assignments and also any numlocked assignments in FSUIPC.