John Dowson

Sounds like it might be an issue with your USB hubs. Try switching hubs for the GF-Pro yoke if possible, and check that you have power management disabled on all USB hubs. Windows has a tendency to revert this setting on some windows updates. Good to know, thanks! John

MSFS is a very different beast to FSX and takes some time an patience to configure correctly... But what exactly is your problem with FSUIPC7? What do you mean by this? Are you assigning in FSUIPC?? Can you show me your FSUIPC7.ini and an FSUIPC7.log file, generated when you experience this issue, and preferably with relevant logging enabled - maybe start with Buttons & Keys and Events, but if your issue is with axes assignments you will need Axes Controls logged. Do you mean that FSUIPC7 does not auto-start? If that is the case, please see Otherwise, please explain what you mean. I don't know what you mean...of course people have issues (which I am here to help with), but FSUIPC7 is stable in MSFS. Almost all reports of CTDs are MSFS CTDs, not FSUIPC7. A trial license is also available for FSUIPC7, and I recommend you always try with the trial license before you buy. John

What do you mean by this? The PMDG offsets are read-only - you cannot write to them. So 646C should report the state of the left aft low pressure annunciator, and 646D the state of the right aft low pressure annunciator. Writing to PMDG offsets will have no effect.

Could you post a link to this response in case any one else comes across this post - would be useful... Thanks, John

Great - glad you got it working! John

Yes, thanks - but far too short! The first log is for a registered version on windows 11 but ends after 21 seconds by user request - it is useless to me as it shows nothing. The second log file is more interesting, but is from an unregistered version in windows 10. All lvars/hvars have been received, and so should be available for use/assignments - are you sure the WASM menu items weren't enabled? I will look into this (i.e. on an unregistered version), but if the WASM menu items are disabled once you have an aircraft loaded and ready-to-fly (and lvars.hvars have been received) can you try: 1. Disconnecting and re-connecting from MSFS to see if that triggers the menu enable once the lvars/hvars have been received 2. Exit and re-start FSUIPC7 to see if that enables the menu items on lvar/hvar exception Note that the menu items should be available once a message similar to the following is displayed in the FSUIPC7 main window (and not before): i.e. after the number of lvars/hvars/presets loaded has been reported Also, when you attach a log, can you give some information on how and when FSUIPC7 was started and, if not auto-started, the state if the sim - was the sim in the main menu or was an aircraft loaded and ready-to-fly? Also, its not a good idea to start FSUIPC7 when MSFS is in a pause state. Its generally better to have FSUIPC7 auto-started by MSFS. I also see you are using the beta version 7.3.9c. I released an updated beta 7.3.9d earlier today so please update. John Later: after checking the code, I cannot see how the WASM menu items were not enabled after this message in your second log file: 299204 [DEBUG]: EVENT_LVARS_RECEIVED:14 of 14: dwObjectID=0, dwDefineID=17, dwDefineCount=1, dwentrynumber=1, dwoutof=1 The WASM menu items are enabled after all lvars have been received, as indicated by that message.

Ok, thank you. Regards, John

Could you add the following to your FSUIPC4.ini file in the [General] section please: NoWeatherAtAll=Yes Debug=Please LogExtras=x400 and generate and show me a log file with that logging enabled. Also, after the crash, can you check the windows event viewer and paste any crash event information you find there. But unfortunately I don't think I can do much about this... FSUIPC4 has been closed for development for many years, and it will be difficult for me to track down this issue without purchasing this aircraft...I will look into this further though if you can provide me with the above information. You also don't seem to be using FSUIPC4 for much, if anything... John

I know that you weren't blaming FSUIPC. Looking at the file you posted, 2 things stand out: 1. You are using an old unsupported version of FSUIPC - 7.3.3. The latest and only supported version is 7.3.8 (as well as the 7.3.9 beta available in the announcements sub-forum). Please updated to a supported version, 2. Your FSUIPC7.ini file shows that you are not using FSUIPC7 for anything at the moment - you have no assignments and your VRI instrument radio stack is not even detected. So as FSUIPC7 is not involved at all, I cannot really help. I suggest you try support from VRI or Aerosoft for this issue. I have updated the title of your post so that it may attract other users of this hardware who may be able to assist. John

I have added a new option Open on Start and it is available in the latest beta release v7.3.9d which I have attached. John FSUIPC7.exe

Hi Joe, better search functionality for the controls/presets drop-downs has been requested many times already, but its not that easy to implement with the current toolkit used. FSUIPC uses the old Win32 API, not javascript, and doesn't filter the drop-down list - it just positions. I did look into filtering the list a few years ago, but it was messy and slow - too slow to use. This type of filtering is just not a natural fit for the win32 combo box (see https://stackoverflow.com/questions/71584954/how-to-filter-combobox-by-textsearch-input-win32-api). I will look at this again, when time permits, but for now I recommend using the MF HubHob site to search for presets (https://hubhop.mobiflight.com/presets/), and the automatically generated text file (Controls List for MSFS Build 999.txt) to search for NSFS controls/events. Not ideal, I know. Also, for presets, you can always copy the presets for the aircraft that you use from the events.txt file to a myevents.txt file, and then remove the events.txt file. This will restrict the presets available to the aircraft that you fly. Thanks for taking the time to provide an example, but it is of little use due to the way drop-down menus are implemented in win32. Regards, John

