All Activity

Yes - look under the Add-ons -> PFC menu. The PFC driver for MSFS is the same as the one for FSX, except that it is 64-bit vs 32-bit. Please see the PFC.DLL User Guide document - this is valid for both the 32-bit PFC.com driver and the 64-bit PFCcom64.dll driver. John

The drivers worked and allowed it to connect to the game. However, only the rudder was working. Is there any simple COM port menu similar to the FSIUPC found on FSX to change assignments and settings or is it just the complex one under assignments?

That is not an error from FSUIPC7 itself, but from an FSUIPC client. I cannot diagnose issues with FSUIPC clients - you need to contact the developer of the client. John

I make use of the FlightsimServer and GSX Remote app latest updates of MBerger, but when I (only) start the menu option on the client; GSX Remote, fsuipc7 comes with numerous pop-ups with the following error ; "FSIUIPC_error#15; FSUIPC_ERR_SIZE.The amount of data requested exceeded the maximum allowed in one process." as long as I am in this menu option. I cannot find anything in the attached log. FSUIPC7 version 7.4.11. I wonder what the selected option GSX Remote from the menu trickers FSUIPC7 to give this error? Please advise on this! Kind regards, Fred FSUIPC7.log

Using PFC COM devices in FSUIPC7 / MSFS2020 is pretty much the same as using them in FSUIPC4 / FXX - you need to install the appropriate PFC com driver. The only difference is that for FSUIPC4 you would use the 32-bit driver (PFC.dll) and for FSUIPC7 you need the 64-bit driver (PFCcom64.dll) - all available from fsuipc.com, COM functionality in FSUIPC7 is pretty much exactly the same as in earlier versions. John

Yes, you can get the latest version on NuGet - it's called FSUIPCClientDLL. It targets all versions up to .NET7. Full details are on the website: http://fsuipc.paulhenty.com Paul

What exactly was this message? Was it for FSX or windows? But is it detected by FSUIPC? Is FSUIPC still running with FSX? If FSX is no longer loading FSUIPC, maybe see John

*** Moved from FAQ sub-forum to Client DLL for .Net sub-forum *** Hi, i'm just wondering if there is a updated DLL for a newer .NET version? The only DLL I can find is for .NET4 which isnt supported anymore. Any help is appreciated. Thanks, Ben.

Hello! I am a FSX user, running win 11. I used the Goflight RP 48 hardware on my previous computer running win 8. It was running well. On my new PC (win 11), the Goflight RP 48 is detected using the Goflight config module but the hardware is not functioning with FSX! I downloaded the driver GFdev.dll (dated 2013) from the FSUIPC.com Website. After that it worked but after shutting down FSX I got the message that a "compatibility change was made". Do you want to save the changes? Yes/No? After saying yes, the RP 48 was still detected in the PC control panel but not working. After reinstalling the driver from FSUIPC and saying "No" to the compatibilty message I am unable to get my RP48 back to work!! Requesting ideas and input. Thank you very much.

I have been using an older FSIUPC for FSX for connecting my PFC COM port equipment to the game. I have recently moved over to the new MFS2020 and I have been struggling with the new software. I only have FSIUPC7 (and the free trial key). Is there any software or method to connect COM port devices using FSIUPC7 or does it not have that functionality?

Thanks, I did allow the trojan in the security. I have to disallow it now. I'll try it now.

I figured it out. The timer that does the processing for the offsets was missing. Had to stop the connection timer when connection opens and start the process timer. If the process timer throws an exception, restart the connection timer. It all works now. 🙂

IsOpen is true because it's connected to FSUIPC7. The counter is probably doesn't update until the player has loaded an aircraft. It should start counting up when you start a flight. This seems correct then. If it's sticking at 219 then there is no activity. The ValueChanged property on 0x337E will be false. So your app knows that MSFS has been unloaded. The activity counter might also stop when the user has ended the flight and is back in the menus. Paul

Just did a test where all the timer did is report the activity count. When I started my app before MSFS was loaded, the total count is 0. After getting to the welcome screen, it still reported 0, even though IsOpen reported true. After restarting my app, I now have a total count of 219. Now, when I close MSFS, the display in my app still shows 219/connected for the current status. I don't understand, because this method works for other parts like aircraft panels. Not sure why it doesn't work here.

You need to be checking the ValueChanged property of offset 0x337E. If you close MSFS and this offset is still changing (counting up), you'll need to ask John Dowson in the FSUIPC7 support forum if he has any other ideas for detecting if MSFS is unloaded. Paul

I tried this offset. I have the same result as when checking IsOpen. The app shows not connected until MSFS is active, then changes to connected as expected. However, closing MSFS while the app is open still results in the connected message staying on screen, even when MSFS has completely unloaded. Restarting my app then displays not connected. Wonder why it's doing this...strange.

