till213 / SkyDolly

Sky Dolly connects with Flight Simulator 2020 and records the flight path and basic instruments for replay.
MIT License
79 stars 10 forks source link

Unable to connect 0.17.0 and 0.17.1 to Sim #154

Closed betterpilot closed 3 months ago

betterpilot commented 4 months ago

Describe the bug I am trying to use the new versions 0.17.0 and 0.17.1 on the same computer as I am running my sim on. The legacy versions work great for me but I am unable to get this version to connect.

I checked my Simconnect.xml and reinstalled the Simconnect Library but still cannot get Skydolly to connect.

I have the Extracted Skydolly folder on my desktop and I am running the Skydolly.exe from the folder on my Desktop.

Apologies in advance if this has nothing to do with SkyDolly and something to do with my system setup but I have tried everything I could think of and cannot get the app to function.

till213 commented 4 months ago

Hello,

I saw your comment on flightsim.to and was just about to suggest to raise an issue here on github.com, as it makes it easier to reply and provide further information (with screenshots etc. if necessary).

Indeed, there has been a change in Sky Dolly v0.17 related to how the SimConnect connection is setup: Sky Dolly now properly honours the presense of a SimConnect.cfg client configuration file (to be placed into the Sky Dolly application folder). That is, Sky Dolly now provides a proper "configuration index" (relating to one of the configuration sections of said SimConnect.cfg) as argument when connecting to the flight simulator (MSFS).

Sky Dolly v0.17 now also ships with an example SimConnect.cfg (in the Sky Dolly application directory), providing three configuration sections:

The Sky Dolly application settings - under Flight Simulator - let you chose the connection type:

grafik

Those three connection types refer to the provided SimConnect.cfg configuration sections 0 (default), 1 and 2:

SimConnect.cfg:

# Connection type: "Local (pipe)"
#
# This is the default connection type: MSFS and Sky Dolly run on the same local machine
[SimConnect]
Protocol=Pipe
Port=Custom/SimConnect
Address=127.0.0.1

# Connection type: "Network 1 (IPv4)"
#
# This is the network configuration with IPv4: MSFS and Sky Dolly may run on the same local
# machine (local address 127.0.0.1), or on different machines. In the later case adjust the
# 'Address' with the corresponding IPv4 address of the server (running MSFS).
[SimConnect.1]
Protocol=IPv4
Address=127.0.0.1
Port=500
MaxReceiveSize=41088

# Connection type: "Network 2 (IPv6)"
#
# This is the network configuration with IPv6: MSFS and Sky Dolly may run on the same local
# machine (local address ::1), or on different machines. In the later case adjust the
# 'Address' with the corresponding IPv6 address of the server (running MSFS).
[SimConnect.2]
Protocol=IPv6
Address=::1
Port=500
MaxReceiveSize=41088

These configuration sections should work out of the box with the default SimConnect.xml (= SimConnect "server configuration", where server is the flight simulator, here: MSFS). And when I say default then I mean the SimConnect.xml that is automatically generated in the Microsoft Flight Simulator data folder when not present (or renamed):

Given the fact that you already mentioned SimConnect.xml (attention spelling: capital C! But should not make a big difference on a case-preserving, but not case-sensitive file system) I assume you already know most of this. Also refer to the official documentation here:

To summarise:

All that being said, Sky Dolly is fully "self-contained". Specifically it comes with its own SimConnect.dll (originating from the official MSFS Software Development Kit (SDK)). So there should be no need to "re-install the SimConnect library".

-> But it is theoretically possible that other SimConnect related addons have installed "system-wide" SimConnect configurations (Sky Dolly does not install anything except in its own application directory), such as SimConnect.xml that would -somehow - interfere with the SimConnect.cfg as provided (newly) by Sky Dolly.

In fact, I remember an older issue where one user also could not establish a connection with MSFS: the actual "MSFSSimConnect" plugin (Sky Dolly uses an extendable plugin architecture) did not even load, as the underlying SimConnect.dll reported errors.

Turned out that the original author of that issue once had a SimConnect.xml server configuration somewhere on his system that could not be found anymore (?), and that this was now somehow interfering globally with SimConnect connections. In fact, the original author could not even launch the "Simvar Watcher" example application that comes with the MSFS SDK: the underlying SimConnect.dll simply refused to load ("link"), apparently due to some "global / sytem-wide" mis-configuration.

To be clear: this does not seem to be the same problem in your case: I was just mentioning this issue to illustrate that yes, theoretically it is possible that other "global" configurations interfere now with how Sky Dolly tries to connect with MSFS via SimConnect, especially since Sky Dolly now properly honours existing SimConnect.cfg client configuration files.

What I am just about to do:

Just for the record: I cannot reproduce this problem (I do have some other addons like the Fenix A320 and Flight Recorder etc. installed that also make use of SimConnect - but no addons that install any "global" SimConnect configuration settings, or change the SimConnect.xml in the MSFS data folder, to the best of my knowledge).

So what you can do (already now, but latest with the upcoming v0.17.2):

Let me know how it goes.

till213 commented 4 months ago

Related issue:

https://github.com/till213/SkyDolly/issues/123 ("SkyDolly on Remote PC via SimConnect")

Possibly related:

https://github.com/till213/SkyDolly/issues/12 ("global SimConnect.xml server configuration not found")

betterpilot commented 4 months ago

