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.
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.