Paul Henty

Hi Ray, The other three posters in this thread had written their own software in VB.NET and C#. This talked to the Arduino boards and to the Flight Sim via my FSUIPC Client DLL. I can't speak for their work but my DLL is still supported and widely used. If you're familiar with any of the .NET languages then my DLL is an easy way to get your application to talk to the Flight Sim via FSUIPC. I've no idea how one talks to an Arduino board however. If you know other programming languages then there are other SDKs available to talk to FSUIPC (e.g. C, C++, Java etc). Or you can bypass FSUIPC and use the SimConnect interface directly. You would really need C++ for that. Everything you need to know about my .NET DLL is on the website: http://fsuipc.paulhenty.com If you need any help using the DLL please feel free to start a new thread in the support forum: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ Be aware that the SimConnect interface for MSFS2020, as well as FSUIPC7 are still in development. At the moment there will be limitations in terms of the data available compared with P3D and earlier Microsoft flight sims. Paul

I can't remember why I didn't include them, but I'll have another look next week. Paul

Hi Jason, Yeah, I couldn't see a way to tell Visual Studio to get the latest version of the NuGet package. It's easy to forget to update the DLL in the the example applications so I've just updated them (1.1.0) so they now check the version of the DLL installed and notify you when it's out-of-date. The only other changes are the BitArray example now uses FsBitArray and there is a new example for using the ValueChanged property. Paul

Hi Steve, I don't think I'll be converting to .NET Standard. It doesn't make any sense to me to use a restricted feature set when I can use the full .NET Framework. The only reason to use the cut-down .NET Core and .NET Standard is portability. But my library (and the server you are writing) would never be able to work on anything but Windows. In that case one would just use the full .NET Framework as there is no reason not to. Paul

I'm not sure what the point of that would be. The main advantage of using .NET Standard is to be able to run the application on other operating systems like Linux, MacOS and Android. Since FSUIPC only runs on Windows and uses the Win32 API to communicate, the DLL could not be run on any other operating system. If there is another reason to use .NET Standard let me know and I'll look into it some more. Paul

New version 3.1.20 now on NuGet. MSFS has been added to the flight sim Enum FsVersion.ToString() should now return the correct version value when connected to MSFS Paul

Hi James, The DLL looks for UIPCMAIN and if it cannot find it then looks for FS98MAIN (Which is what WideClient.exe uses). Please check you're not running some parts of the connection 'as administrator' and other not. Also, what is the error you are getting? Is it #2 FSUIPC_ERR_NOFS? Paul

Does that mean V1.1.0 or V1.10 or something else?

Hi John/Pete Is the 'specific' flight sim version number at 0x3124 relevant to MSFS? If so, what is the format? Same as P3D? Thanks, Paul

I need to tell the DLL about MSFS2020. I'll have a new version out later today. Paul

Normally, the most common cause of this is that either your app or the sim is running 'as administrator'. Either both have to be run 'as administrator' or neither. If that's not the case, can you please try another FSUIPC application and see if that connects (preferably one not using my DLL e.g. FSInterrogate2std.exe from the FSUIPC SDK). Paul

Hi James, Yes, RefreshData() is just calling Process() for an internal group containing the 0xB000 offset. It then parses the 2048 bytes that get returned and populates the string properties for you to read. The parsing time is negligible compared to the Process() call, so there's no more overhead than a normal Process(). Paul

Hi Jason, Donation details are on the website: http://fsuipc.paulhenty.com/#donations Thanks, Paul

Hi Jason, I've added a new class FsBitArray to version 3.1.19-Beta. Now available on NuGet. Remember to tick the 'Include Pre-Release' option. This is identical to the .NET BitArray except it can also tell you which bits have changed. Use the new class when you declare the offset: e.g. private Offset<FsBitArray> lights = new Offset<FsBitArray>(0xD0C, 2); You can then use the HasChanged() method or use the array of booleans returned by the Changed property. e.g. To test if the taxi lights have changed use either of these: this.lights.Value.HasChanged(3) this.lights.Value.Changed[3] You can also use the array from the Changed property to iterate through all the bits: FsBitArray lightBits = this.lights.Value; for (int i = 0; i < lightBits.Changed.Length; i++) { if (lightBits.Changed[i]) { // Light i has changed. } } The ValueChanged property on the offset will still tell you if ANY bits have changed. This could be checked first to save checking every bit if nothing has changed. Paul

Hi Jason, Yes, the ValueChanged would be for the entire BitArray, not individual bits. I've had a look at the BitArray class. It's part of the .NET framework and unfortunately Microsoft decided to seal it so I can't extend it with any new properties. I can probably create my own FsBitArray class that does the basic set/get bits but also with a HasChanged(n) property. I'll look at this over the next few days. Paul

