YourDailyTsunami wrote:I think that'd bring down the performance of FG on older computers quite a bit!
That's actually a slightly misleading interpretation, there's really no technical reason why a capability to select and switch FlightGear aircraft at runtime within the simulator should have any significant or relevant performance penalties associated (after all: once you want to switch aircraft, you don't care about a simulator slow down during re-initialization-you certainly don't if you are accustomed to having to restart the whole sim!).
In fact performance-wise, the opposite would be more likely to be true, given that currently changing aircraft means to terminate and restart a whole process, including reloading and re-initializing lots of runtime state that doesn't necessarily have to be reloaded just to change the active aircraft, this happens only relatively quickly because of a hot cache once you've started FG before, but apart from that it's actually a terribly inefficient method to re-initialize an application.
The reason why this still isn't possible in FlightGear is because it is complicated to implement the necessary support because the current architecture was never designed and implemented with this requirement or priority in mind, so most code existing today in FlightGear would need to be changed to make this possible because it was developed without this capability in mind, and even most new code is added without such concerns.
Additionally, most of the necessary modifications boil down to "unsexy" cleanup work, rather than developing exciting new features and code (which provides for somewhat direct gratification), several developers would probably have to spend several months to fix the current design, without introducing major new code or features during that time. This would include lots of refactoring work and other stuff that's generally considered "boring" by most.
And then, this would also first of all require a decision that this is in fact a design flaw which needs fixing, so developers would need to agree that this should be changed.
So, in this sense this issue does boil down to a performance issue at some point, simply because of the limited man power available which would then be pretty busy doing stuff behind the scenes that most users wouldn't get to "see" or understand in any way, until of course such an effort succeeds and people are suddenly able to switch aircraft at runtime.
But the lack of support for changing aircraft at runtime is certainly not in way related to FlightGear wanting to support low end systems or anything like that.
Likewise, FlightGear's extensive use of open interfaces such as XML and scripts shouldn't have any significant performance penalties either.
For example, most costly XML and Nasal processing (think parsing) doesn't happen on a "per frame" basis, but takes instead place before the main loop is run, during initialization.
So, that's when the overhead for parsing and expensive processing comes in.
Most of the code run during simulation is merely based on dynamically populated data structures, for example by initializing the corresponding structures or setting up bytecode that is then run in the Nasal VM, but all this doesn't permanently happen during simulation!
The mere and proper use of technologies such as XML or scripting certainly doesn't automatically impose any significant performance penalties, the few instances where a piece of Nasal code was indeed found to be the case for a simulator slow down this also wasn't a shortcoming of Nasal, but mostly a matter of someone not using the proper approach to do something, or someone just not being aware of the limitations imposed on Nasal scripts that are necessarily run in the main loop of FlightGear and may thus negatively interfere with other subsystems if not properly coded.
Of course there are some scenarios where the use of Nasal cannot be really recommended, but this wouldn't be so much due to shortcomings of the Nasal scripting language, but much more due to architectural shortcomings in FlightGear, that eventually resulted in Nasal being embedded in it the way it is, so that scripts get to run in the main/rendering loop.
But Nasal/scripting in itself doesn't automatically have to imply "slow": with a properly modified FlightGear architecture, Nasal scripts could be used for many more interesting things without necessarily affecting overall simulator performance.