@hamzaalloush: thanks for making these tests and for sharing your screenshots and findings with us. I believe that it would be good to also update the wiki article accordingly, so that we can also document the underlying processes and workflows - i.e. so that abassign and vitos can independently verify these results.
BTW: I particularly liked the idea of running the FDM in standalone mode to demonstrate that threading is not going to be the solution in this.
Anybody interested in seeing the impact of reducing model complexity can do so without even using a 3D modeling program, i.e. by using "osgconv" and its integrated mesh simplifier
Besides,it is true that you cannot reuse GPL'ed code in your own code, without also "tainting" your own code, due to the viral nature of the GPL. The only distinction that the GPL makes is that code has to be running the same process/address space as the GPL'ed code - which is to cover DLLs, DSOs, dynamically linked libraries.
There is no distinction made between binary or scripted/interpreted - and under the hood, Nasal code will indeed be compiled and "linked into" the same address space as other modules.
While that may be an unfortunate fact for external aircraft hangars/developers, $FG_ROOT assets are generally GPL'ed, without any exception for Nasal code in place.
We did have this discussion previously, and a few people suggested to re-license $FG_ROOT/Nasal accordingly, using a more permissive license - and while that might not be such a bad idea, it is a ton of work, especially given that most modules/code were written by people who may no longer be actively involved, so we would need to get in touch with those to explicitly ask the them to re-license their contributions accordingly, which makes the whole not feasible.
It is for that reason that the FSF asks contributors to its GNU projects (e.g. gcc) to explicitly provide the corresponding paperwork upfront, to ensure that such situations can be avoided, i.e. by granting all copyright to the FSF, or releasing all work into the public domain (which is automatically compatible with the GPL. no matter what some folks are saying):
https://gcc.gnu.org/contribute.html#legal Adopting HLA/RTI is going to make this even more problematic, because the GPL can be totally circumvented due to the whole "process/address space" distinction - which is why more and more DISTRIBUTED projects are moving to the Affero GPL (AGPL) instead.
PS: @vitos: I don't remember the discussion you were referring to (changing property names), but unfortunately there are tons of inconsistently-named/placed properties all over the place in FG, and that is complicating matters for other efforts. It would be really good to review/update these things, but that would inevitably break a lot of aircraft. One thing that might work is to update these things at the C++ (core) level and introduce a fgdata wrapper to map/mirror properties to their old equivalent (location/name in the property tree), e.g. using property rules.
Right now, FlightGear's way of using properties is unfortunately pretty problematic and does not scale too well, especially if you look at it with a focus on supporting multiple FDM, autopilot or route-manager instances - e.g. for the AI traffic system, there are too many hard-coded assumptions all over the place.