Avionics seem to use Coherent (HTML + JS), Asobo should open source them

I was looking at some other threads and it looks like Asobo chose to use Coherent to render the avionics UI. Coherent uses the standard web stack of HTML + CSS + JS to build the UI. Given the avionics UI issues in the initial release, this is great news because it means fixes should take less development time than using proprietary frameworks or lower-level development.

But I think a potentially game-changing move would be for Asobo to release the source code for the avionics on GitHub. Microsoft has fully embraced open source and there are a ton of web developers out there playing this game who would be interested. The community could fix these issues faster and ultimately end up with the most accurate avionics simulations anywhere. Asobo can still maintain the quality of the codebase.

There’s no good strategic reason for Asobo to keep these proprietary, since it’s not portable to other sims given the unique API endpoints. The only tricky part would be Coherent and their ability to provide tools to visualize the changes.

10 Likes

I think this is very likely to happen at some point, or at least I hope so.

Most of the source code is already accessible see the .html/.js/.xml files in the asobo-vcockpits-* packages.

3 Likes

I believe you can mod the avionics now. All these files (html, css and js) are available and easy to edit.

2 Likes

Oh, that’s awesome! I’ll check it out.

So this is even closer than I thought. Asobo just needs to setup the GitHub, set the licensing and contribution terms, and manage the pull requests. It would be a huge boon to the default experience and relieve some pressure on them, since right now the G1000 visuals alone are incorrect in arbitrary ways.

1 Like

How do we interface and start js functions that controls the instrumts?

I’ve been digging through that but it is not easy to figure it out due to things being scatter in multiple files. There is a section about that in the SDK, it is marked as TODO, so I am sure they will add more documentation about that in the future.

This is what I have been able to figure out so far:

The panel.cfg file defines the entry point for the html gauge, e.g.:

...
 [VCockpit01]
size_mm             = 512,79
pixel_size          = 512,79
texture             = $ADF_Screen
htmlgauge00=Generic/Radios/KR87/KR87.html,          0,0,512,79
...

The html file defines the layout. There is also a .css file that define the style (colors, fonts, etc.). At the end of the html there are one or more js scripts included

<script type="text/html" id="KR87">
    <div id="Mainframe">
        <div id="Electricity" state="off">
            <div id="AdfPanel">
                <div id="ANTModeAnnunc"></div>
                <div id="ADFModeAnnunc"></div>
                <div id="FRQ">
                    <div id="InUseFrequency"></div>
                </div>
 ...
<link rel="stylesheet" href="KR87.css" />
<script type="text/html" import-script="/Pages/VCockpit/Instruments/Generic/Radios/KR87/KR87.js"></script>

The js file defines a new class for the instrument which extends BaseInstrument and then it registers it with the sim with the registerInstrument function:

registerInstrument("kr87-element", KR87); 

The basic methods / callbacks that needs to be implemented by the class are:

class KR87 extends BaseInstrument {
...
  connectedCallback() {
  ...
  }
  disconnectedCallback() {
  ...
  }
  onInteractionEvent(_args) {
  ...
  }  
  Update() {
  ...
  }
}

Update() seems to be called whenever a new frame needs be to draw and for simple instruments it is as simple as updating the html elements with data from simvars (e.g. frequency, time, etc.).

The tricky one is onInteractionEvent which seems to deal with user interactions like button pushes, turning knobs, etc. The interaction model seems to be specified in XML files that also describes the various events that are send to this callback:

<UseTemplate Name="ASOBO_Button_ADF_ID_Template">
  <BUTTON_ID>ADF</BUTTON_ID>
  <HTML_EVENT>adf_AntAdf</HTML_EVENT>
  <TOOLTIPID>TT:COCKPIT.TOOLTIPS.ADF_BUTTON_ADF</TOOLTIPID>
</UseTemplate>

