I think it needs to be said that trying to extend XML into a new untyped,
unstructured, undocumented programming language in 2022 using string
concatenation as a higher-level functional construct is so extremely odd that
shouldn’t simply happen without comment from anybody. It’s bizarre and going
to get increasingly problematic as this project progresses. I get the
attractiveness of templating the model XML. But what’s happened is the idea
that one template can manage the throttle in every aircraft has ended up with
the tail wagging the dog and the template necessarily having to invent a
complex sequence of if-then-else, parameter substitution, procedure calls and
case functionality to cope with wide range of requirements. A simpler set of
building blocks may be a more optimal solution. MSFS is an important project -
my advice is take a good look at the fairly impressive tech strategy and
review whether that newly-invented XML programming language is actually a
strategic asset or a potential liability, and plan accordingly.
Do you mean the reverse polish notation (RPN)? It’s documented here:
https://docs.flightsimulator.com/html/Additional_Information/Reverse_Polish_Notation.htm
Nope - RPN within a single XML element is kind of a succinct solution to
making very simple code portable, without allowing it to have complex features
that would impact performance of the main rendering loop. Bit of an odd unique
language, true, but those guys knew what they were doing. You need to look one
level up at the Asobo XML templating system which started with a simple idea
that a small XML ‘template’ could be populated with parameterised values and
be expanded into the more complicated model XML which FSX has used. This has
led to adding case, select, if-then-else and looping special tags in the XMLas
the one-size-fits-all templating methodology has required ‘programming’
functionality to get it to work. For example, it is expected you include your
RPN as a parameterised value that is then passed down the template chain,
ultimately being expanded into the section of XML you never. BUT, Asobo has other code they want to put in the same section (e.g. for an animation, or
to control the execution of your code) and Asobo have used simple string
concatenation for this. I.e. you feed your RPN to the template as x y z and
Asobo’s system eventually spits out (Asobo's code goes here) (your ANIM_CODE) (more Asobo code goes here). It’s a bit of a mystery what happens if you have
‘quit’ in your RPN. I’m pretty sure the emergence of this new programming
framework (undocumented new XML tags used within the model XML system creating
a new Turing-complete programming language) was never part of any strategy, or
had any code review - it’s just been bolted on a piece at a time as each new
template needed some new programming capablity to get one template to work on
every asobo aircraft.
AFAIK back when Microsoft invited us at Seattle, the addition of XML was meant
to make developing gauges easier to people without programing experience. It
was a low level of entry to building what is visible in the cockpit only,
nothing more. I agree the templating system is clever on paper, mimicking the
idea of encapsulation, but in practice, it is becoming a very complex system
especially because the tooling is lacking (hierarchy browser, pre-
visualization of the tail of the chain of templates when instantiated with
parameters - like you have with VS2019 IntelliSense allowing to substitue
template argument - ) In my opinion, at the level of encapsulation one reaches
today, it raises the question whether this is a hindrance or a helper, and
whether modern languages supporting sophisticated constructs yet simple enough
for most users (LUA type) wouldn’t help here. But like you said, the point of
this is probably elsewhere: fast parsing and execution at runtime. There is a
similar idea in my opinion behind the L:, A:, etc… vars: these are
conveniently segregated so that the parser resolves what to do based on a
switch/case of the first letter (actual FSX code). Anyways, the actual system
is doing the job.
I don’t think what has happened with the XML is fully understood by Asobo or
the majority of devs. The system only works if the Asobo template matches
your requirement, and Asobo are only targeting their own aircraft with the
template development (i.e. the throttle template explicitly checks which Asobo
plane is using it). The most significant issue is Asobo have moved
functionality from the ‘base’ XML into the templates with new undocumented
variables and events which are not accessible if you do not use code from
their template. If you can use, e.g. the Asobo ‘prop feathering’ template in
your plane, you are ok, i.e. all the work Asobo has done to hard-code the
template for their stock aircraft works for your aircraft. But if your
aircraft is in some way different (e.g. it feathers but doesn’t use the same
cockpit elements) then general programming is no longer possible. IMHO Asobo
should add templates for those that can use them, but continue to treat
documented general programming as the strategic base.