Please add JS/HTML/CoherentGT documentation in the SDK, especially best
practices for common patterns like creating extra menus, trapping keys,
registering to all kind of events, with performance considerations.
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](https://devsupport.flightsimulator.com/questions/493/systemcfg-
autopilot-altimeter-altitude-referencing.html) [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.
“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.” Definitely. I think it ties in with this
issue/idea, which not only deals with Lvars/H-events over simconnect, but
making additional data types so communication is more efficient between JS and
C++/C#. Being able to trigger coherent events over SimConnect would be nice as
well. https://devsupport.flightsimulator.com/t/3082
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::
- 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.
- The required methods from BaseInstrument, e.g. Update(), including whether super() should be called
- 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.
- Persisting data between sessions (i.e. Get/SetStoredData)
- Handling events from the ModelBehaviours XML (XML H:events, JS onInteractionEvent() ?
- Handling ‘touch’ events on the gauges (standard JS .on(“click”) ? )
- Reading files in the VFS (XMLHttpRequest?)
- Asobo classes/methods (i.e. interface) that can be used in developer gauges (BaseInstrument, MapInstrument, NetBingMap, SimPlane? etc).
- Coherent.call() methods that can be used, with simple samples e.g. GET_FLIGHTPLAN, when RegisterViewListener is required.
- 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.
I’d like to build a addon for the toolbar. Any idea where I can find
documentation? If there’s no docs, any suggestions of existing code I can look
into?
@SonantAlpaca Hi Alyzée, Hi Eric
@EPellissier It has been 1 year no, so sorry to
remind you guys… but, any chance of some documentation on HTML / JS and
Panel.xml? we really struggle to get things done, we always have to reverse
engineer things based on Asobo offerings but it doesn’t mean we do understand
what we doing because we are pretty much just copying something to obtain a
result without really knowing what it does. For example, panel.xml… we have
nothing explaining what happens there… what the tag, really does, what other
options are available? maybe this could solve issues we find?.. or what does
the tag really does… neither we know any of the possible coherent calls
available to build some solutions, these are just some examples. I am running
now with troubles in Garmin configs… and simply put, I have nothing at my
disposal to help me except raising questions to you guys on this portal, which
only puts more pressure to your team and places me on hold until any help is
possible to be provided (and i understand your team struggles, this is not a
criticism of delays). This is just a feedback and a little reminder, so you
guys don’t forget we still looking forward to see something in the
documentation about how to use this part of the SDK. Wishing you all a
wonderful weekend, Raul
Hello! Just to update on this… SU12 will see the release of the initial
draft of documentation covering HTML/JS/CSS instruments. It’ll be a work in
progress, with some things needing fleshed out still, but it will cover the
entire panel.xml file, as well as the most important methods from the base JS
files (BaseInstruments, coherent, etc…) and the Aircraft Tutorial will have
new sections covering creating simple gauges and debugging them. Hopefully
this will address some of the primary problems people have been having! All
the best!