John Dowson

What do you mean by 'unable to press any button'? Are these physical or virtual buttons? If the former, than what has this got to do with the mouse, and if the latter then you will be using the mouse to click the button. So I don't understand this. The issue with focus is with key assignments. MSFS needs to have the (keyboard input) focus for it to receive key presses. If the focus is elsewhere, you could try adding SetForegroundOnKeySend=Yes to the [General] section of your FSUIPC7.ini if this is the issue. You can aslo try with KeyboardFocus=Yes (not sure what the difference is). Note also that there is a specific FSUIPC-added control called "key focus restore" (number 1125), as listed later in the Added controls list. Please see the Advanced User guide for a details on these parameters. Otherwise, could you please clarify what the issue actually is. John

If Loaded PCFhid64.dll does not show in your log, then the dll is either not in the correct location, or you are using an older version that is not supported by FSUIPC7. I have attached the latest version, just in case: PFChid64.dll However, as I keep saying, if your device is recognosed (you can assign to buttons on this device, so it is recognised), then you do not need it. Again, this implies you don't need the PFC/FSUIPC driver dll. Then this would imply that something else is needed from PFC for the yoke motion, if their own test program doesn't even recognise it.... What console buttons? Is this on the same device, or a different device or the same one? No log or ini files attached. Have you assigned to any macros? Do you have any in your installation folder? I do not understand this without seeing those files... Ok. Macros have nothing to do with devuce/controller recognition, so will not be related to your yoke recognition issue. John

Ok, so you are using custom controls as opposed to the Rotor Brake control. I will check the use of custom controls via offset 0x3110 when I get time - most probably next week, and report back. The Java CDU looks good! Is that available anywhere to download and try?

Then the custom control number and the Rotor Brake parameter will be the same. Are you writing the custom control number or the Rotor Brake control number (together with the parameter) to offset 0x3110/0x3114? As the Rotor Brake control us a standard event, it should work the same in MSFS as in P3D. I haven't tested/checked writing custom controls to 0x3110 - it is possible that this is no longer working (if they are wrongly determined to be presets). I can/will check this, but it will take me a few days before I can get around to this (next week sometime). If you could let me know what controls you are writing to that offset that aren't working (i.e. control number + parameter) that would help. You need to use what works! Some aircraft make use of hvars, others not. PMDG aircraft mainly use custom controls. However, rather than using hvars or lvars directly, it is far easier to use presets. Please see the MobiFlight HubHop resource (https://hubhop.mobiflight.com/presets/) which is a community effort led by MobiFlight that provides presets for many aircraft. You can also check the code used by the preset, which can contain use lvars, hvars & controls/events (as well as other variable types!). John

Those offsets are for sending controls/events and the aircraft loaded does not make any difference to there use - writing to them just sed the control/event to the FS. The events will be sent, but maybe those events are no longer working in the MSFS version. What events are you sending? Maybe you need to use a preset in the MSFS version instead? You can also send presets using offset 0x3110, but it is easier and recommended to use offset 0x7C50 for this, as you can use the fixed preset name in this offset rather than calculating the control number for the preset, which may also change when the preset list is updated (events.txt file). By the way, Pete retired several years ago, although he still helps out occasionally. John

The PFC menu will only be added once you have an aircraft loaded and ready-to-fly, at the time the connection check dialog is displayed. If you check your FSUIPC7.log file, you will also see the following message when it is loaded (i.e. when FSUIPC7 is started, not when the menu entry is added): 1016 Loaded PFCcom64.DLL okay! However, if your device is recognised without this, then you (obviously) don't need it. If the switches on the yoke are recognised, then so should the yoke itself. Do you see anything registered at all in the axis assignment dialog when you move the yoke? Note that if you see another axis, registered, you can click the Ignore button to ignore that for the rest of the time the axis assignment dialog window is open. If you still have issues, please attach your FSUIPC7.ini and FSUIPC7.log files. John

Hi Peter, This implies that you re-installed FSUIPC7 into a different folder than your original installation. All your FSUIPC7 settings are stored in your FSUIPC7.ini file. If you install in a new location, you have to copy that file across to the new installation folder. Note that FSUIPC7 will create a new FSUIPC7.ini file if there is no such file in the installation folder (and this will be empty, i.e. contain no assignments) when you run it for the first time. This file is not touched by the FSUIPC7 installer, either when you install or uninstall. Not sure what you mean by 'functions' - do you mean presets? If they are not available, then this implies that you have either not installed the WASM module or you have not enabled the WASM. Yes, obviously I would have thought... You can try that, but I really don't understand what you have done. Check if you can find your original FSUIPC7.ini file, the one with your settings, Then re-run the installer and install into that folder. Assuming you mean presets when you say functions, these come from the events.txt file (in your FSUIPC7 installation folder), and the WASM module must be installed and active. No "functions" have been removed... You need to find where your original installation folder was, and either re-install into that folder or copy across any files that you use (FSUIPC7.ini, FSUIPC7.key, *.lua, *.mcro, *.dll) to the new installation location. I really don't understand why you are having so many issues. Re-installation of FSUIPC7 is really very easy - you just download the latest version, unzip the file, run the installer (no need to uninstall first - the installer will prompt for this) and just accept the defaults and click Ok in each window until you get to the registration window, which you can skip. It is designed to be easy....or so I thought... Any further issues, please at least show me/attach your InstallFSUIPC7.log file and a FSUIPC7.log file. John

Please find attached. John FSUIPC7.exe

👍😎

You can certainly do that. You need to assign to one of the following (both may work, or one only, depending on the aircraft) with a parameter of 0: ELEVATOR_TRIM_SET AXIS_ELEV_TRIM_SET AILERON_TRIM_SET AILERON_TRIM_SET_EX1 You can also write to the trim offsets using the control Offset Word Set - see page 33 of the Advanced User guide for details on this as well as other offset controls. John

Most, but maybe not all) presets for the 737-700 will be ok for the 737-800. However, I cannot confirm this as I don't have the 737-800, but the simple way to check this is to compare the header files they provide - if they are the same, the rotot brake parameters and custom control numbers will be the same. And if you find that any are not working as advertised, and they are being correctly applied in the FS, then it will be an issue for PMDG support. Good luck with your project! Cheers, John

