Now that 0.7.9 is released I've got round to looking at the subject of ATC again. This is probably going to be a long post so make sure you've all had your coffee :-)
I basically hacked the ATIS support into Flightgear, on the grounds that is was the simplest possible part of ATC to implement, and could be done by that kind of thuggery. As the ATC gets extended though this approach won't be good enough, so after some thought I've come up with a proposed ATC architecture within Flightgear. I'm not an experienced programmer as far as architecture goes though (this is the only large scale C++ code that I contribute to) so I'd like to throw it out to the rest of you for consideration. At the moment I've modelled the comm/ATIS interaction on how the nav/VOR adf/ADF works in FGRadioStack. The FGRadioStack::Search() function searches for valid stations and flags hits. The FGRadioStack::Update() function processes the results of valid hits, updating the vor/adf/ils needles, and managing and updating the atis transmission. This works fine for vor/nav/adf etc since the pilot is only concerned with his/her own instruments, and it is a fairly well bounded problem. It's going to fall down with ATC since potentially the system must display messages from/to other aircraft, and the problem is much larger in scope and will thoroughly mess up radiostack.cxx. Hence I propose that all FGRadioStack does is to either just supply the selected comm frequencies to an ATC manager, or possibly do the station lookup in the Search() function and then flags hits to relevant stations to the ATC manager. The latter has the advantage that any work done by the navaid people to better model the limits of reception may be used by the comm stuff. The former has the advantage that the ATC manager will probably have to have the capability to do station/frequency lookups anyway for the AI traffic. For the ATC itself, I propose that the overall ATC is handled by one global FGATCMgr. This will accept input from several sources; the radiostack of the current aircraft (as discussed above), the position of the current aircraft, the AI traffic module, and an input module to parse input from the user of the current airplane. It will output to one global FGATCDisplay module (as the hack does at the moment) for rendering of the ATC output, either to screen or voice or both, and also directly to the AI traffic module. It will maintain instances of FGATIS, FGTower, FGEnRoute, FGGround etc as needed, possibly more than one instance of each if required. These sub-modules will do the actual work of generating the transmission contents. Its possible that it might be necessary to write an FGFlightPlan module as well - can someone tell me whether real life ATC actually knows whats in a flightplan after its been filed or is it simply a case of the pilot just requests what's on his/her flightplan? ATC potentially requires large amounts of data - airways, sid/stars, frequencies for all the types of ATC, etc etc. For now I will carry on with the STL <map> approach that the airport data and atis uses, but try to compartmentalise the reading of the data such that it will be easy to just change the data access functions if we want to move to a database or whatever in the future. None of this is going to appear very quickly (unless someone else is already working on it or planning to!) since I am very time pressed, but I will start implementing this, so get comments on the architecture in now if you think I'm going wrong please. If anyone else is working on aspects of ATC/AI traffic modelling please give me a shout since I've no desire to duplicate work. I'm sure someone mentioned on this list once that they were working on canned voice ATC, or was I imagining it? Due to the natural physical splitting of ATC into ground/tower/approach/departure etc in real life its also a prime candidate for a collaborative approach if anyone who wants to contribute to Flightgear but doesn't know where to get started fancies pitching in... Cheers - Dave -- [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
