On 15 Sep 2009, at 13:15, John Denker wrote:

> Constructive suggestion:  Seriously, unless/until we
> can do a reasonable job of switching the reversible
> ILS, it would be better to not switch it at all.  In
> particular, it would be better to just settle on one
> end or the other and stick with it for the duration
> of the simulation.  I would initialize it randomly
> during startup, and leave it alone thereafter.  This
> would create a 50/50 chance of having to shoot a the
> ILS with a tailwind and then execute the circle-to-land
> procedure ... which is good practice anyway.
>
> If you make the switch visible in the property tree,
> on a per-navaid basis, anybody who really cares can
> go in there and throw the switch the way he likes.
>
> Having navradio.cxx throw the switch in mid-flight,
> based on completely bogus criteria, is really, really,
> really not appropriate.

Okay, that's food for thought, and is probably how thins will end up  
anyway, with my interim plan... see below

>
> ========================
>
> What's worse is that all of the above is only the
> tip of the iceberg.  The iceberg as a whole is what
> I call "nontrivial external situations".

<snip>
> ===
>
> I realize that doing a good job of implementing
> the external process is not easy.

I agree agree with this concept, but of course the implementation  
required is 'some' way off :)

>
> In the meantime, though, we should try to put
> in the hooks to make such a process possible
> in the future.  That is, low-level routines
> such as navradio.cxx should not be making
> high-level decisions, such as ATC decisions
> about which runway is in use.

Agreed.

My plan in this area is to create classes / extend existing classes  
which capture your 'external' state, especially regarding ATC. Some of  
those objects currently live in the AI world (including multiplayer  
aircraft), and some live in weird places. The key one which I'm going  
to be seriously messing with is FGAirportDyanmics, which essentially  
represents all the dynamic (as opposed to static, apt.dat derived)  
state of an airport. (I'm also not happy with that division of labour,  
I might replace the class completely with some other helpers to  
FGAirport)

One of these objects/helpers/etc is going to implement  
getActiveRunwayForUsage 'better'. There are various ways to define  
better - a heuristic using aircraft position, runway directions,  
current local surface wind speed and direction is one. Another is to  
use the rwyuse.xml files in the scenery. A third is just to roll a  
dice at startup as you suggested. As you point out, anything would be  
better than changing mid-approach.

I'm not sure exactly what policy I will end up with - almost certainly  
I'll default to rwyuse.xml where it exists, but the point is there  
will be an object which represents part of the Tower/Approach for an  
airport's knowledge of it's own state. It's a very small step from  
there, to attach this to better ATIS (which I know you have already  
worked on),  and then an *ambitious* person could look at making this  
do AI-based ATC. (Good luck with that task!)

Incidentally, this would also be the path to implementing 'click the  
mic to activate' PCL field lighting at non-controlled airports. I  
might well end up with FGUncontrolledAirportTower,  
FGControlledAirportTower, etc to keep things sane.

Regards,
James


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; 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

Reply via email to