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