> 3) ATC/AI
> This may just be my group of friends :P, but many of them find it much
> more fun and interesting if there are other aircraft in the world, and
> if they can communicate with ATC. Durk's work in this area is making
> this easier, but ATC itself can still feel quite primitive. Coupled with
> this, people expect to start on the apron if it's there, and then to
> taxi out to the runway of their choice.

As Curt wrote earlier, the 1.0 release will probably mark the start of a new 
phase in FlightGear development. I tend to share this view, as more and more 
development efforts will shift from writing c/c++ code to designing 3D models 
and writing configuration scripts in, for example, nasal or .xml.

AI traffic and ATC is probably one of the major exception to the rule (the 
other being glass cockpit support??), because development started relatively 
late and there is still quite a bit of C++ code that needs to be written. I 
hope to have some more of the basic functionality of the AI subsystem 
working, before the famous 1.0 release. 

But, similar to the other fields of development, the AI system will ultimately 
only come to life when people start contributing traffic patterns and low res 
aircraft models (c.f. www.projectai.com). 


P.S., I just sortof finished a first stab at implimenting preferential runway 
use. I've been testing this at EHAM, where traffic has been taking off from 
runway 24 and landing on 27, just like it did today in real life. :-)

I'm considering incorporating David Luff's taxiway code before submitting my 
new code, but I'm not sure how much time I will have in the next weeks. 


Flightgear-devel mailing list

Reply via email to