John Dowson

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.

Ok, good - as you image showed you were selecting for a key assignment, and you need to set 'Select for FS control'. Doing what I said, don't you get faster movement for the second (i.e. when assigned on press and release) button? Did you try logging the press/release events of these buttons? Repeat should work, but as it is continually repeating it seems that the device isn't sending a button release code. This is why I asked you to activate logging to see what your buttons are emitting. It is difficult for me to advise when I don't have such a device and I cannot tell how its configured and what press/release codes it is emitting. Also, as its a GF device, do you have the additional GF software running? Does this not let you assign and configure the trim wheel? Or are you just using the GFdev64.64.dll? If you cannot get the movement you require via standard assignments, maybe you should look into using lua scripts. You can do something based upon the scripts in this post (although they are originally for Saitek trim wheels , but if using buttons to control trim, it shouldn't make a difference) - but you only want the button functions, and can remove the axes ones (and make sure that you update the joystick and button numbers used to match those of your device): You can also use that as a basis to write a script to control with 2 buttons for slow up/fast up & slow down/fast down.

Yes, but as noted above, no need for calling cmd.exe, calling start shell:AppsFolder\Microsoft.FlightSimulator_8wekyb3d8bbwe!App -FastLaunch is sufficient.

Btw, thanks for this pointer - very useful for me! Done.

Yes, a new profile will initially be empty - don't forget to save it/them. When you restart MSFS, it should default to the previous profiles assigned. One user did report that they needed to add at least one assignment to the profile for it to be enaled (by which I think they meant loaded on start-up), but I don't find this to be the case - maybe that was in an earlier version of MSFS.

Which saitek throttles are you using? (I ask as I didn't know that some models have a reverser) Could you attach your FSUIPC5.ini please and I'll take a look, as well as your FSUIPC5.log and FSUIPC5.JoyScan.csv files. That is strange.... Do you have controls enabled or disabled in PD3v4? If enabled, check the assignments. Otherwise, are you running any additional software for the throttles that could be interfering? That's rather worrying...I'm still on 1909 but was thinking of upgrading this afternoon.

Ah, ok. So one up button should be for fast trim down and one to slow trim down, and similarly for the down buttons gpr trim up. Can you check if/when the trim wheel "button" are sending release codes (by activating 'logging for 'Buttons & Switches'). You could try assigning the first up-button (on trim wheel), to "trim down" on press only. For the second up-button, assign to "trim down" on press and release. And similarly for the down buttons.

Thats interesting - and strange! The units for offset 0x07F2 are ft/min. What are the units you are using for the parameter of the AP VS SET command? I could automatically do this in FSUIPC7 maybe. Presumably it needs to be sent on each change of aircraft or new flight, no?

What do you mean by this? FSUIPC7 does not recognise an axis on one of your devices? Are you assigning to a switch or 'sticky' button? If it continues, then its not receiving a release event. You can check what events your buttons/switches are sending by logging 'Buttons & Switches'.

Are you sure its not in the system tray? Also try the default hot key - Alt-F. If its not in the tray and Alt-F doesn't show the UI, please attach your FSUIPC7.log file.

Yes, unfortunately. An alternative solution would be if I mapped the received numpad 0-9 keys to their num lock off equivalent. This would allow you to assign in FSUIPC7 with the num lock off, but then use those assignments (when MSFS has the focus) with numlock on. This would be a temporary fix that I would revert once the problem has been fixed by Asobo. Yes, of course. I will raise a zendesk bug report.

Did you try this? This would be a work-around. Doing this, the keys should function when both MSFS and FSUIPC7 have the focus - and numlock is off. That's not quite true! It should work when MSFS has the focus and the num lock is off and you assign in FSUIPC7 with the num lock on (i.e. assign to the num0-9 keys) .If you want it to work when FSUIPC7 has the focus as well, then you can also assign to the keys with no num lock (End, Down, etc). This is because MSFS/SimConnect only sends the numpad keys when num lock is off, but FSUIPC7 receives them via SimConnect and then sends them to itself as if the num lock was on. I'll report the issue tomorrow.

As I said, the issue is that simconnect is sending the numpad keys when num lock is off (when it should be sending them when numlock is on), and FSUIPC7 is receiving these as the 'num lock off' keys (End, Down, PgDn, etc). Did you try this? This would be a work-around. Doing this, the keys should function when both MSFS and FSUIPC7 have the focus - and numlock is off. I don't have a numlock light on my keyboard, so I can't tell when its on or off. I'm presuming its MSFS that has this wrong at the moment, not FSUIPC7, but once confirmed I'll raise this with Asobo. John

It seems that MSFS only sends these keys when numlock is off, rather than on. And when numlock is off, FSUIPC sees these keys as Ins (0), End (1), Down (2), PgDn (3), Left (4), Clr (5), Right (6), Home (7), Up (8). PgUp (9). So, to have these keys working, try with Num-Lock off, and assign in FSUIPC to those keyboard input strings. EDIT: I also have a non-standard (ie. not windows specific) keyboard. I'll try and dig out another keyboard tomorrow and test with that as well.

I've just done some more tests and I think this is an FSUIPC issue.There seems to be a discrepancy between the vk codes between MSFS and FSUIPC. I'll investigate more tomorrow and let you know.

No response that I'm aware of, but its difficult to track these things - or at least I have not found a way. I don't seem many responses from Asobo on the forums, and all I get when I raise a zendesk ticket is, eventually, a 'thank you for your feedback message' saying that it has been submitted. Checking the status of these, they all say 'Solved' but I don't think this means anything - they have that status as soon as they are raised! I'm not sure I included the numpad keys in my initial zendesk bug, I'll check and add if not. FSUIPC7 is trapping them when it has focus, and acting on them if assigned in FSUIPC7. If not, it forwards the keypresses to the sim. The problem is when the sim has focus - its not forwarding certain keypresses (including the numpad keys) via SimConnect evn though requested. John