So I understand, FSUIPCConnection.IsOpen only checks to see if FSUIPC itself is actively running. It knows nothing about MSFS or its current state. When MSFS closes, my app will always return the last known state of FSUIPC, which was open at the end of the test. To deal with this, I should check the activity counter offset since it can determine if MSFS is currently loaded. I can use the offset for now, but is there a way you can add this as a property to FSUIPCConnection?

Hi Andy, The IsOpen property refers only to the FSUIPC connection, not the flight sim. Prior to FSUIPC7 this was effectively the same thing as FSUIPC ran inside the flight sim. WideClient.exe and FSUIPC7 run outside of the flight sim, so the connection will be open if they are running, even if the flight sim is not. If you want to know if the flight sim is open you can try polling offset 0x337E (activity counter) to make sure it's changing. See the notes in the documentation as there are times it might not update (e.g. loading new aircraft). Paul

I can download the zip file today/now and it doesn't get quarantined, so maybe Microsoft have now corrected this - can you try please? You maybe need to update your virus definitions if you don't have that set to automatic, or wait until you get the latest update, which is Security intelligence version 1.409.501.0 (created 25/04/2024 03:28). John

But this is just not possible. If you move the rudder while moving on the ground, the aircraft will turn, but from the rudder effect not the nosewheel steering. There is no nosewheel steering on this aircraft (as far as I am aware). If it is steering too much via the rudder only (compared to real life), then this is an issue with the model. You may be able to adjust this by updating some of the model parameters, but I cannot help with this - you need to talk to the aircraft developers. What do you mean? If you changed that section of code to exit/return if ground speed was above 20 knots/37 kph, then no differential braking would be used above this speed. You could do that, but I think what you would want is the rudder controls to also work, but it is not clear to me if you want the rudder to work when below this ground speed or above, and this is the section of code that determines when to send the rudder controls: So, please explain exactly what you would like the script to do. You can also try adapting it yourself... Note the following restrictions due to the way the aircraft is modeled - to get these changed you need to talk to the aircraft developers: - the brake lever only moves when you send the BRAKES control, so when differential braking, the lever will not be in the correct position - how the aircraft steers on rudder control only when on the ground is up to the aircraft model John

I have already pinned the topic 'Download link virus detected' to the top, which contains the link to the solution in my response. No. Windows will just quarantine the installer zip file if that is still around. It won't detect anything wrong with FSUIPC7 itself or any of the files installed, so that will not be affected, and even the Install_FSUIPC7.exe is clean. It seems to only affect the zip file, which is why the latest beta is the exe only. When I release 7.4.12, I will provide the usual downloadable zip but also separate downloads for the zip contents - the FSUIPC7 installer, the readme.txt and changes.txt files, and installation and registration guide/pdf.

Sir, I definitely think we're getting close. This last one is the best yet! We still want the rudder to move though. We just don't want it to perform a nosewheel steering sort of function on the ground. What if we change this portion of the script (or a different portion if I've got that wrong) to an airspeed value instead of having "onGround?" Could we maybe do something like 20 knots/37 kph? That way it could work with the funky braking requirements of the Chang on the ground but still be functional as a necessary control surface for takeoffs and landings. function calculateBrakeValues() -- First check if on ground - if not, we can ignore onGround = ipc.readUW(0x0366) if onGround == 0 then -- airborne return end What do you think? -Josh

PS - The confusing thing, I bet for many of us, is that I have the firewall and defender off (too many resources used). I scan at midnight. With all that off, Windows still killed it. ???

Thanks, can you put it at the top like the "Trial License" post? At least it will be seen as a person creates a new topic.

I have a C# WPF app with a main window that controls startup routines. In the main window, I have the following. The user control displays connection status. Unfortunately, the connection status shows 'not connected' when the window loads if MSFS is closed. It will also display 'connected' when MSFS is loaded. When the app is running and MSFS closes, the status remains at 'connected'. It should toggle between not connected and connected based on the status of MSFS/FSUIPC. Any ideas how I can fix it? connectionTimer = new() { AutoReset = true, Enabled = true, Interval = 300, }; // Connection elapsed event. #region connectionTimer.Elapsed += (s, e) => { // Try to open the connection. Otherwise connection timer will do nothing. try { FSUIPCConnection.Open(); FSUIPCConnection.Process(); } catch(Exception ex) { } }; #endregion connectionTimer.Start(); #endregion In the user control embedded into the main window, I have the following. var timer = new DispatcherTimer { Interval = TimeSpan.FromMilliseconds(300), IsEnabled = true, }; timer.Tick += async (s, args) => await UpdatePanelControlsAsync(); timer.Start(); private async Task UpdatePanelControlsAsync() { await Task.Run(() => { string status = FSUIPCConnection.IsOpen? "Connected" : "Not connected"; Dispatcher.Invoke(() => { connectionStatusTextBox.Text = status.ToString(); }); });