The animations (and other stuff?) in the model behaviour XML files call into so-called templates, defined in various files in fs-base-aircraft-common\ModelBehaviorDefs. Looking into these, one is, how should I put it, amazed and filled with horror. Such complexity to express things that could be expressed much less verbosely in some normal programming language.
I mean, things like the templates, an excerpt:
<Condition NotEmpty="AFTERBURNER_GATE_POS_16K">
<DRAG_MIN_VALUE>(A:THROTTLE LOWER LIMIT, position 16k) (O:XMLVAR_MIN_Limit) max</DRAG_MIN_VALUE>
<DRAG_MAX_VALUE>16384 (O:XMLVAR_MAX_Limit) min</DRAG_MAX_VALUE>
<PROCESS_LIMITS>
#PROCESS_LIMITS#
(A:GENERAL ENG THROTTLE LEVER POSITION:#ID#, position 16k) #AFTERBURNER_GATE_POS_16K# - abs #GATE_MARGIN# > if{
(A:GENERAL ENG THROTTLE LEVER POSITION:#ID#, position 16k) #AFTERBURNER_GATE_POS_16K# > if{
#AFTERBURNER_GATE_POS_16K# (>O:XMLVAR_MIN_Limit)
} els{
#AFTERBURNER_GATE_POS_16K# (>O:XMLVAR_MAX_Limit)
}
}
</PROCESS_LIMITS>
<RESET_LIMITS>
(A:THROTTLE LOWER LIMIT, position 16k) (>O:XMLVAR_MIN_Limit)
16384 (>O:XMLVAR_MAX_Limit)
0 (>O:XMLVAR_Limits_Needs_Recalculation)
</RESET_LIMITS>
</Condition>
A strange mixture of what clearly is an expression syntax in XML and a postfix language inside some of the elements. Plus, this being XML, to add insult to injury, that postfix language then has ânormalâ operators like > , which has to be written as > because XML. Elegant, not.
Is this the result of a translation from some higher-level more elegant and less verbose language? Why is the detour through XML needed? Surely this will upon loading into the simulator be converted again into some more efficient internal structures. Possibly even JITting is involved.
The old saying Whoever does not understand LISP, is doomed to reinvent it comes to mind, but I digress. This being a Microsoft product, one would have expected C# to be used, a lot.
Yes, I know, but the most important thing with what essentially is source code is that it is to be read by humans, multiple times, not only written once by a human and only read by a compiler or other software after that. We have come a long way since it was a good idea to base some programming language syntax on what is âcompiler friendlyâ.
Yeah. I have dabbled a little bit with generating Postscript some decades ago so postfix languages arenât completely strange to me.
(And way back in the day, the Forth programming language was allegedly popular in some use cases. And Forth was also used, of all places, in the command line interface to OpenFirmware, which is (was) used at least on Sun computers as what PC people calls the âBIOSâ. And Wikipedia tells me that it is also used on IBM Power machines.)
Still I question the sanity of this development decision.
K.I.S.S. technology should always be used (and documented) or grab your briefcase and head for the door.
The corporate I.T. departments that have programmers in them (including management), that purposefully write code in cryptic fashion is just one thing: job security for them. And, the CEOâs know and understand this (and donât like it).
I understand that in some company where you develope for the company inhouse, or something.
But we are the ones who have to work with that too. Without 3rdparty devs msfs wouldnât be much. So imo there should really be a good reason to implement some weirdnes like this.
Compiler friendly isnât enough for me, on first sight at least. Maybe i donât have enough oversight to see why
One possibility is that this XML format is just a stopgap measure, and that the XML is generated from some high-level language, and what they actually want to do is to to compile that to .NET bytecode, or perhaps more likely WebAssembly bytecode. But then there were some problems with that and then managerial decisions to release the produce intervened and they had to quickly come up with something, and hey, XML is great, right?
But even if that is true, now they are then stuck with supporting this XML forever, as 3rd-party add-ons already use it. (That doesnât mean they canât eventually do what they perhaps originally wanted, too, sure. Itâs a bit sad to see âbackward compatibilityâ and âhistorical reasonsâ evolving in front of oneâs very eyes.)
I mean, wouldnât it be really cool to describe your aircraftâs behaviour in some actual programming language? Like C#, Javascript, Java, or even C++. Some that can be directly compiled to either .NET or WebAssemly bytecode. Or is there a large number of 3rd-party developers who wouldnât want to touch DIFFICULT PROGRAMMING (sarcasm) but are perfectly fine with writing XML manually? (But sure, when I say write I mean copy-paste and modify a bit. But there could-be equally copy-paste-friendly sample source code snippets, too, of course.)
This type of XML config/code goes back to FSX, so I suppose they already had code and tooling that works with it. Why reinvent the wheel as they say.
With the new HTML & JS gauges and WASM modules, they clearly are embracing modern tech when it has a benefit.
While the model behavior templates seem daunting at first, once you get the hang of it, seems to be a perfectly adequate system. There is quite a bit of existing documentation and FS dev forum posts about all of this stuff and much of it is still relevant today.
Hereâs a link to the P3D SDK docs and itâs still very useful for MSFS 2020 dev work.
Do you know whether the flybywiresim truly open source glTF with Asobo extensions exporter (and importer) is as good as that MSFSToolkit one, which is not really open source style in development even if not proprietary. At least flybywiresimâs seem to follow the upstream Khronos importer/exporter which is great.
Just looking at the raw text I have to think no - they must have a designer or source language for this. Itâs way too brittle not to invest in that kind of generator. Asobo are not idiots. They are big mature software company. Any intern can knock out an improvement on this as a source language in a couple of days.
