How to build your own HTML Gauges documentation

Hello, Are we going to get any documentation or tutorials about how to build
custom HTML panel gauges?
currently the only way forward is to try to
reverse engineer Asobo default panels… which is incredibly super time
consuming… In addition, how are we supposed to debug any custom HTML panel
while on development?
I tried doing a simple gauge and:

  1. Had to reload the aircraft every-time I changed the code (HTML or JS) to see if it worked.
  2. The build package console doesn’t show any usefull information if you have a issue inside the JS code.
  3. I had no way to debug correctly (variables, errors or anything) besides putting a string on the gauge $texture to see to which line I was running.

The issues above slows down development times massively… and also increases
development costs obviusly… So it makes me wonder how is it Asobo managed to
build such complicated gauges as the G1000 with the current tools available
via the SDK… Thanks in advance, Simbol

Hi Simbol, I hope you already voted the Idea I posted here:
https://devsupport.flightsimulator.com/t/3153 Voting is surely the best way
for the issue to get traction. About debugging, have a look at the CoherentGT
Debugger found in the Tools folder or the SDK. It’s easy enough to use and,
for more documentation, you can check the Safari debugger documentation on
Apple site, since the debugger is based on Webkit, which powers Safari too:
<Safari Developer Help - Apple Support
devd24689f72/mac> Yes, you can trigger a reload of an Html/JS gauge while the
airplane is running, place breakpoints, inspect variables, inspect the DOM,
etc. But while this is a big help for debugging your code, I think it’s not a
replacement for a proper HTML/JS/Coherent documentation, which I think right
now is the biggest missing feature in the SDK.

Hi Umberto, Thanks for the tips about debugging… I will have a look to see if
this helps… and I voted your proposal for documentation… I think this is
really need it… specially when you want to develop custom panels to replicate
real world behaviours, etc. Regards, Raul

Its the standard Coherent Debugger, so is fully documented by Coherent - and
it looks likek most of that documentation is freely available from the
Coherent website. <https://coherent-labs.com/Documentation/cpp-
gt/dd/d68/debugging.html> Currently, it looks like the UI is a little “messed
up” with some text overwriting other text and the click spots being a little
out in places, but it is quite usable.

Thank you both… so the only question that remains is about the internal MSFS
HTML panel gauge documentation so we get a better understanding about how it
works. Regards, R.

Ok I used the Coherent Debugger, it helps to see what is going on to a certain
extend but several issues remain. For example, I updated JavaScript modules
and these would not reload unless an “aircraft resync” was issued from inside
MSFS… so the process / workflow to develop custom HMTL gauges is still
extremely slow.
Clearly Asobo is using Coherent to develop their panels,
which by the looks on the Coherent website looks great and really easy to
use… But the question is how 3rd party devs can achieve the same results?
currently we are unable to use Coherent GUI interfaces do custom panels… all
we have is a debugger, we end up having to use just standard HMTL + JavaScript
editors, force to resync airplane everytime we change a JS so the debugger
really loads the change to the library / code and inspecting Asobo current
instruments to reverse engineer wherever we can… this is far from optimal.
Surely I must be doing something wrong right? it can’t be this hard… Regards,
S.

Asobo actually doesn’t use a GUI to develop the panels, they also use a
standard IDE (in this case Visual Studio). We here at Working Title use VS
Code for all our development. The Coherent GUI is not really a WYSIWYG thing
so much, and in any case developing a panel that way would be unlikely to
deliver adequate performance. You should be able to refresh your panel after
updating your code from the Coherent debugger. Just click on the reload button
in the upper left area underneath the address bar. You can also force it to
ignore the JS cache by refreshing with Ctrl + Shift + R.

1 Like

Hi Matt, Thanks,I clicked the refresh of course, the html part got reloaded
but the JS never does… unless I force an aircraft reload. I will try the Ctrl

  • Shit + R and see… Would it be posible to have a sample project or
    documentation regarding how set for VS to work / created custom HTML panels
    with instructions of how to link this to MSFS the way you and Asobo do it
    then? As you must appreciate we are really working in the dark here… causing
    s lot of mistakes and bad workflows that will inevitable not only increase
    developing time and cost but also reduce the quality of products delivered.

