SDK Avionics Road Map / AAU1

Questions & Community Discussions Aircraft
1

Dear Asobo, I have been testing AAU1 for a while now, and I am noticing how
MSFS is making the Working Title units as default for most airplanes. With
this move of course the expectation from our customers is to follow the same
example and do the same for our products, therefore I am wondering if there is
some planning to absorb these units as part of the main MSFS SDK and what can
be done or designed to integrate them better to our products. For example one
of the biggest issues we face is the lack of extensive documentation about how
to integrate these units to our projects, such as, how to configure the
behaviour files, panel.cfg, panel.xml, etc. In addition if I am not mistaken
(since no enough documentation is available at this time) the autopilot is
also configured differently and it doesn’t follow the settings we write in
system.cfg, so how we configure the AP? Another big change seems to be how we
configure the Engine sections in the panel.xml, with AAU1 and inspecting the
TBM for the G3000 unit, I can see a big shift from how we do things currently,
for example, with Asobo units we normally just put a gauge xml tag like this:

      1.   2.             DoubleVertical
  3.             Turbo_FuelGauge
  4.             
  5.             LBS
  6.             0
  7.             580
  8.             
  9.             
  10.                 
  11.                      name="L:FSR_M500_FUEL_LEFT_QUANTITY" unit="number"/>
  12.                      name="FUEL WEIGHT PER GALLON" unit="pounds"/>
  13.                 
  14.             
  15.             
  16.                 
  17.                      name="L:FSR_M500_FUEL_RIGHT_QUANTITY" unit="gallons"/>
  18.                      name="FUEL WEIGHT PER GALLON" unit="pounds"/>
  19.                 
  20.             
  21.             
  22.                 red
  23.                 0
  24.             
  25.             
  26.                 red
  27.                 0
  28.                 25
  29.             
  30.              text="True">100
  31.             
  32.

This is very easy to do, quick and easy to understand. Whereas the TBM
panel.xml under AAU1 has a link to JavaScript files and the engine gauges are
writing in pure JavaScript format, taking several lines of code:

1234×653 179 KB

1233×667 384 KB
This is incredible powerful for
sure, but at the same time much harder and difficult to implement, especially
without any documentation or easy examples available for 3rd party developers.
But perhaps we still can use the old method + this method? Is hard to know at
this stage and in hence why I raise the question about what are the plans for
the future of avionics in terms of the SDK, it would be great if everything we
need to develop airplanes comes directly from the MSFS SDK installer,
alongside with documentation, examples, etc. Kind Regards, Raul Morales

2

Very well written explanation of the issue at hand here, kudos. This issue
continues a trend that I’ve noticed over the last year where additions and
improvements to the simulator seem to be largely internally driven without any
meaningful input or feedback from the 3rd party community. With proper
documentation and examples being left until the very last, we are often left
scrambling to adapt to new changes. Extremely frustrating, to say the least.

3

At first look at the TBM code, this does look very powerful, however I agree
with Raul, that the documentation is lacking. Who is the owner of this “SDK”
Working Title? or ASOBO? Microsoft? and hence accountable for providing it? WT
is doing amazing work, but the avionics sdk lacks the updated documentation
and samples. The section “Interacting with MSFS” needs to be expanded. More
info on AutoPilot, Electrical, Fuel, Failures, Engine monitoring/display It
seems now that using the glass cockpits is our 3rd part dev aircraft, requires
the dev to learn javascript, typescript, JSX, the WT avionics sdk and the
coherent debugger. OK, I’ll learn js, TS JSX and the coherent debugger, help
me with the WT avionics SDK. I like the suggestion of the old method and new
in combination. I was hoping that the panel.xml method would be
expanded/updated/documented. My problem is my aircraft projects use the older
2006 version of the Garmin G1000, G500 so do I pretend to update the old
aircraft with a new G1000 Nxi or try to remove some Nxi features to emulate
the original equipment version of the G1000. Ya, that’s my problem, but was
hoping to use panel.xml to work around that. ASOBO is not in charge of what WT
does, assuming WT works directly for MS. Not sure what influence ASOBO has in
this documentation issue.

4

We do plan to add documentation for the G3000 plugin system, and there is
already documentation for the Avionics Framework. However, due to the nature
of the avionics being in beta we actively discourage folks from trying to
write against things that are still moving targets. Once the avionics are out
of beta, we will release plugin documentation in the following weeks.
Unfortunately, due to the complexity of all known G3000 and G5000 EIS
installations, it was simply impossible to expand the panel.xml to be
expressive enough to create all the required elements, which differ in layout
and style significantly across installations. As such, the new G3000 will not
support EIS definitions through that method. However, the upside is that the
expressiveness available via JS allows for more or less whatever an aircraft
developer needs.

5

