Hi all, I'd like to do a suggestion here, although I'm not able to code it myself (I'm sorry...)
How about making allowing one to set the proposed preferred-approach-deg property, but not requiring it. IE, if it is not set, apply the current heuristic or some to be developed improved heuristic. This would not change current behaviour, but it would improve the situation. Thanks, Stefan 2009/12/20, John Denker <j...@av8n.com>: > On 12/20/2009 05:06 AM, James Turner wrote: > >> Anyway, my objection is that delegating the active runway to a user >> property (or menu item) is abdicating a hard problem to the user, > > It's not just hard, it's ESP-complete. > >> ... for most users >> it's a confusing setting. > > The more relevant question would be, is it more confusing > or less confusing than what we have now. > > Right now, every approach that involves a reversible ILS is > unflyable. In some cases you can't fly the missed approach > segment, while in other cases you can't even fly the final > approach segment. That seems kinda confusing to me. > >> For better or worse, MSFS and X-Plane do >> *not* require such a piece of user interaction, and therefore it is >> my position that we should not either. Clearly they have a better >> heuristic than we do - what I would like is for someone to propose a >> better heuristic. (My personal guess is that the heuristic will be >> based on local surface winds, but who knows, as ever I am not a >> pilot) > > A better heuristic? Better than what? Right now *all* > reversible ILSs are broken in FG. > > Basing the decision on wind would be an improvement over > what FG is currently doing. However, basing it on wind > _alone_ would make it hard to practice a circle-to-land > approach, which is something that real-world pilots need > to practice. Also, deciding based on the _instantaneous_ > local wind is a losing proposition, since the wind might > shift while you are in the middle of an approach. > > The submitted code that looks at preferred-approach-deg > _allows_ but does not _require_ you to align the approach > with the wind. This is an argument for adopting the code, > not for discarding it. > > Having a preferred-approach-deg setting is clearly Pareto- > superior to what FGFS is currently doing ... and is quite > possibly superior to whatever Xplane and MSFS are doing. > >> Aka 'figure out what the user wanted, and do it'. I know John alluded >> to ESP, but I regard that as abdication - we simply need to try / >> think harder about a workable heuristic, instead of abandoning the >> idea in favour of a setting. > > Everyone is welcome to "try / think harder". In the meantime, > implementing an interim solution that is both realistic and > useful is better than sticking with something that is completely > broken. > > If somebody has a specific proposal (or, better yet, code) > that works better than the preferred-approach-deg scheme, > please let us know. > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
