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.
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.
For a demo, I thought it would be a nice idea to schedule some flights between
KSFO and EHAM (my home city). Since the only flight I could find was flown by
an MD11 in real-life (by KLM), I started off building a schedule around this
route. Since the total time for a return flight is almost 24 hours, I needed
to set up a weekly rotating schedule, where the aircraft that is flying EHAM
KSFO on day one, is assigned a flight to another destination on day two.
Using this approach, I set up a schedule between Schiphol Amsterdam (EHAM),
and seven other cities, on three continents: North America (KSFO, KMSP, CYVR,
and CYUL), Africa (DNMM, and DGAA), and Asia (VIDP). Because each of these is
a daily scheduled flight, I created seven aircraft schedules, where each one
is offset by one day, relative to the other.
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 DDDD-AAAA.xml, where DDDD
is the ICAO code for the departure airport and AAAA the ICAO code of the
arrival airport.
The version of the traffic manager that is now in CVS is an intermediate
development version, which still has some limitations. These are: 1) It only
handles aircraft that are enroute and ignores the ones that are parked. 2)
Once the traffic manager has handed control over to the AIManager subsystem,
the Traffic manager loses control over this aircraft and will not regain it.
3) Currently, each route listed in the traffic manager need to have a
hand-created flight plan associated with it. Currently, this rather limits
the flexibility of creating new routes. 4) Once an AIAircraft is at the end
of it's flight plan, the aircraft is deleted from memory. 5) AIAircraft
continue to fly, even when they've gone out of range.
Most of these issues are somewhere on my todo list to fix next. Especially
having the traffic manager regain control over aircraft that have flown out
of range and automatic flightplan generation are quite high on my priority
list.
Cheers,
Durk
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
