John Dowson

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.

Maybe @Thomas Richter could comment on this I'm reluctant to implement any workaround for this that I don't fully understand, and could maybe adversely affect other AP implementations,. As a (maybe) temporary workaround, you could overload your button functions so that they always send (although only actually needed on the first press - maybe you could test for this via an offset condition) an AP SET control before writing to offset 0x07F2.

@ark1320 Please try the attached build. In this version, you can add the following ini parameter to the [General] section of your FSUIPC7.ini: UseAlternativeNumpadKeyMapping=Yes Once this is added, FSUIPC7 will receive the numpad keys (but only with numlock off due to MSFS bug) via SimConnect, but then send them to itself as the un-numlocked keypad keys. So, as discussed, using this you would assign to the non-numlocked numpad keys, and when using MSFS you need numlockk off for FSUIPC to react to these keys. They will also work when FSUIPC7 has the focus (with numlock off). FSUIPC7.exe

Yes Sorry, but this doesn't make sense. Custom controls are distinct, and are additional controls added by add-on aircraft. You should use the event/control name in the dropdown. You can use the offsets, but then you would use the various (depending upon offset size) offset set/toggle controls. If you have a choice between the two, use the control. Writing to an offset to trigger a control just adds another (unneeded) step. Only use the offset controls if no standard control is provided (e.g. for controlling pushback at offset 0x31F4), or for updating offsets for other uses.

Discussed this with @Thomas Richter : So it seems that this is just due to the way the different AP systems work.

Btw, if you are using slopes to try to control the sensitivity for a particular aircraft, its best to make this 'profile specific'. Currently your calibration is only general and so will apply to all aircraft.

By the way, you should activate the "JoyLetters" facility. You can do this by setting AutoAssignLetters to Yes in the [JoyNames] section of your ini. this will prevent you loosing assignments if your joystick ids change. It looks like this has already happened once, as you have entries assigned to device '3' which doesn't exist - you can remove these entries (highlighted in bold below):

No. The read offsets are generally populated from sim variables, not events. The write offsets can use either sim variables or events. i agree that it would be useful to have the events listed against the offset(s) where its being used. I may get around to this at some point but it would take some time which I just don't have at the moment. The drop-down list contains all (or most) of the known sim events, plus additional ones added by FSUIPC and some older ones not mentioned in the MSFS documentation. Note also that the list was built from the MSFS list of the sim events under SimConnect and not under 'Variable Lists', which seems to contain more not avaiable via SimConnect. There is currently no such list - I will provide one later, when the product is released. For the time being you can use the 2016 list which should be 95% applicable - I've attached it below. John The 2016 List of FSX and P3D Controls.pdf

This is also how it works in the A320Neo, but its different in the Boeings. I've already queried this with Asobo (2 weeks ago, as of yet no reply): I think@guenseli may be right and this is expected behavior, although I'm not sure.

There are also a couple of other things you can try. If you look in the FSUIPC User Guide, there is a section called 'Offset Increment/Decrement Controls' (around p27) which actually uses elevator trim as an example. There is also an example lua script provided (in the FSUIPC example lua plugins) which convert the rotary buttons triggered into virtual buttons, toggling one for a slow movement and another for a fast movement. Using this, combined with the offset increment/decrement controls, you could set the slow virtual button to increment/decrement by 64 (say), and the fast by 256 - just vary the numbers until you get the fast/slow speed that suits you.

Just noticed this....strange. Not sure how this happened - you should remove this line (if its still there). Did this improve things?

If you had previously registered then there is no need to re-register - you should have skipped registration (clicked 'not now') and your existing key file would have been used. Did you enter all three details - name, email and your WideFS key?

No, doesn't look right as each button number is different - I was expecting to see both a press and a release on one button assigned to trim dwn, and the same for trim up on another button. However, lookin at the log of button presses/releases, they don't make much sense: It doesn't surprise me that you had problems stopping the movement when you had repeat on, as you would have to position the trim so that all the 'buttons' on it had triggered a 'release' without any outstanding presses. Looking at the log, thats a difficult position to find! Assuming 7 is the topmost button, and 4 the lowest, you could add the following (in bold): 21=P165,5,C65607,0 -{ELEV_TRIM_DN}-22=U165,4,C65607,0 -{ELEV_TRIM_DN}-23=P165,6,C65615,0 -{ELEV_TRIM_UP}-24=U165,7,C65615,0 -{ELEV_TRIM_UP}- 25=P165,7,C65615,0 -{ELEV_TRIM_UP}- 26=P165,4,C65607,0 -{ELEV_TRIM_DN}- This just sends a second control when the buttons are pressed, so should speed things up a bit but I wouldn't expect too much. You can try varying the button numbers (e.g. change one or both of the 7 and 4 to 5 and/or 6), and change the press P to a release U. Ideally you could add these via the UI, as I suggested. Other than that, you would have to try lua.

