News:

Buying something from Amazon? Please consider using my affiliate links - Amazon.com or Amazon.co.uk - You get your stuff, Plan-G gets a little boost :)   

Main Menu

Simconnect to MSFS 2020 on different computer

Started by buntings, September 05, 2020, 07:28:06 PM

Previous topic - Next topic

buntings

was just about to post the text below and realised you had posted about 218 - I will check that now and get back in a few minutes, but this is how it stands at the moment......

I have just tried installing from here:-

https://dotnet.microsoft.com/download/dotnet-core/thank-you/runtime-desktop-3.1.8-windows-x64-installer

It asked if I wanted to repair the installation (which to me means it was already installed) - however I repaired it, I did notice it reported that "Microsoft Windows Desktop Runtime - 3.1.7 (x64)" was installed rather than 3.1.8 but I am guessing this is just an inconsequential typo.

Sadly its made no difference. I also checked the windows logs - nothing there.  Also tried running it as administrator - no joy.

Anyway to tell what mode it is running in or force it to run in 64 bit mode?

Very odd that the same program works on one machine but copy it to a supposedly identical windows build and it errors!

Is there anything else I can do to help diagnose the issue?

Thanks

buntings

OK, downloaded 218 (which I think I did yesterday as well)
Copied the "simconnect.cfg" file into the 218 apps directory (but not the simconnect DLL )
Cleared the logfile.
Ran it and downloaded the 32bit dotnet as it requested

It loads the MSFS data etc ok and looks ok. ( the logfile has a load of SQL errors which I think we covered yesterday re missing columns)
Still doesnt connect - gives the same error.

I have checked and there is a dotnet folder under both "Program Files(x86)" and "Program Files" - both with timestamps that correspond to the times I installed them today.

Logfile attached

tim arnot

yes, the sql errors are no factor.

Hmm, I'm not sure there. 32-bit build, and 32-bit dlls should definitely load okay. The log only shows an FSX connection attempt. It's worth trying P3D if you haven't already - they are different libraries so may behave differently (both should be able to connect to MSFS). Otherwise I'm a bit stumped at the moment.

I'm about finished with build 221, which will have both 32 and 64 bit versions. I still need to test that across a network, but assuming that goes okay, it should be available in the next day or so. Hopefully we'll have better luck connecting with that.

Tim. @TimArnot

buntings

ok, Ill have a bit more of a tinker tomorrow and try the P3D option (which I havent yet tried).


Happy to try anything out that might help you.

Gareth

buntings

Running "218" with the P3D option gives this


11:02:43.0 Initiating SimConnect P3D connection.
11:02:43.1 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 5425

Out of interest  I did copy the simconnect dll over into the 218 binary folder but the same message occured

jccolle

Always the same problem with v221:

12:02:25.5 Initiating SimConnect FSX connection.
12:02:26.5 SetFSConnected: System.BadImageFormatException: Could not load file or assembly 'Microsoft.FlightSimulator.SimConnect, Version=11.0.62651.3, Culture=neutral, PublicKeyToken=baf445ffb3a06b5c'. Tentative de chargement d'un programme de format incorrect.
File name: 'Microsoft.FlightSimulator.SimConnect, Version=11.0.62651.3, Culture=neutral, PublicKeyToken=baf445ffb3a06b5c'
   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

Then I don't understand the Config Index in SimConnect Settings, the value default is 0. Is it a good value ?

tim arnot

Was this 32 bit or 64? Local or remote?

Generally you'll only have one entry in your sim connect.cfg, and so the index will be 0 (because indexes are 0-based). IF however you need a second connection (say you have P3D running on a different PC, then your sim connect.cfg file will have two entries - [Simconnect.0] and [simconnect.1] (you only add the .n when there's more than one entry). Now the index value lets you choose between the two connections.

99.9% of the time though, you'll only have one entry, and so the index is 0.

Tim. @TimArnot

jccolle

This is the 64 bit version in remote mode but it's the same with 32 bit version.

tim arnot

I'm kinda clutching at straws here, cos both versions work from my laptop, with no special attention.

Are you running in Administrator mode, or regular user?
What version of Windows?
CPU?
Do you have antivirus active on each machine?
Firewall?

Do you have another sim installed? (FSX/P3D), can you connect with that (32bit version)?

Tim. @TimArnot

jccolle

The remote computer is under WIN7 and MSFS2020 is under WIN10 and I think that the problem is here. I have a full communication between this  two computer and I can build the Data base but I think that the communication via IP address doesn't work between WIN7 and WIN10.

buntings

I have just had a quick look at 221 and it suffers the same error as before (both 32 and 64bit).

Re the other users comments - if you recall I had this issue on W7 before upgrading to W10, I dont think its a W7 Plang to W10 MSFS issue.

I have just installed PLanG on my W10 laptop and it also has the same problem ( W10 Pro, 64 Bit ) - tried both the 32 and 64 bit version.

I do not have an antivirus (other than the inbuilt Windows Defender ) on the PlanG or MSFS computers ( they are ringfenced - the antivirus overhead is something I dont need), as previously stated PlanG V3 was working on a dedicated PC connecting to MSFS and FSX on the Flightsim PC - so I dont believe it is a firewall issue.

