Bug description: With the new managed SimConnect DLL file the structure of the SIMCONNECT_SIMOBJECT_TYPE enum was changed compared to the 2020 DLL. At the moment you can see this change only when opening the file in Visual Studio because the Documenation still shows the old format.
In the new DLL the HOT_AIR_BALLON was added. Adding this between existing elements makes the new DLL not backwards compatible with the old Simulator, such a major change should be part of the Doumentation. When checking the documentation for the Type it still shows the old enum:
But seriously, who does this kind of thing to an API? Why stick a new value there, because it also starts with “H”? Ridiculous. It’s practically deliberate sabotage, quite frankly. Or an intern’s mistake.
Apologies for this, we didnt’ spot this insertion in the enum prior to shipping…
We are currently assessing the damage and will probably revert to the original enum in the mid-December patch.
thanks Eric for the feedback hopefully there will be not to much damage and you can revert back. The dynamic loading of the DLL works for now as a workaround.
Note, I don’t believe it’s necessary to revert this, just to make the hot air balloon at the end of the enum so it’s basically value 6, the problem is more that adding it mid enum breaks compatibility with anything built with the 2020 SDK that uses the last couple values (e.g. ground is now 6 instead of 5, so ends up being a request for boats instead.)
And of course make the documentation reflect that change for 2024 =)
Well, you can somewhat inefficiently just request ‘all’ objects and filter the results for what you actually wanted. This will work fine in both sims (and is what I did, but I only need that data at singular set points, YMMV).
The errant insertion of the hot air balloon in that enum only skewed boat and ground equipment as indexes really… and the only one you can’t just choose a different index for if it’s FS24 (and you use the 20 SDK/dll) is thus ground equipment…
but you suggested your issue is with something else, so I can’t judge without knowing what (similar) issue you’re encountering.
I’m using the latest available now, looks like it’s 1.1.2 - but I’m still getting only garbage data back from 2020 with calls to RequestFacilitiesList_EX1 or SubscribeToFacilities_EX1. I’m using the managed API.
So for 2020, are we expected to hotswap the DLL? My users can choose which sim version they’re on. The call works OK in 2024.
I’m not sure what this has to do with SIMCONNECT_SIMOBJECT_TYPE but you shouldn’t use FS24 SDK DLLs with FS20. The other way should * work (older SDK to newer sim, minus any FS24-specific features), but SimConnect is not (and has never been) backwards compatible.
-Max
* The change that was being discussed here broke forward compatibility, meaning older SDK working with newer sim, which was the biggest issue.
I pasted the wrong thing, but got it! I guess I need to do a copy of the right set of DLLs over. I thought they were backwards compatible. Not sure if that’s noted in the docs.
But that means in my code, I should reference 2020? It 2024? Maybe 2024, but feels like it might be tricky, but maybe good enough to have runtime flags around any new APIs or runs being used.
@nabeel Really depends on how big of a difference you need for FS24. If it’s just the new HOT_AIR_BALLON enum value, for example, you can also just “fake” it (eg. SIMCONNECT_SIMOBJECT_TYPE.GROUND + 1 and keep using FS20 SimConnect. Any new Key Events or Sim Vars will work just fine with the older SimConnect. If you actually need new SimConnect functions, then those would could to be behind some #if DEF ... #endif blocks (where DEF is defined at build time if FS24 SimConnect is being linked), for example, and you’ll need to distribute separate versions of your app for FS20 and 24.
This topic has been automatically closed after 60 days of inactivity since it was marked as fixed.
If there is important new information about this same report, you can use the “Request reopen” button below to ask the moderation team to review it again.
For other issues or broader discussion, please open a new topic in the appropriate category.
hopefully there will be not to much damage and you can revert back. The dynamic loading of the DLL works for now as a workaround.