MSFS

[gofly02]

Hi Paul,

For those of us with Beta access to MSFS2020, dev access to the SDK and FSUIPC7, is there anything to test for the .NET client?

I am testing my programs that uses your awesome client. There are some fatal exceptions around it specifically so far to FsWeather library that i've seen, as well as some other things.

You can PM me or let me know if I could be of assistance to try out some updates.

[Paul Henty]

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.

Quote

there are some fatal exceptions around it specifically so far to FsWeather library that i've seen, as well as some other things.

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

[Garen Evans]

One of the topics of concern for me is how compatible the new sim is with existing applications that depend on FSUIPC and XPUIPC.  For example , the software I've developed for fsacars.com.

[Paul Henty]

13 hours ago, Garen Evans said:

One of the topics of concern for me is how compatible the new sim is with existing applications that depend on FSUIPC and XPUIPC.  For example , the software I've developed for fsacars.com.

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

Paul

[IanAbel]

Paul,

  Not sure whether to post here or on the FSUIPC forum.

Have MSFS installed, FSUIPC7 and the correct simconnect (from the MSFS SDK install) all loaded, FSUIPC log shows a connection to the sim.

My application (which works fine with FSX, P3Dv4/5 and XP11 via XPUIPC) has the latest FSUIPCClient.dll installed 3.1.19-beta

I get a #12 error from the  FSUIPCConnection.Open() call. Says can't connect to FSUIPC...

[Paul Henty]

Quote

I get a #12 error from the  FSUIPCConnection.Open() call. Says can't connect to FSUIPC...

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

 

 

 

[papanebo]

Hello Paul.

I don't know if i should post it here or in the main fsuipc forum.

 

FSUIPCConnection.FlightSimVersionConnected.ToString() returns 13 instead of a string in MSFS2020. I'm aware that fsuipc7 is still in beta, just wanted to report it.

[Paul Henty]

Quote

FSUIPCConnection.FlightSimVersionConnected.ToString() returns 13 instead of a string in MSFS2020.

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

Paul

[IanAbel]

15 hours ago, Paul Henty said:

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

 

 

 

Paul, sorry probably my problem, I was running FSUIPC7 as admin. Getting a response now.

Thanks.

[737-SimGuy]

Paul,

I am experiencing the problem of connecting to FSUIPC7 as well only when my apps are run on the MSFS machine. I also have an application for control loading from BFF that uses FindWindowEx api call to find the FSUIPC7 window class but it cannot connect either. If you discover why this is happening please post.

This from John Dowson:

""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).”"

Thank you,

James

[Paul Henty]

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

[Paul Henty]

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

[papanebo]

14 minutes ago, Paul Henty said:

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

That was fast! Thank you Paul!

[737-SimGuy]

20 minutes ago, Paul Henty said:

Please check you're not running some parts of the connection 'as administrator' and other not.

 

Hi Paul,

Well this was apparently the problem for my apps! Wow. I checked that both were admin for the BFF app but not my own. Oops. Didn't work for the control loader app from BFF so maybe there is more going on there.

Thank you,

James 

[stevesuk]

Any chance of compiling this to NET Standard?

[Paul Henty]

4 hours ago, stevesuk said:

Any chance of compiling this to NET Standard?

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

[stevesuk]

I'm using .NET Core as that seems to be the way forward for windows. WPF can now use it.

I'm putting together an Alexa skill that talks to a raspberry pi that talks to a windows service running on my sim PC. This service is .NET Core using the newly introduced BackgroundService functionality and can only use .NET Standard libraries (DLLs).

I want to achieve 'Alexa, ask flight control (or my sim, or something else) {show} external camera' etc etc.

Steve.

[stevesuk]

I forgot to add that I want to write a WPF app, that runs on a different monitor screen on my sim pc or installed on another windows tablet, to talk to this same windows service. 

[Paul Henty]

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

[stevesuk]

Ok, thanks. 

[stevesuk]

On 8/20/2020 at 2:57 PM, Paul Henty said:

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 now have to have a little chuckle to myself. A new non .NET Framework version has now been done. You see ..... I knew you would need one eventually!