On Sep 16, 2009, at 12:01 AM, John Denker wrote: > On 09/15/09 20:53, Thomas Betka wrote: > >> Of course the LOC beam width can be adjusted >> to accommodate this, to some degree. > > Not to a sufficient degree if/when the localizer is > at the wrong end of the runway. The localizer course > width necessarily goes to zero at the antenna. There > is no way around this. This adds to the excitement > of back-course approaches.
Well all I would say in response here, is that's why a LOC BC approach is *not* a precision approach. > >> That begs another question then >> though--is this accounted for in FG at present? > > The last time I touched the code, reversible ILSs > were working fine ... both ways ... except for the > switching logic, which failed utterly for missed > approaches, for arrivals from upwind, et cetera. I will need to evaluate this more critically, I can see. I haven't tested an approach at one of these airports, but will try to do so this weekend, when I get all of the Elite hardware set up and driving FG. My new machines should be here in a couple of days, and I plan to get configured for testing this weekend. > >> I still think an acceptable solution is to hit the user with a >> textbox >> message, advising them of the potential conflict. > > I don't recommend that. Unrequested popups are near > the nadir of bad user-interface design ... especially > when, as in this case, they might confront a naive > user who doesn't know what they mean. Well, then I don't see how else you're going to accomplish the task of getting the user to declare their intentions--unless you do it at program start-up (ie; make them have the fore-thought to tell FG what they want to do at initialization). But this would prevent ad hoc approaches using the *other* ILS. > >> And as for an automatic choice, based upon aircraft position, >> heading, >> or bearing from the station--this will be problematic as John >> mentioned. Pilot's are often required to tune NAV frequencies well >> before arriving at the initial approach fix (often the outer marker), >> and thus there's no way sufficient generalizations can safely be made >> regarding the approach they intend to use. > > Agreed. There is no way that automatic switching > based on aircraft position and/or heading will ever > be acceptable. > > In real life, the active runway is changed when the > wind requires it. Making the change at a busy airport > is a big deal, since one way or another you have to > make sure nobody is on final to the old runway. It's > even trickier if the airport doesn't have a tower. Then FG will have to make the determination of the active runway, and that's the way it is. If the user wants "realism"...well, it doesn't get much more realistic than that. > >> So John, are these 202 runways world-wide (I saw EGPH on the list, >> but >> the rest were in the US); and do you know if all of the ILS >> approaches >> on those runways are currently supported in FG? > There are 276 out of 1172 at US "K..." airports. > There are 96 out of 431 at UK "E..." airports. > There are 404 out of 3050 worldwide. I presume then for this statement, that FG currently supports all of these approaches? > >> I suppose you could just fail to support the ILS for one half of >> those >> runways, although it wouldn't be a very popular decision with the >> users I'll bet. > > There's no need for that. If course not--I was being facetious, lol. > > The simplest approach might be: > 0) For naive users, and even experienced VFR users, > they don't know and don't care about this issue, > and everybody would like to keep it that way. > 1) At startup, we shall set every reversible ILS to > the higher-numbered end (19 through 36 inclusive). > We choose this end because most users live in the > temperate zones where the prevailing westerlies > prevail most of the time. (I retract my earlier > suggestion about initializing them randomly.) > 2) There shall be a menu item, which appears when > commanded by the user -- *not spontaneously* -- and > can be used to reverse the nearby reversible ILS(s). > Perhaps an array of buttons listing the nearest 10 > airports with reversible ILSs or some such. And > maybe a textbox to allow reversing an arbitrary > airport or an arbitrary frequency. This should > suffice for single-player FGFS. This would most > likely only be used by instrument-rated pilots, or > instrument students, so we can assume they have > enough sophistication and dedication to deal with > such a popup. We need some kind of switching, > because the ILS is most needed when the weather is > very bad, and that usually means the wind is *not* > from the prevailing fair-weather direction. > 3) Multiplayer is quite a bit trickier, as previously > discussed. This is related to MP ATIS, MP lights, > pilot-controlled lights, navaid IDENT, et cetera. > This will have to be discussed quite a bit more > before anybody starts coding it. Well, I don't see that you even need to support this reversible ILS feature in the MP mode, to be honest. Shooting ILS and and other approaches under Instrument Meteorlogic Conditions (IMC) in an uncontrolled environment is problematic at best...and likely worse. If a user has made the decision to use a simulation to practice in IMC, they shouldn't really expect that each and every MP feature remain supported in FG, IMHO. It certainly isn't done that way in the real world, as the airspace is cleared for the aircraft on approach. In VMC, it's a different story of course. I personally do not see why it would be such a terrible thing to make the user declare which approach they intend to use when they first declare a frequency--they are in the process of setting up for the approach anyway, so there has to be some planning involved. Presuming they plan ahead far enough to select the correct frequency well outside the airport environment, then they would have adequate time to get configured properly. In other words, I don't see how a one-time modal text box would be all that terrible in this situation--it's a small price to pay for realism. That being said however, your idea about a selectable menu item might be a good compromise: They'll either get it right, or forget to set the frequency and mess up the approach. But I bet they wouldn't mess it up the next time around. An interesting discussion... TB ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
