RE: [Flightgear-devel] Beyond presets
David Megginson writes: > Norman Vine writes: > > > > Not really -- the difference is that the actual values > > > (lat/lon/alt/hpr/airport/navaid/etc.) live in the main property tree, > > > and these tell us only where we should look for them. > > > > Sounds to me like what is needed is a way to do > > > > $MY_TREE = which branch I want > > > > / sim / $MY_TREE / *** / ** > > I don't think that's it either -- we have too many different ways to > set the initial position, velocity, etc. Simply selecting a branch of > the property tree won't do it (unless we want to duplicate all of the > information in that branch, in which case we're back to presets > again). I should have clarified this is only when the properties are in 'persistant' mode, reading or writing to/from disk I agree that we do not want or need more then one tree in memory. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Beyond presets
Norman Vine writes: > > Not really -- the difference is that the actual values > > (lat/lon/alt/hpr/airport/navaid/etc.) live in the main property tree, > > and these tell us only where we should look for them. > > Sounds to me like what is needed is a way to do > > $MY_TREE = which branch I want > > / sim / $MY_TREE / *** / ** I don't think that's it either -- we have too many different ways to set the initial position, velocity, etc. Simply selecting a branch of the property tree won't do it (unless we want to duplicate all of the information in that branch, in which case we're back to presets again). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Beyond presets
David Megginson writes: > > Tony Peden writes: > > > >/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) > > > > This sounds awful close to /sim/presets, so it sounds to me like we may > > always need the functionality. That being the case, why change it? > > Not really -- the difference is that the actual values > (lat/lon/alt/hpr/airport/navaid/etc.) live in the main property tree, > and these tell us only where we should look for them. Sounds to me like what is needed is a way to do $MY_TREE = which branch I want / sim / $MY_TREE / *** / ** Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beyond presets
Tony Peden writes: > >/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) > > This sounds awful close to /sim/presets, so it sounds to me like we may > always need the functionality. That being the case, why change it? Not really -- the difference is that the actual values (lat/lon/alt/hpr/airport/navaid/etc.) live in the main property tree, and these tell us only where we should look for them. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beyond presets
On Fri, 2003-09-19 at 13:00, David Megginson wrote: > 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) This sounds awful close to /sim/presets, so it sounds to me like we may always need the functionality. That being the case, why change it? > >etc. > > 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. > > > All the best, > > > David > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beyond presets
Curtis L. Olson wrote: David, I'm open to something more sensible, but let's proceed with caution. I have a side project that is critically wired into the current presets arrangement and I can't afford to have that broken, at least not for very long. Hopefully if you do make changes you are willing to work with me to make sure my other stuff doesn't get seriously broke. I've always had difficulties deciding where the initialization of a property should go: in the presets functions, or in preferences.xml file. I opt for the latter. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beyond presets
David, I'm open to something more sensible, but let's proceed with caution. I have a side project that is critically wired into the current presets arrangement and I can't afford to have that broken, at least not for very long. Hopefully if you do make changes you are willing to work with me to make sure my other stuff doesn't get seriously broke. Thanks, Curt. David Megginson writes: > 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) > >etc. > > 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. > > > All the best, > > > David > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Beyond presets
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) etc. 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. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
