John Dowson

Hi Zsolt, This is the issue. If MSFS doesn't recognise the input as keyboard unput, it won't be forwarded to 3rd party clients. Does MSFS maybe recognise it as another (assignable) device? You can also try to see if FSUIPC recognises your device as a HID type device without running the encoder_keys.exe software. If it is recognised directly (i.e. as a joystick type device), you may be able to assign the MCDU buttons directly to the custom controls. Otherwise you could try using lua. If you want to try this, first verify that the MCDU buttons can be recognised - you can do this using the HiDScanner software, available from here: John

I cannot help with this - you need to look at the FlightPM TQ manuals, or contact them for support for your hardware. I only support FSUIPC, not 3rd party hardware.... No idea. Many people use motorized throttles with FSUIPC, but as I don't have this device I cannot really advise. You may get more response on either the manufacturers forum or over on cockpitbuilders.com. John

Btw, Is FSUIPC4 installed and running ok? If not, I also need to see your installation log.

Can you please show me your FSUIPC .ini and .log files.

Opening FSUIPC6 will make the P3D window go black. Do you not see the FSUIPC6 main window? If not, it is possible that it is being displayed outside if your screen coordinates. If this is the case, delete the ini parameter OptionsDialogOffset from the [General] section of your FSUIPC6.ini file. Not sure what you mean by this...Alt +F4 is the P3D default hot key to exit P3D, which is why you see that pop-up. I think Alt + F is the default hot key to open FSUIPC^, but this is defined by the InvokeFSUIPCOptionsKey ini parameter. There are no issues or conflicts between FSUIPC6 and FSUIPC7. Yes, this will be the issue. Look at (and remove) the ini parameter OptionsDialogOffset and maybe also ConsoleWindow (which stores the windows coordinates of the FSUIPC console window). John

You keep saying this and I keep giving the same response: you will not see your bindings when you look at your log. But you do not see your bindings in the log, as I keep on saying. Your bindings (i.e. assignments) are stored in your FSUIPC7.ini file. You can see the affect of the bindings in the log, if and when you have the appropriate logging options set. Please understand the difference between your FSUIPC7.ini file, which holds all of your settings, and the FSUIPC7.log file, which is a log of the current/latest session. You can assign view controls in MSFS if you prefer. Alternatively, you can assign your POV to the keyboard assignments to control the view. Ok. If you have any issues, activate appropriate logging (which for axes assignments would be Axes control logging) and show me both your FSUIPC7.ini and FSUIPC7.log files, the latter showing you moving your assigned axis through its full range. John

This is true - FSUIPC7 does not detect key presses when it dies not have the focus. It can only detect key presses - when FSUIPC7 has the focus - by receiving the key press as an Input event via SimConnect The issue seems to be that MSFS is not detecting these "key presses" and so not forwarding them to interested 3rd party clients, such as FSUIPC7. Have you tried with an actual keyboard - you should see that it works when using a keyboard and MSFS (or FSUIPC7) has the focus. So this software does the encoding and then forwards to the current windows application that has the focus? Can MSFS see the input from this device as key strokes? If it can, it should forward them to FSUIPC7 via SimConnect. However, if MSFS does not see these as key strokes then they will not be forwarded to 3rd party apps.

Neither your device's GUIDs or Joy Ids should change when using a new hub, so you should be fine. If using JoyLetters and your Joy Ids change, that shouldn't be an issue as the joy letters facility is designed to cope with this. If your GUIDs change then you may need to manually edit your ini. You can do this yourself or post here and we can take a look if that happens. Best wishes for a the New Year. John

For FSUIPC6 and later, I am using the format major.minor.patch with the lower 2 digits of the version number being combined to be the patch number. So v6.1.7 is seen as 0x61070000, v6.2.1 would be 0x62010000m and v6.2.10 would be 0x62100000, etc.

I doubt it, but maybe check on windows 10 if possible. Looking at your assignments, many are using multiple modifiers, e,g, 112=123,15,32907,0 -{alt+lctl+lshift+F12: Press=:MobiFlight.A320_Neo_CDU_1_BTN_R }- I am wondering of this may be the issue... Could you please activate logging in FSUIPC for Buttons and Keypresses as well as for Events, and then generate another FSUIPC7.log file where you load your aircraft and then, when MSFS has the focus, press some of your assigned key combinations - try the following: 6 - should trigger a MobiFlight.A320_Neo_CDU_1_BTN_L3 event lshift+P - should trigger a MobiFlight.A320_Neo_CDU_1_BTN_L1 event alt+lctl+lshift+H - should also trigger a MobiFlight.A320_Neo_CDU_1_BTN_L1 event Then exit and show me the FSUIPC7.log file. Thanks, John

P3D and FSX have a tendency to assign your controllers automatically when they are detected as new controllers. This is why, if assigning in FSUIPC, we recommend to disable controllers completely in the FS (P3D / FSX / FSX-SE). John

Ok - so that is using overloaded assignments to custom controls with an offset condition on the position of the 3 wat switch, as I suggested.... Thanks for reporting back. John