Do you mean that when you move the axis it is not registering the movement in the axes assignment panel? Does windows see the axis? If when moving the axis FSUIPC is picking up another axis first, you can click the 'ignore' button which will temporarily ignore that axis until you close the dialog box. I have had some reports of axis temporarily not being seen by FSUIPC. For other users, this seem to resolve itself with a restart (or maybe a reboot), so maybe try that. If your problem persists, I'll need to see your .ini, .log and JoyScan.csv files (all located in the same folder as FSUIPC7). You could also try downloading nd running the HidScanner program (available from Download links -> Useful Additional Programs). By the way, you seem to be using this thread for all your unrelated problems. This is not how the forum works and does not help other users who may have the same issues. For future reference, could you please - have one topic or thread per issue - give the thread a relevant title - 'problem and discovery FSUIPC' doesn't say anything about what your problem(s) is/are - always check the provided documentation and previously posted questions to see if your issue (and a solution) or similar has been posted before - provide any relevant files Also, please see this sticky post in the main support forum Thanks.

These are also available in FSUIPC7, and should be listed in the controls drop-down menus. Hmm. Very strange and worrying. Same or different aircraft? It seems that the various aircraft implement things differently, so what works in one may not necessarily work in another. Please do.

Should be pretty straightforward. I may add a new ini option to enable this, so you have a choice and can disable once Asobo fix the issue. I'll do this tomorrow now - had enough for today!

Ah, ok - difficult tot tell in those images, especially with my eyesight (and as I lost my glasses yeterday, falling into a river while walking the dogs!). Yes, one should be activated with a small movement and the other with a large movement. For the small movement button, you should assign just to the press, and for the larger movement to the press and release. Well, that was what I was trying to get you to try, to see if that helps. Ok. Would be useful to know if/when its sending button releases. You can also look at the log when you have repeat enabled. Really, you just need to experiment to see what works for you. If you cannot get it working reasonably with direct assignments, you will have to look into using lua scripts to control instead.

And why are you auto-starting the same script twice?

First, can you please update to the latest version of FSUIPC5, v5.157. You are still on 5.124 - I can only support the latest version of each product. Also, you have some errors in your lua scripts: 138625 *** LUA Error: ...ockheed Martin\Prepar3D v4\Modules\NGXMCP_PP_202.lua:101: attempt to perform arithmetic on a nil value Your ini file also has no axes assignments. Where are you assigning - in the sim or in your Mad Catz driver? But your throttles don't have a reverse handle, do they? Do you mean when entering the 'reverse range' of your throttle? You are also using aa PMDG aircraft: 166516 Aircraft="PMDG 747-400 KLM Royal Dutch Airlines (PH-BFN | 2017) For PMDG aircraft, you should not calibrate in FSUIPC really, due to SimConnect priority levels. It can result in multiple values being received via SimConnect. I've no idea why an update to windows 2004 should change anything. I've just updated but haven't had time to test/check anything yet.

Also, you cannot see the axis under calibration unless it is also assigned in the assignments tab. If not assigned, you can still see the movements in the axis tab, but you cannot calibrate or een movements in the calibration tab unless it is assigned in FSUIPC. Also, be careful that it is not also assigned and calibrated in the PFC driver. Depending upon which one you are using, the driver may be sending the axis values direct to the sim and bypassing FSUIPC. I believe there is an option in the driver to changes this, so you can assign and calibrate in FSUIPC. But, you cannot assign on the driver and calibrate in FSUIPC. There are many threads on PFC devices at the moment. Maybe review them before posting again.

Why are you posting in a thread for TransmitClientEvent failures when clearly this has nothing to do with your issue? It is difficult for me to investigate issues when people cross post. Please make sure that you are experiencing the issue identified in the thread, otherwise find another appropriate thread, if available, and if not create a new thread. You are also using both the PFCcom and PFChid drivers. Do you need both? And what 'axis' are you referring to? Is it configured and used by FSUIPC, or is it configured via one of the PFC drivers? Your PFChid64.log also shows various errors, and is using some sort of macro file (PFC.mcro) which I know nothing about. I'm sorry, but not having any PFC devices or knowing how those drivers work in conjunction with FSUIPC, I really cannot advise on this. I suggest you start a new topic for this with an appropriate title (including the PFC device/driver you are having issues with) , and maybe someone else who uses such PFC devices may be able to help.

Your images show one button - Joystick#165 button#5 - assigned in the first image to Elevator trim down on press and release, and in the second image to Elevator trim up on press and release. I don't understand how this can work, sorry. You said that FSUIPC recognised to buttons for up, and two for down. As I said, you should assign the first button (in each direction) to only send the control on the press, and the second (furthest) button to send on press and release. I really cannot advise any further as I still have no idea what codes your trim wheel buttons are sending.