20,741
edits
FlightGear Newsletter November 2015: Difference between revisions
Jump to navigation
Jump to search
FlightGear Newsletter November 2015 (view source)
Revision as of 17:24, 22 November 2015
, 22 November 2015→Troubleshooting reset/re-init
| Line 87: | Line 87: | ||
[[File:Reset-reinit-control-panel.png|thumb|Reset/Re-init control panel, implemented using Nasal & Canvas, for regression testing purposes.]] | [[File:Reset-reinit-control-panel.png|thumb|Reset/Re-init control panel, implemented using Nasal & Canvas, for regression testing purposes.]] | ||
FlightGear does not currently support saving/loading flights or reliably switching between aircraft at run-time (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 is considered broken or fragile at best by most core developers. | FlightGear does not currently support saving/loading flights or reliably switching between aircraft at run-time (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 is considered broken or fragile at best by most core developers, and is known for leaking resources (listeners and memory). | ||
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 (analogous to [[FlightGear Run Levels|run-levels]]), enabling them to be dynamically removed and re-added at run-time. 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 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 (analogous to [[FlightGear Run Levels|run-levels]]), enabling them to be dynamically removed and re-added at run-time. 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}}. | ||