Hi David, Some comments embedded in your original reply.
On Monday 27 December 2004 00:16, David Luff wrote: > Durk Talsma writes: > > I haven't implimented taxiway routing yet, so right now, each aircraft > > taxies straight from the gate to the active runway. I bet you can guess > > what my next logical move will be. :-) > > Hi Durk, > > Take a flight at KEMT with the ai-traffic turned on. There's some taxying > going on there. Okay, I'll have a look. I've actually been browsing and using some of your code from time to time, in particular your method to determine the active runway. I'm thinking about moving this code over into a new FGAirport class, which I'm converting from the old FGAirport struct, which is currently in Airports/simple.[ch]xx The first significant extention consists of a vectro of available parkings and a method to return which one is available. The next logical step would be to add code to determine the active runway, i.e: airport->getActiveRunway(); airport->getAvailableParking(); So the new FGAirport class would provide a unified method to access any airport related data. I also wrote a little tool to test preferential runway use schemes, and managed with just a few relatively simple set of rules to mimic Schiphol (EHAM)'s rather complex preferential runway use system, so I would also like to see if I can inporporate that into the FlightGear FGAirport class. From this perspective, a airport->getTaxiRoute(); function, based on your taxi code would also seem to be a logical extension to FGAirport. > > There are some good bits and some bad bits in my taxying code. The > in-memory storage of a node-arc network, and the routine to find a shortest > path between any two nodes is probably quite reasonable (now there's a > hostage to fortune ;-)), and possibly worth you using. The code to supply > the network from FGGround to the AI plane, and the code for the AI plane to > follow it, is really quite hideous, and probably still has a few potential > blow-ups in it. It really needs re-writing from scratch. Note how the > plane 'wiggles' a bit as it passes each node - I guess I ought to read up > on my control theory. Would it be an idea to return the taxi route as a series of waypoints and than let Dave Culp's AIFlightPlan code do the actual manouvering? Eventually, we need to come up with a way to override flightplan instructions, but it would seem like a good start to me to do it this way (see my original design plan: "Make sure everything works, but without worrying about separation conflics", then as a next step add seperation monitoring and handling). > > Anyway, at this point we definately need to start co-operating, since we're > going to need the same file format and editing tools for both of our AI > traffic, else users are going to suffer. The file format I used was never > meant to be permament BTW - just a one-off quick hack to get the KEMT > proof-of-concept up and running. Do you have any firm convictions in this > area already? For me, pretty much the same holds, a lot of the TrafficManager/AI manager interactions are very experimental and the same holds for the parking code. Paul Surgeon mentioned that the new xplane format allows startup locations, so we should support those if possible, but I don't know yet if these are intended for user startup or for AI parking as well. In addition, I think we should/could e-mail each other off-list some proof-of-concept file formats and decide what we need. I'll send you some stuff once I get this a little further down the line. I just started a major overhaul of the FlightPlan autogeneration code, and my current development verison of FlightGear is in a state of flux, as I'm trying to track down a major segfault. > > I think that the time has probably come for the AI systems to merge IMHO. Yes, absolutely. > I think that probably the best thing to do is for me to instantiate my > models through the Dave Culp system, since his model code is much better > than mine I think. Then I can add ATC-AI interaction in my own bit, and > anything we both need (such as taxying) can go in the AI-models (Culp) code > to be used by both of us from one bit of code. This will require the > AI-models code API to be extended so I can instantiate and control the > models programatically. I believe Erik has some plans to make sure all > models can be distributed logically between multiple and networked clients > as well - it can only help if all AI systems use the same model tree in > that respect. Any objections? I'll take a look anyway and see how much > damage I'd need to do to merge. Sounds good. From what I can tell, it is currently not possible to override AI traffic with flightplans, but it shouldn't be too hard to impliment this. Cheers, Durk _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
