Hi Greg, On Monday 28 July 2008 17:13, Greg Hawkes wrote: > My biggest problem with FlightGear's AI traffic is not the complexity of > the XML files, nor the need to assign individual aircraft to flights > (although anything that reduces that complexity is good). Instead, the > biggest issue that I can see is that there is no way for FlightGear > users to share their flight patterns with each other.
Thanks for your comments. Actually, this problem is actually one of the reasons that prompted me to take action and try to devise a simpler approach. [ SNIP] > > One solution to this problem is to create a shared database of every > (well, every /regularly scheduled/) flight everywhere in the world. This > idea is similar to FlightGear's world scenery database. That project > claims to aim for world domination, so why not have the same aim for the > AI traffic database? Of course, problems with this idea are that 1) > maintaining the database is a huge job, 2) distributing it will be a > large download, and 3) I don't want my CPU burning cycles to simulate > traffic on the other side of the world. Just a few random thoughts: Re: 1). Having something like a web based application, where users can commit their favorite flights, and / or remove them from the database might work here. Admittedly, entering all that data is going to be a huge job. I just downloaded the current KLM time table, and it's approximatle 150 pages, small print and two columns per page. The new format for the traffic manger is very close to that of an airline time table, so that would make it a lot easier to enter the data (i.e. no more rigid scheduling). I'm really happy that Jon Stockill is checking into this. Admittedly, I'm not much of a web application programmer, so my input in this side of things is rather limited. 2). This might not be too bad actually, especially when the output data can be compressed. The new format is quite efficient in storing flight data. :-) 3). That is never going to happen by design of the traffic manager. Only flights that are in close range are being tracked using an AIModels simulation. In traffic manager terms, each aircraft is considered to be a schedule, where flights can be added to. Distant traffic is kept in memory in the form of such a schedule, and the position of each of these (on the basis of the loaded flights) is approximated at a modest rate of one per frame. So the more traffic you add, the longer the update cycle becomes. This doesn't have any impact on performance though... :-) > > Of course, what I really want is to fly from anywhere to anywhere, and > to see all of the corresponding air traffic along the way. Updated > automatically, and in real-time. Could you add that to your to-do list, > please? :-) > Provided that we can assemble enough man power to build these schedules, this can already be done. :-) Cheers, Durk ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