I did take a look at procexp64 to see if there was some odd file or DLL being used that was present locally on the MSFS computer but not on the newly built W10 Plang computer - nothing obvious.
Tomorrow will be my last chance to investigate until next weekend but I will try and and do a little research and try and get you a coherent set of results, logs etc.

buntings

OK, as promised a coherent set of notes.  I have attempted to start afresh and rule out any confusion from previous installs etc.

The Plan-G computer is a
Gigabyte Brix GB-BXBT-1900 , a Celeron J1900 @ 2GHz 8GB Ram
Windows 10 Pro - Version 2004, Build 19041.508

The Flight Sim computer is a
Intel i7-9700K @ 3.6GHz ( Overlocked and is stable at 5GHz )
The motherboard is Asus Prime Z370-P II
16GB RAM

Both are ringfenced and neither have antivirus running and just the inbuilt firewall.


The Plan-G computer used to Run W7 Pro on an HDD but in an attempt to resolve the problem a few days ago it was installed with a fresh download of W10 on a new SSD ( so nothing inherited from W7 whatsoever).


This morning I removed the existing Plan-G V4 folders, including those under "Users"

I did a fresh download and install of V3.2.2.167  and configured it using the inbuilt options to connect to 192.168.1.16, IPV4 port 4506. I ran it once, to create the folders and then re-ran it after I had copied over PlanG3_FSX.sdf (only) from the old W7 HDD

I then ran FSX-SE on the Flight Sim computer and checked the remote connection - works fine. I then stopped Plan-G and FSX, started MSFS and then Plan-G - again, the remote connection worked fine.

So at this stage V3 is working remotely with FSX and MSFS

The Flight Sim computer
----------------------

Next I removed Plan-G from the Flight Sim computer and did a fresh download of V221 (note that I did not remove the files from under "user" ).

At this stage I did not create simconnect.cfg.

I ran the 32bit version and let it organise the 32bit Netcore download.

I started MSFS and got it to the point where it was "ready to fly". Connected Plan-G and it happily connected and display the location correctly.

I then did the same with the 64Bit version - with exactly the same results

So both 32 and 64 bit version work fine "locally"


Back to the Plan-G computer
---------------------------

I did a fresh download ( ie didn't copy from the other computer) of 221 onto the plang computer.  I have not copied the MSFS datafiles.

Ran the freshly installed 32 bit version - same error as before, ditto with the 64bit version

Tried both versions a second time using "run as administrator" - same issue.

Laptop.

I have a W10 pro 64bit laptop ( an I5 as I recall )  that is completely unrelated to the Flight Sim setup and has never had anything installed on it. I put V221 64bit version on it - exactly the same problem.


Thoughts.......

I notice that 221 shipped the simconnect DLL with the 64bit version and that the 32bit doesn't require it - so that rules out any issues with the SDK that MSFS downloaded here.

I am wondering if the message that's being produced is actually wrong or misleading - and the error may be something other than a file in the wrong format, eg a missing file ( I note that there are multiple copies of the simconnect dll in various places ).

I am wondering if there is something else installed or done by the SDK, or MSFS install,  that is not present on the non-MSFS computers and causing problems.  I know you said your laptop works OK - has it ever been used for development or had anything installed on it? Just trying to work out why that one works but others don't.

There is a an older discussion here (which whilst I don't profess to fully understand looks like it may have some relevance but it may mean something to you)...... https://forum.simflight.com/topic/90224-simconnectdll-location-setting/

Not sure that helps much but at least I hope it was an organised fresh attempt to work out what works and what doesn't.

Gareth

jccolle

OK the connection is correct between the same remote computer (WIN7) and MSFS2020 (WIN10) using my old planG V3.1.4.129.
I use the same port 4506 and the protocol IPV4.
Is it possible to use that in V4.

tim arnot

With MSFS, you need to open the port number that you're using in the FS PC firewall (that's 4504 for jccolle and 4506 for buntings) - make sure you have done that. Instructions are stickied in the main support forum. It could be that it's getting bounced by the firewall and reporting the wrong error. Just a thought.

jccolle, yes you can use the same settings, but you need to have a Simconnect.cfg for v4. Use the instructions for setting up P3D in the main forum - they are now the same for both sims.

Plan-G 32-bit is actually using the FSX SP2 simconnect, so you should be able to connect to FSX with it - another test that might be worth trying.

Tim. @TimArnot

buntings

Thanks for the reply.
The firewall is open here (and likely also for the other user) - it has to be for the V3 software to work (which it does as with both FSX and MSFS as per my findings this morning).

I dont believe its a firewall issue for that reason - and, unless the error message is incorrect, the error suggests some other issue. The error also occurs without any simconfig.cfg file being present on the remote computer - which I am guessing means it would either error or, as seems to happen when run locally, attempts to connect via a pipe? I say this as the latest built that I tested this morning worked happily on the local MSFS computer without any config file.

Whilst I appear not to have noted it in my earlier posting, I did try both the 32 and 64 bit versions connecting remotely to both FSX and MSFS - both produced the same error.  My gut feeling is that all versions are failing long before actually attempting to make the network connection

I will go and double check the 32 bit connection to FSX but I am reasonable sure it failed with the same message (you may recall I tried 218 version week for the reasoning ).

Will report back shortly

Turning into a real mystery this one !  :o