There isn’t a link to MSFS in the way I think you’re thinking of it. VS and
VS Code don’t directly talk to the sim at all. With JS and HTML, there isn’t
anything to build, so the projects are just bare folders. The process is
really just to copy the JS and HTML to the output, and then reload in the
debugger. Was there something else you meant when you were referring to a VS
and/or VS Code project?

Coherent only works with Safari version 11 or higher? This thread is
confusing, it seems Raul is having a conversation with someone who’s elected
to not be public in a public forum? Not very useful helpful to anyone else
that might be interested in this aspect of development for MSFS. Cheers, Rob.

Hi Rob, Yes Mat from working title has been responding to me, I was not aware
they were not public… odd! Some of my post are going to moderation for some
weird configuration as well. That could be also the cause for some comments
not being linear, etc. R.

@SimHorizon, Are you not able to see my comments to @Simbol below? -Matt |
Working Title

Hi Matt, First, CTRL + Shit + R worked. So many thanks for that. Second, I am
looking for the best workflow posible to minimize developing time + developing
costs. In my mind I am thinking Asobo / WK must have a development environment
much more efficient so a gauge with all the SVG layout, etc. can be prepared /
tested prior loading the sim. Otherwise developing a complex panel such as the
G3000 by copying JS + HTML and using a debugger only would take several months
surely, maybe years. So is there a way to configure VS for better flow? can we
buy CoherentGT to do things better? Regards, Raul

We all don’t have any other development workflow, no. Just like normal webdev,
you will need to refresh the page when you make changes. We haven’t found that
particularly limiting, especially when compared to the C++/WASM workflow.
Being able to hot reload changes saves a ton of time. If you have specific
elements you want to build, sometimes we will do that in a SVG path editing
tool or use jsFiddle, then drop it in. Creating something complex like the
G3000 to a high level, is probably not reasonable in less than 6-12 person-
months minimum, regardless of framework or language.

Hello Simbol, The documentation about HTML gauges is our top priority. I can’t
tell when it’s fully available but you will definitely have something to start
with in the next few months. Regards, Sylvain

Hi Sylvian, Many thanks for coming back on this. Can I please suggest you guys
document how Asobo developers are managing to achieve such complex gauges?
Although I appreciate Matt (Working title) input as he knows a lot about this
area, I find it very difficult to believe Asobo is not taking much more
advantage of coherent UI in order to minimise cost and developing time. So
ideally I would like to see a workflow sample used by Asobo, if I have to buy
a license of coherent UI, then so be it., as you must appreciate workflow and
dev speed is extremely important for DLC content providers. Simbol

Hi Simbol, As I mentioned before, neither Asobo nor we have any alternative
workflow to provide. Both the Asobo and Working Title HTML/JS projects are
built using a standard gulp workflow to do Typescript and SCSS compilation and
then copy to the destination. There is no connection between the IDE and the
sim or Coherent, nor is there any GUI based editor in use with either team.
Indeed all that you see in the sim was hand-coded. We can certainly provide
some sample gulp scripts, but those will only be of use if you have compile
steps, which not all projects will. -Matt | Working Title

Hi Matt, Well at least there is a workflow… this is the first time you
mention gulp… this is the entire problem… we have no idea how to do
anything. hence my suggestion to Sylvian to push the documentation with an
example of a workflow used by Asobo to built complex gauges. Maybe a new
workflow can be implemented? Microsoft gets better benefits if 3rd party DLC
content providers can built really complex gauges in a shorter period of time.
Failing to do so, result is what we see lately, 777 using 747 panels, E175
using Garmin gauges, etc. We need help, better tools / ways to work.

I definitely understand the frustration here, but the workflow I describe is
not specific to MSFS development. Gulp, grunt, webpack, rollup, etc, could all
be used depending on the specific way you want to develop the gauges and your
webdev tool/language choices. There are a large number of great resources out
there for setting up web dev build systems (only needed if you aren’t using
vanilla JS). The web dev space is already rife with tools; I don’t know what
we could really bring to the table here. We will consider the feedback though!
-Matt | Working Title

We cannot adopt any **effective **workflow without having an understanding
of how Asobo designed and integrated Coherent into their video game engine.
The question to Asobo is very simple really, what is the best workflow to
design complex HTML / JS / Coherent panels with Microsoft Flight Simulator.
Currently is extremely slow and very hard to do them, resulting in a very
expensive cost to develop such panels and it is the reason why so many 3rd
party developers are just giving up and not even attempting to build the
correct panels for their aircraft. This is not good for anybody… S.