Investigating how to support users and myself to have a seamless SimConnect App (c# App that is) I designed an adapter which can help to get there.
Right now I have a proof of concept which works with both Sim versions.
I’d like to get a community opinion whether or not this makes sense before adding too much work to it.
If you are interested in something that looks about like below:
Adapter to seamlessly use MSFS 2020 and/or 2024 SimConnect
Hides the two versions of SimConnect behind an Adapter
Exposes the MSFS2024 interface of SimConnect
Attaches the respective versions DLLs dynamically when either version of the Sim is in use
Adds a Helper class for SimConnectID management
Adds a Helper class for dissecting the managed SimConnect DLL (finding differences)
Adds a Helper method for message handling
**Let me know it this is worth the effort or if you wish to contribute - also appreciated
As usual I provide my stuff on Github for all to use see:
It’s a good effort but in terms of risk/reward I’m not sure there’s enough advantage over using the stock MSFS dll’s.
Given your accumulated expertise with this it’d definitely be valuable to know the differences between the DLL’s. As far as I can tell with my code the MSFS2020 simconnect DLL seems usable for MSFS2024 with some capabilities simply broken in MSFS2024 due to UI changes in the sim etc rather than some fundamental API change.
Maybe the MSFS2024 simconnect DLL is mostly backwards-compatible with MSFS2020? Not sure, never tried it. So it leaves an issue of which DLL you could use if you want portability & your functionality required is simple enough to use either DLL.
thank you for commenting.
Right now the Facility Lists Records Ident field is the main driver for this effort.
Was 6 char is now 9 and the record classes in c# don’t match anymore.
And with the streaming of facilities rather than getting them once from the BGLs this will be more important than for 2020.
It was also mentioned that 2020 simconnect runs in ‘compatibility’ mode rather than native (whatever that means).
May be it’s only a c# issue with it’s strong typing?
I’d hoped for some more improvements in 2024 which would add more future value to the endeavor…
If the current code I have already works I will try to make my apps to use it and see if I gain something.
And yes the fine print with the UI states and transitions is yet to be discovered
Nice, I’ll have a look. CsSimConnect was my attempt to go a step further and also allow for Prepar3D or even FSX, which required me to actually link to the C SimConnect API due to the radically different namespaces. My experience was that most people stick with the standard, even if you give them something better. Or they just don’t like giving feedback…
I have to admit to being a bit of a monomaniac on this subject. I even made a post to propose a more modern version of SimConnect using modern C++, but for some unfathomable reason, people like juggling with void pointers and weird messaging. I guess modern programming paradigms need getting used to. Asobo is simply too busy with other stuff to bother.
In my humble opinion there is no need for a whole abstraction layer when a few #ifdefs will do the job. I’m not sure people realize the maintenance that an abstraction will require. And that means anyone committing to using the abstraction will now be dependent on that. As B21 said, the risk is high and the benefit is subjective.
SimConnect is already forward compatible meaning that older versions work with newer simulators. The old 32-bit SimConnect from FSX still works to connect to MSFS 20 & 24. You don’t get any new features of the newer versions of course, but the existing functions still work.
So any code using a newer SimConnect, with new functions, already needs to know that it is using a newer library, with new functions, and talking to a newer sim. So, basically worse case, one could wrap that code in an #ifdef that excludes code when being built with an older library version (or that’s one technique, anyway).
Of course the app will probably need other logic as well to do new things with newer sim versions… but that applies to any SDK update when features are introduced, even mid-version (granted that the mandatory game updates currently minimizes this issue).
Even if one wants to switch between MSFS and P3D versions in C#, aliasing namespaces is dead simple, one line of code (wrapped in #ifdefs).
I do basically this exact thing for my “Touch Portal Plugin” (links in profile here) which can be built using either the old “FSX” SimConnect (works with P3D also) or newer MSFS version to take advantage of new features. Linking against the correct DLL is trivial, it’s the actual code changes between the two versions that really matter and take time. The MSFS version also uses another custom client to communicate with my WASM module in the sim (if it is installed), which adds further complication. But there’s no library or other way that would take care of this automagically for me… the code must still be tailored to what you want it to do in each sim version!
SimConnect only “runs” on the simulator side (this is the server) and there is only one version of it in the sim. The remote SimConnect is just a network protocol client (“runs” in your app, if you like). There is no “compatibility mode,” either the client/server exchange valid API messages, or they don’t. If the API protocol were open then we could write our own clients entirely, for example. It’s really just like any other remote access/network-message-based API in that regard.
EDIT: I should probably add, for completeness, that of course the server/sim side may make runtime adjustments to message handling based on protocol version of the current client it is talking to (assuming that’s even part of their API). That’s certainly not uncommon in an API evolving over many years. So I guess that could be thought of as “compatibility mode.”
(And regarding my next reply down, this may be another reason to stick with the older “FS20” SimConnect version when targeting FS20, instead of linking to the FS24 SimConnect.)
Even if it technically works (compiles & runs) now, I wouldn’t use/ship the FS24 (SDK v1.0+) version DLL(s) with code meant for FS20. First off, there’s no reason to, and secondly there is no backwards compatibility guarantee from the developers. Sooner or later it will bite.
While I only consider a .Net c# app for FS2020/24, it may be different when adding the previous FSX, P3D into the mix.
And yes the current SimConnect feature update for FS2024 is rather limited…
The main issue might be the limitation of Facility idents where FS2020 is cutting anything down to 6 chars
It seems it boils down to 3 options
Using FS2020 only
One codebase and one deployed app using FS2020 set of MS DLLs
cannot use FS2024 features
stick with it as long it lasts…
Using compile time distinction
One codebase but two deployed apps using distinct MS DLLs
Allows to use FS2024 features
‘ifdefs’ to be maintained
Using an adapter
One codebase and one deployed app using either of the MS DLLs
Allows to use FS2024 features
Adapter must be maintained
My personal preference would be then
use 1) as long there is no absolute need to use FS2024 features or Ident length screws up.
then use 3) as it provides a better abstraction and less deployment care
eventually leave FS2020 alone and switch 1) to FS2024
But then it’s only me
