Isn't that maybe a bit too naïeve, users seeing them as integrates from their point of view? A few days ago, I spend an entire evening until 2 AM trying to solve issues related to AES/GSX/SODE/APC conflicts in an effort to get jetways working on 1 or 2 scenereis. With all the different scenereis, I need all of those acronyms to get functioning jetways. It is really unfortunate that I had to spend so much time on these easily avoidable issues, instead of actually completing some flights.
Yes, you are right about SODE, but the only real issue, is caused by developers who choose to use SODE in its initial stage, but haven't updated their sceneries to use the latest version of its SDK. Which really doesn't make any sense, since it's ever *easier* to use, and it surely works better.
The analogy with FSUIPC is not really fair: FSUIPC is for the most part a programming interface and communication intermediate for developers, like simconnect. On the other hand, GSX/SODE/AES/APC are modules that the 1st party interfaces with. From a user experience design viewpoint, the hierarchy Qualitywings-FSUIPC-simulator is the same as GSX/couatl-simconnect-simulator.
First, it's not true that FSUIPC is a developers-only product. There's a large part of it (joystick configuration, for example), which is something users are supposed to use. In fact, it seems to be considered the most valuable part of it, since it requires registration!
In relationship with what we are discussing here, which is the integration with GSX, SODE is EXACTLY like FSUIPC, because we are using it as an API and, the whole point of it, is that user won't have to use the SODE user interface anymore.
Also, fixing one symptom of an underlying fundamental issue does not prevent similar situations occurring again. Now that manipulating and controlling simobjects through simconnect is a rather well known technique (couatl, SODE and APC all seem similar in this), there will doubtfully be more similar modules that will be affected by GSX removing simobjects from view. The root cause of so many different solutions and competing modules trying to do the same thing, using the same methods, without any standardization and causing conflicts, is still present.
What happened is that, along the years, other developers found methods to manage Simobjects using Simconnnect, in a way we were doing since FSX appeared. That's to be expected, with many different motivations, either wanting to offere a free solution, or because another commercial developer didn't want to license our solution that, of course, having benefited from so many years of development and testing, is by far the most powerful.
But that's just nothing we can do to "fix" this, FSX/P3D are open platform with an open SDK, and there's no way a "standardization" as you would like to have will ever happen. This can only be possible on a closed platform, like the upcoming DTG Flight Sim.
So, it's the old conflict between openness and smooth user experience (not unlike IOS vs Android).
If you want a smooth user experience, you must give up some freedom and when flight sim is concerned, users until today ALWAYS voted for freedom and AGAINST a closed platform, and when it was tried, it always ended up in spectacular failures, like MS Flight.
I'm not sure what will happen with DTG Flight School and DTG Flight sim. They surely are taking a big gamble, but the whole point of it, they are trying to find NEW users (at least with Flight School), rather to appease to existing ones.
Taking on the burden of supporting a 3rd party module and technique is difficult when there is no standardization or any form of standards. Also, SODE being in the hands of a sole developer (Jeffery, you are doing a great job, nothing bad about that!) poses the same danger that AES (and the community for many years) suffers from: slow development, limited support, lack of openness, etc.
AES is not a free product, that's a big difference. And it was based almost entirely on low-level hacking instead of Simconnect so, any new version of the sim would require re-hacking it again, that's why development dragged on. But it was also hampered by its own business model: since income only comes by selling credits for supported airports, most of the development time is likely spent on doing these airport customizations.
Once 3rd party developers found other means to add these features (like SODE or Airport Controller), it's normal they wouldn't want to have some scenery features depending on users spending an extra on a product which might be seen outdated now.