onInteractionEvent(_args) {
        if (_args[0] == "adf_AntAdf") {
            this.AntMode = !this.AntMode;
        }

Some events seems to be handled directly via XML, very similar if not the same with how FSX does it (from what I have read online, I don’t have any experience with FSX development):

<UseTemplate Name="ASOBO_GT_Knob_Finite_Simvar">
        <ANIM_SIMVAR>ADF VOLUME:1</ANIM_SIMVAR>
        <ANIM_SIMVAR_UNITS>Percent</ANIM_SIMVAR_UNITS
        <CLOCKWISE_CODE(&gt;K:ADF_VOLUME_INC)</CLOCKWISE_CODE>
        <ANTICLOCKWISE_CODE(&gt;K:ADF_VOLUME_DEC)</ANTICLOCKWISE_CODE>
</UseTemplate>
5 Likes

Thanks for this info. I am specially interested in how to interface and send commands to emulate button presses from a C++ application I am developing.

Are you developing an instrument using the C++ / WASM interface and want to receive user interaction events? Or do you want to send events from a C++ application outside of the simulator?

If the former, I think you can use the register_key_event_handler function documented in the SDK. You can listen for standard events defined in the sim and also for custom one, see gauges.h in the SDK:

// Third parties can use custom events in this range to communicate between 3D VC's and 2D C++ gauges.
#define THIRD_PARTY_EVENT_ID_MIN                0x00011000
#define THIRD_PARTY_EVENT_ID_MAX                0x0001FFFF 

If the later, you can use simconnect APIs, see the SDK documentation for the available events.

Ohhh thanks for the breakdown @GastricBoat5584 !

Going to come in handy when I start coding the EFIS INTEGRA TL-6524

1 Like

The problem with using Simconnect is that not all Events are available. Many of the switches, buttons, rotaries are using locally defined events that only exists in the Javascripts. I use Simconnect for those that are reachable and they work OK. One example of buttons that I need to have access to and only exist the Javascripts are the CDU buttons for the B747 and B787.

OK, so I have dug deeper and looked at a couple of knobs in the C172 (classic not g1000): the volume knob and the com/vloc knob.

If you are using simconnect to try and drive the those knobs you will notice that you can do it for the volume knob (with the COM1_VOLUME_INC and COM1_VOLUME_DEC events or with the COM VOLUME:1 variable) and by that I mean the animation will show as well as the volume will be modified. However, even though you can change the frequency the COM/NAV knob will not animate.

The good news is that in both cases the mechanism driving the animation / interaction is based on a simvar, however in the case of the volume knob the global A:COM VOLUME:1 variable is used, while in the case of the frequency knob the O:_KnobAnimVar component (AS530_KNOB_MHZ_1_1) variable is used.

So, as along as we will have the option to access component variables through simconnect it should be possible to interact remotely with everything in the cockpit.

Note that there is a “model behaviour” tool in the devmode windows menu, that allows you to inspect the behaviour model in great detail.

Model behaviour for the AS 530 NAV/COM knob

2 Likes

This is how it is done in FSX/P3D currently.

SimConnect is junk, and all my code avoids it.

How do you then interface the sim code?

Are you able to display the live G1000 in a browser window or externally?
I know you can pop-out the displays in the sim, but my touch screen monitor doesn’t interact with it properly. I’m curious if I can open it up in chrome while the sim is running or something.
Excuse my ignorance or stupidity.

No, it will not be possible to display the live G1000 in a browser window. The game runs its own internal browser engine that shares state with the rest of the game through simvars and simevents.

However, it opens up the possibility of an emulator / developer mode that runs in an external browser, with the sim events and vars emulated instead of picked up from the game. That would make development and debugging much faster and it would attract more contributors. And when combined with a browser gltf rendered (e.g. babylonjs) it could create a complete cockpit development environment.

And the awesome thing is that, due to the design choices and focused on standard technologies made by Asobo, this kind of simulator can (probably) be fully built by the community.

BTW, does anyone who has the steam version can look at the fs-base-ui package data that come with the updater? I can’t read the files in that package due to ms store protections, and I am curious to look in some of JS files in that package.

1 Like

Coherent GT can be a little more complex than that. You can also make direct calls into the engine from JS as well as from C++ into the JS. It looks to me like the base nav display on which all the displays are based (the G1000, the big jet MFDs, etc) call into the engine with each update tick to grab the nearest navdata to add it to the collection of SVG elements to place. That code in particular looked like it could use some love.

Like yourself, I got as far as I could without being able to access the base nav JS.

1 Like

I was messing around with those Garmins and holy I really see the potential of this being correctly open sourced by MS. Not sure if they will, as they seem to have it licensed with Garmin, but in all cases this will certainly be modded by the community.

BTW if someone find a way to reload the JS at runtime, send me a DM.

2 Likes

The quickest way I found is the enable devmode and reload the aircraft. It takes about 10s, so it is not that bad.

Doesn’t seem to reload the JS, only HTML/CSS (and it seems that it also does some caching sometimes which is weird), maybe I missed something, I’ll try again.

Ah, you are probably right, I just tested with CSS/HTML and I thought it applies to JS as well.

1 Like