Simconnect to MSFS 2020 on different computer

[buntings]

Righty, I can confirm that the 32 version of 221 does not connect, results in the same error as per the log below

My Simconnect.cfg file ( which is located in the same directory as the Plan-G Binaries ) looks like this

[SimConnect]
Protocol=IPV4
Address=192.168.1.16
Port=4506
MaxReceiveSize=4096
DisableNagle=0

which matches the settings in the working version 3 and the simconnect.xml.

The Plan-G logfile is below - if I understand what it is complaining about is that it cannot find the 64bit simconnect DLL.....which from your comments it shouldnt be?

As an side, once you press the "connect button" and the error is produced the connect button continues to be greyed out with only the disconnect being available - it doesnt time out trying the make the connection as V3 would if there was a genuine comms issue.

--------------------------

16:10:02.2

---===+++ 12/09/2020 +++===---

16:10:02.2 Starting Plan-Gv4 build 4.0.0.221 32-bit
16:10:02.2 OS is Microsoft Windows NT 6.2.9200.0
16:10:02.2 Plan-G Files folder is: C:\Users\garet\OneDrive\Documents\Plan-G Files
16:10:04.9 Map tiles cache: C:\Users\garet\AppData\Local\GMap.NET\
16:10:05.6 Program in: C:\Local\221\Plan-G v4 32bit
16:10:05.6 Data in: C:\Users\garet\OneDrive\Documents\Plan-G Files
16:10:05.7 Starting timer
16:10:05.7 DownloadCurrentMetars thread started
16:10:05.8 Metar14Z.TXT started
16:10:05.8 Metar15Z.TXT started
16:10:08.2 Stopping timer
16:10:08.2 StartMap
16:10:08.5 MEFs: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\MEF.db'
16:10:09.0 Cleanup
16:10:09.4 Metar15Z.TXT done
16:10:12.3 NdbsInBounds 0
16:10:12.3 Metar14Z.TXT done
16:10:12.4 DownloadCurrentMetars done
16:10:12.4 VorsInBounds 0
16:10:12.6 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
16:10:13.4 AirportsInBounds 0
16:10:13.5 AirspaceInBounds 0
16:10:13.6 MEFs: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\MEF.db'
16:10:13.8 NdbsInBounds 0
16:10:13.9 VorsInBounds 0
16:10:13.9 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
16:10:14.0 AirportsInBounds 0
16:10:14.0 AirspaceInBounds 0
16:10:14.5 Initiating SimConnect FSX connection.
16:10:14.7 SetFSConnected: System.BadImageFormatException: Could not load file or assembly 'Microsoft.FlightSimulator.SimConnect, Version=10.0.61259.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. An attempt was made to load a program with an incorrect format.
File name: 'Microsoft.FlightSimulator.SimConnect, Version=10.0.61259.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
   at Plan_G.Model.SimConnect_FSX.Connect(IntPtr myWindow)
   at Plan_G.ViewModel.MainViewModel.SetFSConnected(Boolean value) in C:\Users\Tim\source\repos\Plan-G\ViewModel\MainViewModel.cs:line 5421


16:10:15.6 ProcessMetars done
16:10:17.1 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
16:10:17.3 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
16:10:29.9 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
16:11:01.0 Cleanup
16:11:57.9

[jccolle]

So the problem is :

Why Plan-G V3, in remote mode, runs correctly with MSFS2020 and  not Plan-G V4 with the same computers and configuration ?

[tim arnot]

v3 doesn't use the standard simconnect library, it has a 3rd party plugin which is unmaintained, and very buggy. It may connect, but it also crashes Plan-G regularly and frequently.

[tim arnot]

The error we're getting comes from (according to the docs) the DLL it finds doesn't match the DLL it's looking for, either in version number, or CPU architecture.
The DLLs are as follows:

32-bit	L-M	3.4.0.0	30/01/2017	253Kb
32-bit	MSFS	10.0.662651.0	26/09/2007	107Kb
64-bit	L-M	5.5.0.0	18/06/2020	321Kb
64-bit	MSFS	11.0.62651.3	26/09/2020	129Kb

