Paul Henty

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

Hi Jason, Thanks for reporting this. Yes, it was a small bug affecting string offsets. Fixed in version 3.1.16 (not beta), now on NuGet. Paul

Thanks Pete, I've found the controls. @Armandmar I've tested this here and it it gives me very fine control over the speed of the forward movement in slew: FSUIPCConnection.SendControlToFS(FsControl.AXIS_SLEW_AHEAD_SET, x); Where x is the position of the axis which translates to the speed of movement. The range seems to be -16380 to +16380 with negative values moving backwards. Other slew controls are available in the FsControl enum - e.g. AXIS_SLEW_SIDEWAYS_SET. Paul

How would you send data to axes using the FSUIPC C SDK? Are there FSUIPC offsets or controls for this, or would you need to use something like DirectX or DirectInput? Paul

Hi Jason, Using offsets indirectly (e.g. passing them around as parameters) gets a bit difficult. The DLL does have a base (untyped) 'Offset' class, but it doesn't have a Value property as you found out. The problem with passing the typed Offsets is that you can only pass one type of Offset into the method, as you've also discovered. Some toggle offsets are bytes, some are shorts, some are int. You could just duplicate the function for each type you want to use. However there is a way to have a single method which is preferable.... Pass the offset as the base class but also pass a value which you can convert to a common type from each of the typed offsets you need to use (byte, int etc). Something like the following... (as it's a toggle I've chosen bool as the common value type, but you can use the same idea for non-toggle data - you just choose an appropriate type to cast the values to (e.g. double)): private void ReadToggle(Offset instrument, bool toggleStateOn, string name, string OnMsg, string OffMsg) { if (instrument.ValueChanged) { if (toggleStateOn) { Tolk.Output($"{name} {OnMsg}"); } else { Tolk.Output($"{name} {OffMsg}"); } } } Call like this using any numeric data type (offset size): ReadToggle(AvionicsMaster, AvionicsMaster.Value > 0, "Name", "Msg1", "ms3"); Note that in ReadToggle we have the base Offset type with no Value property. It does have the ValueChanged property however. When calling the method, we still have the strongly-typed offset so we can still use the Value property there to determine the toggle switch value. Paul