What is the best way to make custom-made html gauges?

Hi everyone, can anyone share how to create html gauges for msfs?

Thank you.

The getting started guide for the avionics framework is a good place to begin: MSFS Avionics Framework | MSFS Avionics Frameworks and Instruments

1 Like

I have to say I’m less enthusiastic about jumping into a complex 3rd-party framework to build a basic html/js gauge as learning the basics of the MSFS gauge system seems a better place to start.

Alternatively download a freeware plane with existing simple HTML gauges, e.g. my LS4 glider on flightsim.to and try copying/editting the html_ui path to a SINGLE gauge (e.g. the clock) into your package plus the entry in panel.cfg, and get that working. To update the layout.json each time you add files use MSFSLayoutGenerator.

It’s likely you’ll struggle with this as you try to get to grips with how the few bits of MSFS connect with each other (in-model writeable textures, panel.cfg, the html, css and js), but that’s the important part. Starting with a 3rd-party utility which follows the web trend of adding tens of thousands of lines of Javascript to what otherwise would be pretty simple web content is a popular web-dev theme but I’d question it’s value in MSFS.


There is a page by Asobo here that nicely documents how to build a gauge: JavaScript

It’s a pretty good explanation of the concepts and connections, and doesn’t rely on npm or typescript. For a larger project, using a code packing tool (like webpack or rollup) will make it much easier to manage a large codebase and also deal with language versioning. But if your goal is to make a little custom timer or clock, it may be a bigger learning curve and a lot of new problems for an isolated task.

1 Like

Also don’t forget to check out the Coherent GT Debugger. It’s in your MSFS SDK Folder under Tools. It’s a great resource to use. I use it to find bugs and to reload Javascript without having to restart a flight every time you update your code.


This video also helped me a lot in understanding some of the puzzle pieces. (There are lots of puzzle pieces to sort out)

I actually got my first gauge to work by looking at the FLAPS Gauge in the AS33me glider. (Thanks @B21 )

Another thing that can make you lose a lot of hair is remembering to update your layout.json file when you make changes or add files to your project. I use the SDK to rebuild the Package, so it’s less of a problem, but if you edit the gauges’ files manually and add images for example, if you do not add the file names in the layout.json file, the Sim engine does not see them.


Thank you all. Great sources. It’s great.

I started on the same path some months ago. Although I like structured learning and structured working, the path is at times quite chaotic. Looking back I think the best starting point for me was the tutorial in the SDK called “Creating An HTML/JS/CSS Instrument”. It is based on the sample DA62 and it brings you to a point where you can create a “Hello World” gauge using the most basic HTML, JS and CSS. In parallel I am learning JavaScript via W3Schools. At first I thought I had enough general coding knowledge to understand JavaScript, but I did not. I am using the sample DA62 project with the “Hello World” gauge to try the things I learn at W3Schools. In most cases you cannot simple copy the W3School examples, but that is the point. You learn how to code these examples in the MSFS environment. I discovered that the html page as such is very, very limited in it’s functionality. The functionality is exported from the JavaScript and inserted into the html page. At the moment I have one addon in use for the Latecoere. This addon is accessible from the ingame menubar at the top of the screen and it makes the flying of the Latecoere a bit smoother. The addon is on a simvar watcher level with some calculations and if statments.

1 Like

The framework was created by us at WT, a first party on MSFS, and intended to be a primary starting point for creating instruments in the sim. We didn’t create the framework because we’re hooked on some theoretical JS fashion sense, but because we wanted to allow developers to get started quickly as well as avoid the many many performance pitfalls that come with manually building vanilla JS. The framework is built specifically for performance while allowing developers to use paradigms they’re already familiar with in other frameworks (React and JSX) to get started quickly and easily. Furthermore, the framework, being built on JSX, promotes high quality code encapsulation by keeping components easily separated and composable.

Being built with performance first in mind, the framework steers the developer towards low-overhead, low-garbage paradigms, and unlike other web frameworks that are like it does not at all use shadow DOM or a reconciliation loop, again keeping the garbage load as small as vanilla JS while keeping the user out of slow, brittle code that uses string based selectors that can easily break when page structure changes or forcing users to use hundreds of lines of createElement() or createElementNS(); instead you get to use hard refs that break at compile time instead of runtime and JSX that syntax highlights in every JS IDE. On top of that you get a huge amount of compile time type safety through TypeScript.

As I’m sure you are no doubt aware, modern web tooling does not include code that does not get used. So if you only use the very framework basics for rendering, you’re not going to get 10,000 lines of extra code or anything near that. We highly recommend using the MSFS Avionics Framework over attempting to re-invent the wheel in vanilla JS.