Fixing presets: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 9: Line 9:
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|
Unfortunately, while the presets hierarchy brought some benefits, it
also broke saving and restoring flights.  I think that it's time to
consider doing away with the presets hierarchy, and trying something
like this:
1. Make an in-memory copy of the property tree that we can revert to when the user wants to reset; we could even keep a stack of reset points, if that was useful to anyone.
2. Add a few /sim/startup properties to indicate what information should be used for position, orientation, etc.  For example,
*  /sim/startup/init/position-type : (latlon,airport,navaid,runway)
*  /sim/startup/init/altitude-type : (msl,agl,glidepath)
*  /sim/startup/init/orientation-type : (rph,runway)
*  /sim/startup/init/time-type : (utc,local,sunpos)
I'm sure that people can think of a better classification.  From this point on, then, our initialization code can simply look at these to decide whether to initialize based on the airport, etc.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg17214.html |title= Beyond presets|author=David Megginson |date=Fri, 19 Sep 2003 13:07:52 -0700}}</ref>|David Megginson}}
<references/>

Navigation menu