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

Reply via email to