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
> >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.
> >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
> 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
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