Jump to content
The simFlight Network Forums

MSFS


gofly02
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 weeks later...
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

Link to comment
Share on other sites

  • 2 weeks later...

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...

Link to comment
Share on other sites

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

 

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 7 months later...
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!  

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.