On 4 Dec 2008, at 06:40, Rob Shearman, Jr. wrote:
Maybe what I am about to suggest is NOT how real-world route managers are supposed to work -- so take it with that caveat. But I would think that if your last waypoint before KSFO is 1000nm away, but you want to hold off the descent until closer to KSFO, you could simply insert another waypoint about 50nm out at the cruise altitude, and the effect would be to "tell" the route manager where to begin the descent.Now, whether that's the "real-world"/"correct" solution, or just a work-around, someone else will have to say...
Heh: that's 'top-of-descent calculation', which I want to do in the future, along with other 'non-positional' waypoints - i.e ones defined by speed/altitude, not lat/lon. Step-climb profiles are the other obvious example there. The issue is the current SGWaypoint isn't amenable to such usage, and such calculations need some aircraft performance data - the nominal or planned descent rate chiefly.
For now, I'm working on improvements that don't require updating aircraft, or big changes to the SimGear code. I'm sure I will end up needing such things, especially to support sub-routes (airways/SIDs/ STARs/GPS approaches), but I want to get more familiar with the code, and how people are using it, before attacking such things, and potentially introducing bugs.
Regards, James
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
