Re: [Flightgear-devel] Traffic Manager update
On Sunday 21 November 2004 20:55, Durk Talsma wrote: Hi Everybody, The last couple of months have been extremely busy for me, so there wasn't much time left for FlightGear. But during the last week or so I managed to tweak my local copy of FlightGear so that the traffic manager controlled aircraft's behavior is extended in significant ways. To list some of the changes, A.I. traffic can now: - Be initialized while on the ground and remain parked until the scheduled time for take-off. - instead of disappearing at the end of a flight, load a new flight plan and wait in parking position until the next scheduled departure time. - communicate back to the traffic manager which aircraft have been deleted from the AIModels manager. The last part of the code would allow for flights that have gone out of user range to be deleted and recreated when necessary. I'm not using the latter part of the code though. I haven't submitted the new code yet, because I'd like to test it a little more. Hopefully I'll get it out sometime this week. Next, I'm thinking about creating some more traffic in and out of KSFO. Although there is no realistic aircraft parking yet, having some traffic moving at KSFO makes the area a lot more interesting. Cheers, Durk Looking forward to seeing this in action. Sounds like fun:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Traffic Manager
On Saturday 12 June 2004 04:48, Chris Metzler wrote: This is very very cool. I have one recommendation -- put a copy of this message on the wiki? Updated in the future as there's more to say about it, that sort of thing? I've been searching through mailing list archives the last couple of days, looking for descriptions of the possible elements (and possible values of elements) for different .xml files. Putting this stuff in the wiki would be good. Yes, I was thinking about that as well. Just haven't had the time to do so yet. Do you have any kind of feel for what the overhead of this is? How many concurrent routes can the traffic manager handle at once without significantly impacting the simulator? How many AI aircraft can that component handle? The overhead for the traffic manager itself is pretty low: It checks the position of only one aircraft, on every update, so the more traffic you add, the longer it takes before each position is updated. I've added close to 6500 aircraft to my test schedule, and then it took about 90 seconds, to complete the update cycle. This is also why I'm using a slightly conservative value of 500 nm distance to user as the cut-off distance to hand over traffic to the AI Model subsystem and start a more detailed simulation. I don't know how large the overhead of the AIModel subsystem will become once we start simulating high traffic loads in the vincity of the user. Is this a general thing? For instance, let's say two different planes fly from EHAM to KSFO. Will they both have to use that same EHAM-KSFO.xml as their flight plan? I looked in the PH-KC? files and didn't see an entry that specified the flight plan file, which makes me think the flight plan would be generic to any planes flying that route. True? I guess the auto-flightplan-generation will change this, but I'm just curious how it works. Yes, for now these are generic routes. The traffic manager composes the name of the flightplan based on departure and arrrival airport, and tries to open the file with the matching name. I haven't really worked out the details of the future automatic Flightplan generation scheme though... Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Traffic Manager
On Thu, 10 Jun 2004 21:46:24 +0200
Durk Talsma [EMAIL PROTECTED] wrote:
Last week, Erik Hofman was kind enough to commit the first version of a
traffic manager into cvs. Since then, I've been hinting at the
exsistence of this system, but because I was a little low on time so I
didn't have a chance to tell more about it.
This is very very cool. I have one recommendation -- put a copy of
this message on the wiki? Updated in the future as there's more to
say about it, that sort of thing? I've been searching through
mailing list archives the last couple of days, looking for descriptions
of the possible elements (and possible values of elements) for different
.xml files. Putting this stuff in the wiki would be good.
So, what is the traffic manager? Simply put, it's a subsystem that
maintains a database of routes that will be flown by aircraft listed in
this database. Based on these routing tables, it tracks the approximate
position of each aircraft, and when one of these aircraft come within
range of the user (currently hard coded as less than 500 nm), the
traffic manager creates an AIAircraft, which then continues to fly it's
assigned route.
Do you have any kind of feel for what the overhead of this is? How
many concurrent routes can the traffic manager handle at once without
significantly impacting the simulator? How many AI aircraft can
that component handle?
These traffic schedules can be found in ${FGROOT}/data/Traffic. Each
route needs to have flightplan associated with it, in
${FGROOT}/data/Data/AI/FlightPlans/ These are named -.xml, where
is the ICAO code for the departure airport and the ICAO code
of the arrival airport.
Is this a general thing? For instance, let's say two different planes
fly from EHAM to KSFO. Will they both have to use that same EHAM-KSFO.xml
as their flight plan? I looked in the PH-KC? files and didn't see an
entry that specified the flight plan file, which makes me think the flight
plan would be generic to any planes flying that route. True? I guess
the auto-flightplan-generation will change this, but I'm just curious
how it works.
Thanks.
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove snip-me. to email)
As a child I understood how to give; I have forgotten this grace since I
have become civilized. - Chief Luther Standing Bear
pgp6HQz7t3uvv.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
