Reset & re-init: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
Line 89: Line 89:
** 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.
** 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 ([[FlightGear Sessions#The FlightGear Frontend Debacle|we have about 10-15 GUI launchers for FG currently]]).
* Separate startup GUI frontends like fgrun may become obsolete or at least optional eventually, because FlightGear itself would become increasingly runtime-configurable ([[FlightGear Sessions#The FlightGear Frontend Debacle|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
** once FlightGear can be propertly re-initialized, providing a [[Canvas]]-based GUI on top would be fairly simple, see [[Aircraft Center]]
** this should help improve end user usability - because FlightGear would become more self-contained, without inevitably requiring external tools to provide basic GUI configurability.
** 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.
** 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.

Revision as of 18:15, 9 July 2014

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.

Note  Also see Initializing Nasal early, Aircraft Center & FGCanvas


Screen shot showing a the performance monitor in a patched version of FlightGear 3.2 where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for benchmarking, but also headless regression testing - and eventually, also a standalone FGCanvas startup mode.

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..

Status / related Commits (03/2014)

Over the next few days James is going to start switching over the reset system to use the new code. The following changes will happen, in order:

  • places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally.
  • the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path that triggers a reset its the actual menu command / key-shortcut - If anyone knows of some strange way we trigger a reset, please do let me know)
  • the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used
  • Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but James will try to address issues as quickly as possible. Unfortunately each time a fix in preferences.xml is made, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :)

James is not expecting any build failures since the code is already in Git, but I would ask that any bug-reports are only made /after/ wiping your autosave XML file.


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.


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, see Aircraft Center
    • 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.