Re: [Flightgear-devel] reversible ILS
On 20 Dec 2009, at 00:02, John Denker wrote: 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. The off-list discussion was with me, for the record, and I apologise to John for being a bit glib, and then unresponsive - the last Saturday evening before Christmas, is not the ideal time to be discussing such things. What I should have said is, I don't think John's patch is a reasonable fix to the problem. Or rather, it fixes the major issue from John's perspective, which is un-flyable missed segments, but replaces it with another problem which I consider to be equally bad. (I would guess John will consider that my issue is less serious than the one he is trying to fix, but that's where we differ, I think). Anyway, my objection is that delegating the active runway to a user property (or menu item) is abdicating a hard problem to the user, instead of actually figuring out a 'good' solution. (Hence my glib 'not good enough' remark) It makes sense in a live ATC context, or some other situations (eg an instructor station), but for most users it's a confusing setting. 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) 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. It could be argued that John's patch is an interim step (with the heuristic being developed afterwards), and should be committed as is, but personally I don't think that's the case, and hence I do not wish to be the person who commits it to CVS - as I said off list, I'm only going to commit other people's code to CVS if I can positively convince myself that I agree with the design and code - any other stance would be untenable, really. Regards, James -- 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
Re: [Flightgear-devel] reversible ILS
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
Re: [Flightgear-devel] reversible ILS
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
Re: [Flightgear-devel] reversible ILS
On 12/20/2009 09:15 AM, stefan riemens suggested: How about making allowing one to set the proposed preferred-approach-deg property, but not requiring it. It's already not required. It has a reasonable default. Most users will never even know it's there. This is in line with real-world reality. There are some real-world pilots, including virtually all VFR pilots and even some instrument-rated pilots, who have never heard of reversible ILSs. -- 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
Re: [Flightgear-devel] reversible ILS
Every airport has a preferred runway to use. I'd suggest using that one regardless. The surface wind goes into the equation to select which runway, but it doesn't kick in until crosses a threshold. Of course, if you can find ATIS information online :) Alex Perry wrote: +1. Reversible approaches should be configured like any other ATC controlled ground system - such as runway lighting. I have no objections to an automatic selector for which ILS end to enable, but it should be based on surface wind (for example) and not the aircraft position. John Denker j...@av8n.com wrote: 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
Re: [Flightgear-devel] reversible ILS
I am unable to use MSFS. Has someone checked whether they handle reversibles with a heuristic, or are you just guessing? James Turner zakal...@mac.com wrote: On 20 Dec 2009, at 00:02, John Denker wrote: 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. The off-list discussion was with me, for the record, and I apologise to John for being a bit glib, and then unresponsive - the last Saturday evening before Christmas, is not the ideal time to be discussing such things. What I should have said is, I don't think John's patch is a reasonable fix to the problem. Or rather, it fixes the major issue from John's perspective, which is un-flyable missed segments, but replaces it with another problem which I consider to be equally bad. (I would guess John will consider that my issue is less serious than the one he is trying to fix, but that's where we differ, I think). Anyway, my objection is that delegating the active runway to a user property (or menu item) is abdicating a hard problem to the user, instead of actually figuring out a 'good' solution. (Hence my glib 'not good enough' remark) It makes sense in a live ATC context, or some other situations (eg an instructor station), but for most users it's a confusing setting. 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) 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. It could be argued that John's patch is an interim step (with the heuristic being developed afterwards), and should be committed as is, but personally I don't think that's the case, and hence I do not wish to be the person who commits it to CVS - as I said off list, I'm only going to commit other people's code to CVS if I can positively convince myself that I agree with the design and code - any other stance would be untenable, really. Regards, James -- 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
Re: [Flightgear-devel] reversible ILS
On 20 Dec 2009, at 19:08, Alex Perry wrote: I am unable to use MSFS. Has someone checked whether they handle reversibles with a heuristic, or are you just guessing? Well, that was my recollection last time I used MSFS, which was 2004 (I think). I'm assuming they used a heuristic because the ILS seemed to behave as expected for airports that I know (now) are reversible, such as 06/24 at EGPH. I would be very grateful for people with experience of current MSFS or X-plane to describe what behaviour they see in these cases, and if they experience any problems (especially with flying missed approaches, and the other various patterns John mentioned, such as circle to land) Regards, James -- 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
Re: [Flightgear-devel] reversible ILS
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
Re: [Flightgear-devel] reversible ILS
+1. Reversible approaches should be configured like any other ATC controlled ground system - such as runway lighting. I have no objections to an automatic selector for which ILS end to enable, but it should be based on surface wind (for example) and not the aircraft position. John Denker j...@av8n.com wrote: 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 -- This SF.Net email is sponsored by the Verizon Developer
Re: [Flightgear-devel] reversible ILS
On 16 Sep 2009, at 06:01, John Denker wrote: 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. snip This will have to be discussed quite a bit more before anybody starts coding it. A quick comment, wearing my software engineering hat here: there's a lot of opinions about policy here (defaults vs GUI vs heuristic rules based on winds, etc). There's also some key requirements (not upsetting VFR / casual flyers, aka 'keep Curt happy', for example) - and people have asked about control from Nasal or the ATC aircraft, and John Denker has mentioned the multiplayer situation. My point is, what I'm going to do first, is improve the *architecture*, so the policy is explicit (and centralised!). Likely this will include a Nasal interface (to be driven from a GUI dialog / ATC-controller / whatever) and I even have some ideas about synchronising the state across MP. And whatever policy is default, we're going to need a pref property to allow alternate policies to be used, I suspect. Along the way, I'm going to keep the current behaviour (with its inherent problems) working, but that's *all* I'm promising, until the architecture work is done. I now return you to the policy discussion :) Regards, James -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
John Denker wrote: 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. For case 2 the appropriate navaids/rwy directions could be set simply by requiring the pilot to call his approach (which, in real life, you have to request if you do not (cannot) accept whatever is suggested from the controller)? I haven't done any instrument approaches in FG but there could be a menu item where one selects an approach from a selectable list of approaches. Of course, this requires that approach related information is available in FG. For multiplayer, could the mp servers simply decide the settings from real weather and all MP players has to accept the settings and make the appropriate approaches? What is the level of realism to expect in multiplayer mode? Is it naive to expect that most users will land/start in the proper direction in multiplayer mode? Cheers, Jari -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
On Wed, 16 Sep 2009, Jari Häkkinen wrote: For multiplayer, could the mp servers simply decide the settings from real weather and all MP players has to accept the settings and make the appropriate approaches? What is the level of realism to expect in multiplayer mode? Is it naive to expect that most users will land/start in the proper direction in multiplayer mode? Currently the mpservers are really simple creatures - they know only where the players are and know absolutely nothing about weather or even time of day. They simply provide a information propagation service. I would prefer to keep it that way (the information propagation can certainly be made more efficient, though). From a user perspective there may very well be good reasons for not complying with the real world state (and hence fly in a slightly different world) but still enjoy being connected to MP. E.g. I switch off real weather if the current weather doesn't allow VFR and I also often offset the time of day since I want to fly in daylight, though my job prevents me from using FlightGear during that time of the day. If the active runway is selected based on the (in sim) weather users that team up for a realistic session can either all use real weather fetch or agree on a weather setting to have a reasonably uniform environment. One can also imagine letting the tower aircraft emitting information about active runway and serviceable nav aids and other users could choose to have these settings applied to their local environment. Such a thing could be implemented today by the methods used in dual-control and wildfire. (However, further development of the MP protocol can make all of them more efficient.) Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/-- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
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
Re: [Flightgear-devel] reversible ILS (was: Glideslope bugs/improvements)
On 09/15/09 06:31, Curtis Olson wrote: I believe the original intent was to make the system function in away that made it appear that whatever approach you were trying to fly was the one that was turned on. We agree that was the original intent. However it was doomed from the start, because navradio.cxx has never had any workable way of divining which approach you were trying to fly. So biasing the choice based on which approach you are most likely to be flying seems to make some sense. You don't care about aircraft heading because (I don't know) maybe you do a 180 because you get lost or you want to fly back and start over again, or whatever. The active glideslope dme ils transmitters should change when you turn away from the airport. The important thing is which end of the runway you are off of. We agree that basing it on heading doesn't work, because you might be approaching the airport from upwind and need to make a 180 to get established on the final approach course. But basing it on position doesn't work either, and is arguably worse, because a) You might be approaching the airport from upwind, and b) more importantly, you might need to fly the missed approach segment. Missed approaches are a matter of life and death in the real world. As the saying goes, if you are not prepared for the miss, you are not prepared for the approach. I think we can concede that we don't have real world controllers turning approaches and lighting on and off for us on the ground. That's not the right question to be asking. There are ways of achieving acceptable verisimilitude without having to hire actual real-world certified tower controllers. FGFS already solves problems that are vastly more complicated than reversible ILSs. So either we create an elaborate system and force the user to make all these detailed choices every time we start up the sim, or we create some functional defaults that behave like people would expect, and allow people to easily use the simulation to practice flying any published approach. No, those are not the only options. No, a workable system does not have to be elaborate. No, we do not need to force ordinary users to do anything at startup. I think it's pretty important to be able to fire up FlightGear and practice any published approach without needing to go through contortions or elaborate setup proceedures, Agreed. Right now *none* of the reversible ILSs are flyable, because of the aforementioned unrealistic behavior when approaching from upwind, and wildly unrealistic behavior on the missed approach segment. or having to repeatedly restart the sim until the particular approach we are interested randomly is enabled. Flying an ILS with a tailwind and then following the published circle-to-land procedure is not unreasonable. Indeed it is a good thing to practice. In the real world you cannot just show up at KJFK and demand that they turn on the ILS you are interested in. It is realistic to choose what airport you are interested in flying to. It is not realistic to dictate that the approach in use will be the one you are interested in. Glendower: I can call spirits from the vasty deep. Hotspur:Why, so can I, or so can any man; But will they come when you do call for them? FlightGear is used as part of FAA certified flight training devices so this is an area of the code where the basics need to work and be solid, and then if we want to get fancy and add additional realism, that's great. There is a lot of room for compromise between fancy and wrong. Right now it is wrong, as has been pointed out repeatedly over the years. It can be improved quite a bit without getting fancy. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS (was: nontrivial external situations)
Hi Folks -- Of the 3050 ILSs in section four of my copy of nav.dat, 404 of them, i.e. more than 13% of them, are reversible. That's 202 pairs, if you want to count by pairs. -- In all such pairs, both ends use the same frequency. -- In all such pairs, the two ends have different IDENT codes. -- In all such pairs, the localizers face in opposite directions. -- In all such pairs, with two dubious exceptions, the localizers are documented to be more than 1km apart. Here are a few examples Airport freqLOC-LOC distance EGPH: IVG 06 == ITH 24 (108.90) 1.817 nm KJFK: IHIQ 04L == IIWY 22L (110.90) 1.646 nm KJFK: ITLK 13L == IRTH 31R (111.50) 1.953 nm KLAX: IGPE 06R == IHQB 24L (111.70) 2.044 nm KLAX: IUWU 06L == IOSS 24R (108.50) 2.099 nm KLAX: IMKZ 07R == ILAX 25L (109.90) 2.270 nm KLAX: IIAS 07L == ICFN 25R (111.10) 2.263 nm KPHL: IPHL 09R == IGLC 27L (109.30) 2.065 nm KPHL: IVII 09L == IPDP 27R (108.95) 1.898 nm The whole list can be found at http://www.av8n.com/fly/reversible.txt There are several reasons why the two ends of such a pair must be considered _different_ ILSs, and cannot be operated simultaneously: 1) First of all, you have to ask where the localizer transmitter sits. The rule is that they sit a little ways beyond the departure end of the runway. If you tried to use a transmitter at the departure end of runway 6 to serve approaches to runway 24, the LOC course width would go to zero long before you reached the threshold of runway 24. There is no way this would go unnoticed. Also, locating the localizer transmitter at mid-field is out of the question. 2) Secondly, if you tried to serve two reciprocal runways with the same localizer, one or the other of them would be reverse sensing. There is no way this would go unnoticed. 3) If you tried to operate two transmitters at the same time, they would interfere. In particular, the outbound (missed approach) segment of one would ruin the inbound (final) segment of the other. Also there would be no way to make sense of the IDENT. And FWIW, I have experienced this first-hand. Sometimes a student is capable of forming an unshakable expectation that he will be using runway 6 right. He has the approach plate already out. He listens to the ATIS, but ignores the part about landing and departing runway two seven left. He IDENTifies the ILS, hears some code, and assumes it is the right code, even though it's not. I tell him to double-check the IDENT, whereupon he double-checks the frequency, and sure enough the frequency is right. He has a real hard time getting established on the localizer, because it is reverse sensing ... not to mention various other problems. I explain to the long-suffering controller that my student got out the wrong approach plate, and we need to go hold somewhere and sort things out. The student overhears this, and still doesn't understand what went wrong, because he is absolutely sure that there is no such thing as a reversible ILS. In contrast, a skillful instrument pilot does not really need to know or care about reversible ILSs, because the wording of the ATIS and the wording of the clearance suffice to tell him which approach plate to use. I remark that section 4-7-13 of FAA 7110.65P, which specifies the duties of air traffic controllers, briefly mentions some procedures for Switching ILS/MLS Runways. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
On 09/15/09 20:17, I wrote: Of the 3050 ILSs in section four of my copy of nav.dat, 404 of them, i.e. more than 13% of them, are reversible. FWIW if we restrict attention to US airports, i.e. having ICAO identifiers of the form K..., then 276 of the ILSs are reversible i.e. more than 23% of the 1172 total ILSs. That's 138 pairs if you want to count by pairs. The higher percentage stands to reason, given the high density of airports and air traffic in the US, and the paucity of available ILS frequencies. Bottom line: These critters are not rare. Getting FGFS to handle them properly is worth a bit of effort. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS (was: nontrivial external situations)
Well, then indeed...you're going to have to implement a textbox-style warning to the user that there may be a potential conflict at those airports. You're correct about there being an issue with making the back-course reverse sensing, when the published approach plates indicate that it shouldn't be. That would be a problem. But remember that precision approaches need to have a specified LOC width at the approach end of a runway--thus the LOC antennas are located off the departure end of the runway the required distance (as practical) to fulfill that requirement. Of course the LOC beam width can be adjusted to accommodate this, to some degree. That begs another question then though--is this accounted for in FG at present? I haven't tested it, but maybe John has. I still think an acceptable solution is to hit the user with a textbox message, advising them of the potential conflict. While Elite has apparently gone away from having it on the pilot's screen (and thus interrupting program execution) in their current software, the new improved way provides for the feature on the instructor's screen in the enterprise-level software. But I don't see how you'll get around program interruption in the case when the pilot is using the software independently--who else is going to make the choice? 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. For example, suppose an aircraft is approaching an airport from the south, but needs to use the ILS RWY 18. If RWY 36 uses a reversible ILS (weird term, and I still don't think I've ever heard it before...) and they tune to that frequency, then the only way for them to know which approach they were actually tuned in to would be the morse identifier (as John suggested). 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? 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. So if you must support the approach and cannot employ sufficient logic to make decisions as to which runway to (automatically) select when one of those frequencies is selected--then about the only option you have left is to ask the pilot which runway they intend to use... It might just be crazy enough to work. TB On Sep 15, 2009, at 10:17 PM, John Denker wrote: Hi Folks -- Of the 3050 ILSs in section four of my copy of nav.dat, 404 of them, i.e. more than 13% of them, are reversible. That's 202 pairs, if you want to count by pairs. -- In all such pairs, both ends use the same frequency. -- In all such pairs, the two ends have different IDENT codes. -- In all such pairs, the localizers face in opposite directions. -- In all such pairs, with two dubious exceptions, the localizers are documented to be more than 1km apart. Here are a few examples Airport freqLOC-LOC distance EGPH: IVG 06 == ITH 24 (108.90) 1.817 nm KJFK: IHIQ 04L == IIWY 22L (110.90) 1.646 nm KJFK: ITLK 13L == IRTH 31R (111.50) 1.953 nm KLAX: IGPE 06R == IHQB 24L (111.70) 2.044 nm KLAX: IUWU 06L == IOSS 24R (108.50) 2.099 nm KLAX: IMKZ 07R == ILAX 25L (109.90) 2.270 nm KLAX: IIAS 07L == ICFN 25R (111.10) 2.263 nm KPHL: IPHL 09R == IGLC 27L (109.30) 2.065 nm KPHL: IVII 09L == IPDP 27R (108.95) 1.898 nm The whole list can be found at http://www.av8n.com/fly/reversible.txt There are several reasons why the two ends of such a pair must be considered _different_ ILSs, and cannot be operated simultaneously: 1) First of all, you have to ask where the localizer transmitter sits. The rule is that they sit a little ways beyond the departure end of the runway. If you tried to use a transmitter at the departure end of runway 6 to serve approaches to runway 24, the LOC course width would go to zero long before you reached the threshold of runway 24. There is no way this would go unnoticed. Also, locating the localizer transmitter at mid-field is out of the question. 2) Secondly, if you tried to serve two reciprocal runways with the same localizer, one or the other of them would be reverse sensing. There is no way this would go unnoticed. 3) If you tried to operate two transmitters at the same time, they would interfere. In particular, the outbound (missed approach) segment of one would ruin the inbound (final) segment of the other. Also there would be no way to make
Re: [Flightgear-devel] reversible ILS
Well, right. They are apparently a lot more common than I gave them credit for--but it does seem that they tend to be at airports one doesn't frequent with a 172. But as many FG users are flying airline- style aircraft (and thus likely using these airports), it does become relevant. And the other problem is that if you've made the decision to support all of these approaches with NAVAIDS in Flightgear, then you've already made the decision to do it right--because these runways will all have published approach procedures that the users will have access to. Thus you cannot require them to follow some alternate procedure without published documentation. So even if there are only 10 such instances, you're pretty much stuck doing it correctly. I do agree with JD in that respect. TB On Sep 15, 2009, at 10:50 PM, John Denker wrote: On 09/15/09 20:17, I wrote: Of the 3050 ILSs in section four of my copy of nav.dat, 404 of them, i.e. more than 13% of them, are reversible. FWIW if we restrict attention to US airports, i.e. having ICAO identifiers of the form K..., then 276 of the ILSs are reversible i.e. more than 23% of the 1172 total ILSs. That's 138 pairs if you want to count by pairs. The higher percentage stands to reason, given the high density of airports and air traffic in the US, and the paucity of available ILS frequencies. Bottom line: These critters are not rare. Getting FGFS to handle them properly is worth a bit of effort. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
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. 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 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. 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. 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 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. 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. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
On Tue, 2009-09-15 at 22:01 -0700, John Denker wrote: Can I also suggest, that like most things in FG, we have a property and a Nasal API. Now I haven't thought about this very much, but rather than forcing some UI into concrete, it might be better to provide a programmatic interface, then implement a default behaviour that can be overridden later, for example a ATC aircraft may wish to manipulate and control this at some point. * Nasal interface to lookup available ILS information (from nav.dat) - airportinfo() already gives us a list of runways and headings * some properties that can be changed to switch the ILS. Then someone else can make a Menu in Nasal that uses that above to achieve item 2 outlined below. Scott. There's no need for that. 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. ** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ** -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
