On Friday 21 January 2005 20:32, David Luff wrote:
> On 21/01/2005 at 20:04 Durk Talsma wrote:
> >So time permitting I wouldn't mind having a stab at porting (some of) your
> >
> >code to interact with the AIModel system, it that is okay with you. As I
> >mentioned yesterday, the taxiway code comes to mind. This approach might
> >actually be mutually benificial, if this would free up some time for you
> >to
> >work on taxidraw. Eventually, we need data for the AI system, such as,
> >taxiways and parkings/gates and taxidraw would be an ideal tool for that.
> >Let
> >me know what you think.
> Yes, in principle that's fine by me.  I'd like to keep the ATC system
> itself in it's own directory, but I'm happy for a significant portion, or
> possibly all of, the AI code to move over, and for you to 'take ownership'
> of it.  I'm not sure how far you want to go in moving it over - some of the

Me neither actually. As I am moving forward, I'm trying to gather some ideas. 
I'm currently mainly working on splitting up the dynamic flightplan 
generation code, so that I can generate pushback, taxi, takeoff, climb, 
cruise, decend, landing, taxi, and park, sections one at the time. This code 
is now works, albeit at a very rough an primitive level. It's now part of 
FGAIFlightplan, but could logically also be part of ATC. I'm currently 
leaning toward having the basic route generation part of the code be part of 
the AIModels codebase, and traffic monitoring be part of ATC (including some 
code that sends instructions to the AI planes to divert from their planned 

But, its a fine line to draw. AIAircraft are currently pretty senseless 
(literally: They just follow routes and don't interact very well with their 
environment). I'm thinking about adding a series of invisible paths sections 
of taxiways, and sequence each aircraft based on their position along these 
paths. then it would be relatively easy for each individual aircraft to 
determine it's distance to it's predecessor and adjust speed accordingly.

> stuff is very AI/ATC interaction specific, such as the logic to fly
> circuits, respond to ATC instructions, and alter the circuit pattern in
> response to the user position (in theory anyway - one of the little
> blighters on downwind the other day was instructed by ATC to follow me in
> whilst I was about 2 mile final on straight-in.  At about 1 mile final he
> cut in front of me, and caused me to get told to go around after taking a
> shade too long to clear the runway!).  I'll have a mull over it this w/e
> and have a think about where a good cut-off point might be, and what API
> the AIModel code will need to expose to allow the 'intelligent AI' to
> continue to do what it does if left in the AI/ATC branch.
> Certainly, taxiing and 3D model creation and management would be good
> candidates for moving over to AIModels initially, leaving the heuristic GA

Yep. Model management is already implimentent, and taxiing would seem logical 
to me. 

> generator and the circuit-flying/tower control interaction portions in the
> AI/ATC for now.  The AIModel code would need to expose an API for the
> heuristic generator to call to generate appropriate traffic, and another
> API for the 'intelligent-flying' code to have sufficient control of the
> plane.

Both would be possible relatively easily. There is already code to set target 
heading, speed, and altitude, IIRC. The only thing that would be required is 
some code to override FlightPlan control, but that shouldn't be too hard 


Flightgear-devel mailing list

Reply via email to