The log definitely shows 32-bit build, looking for the v10 DLL. Which should be present. That just leaves the system somehow thinking that it's X64, not X86. Maybe there's some result of the conditional compile code that lets it be one thing while thinking it's something else - on some computers (since it doesn't do it here).

With that thought in mind, I've attached build 222. I've taken out every reference to X64 or AnyCPU from the project files that I could find. Build 222 is as 32-bit as I can make it. The DLLs are definitely 32-bit. I've copied it to my laptop, and it connects with no problem (as did previous builds)

If I remove simconnect.cfg, I get an error "HRESULT E_FAIL has been returned from a call to a COM component." which suggests that it was able to get through to the sim PC, but the connection was rejected by MSFS, which is perfectly reasonable.

https://1drv.ms/u/s!AkfXrd8YzuWw7AmdbVyOzpBBj5VT?e=EiSMNZ

Edit: I should add, no need to rebuild databases in this one.

[buntings]

Thanks for the update, makes sense.  I have just loaded it onto the plan-G computer, Sadly Im afraid the result isnt any better.

I have also just tried running it in "compatability" mode for W8, W7 and XP - all with the same result.



---===+++ 12/09/2020 +++===---

18:51:56.7 Starting Plan-Gv4 build 4.0.0.222 32-bit
18:51:56.7 OS is Microsoft Windows NT 6.1.7600.0
18:51:56.7 Plan-G Files folder is: C:\Users\garet\OneDrive\Documents\Plan-G Files
18:52:00.9 Map tiles cache: C:\Users\garet\AppData\Local\GMap.NET\
18:52:01.5 Program in: C:\Local\Plan-G v4-222 32bit
18:52:01.5 Data in: C:\Users\garet\OneDrive\Documents\Plan-G Files
18:52:02.1 Starting timer
18:52:02.1 DownloadCurrentMetars thread started
18:52:02.2 Metar17Z.TXT started
18:52:02.2 Metar16Z.TXT started
18:52:04.7 Stopping timer
18:52:04.7 StartMap
18:52:05.1 MEFs: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\MEF.db'
18:52:06.6 Metar16Z.TXT done
18:52:08.6 NdbsInBounds 0
18:52:08.7 VorsInBounds 0
18:52:08.8 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
18:52:09.6 AirportsInBounds 0
18:52:09.7 AirspaceInBounds 0
18:52:09.8 MEFs: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\MEF.db'
18:52:10.0 NdbsInBounds 0
18:52:10.0 VorsInBounds 0
18:52:10.1 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
18:52:10.1 AirportsInBounds 0
18:52:10.2 AirspaceInBounds 0
18:52:10.5 Metar17Z.TXT done
18:52:10.6 DownloadCurrentMetars done
18:52:10.9 Initiating SimConnect FSX connection.
18:52:11.0 SetFSConnected: System.BadImageFormatException: Could not load file or assembly 'Microsoft.FlightSimulator.SimConnect, Version=10.0.61259.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. An attempt was made to load a program with an incorrect format.
File name: 'Microsoft.FlightSimulator.SimConnect, Version=10.0.61259.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
   at Plan_G.Model.SimConnect_FSX.Connect(IntPtr myWindow)
   at Plan_G.ViewModel.MainViewModel.SetFSConnected(Boolean value) in C:\Users\Tim\source\repos\Plan-G\ViewModel\MainViewModel.cs:line 5421


18:52:13.6 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
18:52:13.7 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
18:52:14.6 ProcessMetars done
18:52:33.0 User Waypoints: Data Source = 'C:\Users\garet\OneDrive\Documents\Plan-G Files\Data\UWpts4.db'
18:52:34.1 Cleanup

[jccolle]

Same results for me with this version.

[tim arnot]

We know that Simconnect loads when it's run on the FS PC, because it connects. From Plan-G's perspective, there's no difference between running local or remote - it loads the DLL, shoots data at it and gets data back.

Do you have any other simconnect utilities that can run from the client PC?

If you have Plan-G v3, can it connect remotely using P3D Simconnect? (P3D SimConnect is identical between v3 and v4/32 bit).

