plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.

Please take a moment to read the platform’s guidelines before you get started!

Idea

virtuali avatar image
virtuali suggested B21 edited

Add JS/HTML documentation to the SDK

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.

defaultdocumentationhtmlgauges
10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

IcemanFBW avatar image
IcemanFBW commented

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.

10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

virtuali avatar image
virtuali commented

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.

1 comment
10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

"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/idea/264/support-strings-and-structs-in-lvars-and-allow-rea.html?childToView=616#comment-616

3 Likes 3 ·
Noga avatar image
Noga commented

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.

10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

N6722C avatar image
N6722C commented N6722C edited

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.









10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

SimHorizon avatar image
SimHorizon commented

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.

10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

mattnischan avatar image
mattnischan commented mattnischan edited

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

10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

B21 avatar image
B21 commented B21 edited

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.

10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

SonantAlpaca avatar image
SonantAlpaca commented

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.


10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

B21 avatar image
B21 commented B21 edited

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.

10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Write a Comment

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Your Opinion Counts

Share your great idea, or help out by voting for other people's ideas.

Related Ideas