Reset & re-init

From FlightGear wiki
Revision as of 05:42, 27 January 2013 by Hooray (talk | contribs) (→‎Benefits: add more benefits)
Jump to navigation Jump to search
Reset & Re-init
Started in 01/2013
Description Fixing reset & re-init
Maintainer(s) Zakalawe, ThorstenB
Contributor(s) User:Zakalawe (since 01/2013),
Status Under active development as of 01/2013


Scheme agreed by James & Thorsten at FSWeekend 2012 to fix reset / re-init weirdness.

Motivation

  • Re-init of all subsystems doesn't work, because many subsystems don't support it. (There's an open bug about this in the tracker). Instead we have 'reset', which does some special operations, but is different logic from normal startup. This leads to bugs when the reset behaviour differs to a fresh start.
  • JSBSim has issues with resets since it doesn't read simulation state each frame - this is why you can't resume flying from a recording / replay for JSBSim aircraft.
    • Note this is a different issue from problems with in-air starts, which also needs some tweaking to work with JSBSim.

Solution

  • Get rid of reset / reinit entirely, and simply re-run the normal init sequence after tearing down almost everything. (What remains, is to be decided by testing - probably scenery, maybe nothing else at all).
  • The requires reliable deleting + cleanup of subsystems - i.e fixing and fixing all the places using statics incorrectly. Some work towards this has already been done.
  • The current property tree mirror needs to be replaced with some similar, but simpler logic, to preserve the user-archive properties, and re-overlay them after the property tree is rebuilt.
    • This is simpler than the current 'clone the entire property tree' logic which also causes bugs. Indeed, one approach would be to actually update the autosave.xml as we do at shutdown, and re-read it. Hence no difference between a reset and quit + restart.
  • Subsystems that remain alive must hence be checked that they unbind / re-bind correct, since we will get a new, clean property tree root. This will be easy for some cases, tricky for others. Probably only subsystems related to rendering and display should even be considered for this.

Benefits

  • No more 'X breaks on reset' bugs - less code to maintain and fewer special cases in the code.
  • Dynamic switching of aircraft
    • Since the property tree will be rebuilt, we can safely read a different -set.xml file without the universe imploding.
  • Restarting of Nasal (re-read scripts on the fly)
    • Since it's a new property tree, we have to destroy and restart the Nasal context anyway. This should greatly simplify aircraft Nasal script development.
  • Separate startup GUI frontends like fgrun may become obsolete or at least optional eventually, because FlightGear itself would become increasingly runtime-configurable (we have about 10-15 GUI launchers for FG currently).
    • once FlightGear can be propertly re-initialized, providing a Canvas-based GUI on top would be fairly simple
    • this should help improve end user usability - because FlightGear would become more self-contained, without inevitably requiring external tools to provide basic GUI configurability.
    • given the number of separate FlightGear launchers, there are also lots of developers involved in developing and maintaining these external software packages, some of them also active FlightGear core developers/contributors - so this step could further help channel important development resources, to focus on the main project, i.e. fgfs.

Implementation

  • This is a complex change, which cannot easily be done incrementally. It will inevitably cause some breakage and issues while everything is tested.
  • The init / shutdown code, including FGGlobals, needs to be adjusted to do the actual deletion and run init again. Most of the other init steps (configuration options) are already re-factored in this direction anyway.
  • Any subsystems which should be retained, such as tile-manager or renderer, need to be checked very carefully.
    • This likely requires some new SGSubsystemGroup hooks to extract the subsystems from their owning groups so they escape shutdown and deletion.
  • Any systems with other threads need to be inerted during the reset. In particular any osgDB paged loaders, or TerraSync threads, need to be paused or audited for safety. TerraSync should be relatively simple (since it's a regular subsystem), osgDB interactions, especially with properties, will be harder.
    • All animations and effects will need to be destroyed for sure, since they have property tree references.