Thank-you, but I believe your G3000 explanation is for
@Simbol, but I will interested in the G3000 later.
Does this preclude that panel.xml will not have updated functionality for the
G1000? Forcing devs to learn JS/TS JSX will add a huge layer of complexity to
glass cockpits. This will force devs to spend a lot more time providing these
add features that are in high demand for “immersion”. Can your team not
provide some documentation for the avionics sdk. The “Here how to access a
simvar” is a very basic piece of info. I’m hoping for a detailed DA62 like
sample. Describe the G1000 in high detail for parts of the features, COM NAV
Airspeed Altitude Autopilot Electrical HSI for PFD as a start surely that is
not changing. Hoping any other devs here feel that the barrier to them
providing aircraft with glass cockpits is more difficult, not less difficult,
will speak up and ask for a more simpler way to add aircraft specific display
pages like the engine display. Get ready for the $95 GA plane with a glass
cockpit people. To: MS/ASOBO - Devs will be asking for JS code obfuscation to
guard their hard work now. (JS obfuscation works, but will it be allowed for
in MS Marketplace aircraft?)

6

We have no intention of removing panel.xml support (and indeed have not
removed it) from the G1000, since the elements available in the G1000 are much
simpler and have a fixed number of layouts. The G3000 is a totally different
beast altogether. We will not be documenting in detail each piece of the G1000
itself, which is not part of the Avionics Framework. If you would like to fork
the G1000 code, that is supported insofar as the code is available for you to
do that, but attempting to document the inner workings of the instrument
itself outside of the plugin system is well beyond the intended scope. On the
subject of developer accessibility, we feel that while RPN and RPN-like XML
subjectively feel familiar to developers already inside the niche MSFS
community, as a whole using more commonly available languages, paradigms, and
stacks with modern debugging capabilities (like is done with the Avionics
Framework, using the most popular programming language (JS) and emulating it’s
most popular framework paradigm (React)) helps make the barrier to entry for
the development community at large much much lower, and promotes an
environment that even beginner developers graduating from their first simple
webdev React sample can easily wrap their head around.

7

I have to disagree that this will be easy for developers to use JS TS and JSX
with the coherent debugger. Time will tell. I hope I am wrong. I would like to
fork the code, however the current git is three months old. Any chance you can
release the latest beta? I can understand, you do not want to answer questions
on that while developing it. If there is a way to access it, the community can
field those questions. Would this not help the situation.

8

No, we have no plans to start putting the beta versions of the code up. This
would promote folks coding against a potentially moving API surface and
increase the number of issues developers run into as they encounter breakage
with beta updates.

9

I am totally confused as to how a dev is suppose to work with the avionics
mirror and any Garmins that you update. There is a rumor that the G3000 will
not be pushed to git (at least some people think that based on some
discussions on your discord). Please say that is not correct. You tell me I
can fork your code, but have to wait until you actually release it. Isn’t that
too late, as the next beta cycle is SU12 for a potential release in March,
meaning that SU12 beta is mid February. So devs are chasing fixes for AAU and
will need to opt out of the SU12 beta. I’m assuming we are getting beta
versions of the sim API when we download the beta. A beta AE. A beta aircraft
project build compiler. So why not give the devs a chance to get ahead of
potential issues. To: MS - the marketplace updates need to be streamlined and
quicker now for devs to keep on top of fixes for their customers.

10

Thankfully, nobody is forced into the new G3000. The previous G3000 (AS3000)
will work just fine and will live side by side with the new G3000. So nobody
is left out in the cold and there is no breakage here, just as there was not
with the G1000 NXi, which still lives side by side with the AS1000.
Additionally, if you have forked the G1000 NXi and created a custom version,
then you are already including the forked version in your product, and thus
isolated from breakage due to any changes in any upcoming G1000 NXi updates by
design. If you decide to update your forked version and merge in new changes,
you will be able to do so when the product enters the stable phase and the
mirror is updated. If you haven’t forked the G1000 (or other avionics, as they
are added), then you are receiving the updates already as they land in the
beta and updated code in the repository is not required anyhow; you can simply
address or report bugs during the beta period like normal.

11

Thank You Matt, Appreciate the open discussion here. I’ll wait for the AAU
release and SU12 beta. You and your team are doing good work. I’ll let you get
back to updating the AAU avionics documentation. :wink:

12

I believe standardization and better communication between avionics data could greatly benefit the overall efficiency of developing for the platform. It’s essential to have a unified approach to ensure all systems work cohesively, and in turn, this would greatly benefit 3rd party devs and consumers alike.

13

Realistically SDK support would necessarily be in the common languages XML and Javascript. Working Title have invested heavily in popular WebDev frameworks/tools that layer on top of the browser html/js core functionality which raises the bar in terms of any SDK support. I think realistically the Working Title code will remain specific to their flat-panel gauges, and the framework used will date rather rapidly.

What’s essential is the crucial existing components, like the underlying map-drawing and classes / JS calls that retrieve airports or other aircraft, remain in the current plain Javascript and they should be documented in the SDK. Those are the things that primarily deliver the ‘avionics data’ from the sim.