Thanks for getting back to me.

I had previously tried to delete my SimConnect.cfg in the LocalCache folder so that MSFS would regenerate the .cfg but that did not work for me.

I just renamed the Simconnect.cfg in the Skydolly folder in the newest version and that did the trick and allowed me to connect to the sim in the legacy way.

I am now able to use the new version! Is there any disadvantage to connecting to MSFS in the legacy way versus the way you intended the new version to hook into the sim?

Thanks!

till213 commented 4 months ago

I had previously tried to delete my SimConnect.cfg in the LocalCache folder so that MSFS would regenerate the .cfg but that did not work for me.

It was confusing for me as well, but there are at least three different SimConnect related configuration files: perhaps confusingly all with different syntax (and file suffixes: .cfg, .xml and *.ini).

I will ignore the *.ini configuration file for now (it is documented here).

The two relevant SimConnect configuration files are (to repeat):

So when you said that you "regenerated the .cfg" then you probably meant the server SimConnect.xml source instead. I know, it is confusing ;)

I just renamed the Simconnect.cfg in the Skydolly folder in the newest version and that did the trick and allowed me to connect to the sim in the legacy way.

Okay, so we can conclude that there is indeed "something" interferring with the SimConnect communication as soon as the communication is configured with the SimConnect.cfg client configuration. What "that" is I cannot say (I could only speculate about other "global configurations" defined ("left behind") by other addons.

Because the point is: for as long as you do not change the "connection type" respectively set it to "Local (Pipe)" in the Sky Dolly application settings (= the default value) then the connection should work exactly as before (in Sky Dolly <= v0.16).

Because in this case the first (default) section in the provided SimConnect.cfg should apply:

[SimConnect]
Protocol=Pipe
Port=Custom/SimConnect
Address=127.0.0.1

And this should be the default communication for SimConnect (as if not providing such a configuration at all):

So again, I have no explanation why this configuration could be "messed up". My educated guess would be that - somehow, somewhere - there is another SimConnect.cfg file on your system that magically takes precedence over the SimConnect.cfg provided by Sky Dolly (and located in that very same application directory - so one would expect that this has the highest priority).

Perhaps there are some "environment variables" related to SimConnect that take precedence: but again, I am not such a SimConnect configuration specialist, so I wouldn't know for sure. Well, almost, see my next reply....

I am now able to use the new version! Is there any disadvantage to connecting to MSFS in the legacy way versus the way you intended the new version to hook into the sim?

No, not at all! The irony is: the whole SimConnect.cfg / SimConnectx.xml network configuration has been marked "legacy" by Asobo from the very beginning:

https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/SimConnect_CFG_Definition.htm

IMPORTANT! This section relates to a legacy process intended for use with Microsoft Flight Simulator X. It is still valid for Microsoft Flight Simulator but may be changed or even removed at some time in the future and should only be used for support of legacy add-ons.

It still works, so the only reason why I added support for it was because someone asked for "network support" for Sky Dolly (issue 123). And the only reason why "network support" (respectively the parsing of said SimConnect.cfg) did not work with Sky Dolly was because I initially used a pre-defined "configuration index" parameter (SIMCONNECT_OPEN_CONFIGINDEX_LOCAL = -1) (for no other reason than I saw this one being used in one of the MSFS SDK example applications, and at the time I did not think much about it).

This "configuration index" (that is passed as argument when connecting via SimConnect with the server) essentially prevents the parsing of any SimConnect.cfg that might be around and creates a local (with a "pipe") connection, as outlined above.

So again, with Sky Dolly v0.17 this should still work exactly the same, when setting the "connection type" to "Local (pipe)" (which then corresponds to the zero-th configuration index - counting starts at 0 respectively the section without number is the default ".0"section in the *.cfg).

The difference now (with Sky Dolly v0.17): now I pass an actual "configuration index" value as argument :0, 1 or 2 (or any other possitive number), as per the Sky Dolly application settings ("connection type"). And then any SimConnect.cfg that is found will be parsed accordingly (by the way: this parsing / evaluation is done by SimConnect.dll itself - not by Sky Dolly - when setting up the communication with the server).

What I do now with Sky Dolly v0.17.3: if such a SimConnect.cfg is not found in the Sky Dolly application directory then I fall back to the previous "configuration index", that is SIMCONNECT_OPEN_CONFIGINDEX_LOCAL that has a special value of -1)). And then any configuration will simply be ignored and a local ("pipe") connection will be created.

To summarise:

Again, simply removing the SimConnect.cfg will enforce a local "pipe" connection, and this is the most efficient communication anyway (and the only one that may be working in the future).

You could still try to resolve what might cause the "interference" on your specific installation, but as a software engineer I can tell you that we most often say "oh, it works! Why? Don't know - let's ask this later and put it aside for now...". Not always satisfying - but practical ;)

Anyway, I hope I could give you some insights and possible hints on how to "properly" resolve this. And thank you so much for your donation, very much appreciated!

till213 commented 4 months ago

I will close this issue, as we seem to have found a "working solution". But feel free to ask further questions, or even re-open this issue in case anything else might go wrong (related to this topic).

till213 commented 3 months ago

Note that there was a regression introduced with Sky Dolly v0.17.1 (but not v0.17.0!) which may or may not be related to this issue. Also refer to:

https://github.com/till213/SkyDolly/issues/158