Hi Jason, I understand what you want to do. It's not really possible with properties in .NET as properties use the same type for getting and setting. You could change the property to return a custom type that includes both the Changed flag and the property Value, but you would also need to pass that type to set the value. This would work but it would mean creating an instance of an unnecessary type every time you wanted to set the value. It's extra typing and ugly code. The only thing I can suggest is to use methods instead. You would create a 'set' and a 'get' method (like Java) for each piece of data. e.g. GetHeading() and SetHeading(). Not quite as readable as properties, but not too bad: Instead of: myFSUIPCData.Heading = 100; this.txtHeading = myFSUIPCData.Heading.ToString("F2"); it would be: myFSUIPCData.SetHeading(100); this.txtHeading = myFSUIPCData.GetHeading().ToString("F2"); If you did that you can then have the Get method return a different type than the one accepted by the Set. You would define a struct that included the changed bool and the value and return that from the Get method. The struct would need to include a generic type for the value so you can define the type of the human-readable value (e.g. string, double, etc). I can give you some example code for this if you want to go the methods route. Otherwise you'll need to make a separate 'changed' property for each of your values. (e.g. HeadingHasChanged). Paul

Hi Ruediger, Thanks for the bug report. Fixed in 3.1.18, now up on NuGet. Paul

From what I can tell from reading the forums, no one really knows yet. The sim and its SDK are still under development. Paul

Hi Luis, The error is because the files are not being trusted by your PC. Here are some things you can try: 1. Go to the properties of the .ZIP file (Right-Click -> Properties). If it says the file is blocked, Check the box to Unblock it. Then unzip it again. Here is a example. 2. If you're opening the example application from a network drive, or from a cloud drive, copy the solution to your local disk. 3. Try adding the folder where your example application is stored to the trusted folders in Visual Studio: Tools -> Options -> Environment -> Trust Settings -> Configure Trust Settings: Paul

Sorry, I don't know. @John Dowson will be able to tell us. Paul

No, everything is running on the same machine.

You're welcome. Yes it's working here on FSUIPC4 with FSX Steam Edition. Requirements are: Registered FSUIPC version 4.924 and later FSX Acceleration and SP2, or P3D version 2 and above NewInterceptTextMenu=Yes (or =Full) in the FSUIPC ini file. Paul

Hi Jason, I've added a new class called TextMenu in Version 3.1.17 to handle this. Now available on NuGet. To use this, create a new instance of TextMenu: private TextMenu textMenu = new TextMenu(); To get the last text/menu displayed on screen call RefreshData() and then get the text from various properties: this.textMenu.RefreshData(); if (this.textMenu.Changed) // Check if the text/menu is different from the last time we called RefreshData() { this.lblDuration.Text = this.textMenu.Duration.ToString(); // The number of seconds the message will stay on the screen this.lblID.Text = this.textMenu.ID.ToString(); // The ID of the SimConnect event that created this message if (this.textMenu.IsMenu) // Check if it's a menu (true) or a simple message (false) { // Display different parts of the menu dialog this.txtTitle.Text = this.textMenu.MenuTitleText; // The title bar of the menu dialog this.txtPrompt.Text = this.textMenu.MenuPromptText; // The prompt text (text above the first menu option this.lstMenuItems.Items.Clear(); foreach (string line in this.textMenu.MenuItems) // MenuItems is an array of strings, one string per item { this.lstMenuItems.Items.Add(line); } this.lblLineCount.Text = this.textMenu.MenuItemCount.ToString(); // Number of menu items } else { // Display message this.txtMessage.Text = this.textMenu.Message; } } The ToString() method will also give you back all entire menu text as a single string. this.txtCompleteString.Text = this.textMenu.ToString(); There is also an overload on ToString() that give you more control. The parameters are: RowDelimiter - A string that will be used to mark the end of each row IncludeMenuTitle - Pass true to include the title of the menu in the string IncludeMenuPrompt - Pass true to include the menu prompt in the string AddNumbersToMenuItem - Pass true to automatically add numbers to the menu items The plain ToString() method defaults everything to 'true' with a delimiter of "/r/n" (VbCrLf in VB.NET). To make this work I had to change my FSUIPC4.INI file: NewInterceptTextMenu=Yes It was set to No. I've tested here with a demo of GSX. Paul

The offset for COM2 is: private Offset<ushort> com2 = new Offset<ushort>(0x3118); This can be found in the "FSUIPCX Offset Status.pdf" in the "Modules/FSUIPC Documents" folder. If you haven't already seen it, please look at the Example Application -> "Advanced Concepts" -> "AC001_RadioFrequencies". This shows you how to use these BCD type offsets. Also note that offsets 0x034E and 0x3118 are for FSX and earlier and won't show the narrower frequency spacing allowed in P3D and later. For the newer COM frequencies see offsets from 0x05C4. These are not BCD format however, just a floating point number. Paul

Hi Golfy, There should be no changes required to the .NET Client DLL. One of the great things about FSUIPC is that it allows any FSUIPC application to connect to any version of FSUIPC. The FSUIPC connection code in the DLL was written for FSUIPC3 and has remained unchanged since version 1 of the dll back in 2005. It's worked fine on every new FSUIPC version since so I'd be very surprised if that compatibility is broken with FSUIPC7. From what I've seen on the forums both FSUIPC7 and the MSFS SimConnect interface are still under development. Maybe there is no way to get weather data out of the MSFS yet. My guess is that these problems will go away as development of MSFS and FSUIPC continues. Any errors you are experiencing will be bugs in FSUIPC7 or missing data because those offsets are not (or cannot be) implemented yet. Paul