20,741
edits
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| | ||