No problem. The latest license is always available on the first page/comment in this topic. John

Ok, thanks for the update. John

See the following FAQ entry for using the Rotor Brake control for PMDG aircraft in MSFS: Note also that this method is deprecated (it can still be used without issues - all or most of the PMFG presets use the Rotor Brake method). The preferred (and more powerful) method is to use Custom Controls, as you can use actual parameter values with these, as well as the mouse-code operation parameters. See the following FAQ entry on using Custom Controls: The custom control number for FMS left A is calculated from this entry in the PMDG_NG3_SDK.h file (in your Community\pmdg-aircraft-737\Documentation\SDK folder) : #define EVT_CDU_L_A (THIRD_PARTY_EVENT_ID_MIN + 573) and so the custom control number would be 70205. So, if the Rotor Brake control doesn't work, try the custom control instead. If the Rotor Brake control did work, and the preset using this doesn't, there may ne a problem with your installation somewhere. Check you are using the latest version of FSUIPC, which is 7.3.15. John

Does it work in the 737-700? If so, it will be an issue with the 737-800. That preset uses the Rotor Brake control with a parameter of 57301 - you could try assigning to that instead, to check its not an issue somewhere with the execution if the preset.

How have you assigned this? Again,. how is this assigned? For idle / cut off levers in the PMDG 737, please see the following post: John

This will be corrected in the next release. Not sure when this will be, but I can make a beta version available if needed. Just let me know. I assume you also realise that if doing this, the elevator will also move when you move the drone camera forward... John

I have just updated the license. John

The license has been updated, valid until 5th January 2023.

