Back in the 2nd week of September there was discussion of reversible ILSs. Maybe I missed something, but I thought there was rough consensus around the following ideas:
a) FG behavior should be reasonably realistic. We should not make artificial assumptions that make approaches unflyable, when better alternatives are readily available. Conversely, we should not require FG to implement features that are not available in real life. b) An instrument approach procedure generally contains a "missed approach segment". There is a maxim that says "If you are not prepared for the miss, you are not prepared for the approach." The FAA says that half the time, a practice approach should include flying the missed approach segment. Real-world pilots take this seriously. Lives are at stake. c) You cannot show up at a real-world airport and expect both ends of a reversible ILS to be active simultaneously. The physics doesn't permit it. The signals would interfere. If runway 11 is active and you would prefer runway 29, you can ask Tower to reverse the ILS. They might or might be able to grant your wish. d) For years, FG has attempted to divine which end of the reversible ILS the pilot wants to use based on aircraft position and/or heading. This is both unrealistic (see item c) and impossible. There is no objective way to determine whether an aircraft is flying the "upwind leg" for runway 11 or the "downwind leg" for runway 29; the only difference between the two is the pilot's intentions. You've heard of problems that are so hard that they are classified as NP-complete ... well, this problem is much worse than that. It is ESP-complete. e) The current code is even more broken than that. At some airports, it gets the wrong answer 100% of the time, so that you cannot fly the inbound segments, never mind the missed approach segment. Bug reports on this issue have been discarded without comment. f) Code to fix all these problems has been available since September. It uses a "preferred-approach-deg" value in the property tree to decide which end of the ILS to activate. If you prefer the other end, you can easily change this property. All segments of the approach are flyable. Everything is predictable and well behaved. The same words that described the ILS service volume apply here: This is a significant departure from past FG behavior, but it is not wrong. It is feature, not a bug. This code was not committed. It was discarded without comment. =========== I was recently told [off list] that there was a "requirement" within FG to permit simultaneous approaches to both ends of a reversible ILS. This came as a surprise to me. I do not recall anybody suggesting this, even as a joke, much less any consensus in this direction. Let's be clear: We all agree it is important for both ends of the ILS to be available without undue hassle, but they don't need to be available at the same time. And "without undue hassle" doesn't mean without any pilot input at all, especially when the problem is ESP-complete. Most real-world instrument-rated pilots are content to fly the approach that Tower says is the active approach; they don't show up at an airport with inflexible pre- conceptions about which approach will be active. I was also informed [off list] that the code to make reversible ILSs usable had been "ignored" because it was "not good enough". That is not very informative, not very constructive. No clarification has been forthcoming as to what makes it "not good enough". Perhaps some folks on this list would be kind enough to look at the code and make constructive comments. Take a look at http://gitorious.org/~jsd/fg/sport-model/commits/sport in particular the item that speaks of "reversible ILS". If there are some requirements that I am not aware of, requirements that make unflyable approaches preferable to flyable approaches, please explain. ------------------------------------------------------------------------------ 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