The rotaries.lua script is used when only one button press is available in each direction. It looks at the timing between each press/pulse to determine if it is a 'fast' click/pulse or a slow click/pulse and converts each to an appropriate virtual button press, so that you can assign to both the fast and slow movement in each direction. If you already have a distinct pulse/button press for fast/slow in each direction, you can assign directly to those button presses rather than using the rotaries.lua. However, if using two-phase type rotary switches, where turning the spindle one way gives pulses on two lines phase shifted one way, and turning the spindle the other way gives the opposite phase relationship, then see the Advanced User guide (P23) for details on how to assign to such rotaries. John

I still think your best bet is to get a new license for your VirtualAvionics V3 software, as that seems to be what you need. They must have provided you with the initial license - why was this time-limited? Maybe you need to purchase a new license for this software? Sorry I can't be of more help, but it does look to be an issue for Virtual Avionics. Best wishes to you and your family for a Happy New Year as well. Regards, John

It is not a script. You decompiled the exe, which was originally a compiled C/C++ program. No idea why you would want to do this, or why you even need to know the original language of the executable. John

What does this mean? Are you saying your assignments work with other aircraft, but not for these add-ons? For the PMDG 737NFXu, have you looked into the custom controls that PMDG provide? Many of the standard controls do not work for this aircraft. The TFDI 717 may be the same. This is usually achieved by overloading your SEL switch assignments and adding an offset condition on the position of the 3 way switch. Ok, so that is easier then. You just need to assign the rotary to the correct control. If the standard controls don't work, try looking at the PMDG custom controls. John

So you did gave this working, and its just that a license has expired? What license is this? Can you not renew it? It is one of the example lua scripts we provide, located in the lua examples zip file in your FSUIPC Documents folder. No idea why you included that - it means nothing to me! FSUIPC provides a lua interpreter. Some example lua scripts are included but you really need to learn the lua language and write ort adapt scripts yourseld if going down the lua route. You could look at LINDA, which provide pre-made scripts for many controllers/aircraft. However, if I were you I would try and resolve that license issue first... John

But your bindings/assignments have nothing to do with your log - why do you expect to see them there? You can see the affect of your assignments on the log when you operate them, if you have the appropriate logging flags set.

If you are updating the ini file when FSUIPC is running, you can reload any changes using the reload buttons in the various assignment panels (buttons, keys, axes) depending on which section you have changed. Changes to the [General] section may need a restart. Flicker how? Check that you don't also have assignments in the FS - best to switch controllers off in the FS if assigning in FSUIPC. You can also try the 'Filter' checkbox in the calibration screens if it is a jittery axis. I see Pete has also just replied much in the same vein...

So the gear lever was recognised and assigned, but has no affect when you operate it? If this is the case, could you activate logging for Buttons and Key presses + Events, and produce a short log file where you take off and then retract your gears. Then exit, and show me your FSUIPC7.log and FSUIPC7.ini files. John

You should try the trial license for FSUIPC7 before purchasing, available here: I can also provide you with a trial license for WideFS7 if needed. John

Sorry, no idea what this means. What has your log got to do with your bingings/assignments? Why do you think your 'bindings had to be reset'? No. General assignments for buttons and keys apply to all aircraft, and are added-yo or replaced by profile specific bindings. If there is a profile specific axes section for the loaded aircraft, that will be used exclusively. If no such section is present, the general axis assignments are used. Please don't do this. If the log file is too large to upload, just zip it. Which ones are not working? Looking at your assignments, I see tyhat you have assigned to the PAN controls. These are known not to be working via SimConnect. To control views via FSUIPC, you need to assign your buttons/POV to the default key combinations used to control the cameras in MSFS. The same may apply to eyepoint controls. Sensitivity issues can usually be handled by appropriate calibration and the use of slopes, but this usually depends upon the axis and the aircraft. You could try switching from using 'Send to FS as normal axis' and use 'Send direct to FSUIPC Calibration' and then also calibrate in FSUIPC. Cheers, John

Can you not use the same solution (VAinterface software?) with MSFS2020/FSUIPC7? If not, why not? SPAD.next works well with FSUIPC, although I haven't used this now for several years. However, I think you need to talk , spad.next support to resolve issues if using spad.next. Otherwise, if your controllers are not recognised natively by fsuipc, you could try the lua interface. You could start by looking at the HidDemo.lua, to see if that recognises your controllers buttons/axis. John

Key presses made when MSFS has the focus should be picked-up by FSUIPC (via SimConnect) for action. However, not all key presses are supported. What keys are you using? Could you activate logging for Buttons and Key presses + Events, and produce a short log file where you load your aircraft and then press an assigned key (or key combination), both when MSFS has the focus and when FSUIPC has the focus, then exit and show me your FSUIPC7.log and FSUIPC7.ini files. John

No, this is not possible. There is no interface between FSUIPC7 and AS. This topic is now locked - I have nothing further to say on this issue until/unless AS release a version compatible with MSFS. And even then, it will require integration work and discussions with AS to get this working. John