Nice! Thank you very much, John! When I am at home I will get on it! Ok, but if you want fast when you hold the encoder in, you want to assign to the standard controls first, not the fast one. When you do this. you will find the corresponding entries in your FSUIPC7.ini that will look something like this (the index numbers [12,13], device letter [A] and button numbers [1,2] will be different): 12=PA,1,C65879,0 -{HEADING_BUG_INC}- 13=PA,2,C65880,0 -{HEADING_BUG_DEC}- To make these conditional on the rotary NOT being pressed, you would need to add a compound button condition to those assignments (see page 21 if the Advanced User guide) so that they are only triggered when the encoder isn't pressed in. Assuming the encoder push registers button 5, on the same device (A in this example), then you would change those assignment lines as follows: 12=CP(-A,5)A,1,C65879,0 -{HEADING_BUG_INC}- 13=CP(-A,5)A,2,C65880,0 -{HEADING_BUG_DEC}- You can then manually add the fast controls, by duplicating those lines, changing the index number (must be unique!) and the control number, resulting in the following: 12=CP(-A,5)A,1,C65879,0 -{HEADING_BUG_INC}- 13=CP(-A,5)A,2,C65880,0 -{HEADING_BUG_DEC}- 14=CP(+A,5)A,1,C1025,0 -{heading bug inc fast}- 15=CP(+A,5)A,2,C1024,0 -{heading bug dec fast}- Just give it a try and let me know if you have any problems. Also, please note that when editing the FSUIPC7.ini file, either do this with FSUIPC7 not running, or if it is running then open the button assignments window before editing, and when you have saved the changes, click on Reload all buttons to load the changes. John

Then you posted in the wrong forum - there is a specific sub-forum for FSUIPC7/MSFS - I will move this topic to that sub-forum. How does this work exactly? Is this a sticky button, i.e. when you push the encoder you get a button press, and when you press again a release? Or do you hold it pressed and rotate? Does FSUIPC register a button number when you press the encoder? This is by far the best option. Unfortunately I have no idea how to achieve such thing. I read the "Advanced User Manual" but I do not have a clue where to paste these commands in the .ini file. So you would like to achieve this on the button press of the encoder? I can help you with this. If you can assign your rotary to the fast inc/dec controls and check that is working, then show me your FSUIPC7.ini file and let me know the button number on the encoder push, then I can let you know how to use an conditional assignment for this. John

What FS and version of FSUIPC are you using? What ecent/control are you assigning to for this? Does your rotary have one button in each direction, or two (fast & slow) in each direction? FSUIPC provides additional controls for faster heading bug changes: Heading Bug Dec Fast Heading Bug Inc Fast You can just assign to those rather than the standard inc/dec controls. However, it is more common to want to be able to use both fast and slow increments and decrements. There are various ways to achieve this, depending on your rotary type (2 or 4 button). If you have a 4-button rotary, it will show one button for slow rotation in each direction, and another for fast rotation. Just assign the slow button to the standard controls, and the fast button to the fast controls. If you have a 2-button rotary, with a single button in each direction, then there are a couple of ways to achieve this. The first is to use a lua script to convert your rotary movement to set virtual fast/slow buttons, depending on the speed that you turn the rotary. A lua script is provided for this, which you can use/adjust for your device, called Rotaries.lua - from the Lua Plug-ins manual: The second method is to assign the rotary buttons to both standard and fast controls, and then use an offset condition to determine which control to use. The offset condition can be based on another button press or a key press, so that when you turn the rotary on its own you get slow movement, and when you turn it and the defined button or key is also being pressed/held down, then the fast controls are used - or vica versa. You can also achieve finer control by using offset 0x07CC with the offset controls Offset UWord Increment and Offset UWord Decrement (or the cyclic ones), which allow you to define the actual inc/dec delta values to use (the standard ones use 1, the fast ones use 10). John

Assignment facilities are only available in the registered version. There is a trial license available to test these facilities before purchasing, available from a sticky post at the top of this forum, here: Unfortunately the current license has just expired. I will update this license tomorrow (or maybe later this evening), so please check then. John

You could also try using Alt+Tab to see all windows and select each one in turn - that should also show you what program that window belongs to... Are you tunning any lua scripts in WideClient, i.e. are there any .lua scripts in the WideClient folder? If so, you could also try disabling them to see if they are the cause. There will also be a log file for each lua running, so you could also check those. John

Yes...did you try and determine the program/process that owns this window, as advised? That would be helpful (if it has an owner...) Not sure what WideServer has to do with this...FSUIPC handles lvars through the FSUIPC WASM module. You can add an lvar to a free FSUIPC offset and treat it like any other FSUIPC offset - read its value or write to it to update the lvar, or you can use the lua facilities for lvar handling (or macros). John