John Dowson

These are problems related to the MSFS SDK, not FSUIPC7. What works in the final version will also depend upon what is working in the SDK! Its due to the current state of the SDK that I have released FSUIPC7 as a beta, to hopefully track down such issues, report them to Asobo/Microsoft, and get them fixed. Cheers, John

As mentioned in the 'Limitations' section of the release note, "actions" (usually called events or controls) related to view control (including the PAN * events) are currently not working in MSFS. For view control, you currently need to assign in MSFS. Are there any non-view control "actions" that don't work for you? John

FSUIPC7 can handle up to 16 "joystick" (USB HID compliant) type devices. You can also have 16 devices per WideClient instance (for buttons & switches, not axes), running on separate PCs. John

It looks like the arrow keys are not recognised by MSFS - they don't even appear in the MSFS list of 'Status of Input Events'. I will report this. Could you try to see if your key assignments work when FSUIPC7 has the focus? I just tried with elevator down/up and that seems to work. If all your assignments work when FSUIPC7 has the focus, then this means the events are working but the corresponding input events are not yet working. All you can do at the moment is to assign to different keys. You can also try activating logging for 'Buttons & keys' and 'Events', which should also show you when FSUIPC7 is receiving the key press and what it is doing with it. John

I have a few GF devices (GFP8's, GFT8's & GFR48's) and they work just fine with the GFDev64.dll and FSUIPC7. John

Hi Laurie, please download the latest version of FSUIPC7, released yesterday. It does not require the SimConnect.dll. John

Please see

Did you read this thread? Or search for similar issues? As posted just before your post, please see

There were registry entries in the beta version, which is what FSUIPC7 is currently using. However, it looks like these are no longer present in the released version, which is why FSUIPC7 now cannot determine the default location for flight files and plans. Many offsets won't be populated until MSFS is running and FSUIPC7 is connected. For example, you could check offset 0x3124 (FS version being used) or 0x3308 (FS version as determined by FSUIPC) which will be the first offsets written to when MSFS is detected. However, these offsets aren't currently cleared if MSFS closes. This is because usually you would have FSUIPC7 to auto-close with the FS, but I could clear these in the case that FSUIPC7 remains open if this helps. John

You can try putting the dll in the Windows system folder (and reboot), but this really should be done by the SDK installer (and would then also require users of your software to also install the SDK!). The way to embed the dll is to use a static library. Seems like Asobo only provided a static library for unmanaged C/C++, maybe a static library for managed code will come later. I think for now, you should just include the SimConnect.dll along with your application. John

Its on my list, I'll let you know once implemented. John

Ok, glad that's now cleared-up. Thanks for reporting back. John

It seems that the location for flights and flight plans has changed since the beta. This is causing issues with autosave, as well as flight loading/saving. There also seem to be issues in SimConnect in this area (the required functions are not documented as not or partially working). Also the FS installation location is no longer reported correctly, due to a change in the registry entries/values used, and also the different installation method used by Steam compared to the MS Store. I will investigate these issue. John

I mean your "required" location, i.e. wherever you want to install it. It can go anywhere. If you have FSUIPC6, it will be in your installation folder. If you can't see the extensions, they are hidden from you and you will have to change the Explorer options to see the extensions. You can use the 'Open Folder' option in the FSUIPC6 logging tab, which will open an explorer window on your FSUIPC6 installation folder. Your FSUIPC6.ini file will be there. John

I think it means v11.0: 8484 MSFS version = 11.0.282174.999 John

As I said previously, this needs to be updated to support FSUIPC7. Are you sure that isn't the issue? Are you running both at the same privilege level? If not, please try that. Otherwise I don't understand why it can't find the FS98MAIN window - its there! John

The main window in FSUIPC7 is now FS98MAIN, and, as Pete says, it also creates UIPCMAIN (and UIPCINTERNAL) for messages. The window/class name for MSFS is now AceApp (in P3D/FSX was FS98MAIN). John

I found this under MSFS topic in Paul's forum: I need to tell the DLL about MSFS2020. I'll have a new version out later today. It seems Paul's client needs updating to recognize the new FS version in offset 0x3308 (which is 13) or 0x3124 (now 110). John

Hi James, What apps? Do these apps report any error? Maybe they need updating for the new version? I can't really help without further information. You should also talk to the app developer to see if they have an update planned. John

Was it? I can't remember...I'll take a look at some point but this is pretty minor so it may take a while.

Yes. unsigned byte (UB) Format is the same, but the value is different. Its 110 for MSFS.

I have uploaded a new build of FSUIPC7. This is now compiled against the 0.5.1.0 SDK (was previously 0.4.1.0) and against the static library, so the SimConnect.dll is no longer required with this version. However, the frame rate drop problem is still present.

FYI, I have just updated FSUIPC7-Beta. It is now built against the static lib, so the dll is no longer required.

I have now re-build FSUIPC7 against the static SimConnect.lib, so the SimConnect.dll is no longer necessary. Please download the new version, and delete the SimConnect.dll from the FSUIPC7 installation folder. John

It is only added once FSUIPC7 is connect to the sim. Its not there otherwise.