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 routes. 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 either. Cheers, Durk _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
