Reset & re-init: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 18: Line 18:


{{cquote|
{{cquote|
Actually my most recent observations show some issues with multiple teleports, or combination of teleports and resets. <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg06771.html |title= Crash on "Reset" function.|author=Jim Wilson |date=Wed, 05 Jun 2002 16:38:32 -0700}}</ref>|Jim Wilson}}
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<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg06771.html |title= Crash on "Reset" function.|author=Jim Wilson |date=Wed, 05 Jun 2002 16:38:32 -0700}}</ref>|Jim Wilson}}


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

Revision as of 17:02, 9 May 2013

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.
Cquote1.png 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[1]
— Jim Wilson
Cquote2.png

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

Cquote1.png 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).[2]
— David Megginson
Cquote2.png

For details, see Fixing Presets.

Cquote1.png

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.[3]
— David Megginson
Cquote2.png
  1. Jim Wilson (Wed, 05 Jun 2002 16:38:32 -0700). Crash on "Reset" function..
  2. David Megginson (Mon, 24 Nov 2003 07:22:13 -0800). Re: Helicopters: wow!.
  3. David Megginson (Thu, 06 Jun 2002 05:03:39 -0700). Crash on "Reset" function..

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, also see [1] [2])
    • 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.