Jonathan Richards writes: > On Thursday 06 Nov 2003 1:05 pm, David Luff wrote: > > > The very very latest CVS (not the 0.9.3 release) can generate some > > situation-relevant messages from the tower to the user - if you'd like to > > participate in the ATC development then just shout, there's plenty to do! > > David - I was so enthused there, that I just started a checkout, having > forgotten 'waiting for ehofman's lock'. Sounds like something from the canal > era :�) > Maybe later...
I haven't touched the base since 0.9.3 - from an ATC standpoint you just need to checkout the source and use 0.9.3 base. I think all the Flightgear source should be fine with 0.9.3 at the moment. Once you have the most up to date code, the current capability of the ATC/AI system can best be assessed by: 1/ Start at KEMT with comm 1 and 2 tuned to 121.2 and 125.9 respectively. Either stay where you are or fly LH circuits. This gives a good idea of the current state of ATC/AI and AI/user interaction. 2/ Fly to within about 8 miles of a controlled airport, tune to the tower frequency (I start at Nottingham, EGBN, takeoff South, and tune East Midlands tower on 124.0), press ' to bring up the ATC dialog, follow the reporting instructions, and report runway vacated when you're off it. Don't tune away from tower until you're done - it's not that robust! 3/ Contact East Midlands approach (119.65) from 10 - 20 miles out, and check out Alexander's initial stab at approach vectoring (bring up the dialog with ' again after tuning approach). 4/ Tune the ATIS in (just hit the standby - selected toggle on comm1 at the default startup) to hear the only audio currently available. > I loaded up all the /ATC/*.cxx files into KDevelop this morning to see if I > could understand how it all fits together, but rapidly got lost in the > detail. Have you got a paragraph or two to hand which describes the > architecture, for want of a better word? Hmmm, that almost sounds like a subtle insult ;-) Here goes a brief description - writing a proper description has been on my TODO list for a while, and would help me as well, so I'll try and come up with something more verbose in the next few weeks. The ATC manager, FGATCMgr (ATCmgr.[ch]xx), is the glue that holds it all together. One global instance of this is called from the main FG program each loop. The manager is responsible for deciding which ATC stations should be active based on user's position and tuned frequencies, calling the update functions of active ATC stations at a reasonable rate (it tries to spread the load and not call them all at once), reference counting voices, returning pointers to and frequencies of active ATC stations if reqd, and probably more that I can't think of. You don't want to spend too much time in ATCmgr if you value your sanity!! FGATCDisplay (ATCdisplay.[ch]xx) is a class for displaying ATC, AI and the user's radio transmissions if audio is not available or not desired. Once again, one global instance of this is called from FG each loop. FGVoice (ATCVoice.[ch]xx) is a class to encapsulate a canned voice for one ATC station and voice. The only one available currently is the default ATIS voice. FGATC (ATC.[ch]xx) is a base class for all the ATC stations. Most functions are virtual so the manager can just call update etc without knowing what type of class is being called. It also contains (or will contain) basic functionality to try to communicate at the right times, and to call the appropriate renderer for the output (Voice or text display). Various ATC types are derived from this: currently ground, tower, ATIS and approach. I intend to derive FGVectoredATC from FGATC and derive all the stations that need to vector traffic between waypoints (approach, center and departure) from that. The real messy nitty-gritty stuff is within these files. Others I can think of in the future include UNICOM, AWOS and ASOS. commlist.[ch]xx contains a class to hold details of the various ATC stations available (basically just a data store and lookup) - these are mapped by frequency and position (bucket) for quick lookup. transmission.[ch]xx and transmissionlist.[ch]xx were written by Alexander Kappes, I can't really give a description of them off the top of my head although I have hacked about at them a bit! They're to do with offloading the actual phraseology for various scenarios into config files that non-coders can modify, and which can potentially be varied according to country. FGAIMgr is analogous to FGATCMgr for the AI stuff. FGAIEntity and FGAIPlane are base and first derived class respectively for AI traffic. FGAILocalTraffic is a class that can taxi in and out and fly the traffic pattern. I intend to derive all AI VFR GA traffic from it so they can fly a pattern on arrival at an airport if necessary. If you're still enthused after plowing through that description and trying to reconcile it with the spaghetti-like mess that actually masquerades for code then I can either post my TODO list with comments on what I think are the better ones to tackle as a first project, or advise on the the feasability of what you want to do with the code if you have some burning ideas. Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
