by Hooray » Sun Dec 13, 2015 9:39 pm
I suggest to spend some time doing a little research in the archives.
Note that Torsten's comments above don't necessarily represent a general "consensus" among all core developers - in fact, a number of contributors, including former core developers, did/do have a military background, and their involvement was also in part motivated by this background.
And all that predates Torsten's involvement.
It is true that, at some point, most /active/ core developers were not particularly interested in pursuing military aviation, and combat capabilities in particular.
However, the consensus was that this was not intended to prevent anybody from implementing the underlying hooks, as in generic interfaces and building blocks, without being specific to fighting/combat, because the corresponding functionality would also have applicable use-cases in non-combat/civilian simulation. The specific example mentioned were effects, collision detection etc - none of which would need to be implemented with any particular focus on "combat".
In fact, just look at other FG subsystems (e.g. autopilot, FDM, scripting, shaders/effects etc), which are also not specific to a single type of simulation (civilian, military, single engine).
Finally, this is not specific to the combat/military use-case: People also don't want to see FlightGear restricted to single-engine or multi-engine piston planes or IFR flying only, even though that would greatly focus, and simplify, future FlightGear development.
Just look at features like the property tree, XML, FDMs (YASim/JSBSim), but also Nasal scripting, Canvas, property rules or effects and shaders.
None of these were implemented/provided with any particular/restricted use-case in mind, which means that you can use these subsystems and consider them "building blocks".
And in the case of dog-fighting/combat functionality, this has been demonstrated in a pretty compelling fashion by flug's bombable addon, which only uses a tiny fraction of these building blocks currently, but which is remarkably full-featured, given that none of its features were explicitly designed to be supported by FlightGear.
Equally, there are other extensions, like the advanced weather system, which were developed by people, without the people providing the underlying infrastructure ever contemplating to use Nasal scripting and effects/shaders for such purposes.
Therefore, it is really totally pointless to continue this debate in its current form - I really encourage people to look at the archives for reference, and then look at how FlightGear has evolved in the meantime.
FlightGear is a platform, and you can use it as a framework to implement arbitrary functionality, and as long as you keep other use-cases, features (and people!) in mind, the functionality is likely to be added/supported sooner or later, regardless of what some core developers may have previously stated (in public or not).
In fact, the whole notion of using the property tree for scripted 2D rendering (aka Canvas) was highly unpopular a few years ago, as was using the property tree for POD types in C++ space.
These days, we can all see that FlightGear evolved despite certain resistance.