"ctrl+4" default assignment is to Toggle Instrument View 4. So it sounds like its only functioning when the radio panel is displayed, as well as having to trigger it with the mouse. I don't see how FSUIPC can be involved - but how are you using FSUIPC? Can you show me your FSUIPC7.ini file and an FSUIPC7.log file and I will take a look. I can then maybe suggest some logging to see if that sheds any light on the issue. John

But you cannot do this, as cdukey is a string - just because that holds the variable name, it is not that variable. You could try with: ipc.control(_G[cdukey], Click_L) see https://stackoverflow.com/questions/43776809/how-to-use-string-as-variable-name-in-lua, or google further... John

First, you posted in the Download Links sub-forum where it explicitly states Not for support requests. I have moved your post to the main support forum, where it belongs. As for your issue, I cannot say as I don't have that controller, but I don't see why it wouldn't work. I can provide you with a tine-limited trial license if you would like to try. John

ipc.control takes the control number (n) as a parameter, as an integer. You are passing a string, Even though the sting holds the name of a local variable which holds a number, it is the string that is passed to the function, not the variable value. This should work: ipc.control(L_CDU_5 , Click_L)

I don't have the PMDG 737-800 so it is difficult to advise... Try activating logging for events, open the logging console window, click the button in the UI and see what, if anything, is logged. It is probably using the Rotor Brake control with a specific parameter indicating the action. The 737-700 uses the following, which is available as a preset: PMDG_B737-7_MCP_ALT_INTV_BUTTON : 88501 (>K:ROTOR_BRAKE) i.e. the Rotor Brake control with a parameter of 88501. Use logging, as advised, to check the same parameter is used, or use the one logged.

You could use lua. If the values you want to change are held in simvars that are writeable, then check if the simvar is already held in an offset and if so you can just write/update the offset value using the lua library. If the simvar isn't writeable, then there is most probablt an event you can use instead, which you can also send using lua ipc.control, e.g. for changing the time you probably need to use the Zulu Hours/Minutes/Day/Year Set control. See the Offset status document to see what simvars are held in what offset, and whether writeable or not. You can also check the MSFS/Asobo documentation on available simvars and events, and there is a file called Controls List for MSFS Build 999.txt which also lists available events/controls. For lua, check the FSUIPC Lua Library.pdf document, and maybe the FSUIPC Lua Plug-Ins.pdf and the provided examples (in Example LUA plugins.zip). John

Not possible at the moment, but I can add a new ini option for this. I will let you know when done. John

Well, if it works with other aircraft it sounds like its an issue for that specific aircraft, but as you don't say which aircraft this is I cannot help... Some controls work when assigned in MSFS but not wen sent from external applications, and this can be aircraft dependent., There are usually solutions around this issue, but I need to know what aircraft you are using. John

This is the first I have heard of this... Can you show me your FSUIPC4.log and FSUIPC4.in files please. John

Your log shows there are issues with duplicate ids in your registry, as well as a missing device: But your yoke and VPC joystick are detected, and the latter acquired for use, but with the same id as your Razer Tartarus Chroma: That is very strange,,, Could you also show me your FSUIPC6.ini file please - we can try using that to change/reset the ids. With the same devices? And all is ok there? If that is the case, maybe also show me your FSUIPC7.ini and an FSUIPC7.log file for comparison. John

Your ini shows multiple assignments, which is why they are grayed-out in the assignments tab: So when you press button 6, assignments 19 and 76 are triggered, so toggles twice resulting in the same state. and when you release, assignments 20 and 77 are triggered, again two toggles resulting in no change to the parking brake state. But I don't see how this could have worked with FSUIPC5, as the assignments are still the same. You can always set logging for Buttons & Keys as well as Events, open the logging console and you can see what is being sent when you press or release the button in real-time. This should tell you what is going on. Note that as you have overloaded/multiple assignments, you will have to adjust/remove these by editing the ini file directly rather than using the button assignments panel. John

Just installing FSUIPC6 should not do anything unless configured, and it certainly doesn't affect anything visually, so something else must be going on. What happens if you rename the FSUIPC6.dll (e.g. to FSUIPC6.dll.unused) so that FSUIPC6 is not loaded?

First, you posted in the sub-forum for FSUIPC7 / MSFS2020. As you are using FSUIPC4 and FSX-SE, I have moved your post to the main support forum. Which throttle axis are you using? Did you try other throttle axes? If not, please do. And are you calibrating with a reverse zone or not? I am not familiar with the Eaglesoft C750 2.0, but maybe check the configuration for that aircraft, as some Eaglesoft aircraft require to be configured, e.g. see this for the Eaglesoft Citation: https://www.avsim.com/forums/topic/377514-eaglesoft-citation-x-problem-with-idle-and-throttle/ Otherwise, please show me your FSUIPC4.ini and FSUIPC4.log files, the latter with axes logging enabled and move the throttle through its full range and exit. John

Please see APPENDIX 3: Handling VRInsight serial devices in FSUIPC on page 60 of the FSUIPC7 Advanced User guide, as well as the additional document Lua Plugins for VRInsight Devices.pdf. John