John Dowson

Something must have changed. Do you have your original FSUIPC7.ini? If so, please show me that together with your FSUIPC7.log file. But if you let it rebuild a new one you will have lost all your assignments. I really can't help unless you show me your .ini and .log files. For the log, you can also activate logging for Axes Controls, which will show what axes controls are being sent to the sim.

This topic is over 5 years old, and the last update to the web site you pointed to was over 3 years ago. I would just download and try it first, and contact the author (Alvaro Polo @apoloval) via his website if you have issues.

Yes, many aircraft continually send various events, and its aircraft dependent. You can ignore these by using the DontLogThese ini parameter. Chck the Advanced User Guide for details.

The default PollInterval for buttons is 25 milliseconds, i.e. 40 times per second. You could try adjusting this if you want to receive more. You could also try the example lua script Rotaries.lua. When using this, this will trigger 2 virtual buttons in each direction, one of which you should assign to a standard increment (small increase/decrease), and the other to a larger increment/decrement. Note that FSUIPC adds special controls for using with the 'fast' rotary button (from Advanced User manual, p29): However, I'm not sure if these will work with PMDG aircraft.

But "Fthr" is just a parameter value to a function, so I'm not surprised that you didn't find that. You should certainly be able to find the definition of the DspShow function somewhere. But even if you find that, there are other problems, e.g. functions _MCP1() and _MCP2() aren't defined, nor DspMed1 or DspMed2. This script is obviously meant to run in the LINDA environment.

Interesting, and thanks for those links and reporting back. Let me know if you get any further crashes.

Do you mean from offset 0x0130? If so, could you please add offset logging to for that offset (with type AsciiZ) and show me a FSUIPC7.log file when this is 'randomly populated'. I'm not sure what you mean by 'blocked for reading'. How are you reading this data - via the SDK? If so, which one? Later: I have noticed that FSUIPC quite often receives a message from MSFS with an empty plan name, e.g ".PLN". However, this is usually followed by the actual plan file name, e.g. I guess I should ignore these and not update offset 0x0130 for plans with no actual name or path.

No, its only a warning and nothing to worry about. 32 (buttons 0-31) is the standard button limit, but POV buttons (usually) have the 8 button ids from 32-39 which you can assign as either an axis (e.g usually PAN_VIEW, butthis is not working in MSFS) or as buttons. I would certainly try without the saitek software installed first. You can always re-install it later if needed. I would then try without the drivers, and use the default windows drivers (again, you can always re-install later if needed). Finally you could try without that file - i.e. temporarily rename it. You can revert back to the original name if it doesn't help or causes issues.

The keys seen by FSUIPC7 is currently restricted by what is sent via SimConnect. For what is currently available, you should refer to the MSFS SDK documentation, under SimConnect, -> SimConnect_Status_of_Input_Events. It is acknowledged/known. Again, check the documentation. This is a different problem. FSUIPC7 can receive/see the numpad keys, but MSFS only sends them when numlock is off, rather than on. This has been reported to ASOBO. As a workaround, I have added a new ini parameter to get around this (in the build from 26th September): - new ini parameter UseAlternativeNumpadKeyMapping as a workaround for an MSFS bug on numpad key input. Please see this thread for a discussion on how this is used: Cheers, John

Yes, with FSUIPC7 now being a stand-alone exe rather than a dll, you don't need to have MSFS installed to install or run FSUIPC7. But of course, doesn't normally make much sense doing this! Ok, thanks, I'll update the installer to include V0.2.0 and release sometime next week...once I've updated the FSUIPC7 user manual. I'll also update the FSUIPC6 installer to include this, although I'm not sure yet if I'll add the start/stop/etc integration. I may do that at a later stage, via menu items in the P3D Add-on drop down menu entry, but that will depend if needed (i.e. requested). Regards, John

Ok, thanks Paul. I'll update the installer for this version for the next release. I would appreciate some feedback on the current release though first, in case I need to make some other updates. Thanks, John

As Pete says, your lua script is using a LINDA lua library function that isn't present when you run your script outside of the LINDA environment. To use this outside of LINDA, you would need to include that script, and all its dependencies.

