That's my impression, hopefully I'm totally wrong.
Unfortunately, that's my impression too, they don't seem to be very interested to spend too much time on SDK, except maybe for some airplane-related issues, like WASM having performance problems and being too limited in functionality, which clearly is required to bring advanced aircraft add-ons to Xbox.
In general, it seems they have issues with developing things they "inherited" from FSX, like Simconnect. This seems to be confirmed by the mention they want to redesign the Mission system, which is also derived from FSX, and right now the Mission editor is in a basically unusable state, possibly because they tried to design a node-based UI system around the existing system.
This might be read in two different ways, positive or negative:
POSITIVE:
- They really want to refresh the engine with completely new methods and technologies entirely made by the new team, so they could be better supported, and possibly adding new APIs that might be both more modern and better performing than Simconnect, perhaps making letting it go of its ability to run over a network, which has a strong influence of its design, even when it's run on a single machine.
I wanted to believe this, but then I really don't understand why, after more than a year, they still haven't documented ANYTHING of the new Html/Javascript/Coherent method of creating Gauges and add-ons in general, which IS a completely new part of the sim, with nothing in common with FSX and developed entirely by Asobo. The result is, every add-on out there, is based on reverse-engineering of the default airplanes, and too many times this resulted in things being broken by an update, which is understandable, since we still don't have ANY official documentation of an entire (very important and new ), sub-system of the simulator.
NEGATIVE:
- They don't want add-ons doing things too advanced, because they fear this would confuse Xbox and in general Marketplace users, who usually ( I'm trying to not generalize, but this is mostly the case ) prefer an easier experience with simpler add-ons that have less potential for issues.
A worrying indication of this is the very limited usage case for stand-alone WASM modules.
While WASM gauges can do something, stand-alone WASM modules are extremely limited by the sandbox approach, which is really excessive. While I understand, and even agree with, the prohibition to write anything outside a specific folder that is local of the module itself, it's really overkill denying the ability to *read* outside your own package area. What damage can do an add-on accessing other add-ons in read-only mode ? While a WASM Gauge is reasonably expected to find everything it needs in the airplane own package, a Stand-Alone WASM module which, by definition, runs together with the sim, is not very useful if it can't read anything outside its own package.
This would prevent creating ANY kind of add-on that needs to read (for example), the airport database. Yes, of course, we managed to do that with GSX for MSFS anyway, because we have the Couatl executable, which runs external to the sim, so it can read all airports (except the encrypted ones), but it means these add-on will never by sold on the Marketplace, and will never work on Xbox. We would need to rewrite Couatl as a Wasm module but then, it won't be able to do much, with no access whatsoever outside its own package. We asked long ago for an official API to read the airport database without having to reverse-engineer the .BGL format and wouldn't require any file access to begin with, this is currently one of the most voted SDK proposal, but nobody knows IF and WHEN this new API will come, if ever. Not having this API, will make sceneries bought on the Marketplace to be second-class citizens, because their data can't be read by add-ons. Not just GSX, of course, Flight planners need to read the airport database, for example.
Right now, the ONLY usage case developers have been using stand-alone WASM modules, is to act as Simconnect servers to external .EXE Simconnect clients JUST to give back data which is not normally available through Simconnect, like L:, H: or B: vars and events. With the result that everybody ( and his dog too ), reinvented the same wheel over and over, so now we have several of WASM modules, ALL loaded at start, ALL taking away previous CPU time to the Main Thread, ALL doing the same thing, which could have been easily avoided IF there was a way to get those variable directly through Simconnect OR the stand-alone WASM weren't so limited, so they could be used to do more, instead of acting as dumb slaves to external .EXE which, being external, can do anything they want. Again, an API to get access to these new variables is also one of the top voted SDK request, but nobody has any idea IF and WHEN this API will come, if ever.
So yes, my impression was more negative than positive, we can only hope they'll come up with something new/better/safer to replace the old stuff which, even if it's "old", allowed very complex add-ons.
