On 2/24/04 at 9:41 PM Durk Talsma wrote:
>On Tuesday 24 February 2004 20:44, Erik Hofman wrote: > >> It is supported for airports that have ATC (sorry no AI traffic at >> EHLE). But indeed Eelde has ATC support and therefore can handle ATC >> traffic at the moment. > >Cool! Wasn't Lelystad supposed to get ATC "real soon" about two years ago? >I >haven't been there since returning home last December, so I don't know >what >the situation is. > >> >> I have followed an AI Cessna once but I lost in when it literally flew >> through a mountain, so I guess it is distance limited. > >Hmm, I see. So that's a little too much emhasis on the A and a bit too >less on >the I part in AI, I guess :-). [Ironically, this reminds me that IIRC, one >of >the original design goals of FlightGear (in 1996-1997 or so) was to >develop a >realistic ATC subsystem that does take terrain elevation into account and >not >direct planes into mountains. ;-) Anyways, I'm just kidding. Nothing but >compliments here. This is hard stuff to impliment.] > >Seriously though, so I understand that AI planes take-off and depart to >undefined destinations or do they return? I couldn't really figure this >out >based on the code? Maybe I should follow a chessna taking off from Eelde, >was >there's not much chance of one of those crashing into a mountain. :-) The code to generate the random AI lives in AIMgr.cxx in the ATC directory. At the moment they get generated between 6 and 25km or so from the airport and then arrive and land, either staight-in or via a downwind entry depending on direction of approach w.r.t. the active runway. They're a bit hard to follow at the moment since at one point in the flight they suddenly change direction without banking to approach the airport, I'll try and fix that ASAP. You should be able to hear them more easily than seeing them if you tune your comm radio to the tower frequency. Having departures that persist if you follow them and have an eventual destination in mind if they don't get deleted due to distance from user is definately on the TODO list. Avoiding mountains would be good - I was wondering when someone was going to notice that :-) I have given this some thought, but haven't started implementing anything yet since it could turn out to be a long slog to get something working. My guess is that the best thing to do is to have a coarse elevation map for each tile stored as a file on disk in the appropriate part of the scenery tree, and to use these to avoid terrain. The maps could include hints as to the best option to take in very mountainous areas where certain paths need to be taken to avoid the need to exceed GA type max altitudes. Getting AI traffic to work at non-towered airports shouldn't be too hard - mainly a case of altering the communication to announcing position on the common traffic frequency, and possibly running a dummy tower that doesn't communicate for the positional stuff. (At the moment stuff like whether to extend downwind for due to preceding traffic is handled by the tower class). There are loads of issues to gradually iron out - only one runway ever gets used, AI traffic on a downwind circuit approach can conflict with AI traffic or the user on a straight-in, AI traffic too close to the preceding in the circuit doesn't slow down, the user can get overtaken on either straight in or circuit approach, no facility for user to request an alternate runway from ATC, loads of stuff. > >> Robin Peel already has air corridors (airways) data for X-Plane which >> probably could be used by FlightGear as well. I think it is DAFIF(T) >> based so we can generate them ourselves also. > >That's interesting. I was always curious whether an airways database for >flightgear existed or not. It would be an interesting exersize to plot >these >in Atlas, as this would be a good start to generate flight plans. > In general I've been trying to do GA VFR type ATC and AI first, which leaves a big hole where airline type IFR stuff is basically not there. It would be good if the user could fly a simple flight plan in the 737 with ATC control from tower/departure/center/approach/tower the whole way. It would be good if an AI plane could do the same. It's probably a lot of work though to get working well for high traffic densities, but possibly not too bad for the odd one or two planes to start with. My thoughts were that an FGVectoringATC class derived from FGATC would know how to vector traffic appropriately along paths, and that FGApproach, FGCenter (En-route) and FGDeparture would be derived from that. In addition to Atlas, there is also another open-source flight planner for MSFS, called 'Nav'. It's written in MFC for windows only, but I was wondering how much work it would be to port to wxWindows and convert to reading FlightGear data. Probably a lot and not much respectively. Give me a shout if you're going to seriously hack at the ATC/AI code so we don't end up duplicating... Cheers - Dave PS. Did you ever finish your round the world FG flight? _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
