FlightGear Newsletter November 2015: Difference between revisions

FlightGear does not currently support saving/loading flights or reliably switching between aircraft at runtime (this is extensively discussed at [[FlightGear Sessions]]). [[Reset & re-init]] is an effort to refactor the FlightGear initialization process so that resetting and repositioning is supported, without having to exit or restart FlightGear. Currently, this is exposed via the Canvas-based [[Aircraft Center]], but that is considered broken or fragile at best by most core developers, and is known to be be a source of {{wikipedia|Resource leak|resource leaks|noicon=1}}.

The core developers are aiming to find out the dependencies of different subsystems and re-factor them so that more and more subsystems can be made optional (similar to [[FlightGear Run Levels]]), enabling them to be dynamically removed and re-added at runtime. This will be particularly important to untangle implicit or hard-coded dependencies among the different subsystems, and will be one of the key tasks to move certain subsystems into dedicated [[High-Level Architecture]] (HLA) {{wikipedia|High-level architecture#Common HLA terminology|federates|noicon=1}}.

The other goal is to increasingly modularize FlightGear by using HLA and split off the simulation loops (see also [[FGViewer]]), as well as [[Supporting multiple renderers|supporting different renderers]] (such as [[Rembrandt]] and [[ALS]]), scenery engines (e.g., standard and [[FlightGear osgEarth|osgEarth]]) and weather engines, in a fashion similar to how FlightGear already supports different [[Flight Dynamics Models]] ([[JSBSim]] and [[YASim]]). HLA will make it possible for certain subsystems to be moved to dedicated cores by using separate threads or even processes, meaning that certain subsystems may even be able to be run on a different computer in a distributed setup.

The underlying requirement that these efforts share is the need for a much better re-initialization process, with no hard-coded assumptions about running subsystems or initialization order, because subsystems may be running elsewhere, and may need to be dynamically added/removed at runtime.

You can help this effort by running the relevant APIs and providing [https://www.gnu.org/software/gdb/ GNU Debugger] backtraces and bug reports (or [[CrashRpt|crash reports]] if you have Windows) of any segmentation faults that occur.