Reset & re-init

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.

Actually my most recent observations show some issues with multiple teleports, or combination of teleports and resets. Maybe that should be part of a minimum test before something is commited — Jim Wilson

The last time, "reset/reinit" (as well as saving/loading flights) was reported to work properly, was prior to the "presets" work:

Yes, reset and save/restore are a bit broken in FlightGear right now. I'll try to fix them when I have a chance, but it will require a bit of refactoring (removing Curt's initial-state stuff, for example). — David Megginson

For details, see Fixing Presets.

The original reset was a simple kludge that worked fine for a simple program; now that FlightGear is a lot more sophisticated, we need to refactor a bit rather than just holding things together with scotch tape and bubble gum. The problem is that right now we have two different approaches - a lot of stuff is handled cleanly in individual modules' update() methods, but a lot of stuff is still handled by hundreds of lines of BASIC-like, hard-to-read spaghetti code in main.cxx and fg_init.cxx (forget OO, it's not even functional programming). That was the right idea to get started - I'm not a fan of wasting time on an initial OO design that you won't end up using -- but now we need to finish cleaning it up. We need to make this a high priority. — David Megginson

Status / related Commits (11/2013)

See: https://gitorious.org/fg/flightgear/commit/881df711ba5be8a8c0bc65f2126a0dcb63865df9

2013-11-12 23:36 James Turner       Reset: changes for SGSubsystem ownership.
2013-11-12 23:10 James Turner       Reset: adjust for tweaked TerraSync API
2013-11-12 22:26 James Turner       Reset: explicit close-window function.
2013-11-11 10:13 James Turner       Reset: uninstall deletion-manager
2013-11-05 05:31 James Turner       Reset: route-manager guard against no plan.
2013-11-11 10:11 James Turner       Reset: ATIS shutdown fix  
2013-11-10 12:32 James Turner       Reset: panel-node cleans up listener.
2013-11-05 05:32 James Turner       Reset: guard against NULL HUD / lighting
2013-11-05 05:32 James Turner       Reset: sound manager can be shutdown cleanly
2013-11-05 05:30 James Turner       Reset: drop FGLight prop refs on unbind()
2013-11-05 05:29 James Turner       Reset: remove commands
2013-11-11 10:13 James Turner       Reset: use simple properties for TimeManager
2013-10-06 17:36 James Turner       Reset: Nasal can be shutdown.

• reset scenarios on sim-reset
• Preserve current view on reset/reinit/reposition
• Initial work on dynamic subsystem creation

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 (saving/loading flights [1])
  • 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, also see Nasal Events [2] [3])
  • 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.