Idea

Definitely agree - everything we've been doing with HTML/JS gauges has essentially been from looking at the default aircraft, dumping strings from the .EXE to find all the possible coherent calls, etc.

Considering all the included, default aircraft make use of HTML/JS gauges, I'm surprised there hasn't been at least a single page of detailed documentation on them since the launch of the sim, nearly a year ago.

Exactly, the lack of any official documentation on HTML/JS/CoherentGT is particularly puzzling, also considering its relationship with WASM.

Right now, is not very clear if and how WASM will be developed in the future, considering is not used by any default aircraft or system. It's severely limited, because of the sandbox and lack of access to the Windows API. The only thing it can do, is to call Simconnect, the old Gauges API, and the various graphic APIs for gauges. I guess it might be useful to convert existing C++/GDI+ code used in Gauges, but options for Stand-Alone WASM modules are very limited and, in fact, almost all stand-alone WASM modules that has been made so far, are Simconnnect servers to give access to some of the Gauge API to external .EXEs to let them use L: and H: vars, something that shouldn't be necessary, if it were possible to access these through Simconnect directly.

Is WASM there just to ease porting C++/GDI+ code in a reasonable time ? That's fine, and I can fully understand the benefits of JS/HTML/Coherent but in this case, those MUST be documented, if they are really the way forward, long term.

What I would really like to see, is better integration with all these APIs, like C#/C++ connecting with JS/HTML, either through WASM directly, or through Simconnect, in both direction.

My theory is that PMDG and aerosoft had a lot to say on what part of the sdk got developed first, and since they both use WASM (not sure about PMDG but it makes sense if they do) , well asobo made the doc for them.

Definitely agree - everything we've been doing with HTML/JS gauges has essentially been from looking at the default aircraft, dumping strings from the .EXE to find all the possible coherent calls, etc.

100% agree. And without documentation as any sort of reference, copying those ASOBO default aircraft, means that developers are copying any mistakes Asobo may have made in those aircraft, which is going to lead to some major issues when corrections are finally made.

There are whole sections in the SDK, where Simvars have no description, despite them being (one may assume) the same as in FSX or P3D, whose SDK do have descriptions.

Classic Example

[AUTOPILOT]
altimeter_indicator = 2

What does the 2 really refer to ?

In Asobo GA planes, they have altimeter_indicator = 2

But in doing do, that 2 is really (in practice) referring to Altimeter :3, but Asobo and many other developers have ASSUMED the altimeter_indicator = 2 refers to Altimeter 2.

Without some reference SDK Documentations, there is nothing to stop these type of "assumption" from causing issues when Aircraft are developed, by COPYING an incorrect example.

Has Asobo responded at all to anyone with these SDK questions/concerns?

I'm not very comfortable with the developer favoritism process that seems to be happening ... or more precisely, information not being communicated back to the rest of the developer community. We don't need proprietary content, but we do need how to accomplish tasks with accurate documentation and error free samples.

I understand MS/Asobo are under no obligation to do so, but I don't see how that is helpful to the FS platform and other developer relationships that are being exploited in marketing materials?

Cheers, Rob.

I've certainly tried to answer the questions on specific features in the JS SDK as they come up.

That being said, we (MS, Asobo, and WT) are super aware of the totally non-existent JS SDK documentation. In fact, we're discussing that right now. I realize this won't be a very satisfying answer, but the JS side was built alongside the instruments themselves, and as such don't really have documentation internally either. So it's a bit more complex a problem than just a couple samples (although we're looking at getting some of those too).

But providing some docs and samples is high on the priority list and something that is being actively worked on.

-Matt | Working Title

It would be very helpful if CSS/HTML/JS gauge documentation included a templated structure of a reasonably complex gauge using interfaces that would be accepted as 'strategic'. E.g. subclassing BaseInstrument, using onConnectedCallback, Update, Get/SetStoredData, SimVar.Get/SetSimVarValue, handling events from the model XML and 'touch' user interactions. Also we need to know whether/which Asobo gauge classes/methods can be relied upon (MapInstrument? NetBingMap? SimPlane?).

Without guidance I suspect there will be a lot of html/js code which updates everything on every update cycle (as was typical in XML) rather than being a bit smarter and updating the UI only when underlying values have changed.

A subtle advantage of at least a starting set of documentation is it would provide a base against which bugs could be reported. E.g. after 10,000 lines of html/js programming I'm pretty sure there's a bug in the handling of 'H:' custom events from model XML to the JS, but today I can't be sure whether that support is 'non-strategic' and I should have steered clear of it in the first place.

Hello,

Our new documentation website is constantly evolving, and while our tech writer has already done a great job on many various topics, he still has a LOT to do (as the SDK is big ;) ) The HTML/JS/CoherentGT topic has been on his list for quite a while now, but as you may imagine, it's a massive one and we need time to do something good. We'll probably have more time this summer to work on that, so hopefully we'll be able to provide you a lot more information in the upcoming months.

We already added model behaviour documentation on the next update, including the new input events.

Hopefully helpfully... Here's a more structured comment on what 'sections' of SDK html/js docs would be useful::

1. Template for HTML/JS/CSS structure i.e. subclass BaseInstrument, how the JS classname, the CSS file name, the MSFS-generated gauge 'element' type and the JS 'registerInstrument()' call have to interlink.
2. The required methods from BaseInstrument, e.g. Update(), including whether super() should be called
3. Reading/writing SimVars/GameVars/etc (eg. SimVar.GetSimVarValue) including how to do that in a timely/efficient way with the sim e.g. whether a set of simvars can be collected at the same time, how "sim time" can be accurately known for each update cycle.
4. Persisting data between sessions (i.e. Get/SetStoredData)
5. Handling events from the ModelBehaviours XML (XML H:events, JS onInteractionEvent() ?
6. Handling 'touch' events on the gauges (standard JS .on("click") ? )
7. Reading files in the VFS (XMLHttpRequest?)
8. Asobo classes/methods (i.e. interface) that can be used in developer gauges (BaseInstrument, MapInstrument, NetBingMap, SimPlane? etc).
9. Coherent.call() methods that can be used, with simple samples e.g. GET_FLIGHTPLAN, when RegisterViewListener is required.
10. Using the Coherent Debugger.

I would recommend keeping WASM support as a separate thread - html/js programming is complex much higher up the value stack (i.e. how to integrate Bing maps, how to take advantage of Asobo parent instrument classes) where many of the WASM issues for C++ programmers relate to the lack of a Windows executable.

Hello,

We're currently working on this :)

More details to come next year.