Fixing presets: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 25: Line 25:
The way this was intended to work is that if you want to start on the ground, you should set the altitude to -9999.
The way this was intended to work is that if you want to start on the ground, you should set the altitude to -9999.
Exposing the raw /sim/presets properties to the end user leaves a lot of room for them to make mistakes.
Exposing the raw /sim/presets properties to the end user leaves a lot of room for them to make mistakes.
{{cquote|
Here's my current hypothesis: when FlightGear is
reset, some modules are replaced with new ones (the old ones may or
may not be deleted, but are never unbound).  We end up with all kinds
of dangling references, especially (but not exclusively) for bound
properties, and eventually things grind to a halt.
If I'm right, the property module makes the crash happen sooner, but
the crash *will* happen one way or another, and there are probably
some nasty memory leaks in there as well.  Remember that reset has
always caused occasional unexplained, hard-to-reproduce crashes.
The long-term fix is to finish the cleanup of main.cxx and fg_init.cxx
so that all initialization code is moved out to the subsystems, and
the subsystems themselves are kept in a single, ordered list so that
they can be managed easily and transparently.  It should not be
necessary to delete and replace any subsystems on a reset, with the
exception of the FDM, since all can adjust their state as required.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg06742.html |title= Crash on "Reset" function.|author=David Megginson |date=Wed, 05 Jun 2002 08:00:36 -0700}}</ref>|David Megginson}}


{{cquote|
{{cquote|

Navigation menu