Paul Henty

Version 3.3.12 is now on NuGet. The PMDG_777_Controls enum now includes the new controls added in the MSFS version. The PMDG_777X_Offsets class now maps to the correct PMDG offsets depending on what sim your application is connected to. Connection must be open before instantiating this class. Paul

I can probably get this done by the end of this week. Paul

The only documentation I know of was the 'New weather Interface' document from Pete Dowson which I used to write the weather features. The Enum in the DLL is made from that documentation. Only a few numbers are known/used in Microsoft Flight Sims: public enum FsCloudType : byte { Type_0, Cirrus, Type_2, Type_3, Type_4, Type_5, Type_6, Type_7, Stratus, Cumulus, Cumulonimbus } So 1 would be Cirrus, Stratus is 8. The best thing to do would be to make cloud layers in XPlane with the different type of clouds that XPlane allows and see what number they come though as. Paul

Sorry, I misunderstood what your problem was. You need to check how many layers are returned. If it's 0 then you can add your "No clouds" message. Something like this: Me.lstClouds.Items.Clear() If weather.CloudLayers.Count > 0 Then For Each layer As FsCloudLayer In weather.CloudLayers Dim cover As FsCloudCoverage = layer.CoverageOctas ' Gets the description of the coverage (e.g. Few, Broken etc) Dim coverDescription As String = cover.ToString().Substring(0, cover.ToString().Length - 2) ' add the number of Octars coverDescription += " (" & CInt(cover).ToString() & "/8)" ' Get the precipitation (rain/snow) Dim precipitation As String = "" If layer.PrecipitationType <> FsPrecipitationType.None Then precipitation = " - " & layer.PrecipitationRate.ToString() & " " & layer.PrecipitationType.ToString() End If Dim layerText As String = "-" & layer.LowerAltitudeFeet & "ft" & " " & coverDescription & precipitation Me.lstClouds.Items.Add(layerText) Next Else ' No cloud layers Me.lstClouds.Items.Add("No Clouds") End If Paul

I'm not sure that there can be cloud layer without clouds. The layers have a lower and upper altitude, so they only describe where the clouds are. They don't tell you where there are no clouds. Are you using MSFS? I don't have that sim so maybe it's changed and there are such things as cloud layers without clouds. Or maybe the weather isn't working yet in FSUIPC7. I've looked at your code and ran it here. I can't see any way that layerText can ever be blank or "". Dim layerText As String = "-" & layer.LowerAltitudeFeet & "ft" & " " & coverDescription & precipitation This can't evaluate to "" because even if coverDescription and precipitation are "" and lowerAlt is 0 you'll get "-0ft ". I suggest putting a breakpoint on Me.lstClouds.Items.Add(layerText) and print the value of layerText for each layer in the immediate window. It might give you a clue what's going on. Paul

Then I think the problem is that DetectFuelTanks() is being called before the connection is open. Add a log entry when DetectFuelTanks runs. If it comes before [Info]: Connected to flight simulator (auto connect).: [tfm.Utilities.ConnectionManager.AutoConnect]: [2024-06-22 08:02] then you need change your code to make sure everything happens after the connection is open. Paul

Hi Andy, It's a bit puzzling. I've had a look at the code and the FSUIPCConnection.Open() and FSUIPCConnection.IsOpen wasn't very thread safe. The connection was marked as open before the opening procedure completed. I've improved this in Version 3.3.11 - Now on NuGet. Can you please try this version to see if it fixes your problem. Note that you need to remove the FSUIPCConnection.Open() from the fuel tank code. You can't open the connection twice. The check for IsOpen is good and should remain. Paul

Hi Marc, You need to ask John Dowson about this in the MSFS (FSUIPC7) support sub-forum: https://forum.simflight.com/forum/183-fsuipc7-msfs/ Paul

Did you try with a stock aircraft? It might be the PMDG aircraft that's messing it up the sim variable that feeds that offset. You should also try just logging 3324 using the FSUIPC logging options. If it's producing bad values in the logging with one of the stock aircraft you need to ask John Dowson about it. If it's fine in the FSUIPC logging then it's something in your code. Paul

Yes, that's a good way of doing it. Paul

The offset values are updated regardless of if the aircraft is moving or not. The Altitude offset should definitely contain the correct value while on the runway. It certainly does here. I suspect there's a problem with your event system. It's probably missing the first Process() call where all the offsets will have ValueChanged set to true. From the second process() onwards this property will be false until the value changes. Which it won't until the aircraft moves. You probably need to do an initial sweep of all the values before your event system starts. This also brings up another potential problem with your event system... If it misses a process() call (i.e. two Process() calls happen between your PDF class checking the offsets), it will miss the change in the offset. Your event system should really be called after each process() (on the same timer) to make sure it's 1:1, not on its own timer where its likely to get out of sync. Paul

Just the stock Cessna. I don't have any PMDG aircraft. The Altitude offset is the built-in flight sim altitude. It's not specific to the PMDG aircraft. Have you tried a stock aircraft? If that's fine then it's PMDG messing with that offset. Paul

Hi Andy, I runs fine for me. I pasted your code in (along with your connection manager from your previous thread). I ran it with the following code on a WPF window: private PFD _pfd; private void btnConnect_Click(object sender, RoutedEventArgs e) { ConnectionManager.AutoConnect(); _pfd = new PFD(); _pfd.AslAltitudeChanged += _pfd_AslAltitudeChanged; } private void _pfd_AslAltitudeChanged(object sender, AircraftValueChangedEventArgs e) { this.txtAlt.Text = e.NewValue.ToString(); } It works as expected: No bad values and only updates when the altitude changes. Some things to note about my test: 1. I don't have the Truncate() extension on double, so I had to comment those lines out. 2. I don't have Utilities.MathServices.ConvertRadiansToDegrees so again, commented out. 3. I don't have MSFS - I used FSX - This shouldn't make any difference unless 0x3324 is broken in FSUIPC7 which is unlikely. I think the problem is likely to be somewhere else in your code. Try using a simple window like my code above to see if that works. Paul

