On 12/16/2008 03:05 AM, James Turner wrote: > The dialog box behaviour, is that it explicitly clears out the current > lat/lon before doing the navaid/fix search, so we get the same > behaviour from the GUI - at least it's consistent. > > My proposed fix is to add a 'base position' or similar to the > properties, and use this as the start point for spatial searches in > the position init code. When running from the command line, I'll leave > it unset to avoid surprising anyone with new behaviour, but once we're > started I'll use the current position, which should make the GUI > dialog work as expected. > > However, I'm not sure doing any of this is wise for 1.99.5, better to > do it after the release and let it get some testing, since there's so > many permutations of position-init command lines.
I reckon JT's previous estimate -- "low hanging fruit" -- is closer to the mark. (Guess how I know.) I don't think a "base position" is needed. A notion of "current position" sufficies. As for the CLI, it is useful to process the positioning items _in order_ so that going to --airport=KJFK and then to --vor=SAV will reliably get you to Savannah, GA ... whereas specifying the options in the reverse order would have a different meaning. Other options obviously need to be processed out-of-order, notably --help --verbose. Of course the "locate" dialogs should not clear the current position. I suspect there is little risk of unhappy surprises. Very few pilots intend to relocate from KSFO to Savannakhet in one step. This affects not just the CLI and the GUI, but also some RNAV units. I wrote the code to do this years ago, and have used it a gazillion times since. It works fine. The concept is simple: -- Start at the lowest level. Whenever anybody looks up an ID, always fetch *all* the matching IDs. -- Always sort the list according to distance. -- Then, at the next higher level, if somebody wants only one match, give 'em the _nearest_ match. These bugs arose because there were N different pieces of ID-match code in FGFS. Recently JT has been fixing that, so I reckon almost all of the infrastructure is in place to make this bug go away once and for all, hardly even as a bug-fix, but as a natural consequence of a more general clean-up, which is usually the nicest way for things to happen. =========== While we're in the neighborhood: It would be good to make all ID-matches become case-insensitive. I wrote the code to do this years ago. It's very simple and very helpful. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