Do you have any sims installed on the client (FSX, say?) If Plan-G on the FS PC can connect locally, it should also be able to connect to a sim running on another PC (and I'd expect the client Plan-G to fail to connect to a sim running locally) If you get the HRESULT E_FAIL result, I'd regard that as successful, cos that can only happen if the library is loaded.

[buntings]

Hi,
Unfortunately I am running out time now and wont be able to do much other than follow this thread ( and try anything out on my W10 laptop - but wont have any access to a running FSX/MSFS system until next weekend).

The client is just  low powered little box - its only roll is to run Plan-G on a separate monitor. No flightsim on there - it'd run like a dog but might be enough to test your theory! I cant think of anything else I have that uses simconnect (unless you can jog my memory what may use it -I have a load of arduino stuff I started playing with ages ago but from memory I think that was FSUIPC and WIDEFS.


I dont have the FS system running at the moment but tried V3 on the client with it set to connect to P3D, interestingly it reported.....

20:15:40.2 Initiating SimConnect P3D connection.
20:15:40.2 SetFSConnected: System.IO.FileNotFoundException: Could not load file or assembly 'LockheedMartin.Prepar3D.SimConnect.dll' or one of its dependencies. The specified module could not be found.
File name: 'LockheedMartin.Prepar3D.SimConnect.dll'
   at Plan_G3.Model.lm_SimConnect.Connect(IntPtr myWindow)
   at Plan_G3.ViewModel.MainViewModel.SetFSConnected(Boolean value)

I then tried V4 222 and it reported:-

20:12:02.8 Initiating SimConnect P3D connection.
20:12:02.9 SetFSConnected: System.BadImageFormatException: Could not load file or assembly 'LockheedMartin.Prepar3D.SimConnect, Version=3.4.0.0, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
File name: 'LockheedMartin.Prepar3D.SimConnect, Version=3.4.0.0, Culture=neutral, PublicKeyToken=null'
   at Plan_G.Model.lm_SimConnect.Connect(IntPtr myWindow)
   at Plan_G.ViewModel.MainViewModel.SetFSConnected(Boolean value) in C:\Users\Tim\source\repos\Plan-G\ViewModel\MainViewModel.cs:line 5431

Thats about as much as I can do until next weekend - if you think of anything Id be happy test it out on my W10 laptop, even if its only to try and get the elusive "HRESULT E_FAIL" result!

Thanks for your efforts

Gareth

[buntings]

Sorry, I also meant to add that whilst "googling" I came across something called CorFlags.exe, part of the dotnet SDK apparently, allows you to configure an EXE to force it to run as 32bits ( clearly aimed at misbehaving 64bit apps). I was wondering there is any benefit in trying it, whether it would prove anything.

If so, I dont suppose you have a copy in your development enviroment to share - to save me having to install the entire SDK that I have no use for?

[tim arnot]

Here you go: https://1drv.ms/u/s!AkfXrd8YzuWw7ApoamKTT-gB-sBM?e=BHOdbk

[buntings]

Thanks, quick!

Just tried it on the copy I have on my laptop, gives an error....

corflags : error CF008 : The specified file does not have a valid managed header

I tried running corflags on itself and got the same message - so it likely means nothing.

[tim arnot]

 It's not a tool I've ever used, so I don't know the answer to that.

[AlexC]

Yes, it's the "traditional" method with SimConnect.xml on the host, and SimConnect.cfg on the client (in the Plan-G program folder). You can use the same settings as described for P3D here: http://www.tasoftware.co.uk/forum/index.php?topic=3795.0
with the difference that the MSFS SimConnect.xml goes in

C:\Users\[Your Name]\AppData\Local\Packages\Microsoft.FlightDashboard_8wekyb3d8bbwe\LocalCache\

(you may find there's already one there, in which case you can just add the entry for Plan-G to it).

The config index refers to the Simconnect.cfg file, which allows you to have multiple entries.

Hi, I used this method and Plan G is working fine on 2nd computer. connected right away. Using version 4.0.0.221 64
thanks

[buntings]

But what version and build of Windows are you using?

[buntings]

Not chance to do the further testing as we discussed - but have just tried 225, same problem