Can you also check that you have 'Power Management' disabled' on all your usb devices and hubs.

Maybe you could also try with this added to the [General] section of your FSUIPC7.ini: UseAIClient=No This will instruct FSUIPC to NOT use a separate SimConnect connection for AI, and will use the main connection instead (i.e. no change in functionality). This would help me to determine if the issue is related to multiple SimConnect connections interfering somehow.

@MartyReynolds If you are unplugging and re-connecting USB devices, you should really use the 'JoyLetters' facility (see User guide if you don't know what this is), which will prevent problems if/when Windows assigns a different id to your device(s).

Looks like you have registry issues, but could you please also show me your FSUIPC6.log file. Also, you aren't using the 'JoyLetters' facility. You should really activate this to prevent problems when windows re-assigns your ids. Please see the FSUIPC User guide for details, or simply change AutoAssignLetters=No to AutoAssignLetters=Yes in the [JoyNames] section of your FSUIPC6.ini file and run P3D.

There are many buttons/switches that can't be programmed at the moment either due to lack of controls or controls not working, especially for AP systems (G1000 etc). Also. it seems that, depending on the aircraft and the AP system used, you may have to switch authority from the FCU to enable, and this may also apply to the MCP. I am referring to this post: See this topic for further details:

Nor have I - assignments look good. Try activating logging for Buttons & Switched and Lua plugins to see if that tells you anything. You can post your log file here. Try without LINDA running as well to see if that's interfering.

I'm not sure about the Saitek X56, but its possible with the mode switch on the saitek yoke. When you change the mode switch, does FSUIPC see this in the buttons and switches assignment dialog? If so, it should be straightforward to use in FSUIPC. If not, some folks had to remove/rename a file called SaiD0BAC.PRO (in C:\Windows\System32) to get the mode switch of the yoke recognised. Maybe there is something similar for the X56? Also, note that FSUIPC only sees the first 32 buttons (0-31), so if the button number of the mode switch is higher than that it won't be recognisd in the assignments panel and you would have to resort to lua to program the button. You can check in the windows game controllers utility to see if your mode switch is recognised there (and what number it has). Finally, make sure that you have not installed the saitek software or drivers and just use the standard windows drivers.

@Thomas Richter Those assignments are fine. He's just overloading the previous button press (adding '10' to the entry number, and using offset conditions. These are the ones that should be removed as they are assigned to controls that no longer exist: For the actual problem, I'm still not sure if the TrransmitClientEvent failures are due to MSFS or FSUIPC7. However, when this occurs FSUIPC7 should be able to disconnect and reconnect successfully without crashing. This looks to be a threading issue which I'll look into. Btw, could you also activate 'Extras' logging. This will add a but more information (namely the thread id of the thread logging the message) which may be helpful. Thanks,

Yes, but its pretty much the same in FSX/P3D, although not quite so bad. However, previous versions of FSUIPC had the mouse macro functionality that enabled you to assign to UI components that weren't controllable via standard SimConnect events or variables. I think we have to wait for something similar to be implemented in MSFS, rather than expecting ASOBO to implement SimConnect events to control all buttons/switches for all aircraft.

Starting/stopping luas are controls added by FSUIPC, as Thomas has shown you.

As Pete said earlier, just run it again and it will kill the previous incarnation. Or to just kill it, you can also use the provided control.

You run WideFS on a client PC. If you want to run it on the same PC as FSUIPC/P3D, you have to change the class name - see the provided documentation for details. But, do you really need WideFS? This is really only needed to run FSUIPC clients on a different machine to P3D o/FSUIPC. You should not use that just to use the lua display library. You can use ipc.display instead for luas running in FSUIPC. For example, try the attached lua: FPS_Monitor.lua

Hi Stephan, first, I have moved your post to the dedicated FSUIPC7/MSFS sub-forum. Please use this sub-forum for question on FSUIPC7/MSFS. Yes, you can - but only if your device is recognised as a standard windows HID device. In FSUIPC, you can add 'curves' to adjust the sensitivity. I suggest that you just download and try FSUIPC7-beta. It currently comes with a time-limited license so you can try the assignments. See John