Hi Andy, The problem is that you're instantiating the PMDG offsets before the connection is open. public static PMDG_737_NGX_Offsets offsets = new PMDG_737_NGX_Offsets(); public static PMDG_737_NGX_Offsets offsets = new PMDG_737_NGX_Offsets(); You can declare it at the class level, but you need to create it after the connection opens... Here's my cut-down class manager with the offsets added: public class ConnectionManager { public static DispatcherTimer connectionTimer; public static DispatcherTimer processTimer; public static PMDG_737_NGX_Offsets offsets; // !!! Declare but do not create yet public static void AutoConnect() { // Start looking for MSFS. connectionTimer = new DispatcherTimer() { Interval = TimeSpan.FromMilliseconds(50), }; connectionTimer.Tick += async (s, e) => { // Open the connection. try { FSUIPCConnection.Open(); offsets = new PMDG_737_NGX_Offsets(); // !!! Create the PMDG offsets after the connection is open. // Stop trying to connect so the connection status is properly updated. connectionTimer.Stop(); // Start processing data from MSFS. processTimer.Start(); } catch { } }; connectionTimer.Start(); // Start processing data. processTimer = new DispatcherTimer() { Interval = TimeSpan.FromMilliseconds(50), }; processTimer.Tick += (s, e) => { try { FSUIPCConnection.Process(); offsets.RefreshData(); } catch (FSUIPCException ex) { processTimer.Stop(); connectionTimer.Start(); } }; } } Paul

Are you using the PMDG_737_NGX_Offsets class from my DLL? I can't see any reference to it in the code you've provided. If it is, I would need to see the relevant bits of the code you create it and call RefreshData(). If you have your own class then I'll need to see a few of the offset declarations and how these get processed. Paul

I don't know if the original poster ever got this working. Reading through this thread, it seems not. If you're familiar with C# then you can try the project I posted near the top of this thread. You might be able to get further than the original poster. You'll also need the Skalarki C# SDK. This thread was from 4 years ago so I don't know if it's still available or if it's still the same. If I remember correctly it was installed as part of the 'profiler' software, so if you already have that you might have the SDK already installed. Note that this won't make the switches accessible from the FSUIPC GUI. You'll need to have the C# application running, acting as a bridge. It will read your Sklarki switches and then do the actions in the flight sim via the FSUIPC programming interface. Paul

I ran your code here and it works fine. I deleted the parts specific to your application that I don't have (mainly in the 'catch' statements). I was able to use it to display the player lon/lat on a WPF window. Whatever the problem on your side, it's not this class (unless it's the parts I had to delete). Maybe start with the code below and work your way up to see when it breaks. This works for me: public class ConnectionManager { public static DispatcherTimer connectionTimer; public static DispatcherTimer processTimer; public static void AutoConnect() { // Start looking for MSFS. connectionTimer = new DispatcherTimer() { Interval = TimeSpan.FromMilliseconds(50), }; connectionTimer.Tick += async (s, e) => { // Open the connection. try { FSUIPCConnection.Open(); // Stop trying to connect so the connection status is properly updated. connectionTimer.Stop(); // Start processing data from MSFS. processTimer.Start(); } catch { } }; connectionTimer.Start(); // Start processing data. processTimer = new DispatcherTimer() { Interval = TimeSpan.FromMilliseconds(50), }; processTimer.Tick += (s, e) => { try { FSUIPCConnection.Process(); } catch (FSUIPCException ex) { processTimer.Stop(); connectionTimer.Start(); } }; } } Paul

Hi Andy, The only thing that looks out of place to me is in the processTimer.Tick() function: At the start you have processTimer.start() and right at the end you have processTimer.Stop(). That's last line will mean the timer only ticks once and then stops. I've added comments below with !!!. // Start processing data. #region processTimer.Tick += (s, e) => { processTimer.Start(); // !!! Not required - it's already running. try { FSUIPCConnection.Process(); var counter = activityCounter.Value; } catch (FSUIPCException ex) { /* * Since the connection to MSFS failed, stop the process timer and restart * the connection timer. We don't want to continue processing if * the connection is closed. We also don't want the connection timer running at * the same time as the process timer. It could cause connection problems, and needlessly fill the logs with endless loops of * errors. */ processTimer.Stop(); connectionTimer.Start(); logger.Warn($"Connection to MSFS closed: ({ex.FSUIPCErrorCode} - {ex.Message})."); } processTimer.Stop(); // !!! This will stop the timer after the first tick. }; Paul

There are no features in John's WAPI dll that are specifically for BVars, so the C# client doesn't have them either. You might be able to trigger them with Calculator Code which can be sent via MSFSVariableServices.ExecuteCalculatorCode(). I can't tell you the syntax for this as I don't know calculator code, but you can probably find it elsewhere or ask John in the main MSFS (FSUIPC7) support forum. Paul

Yes, no problem, I've now added .net 8 support starting from version 3.3,10 - available now on Nuget. Paul

FSUIPC uses the Win32 API to communicate with the client applications. It's therefore 100% reliant on the internals of the Windows operating system, so that dependency cannot be removed. While you can install XPUIPC into XPlane running on a Mac or Linux, this will only allow communication with their XPWideClient software on separate (Windows) machine. This communication will be using their own protocol based on TCP/IP. There is no way the FSUIPC protocol can be used on MacOS or Linux. Paul

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

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

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

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