2,733
edits
AI Traffic: Difference between revisions
Jump to navigation
Jump to search
m
http://forum.flightgear.org/viewtopic.php?f=23&t=27580 — <time> wasn't nowikied
Red Leader (talk | contribs) m (http://forum.flightgear.org/viewtopic.php?f=23&t=27580 — <time> wasn't nowikied) |
|||
| Line 71: | Line 71: | ||
Below is a complete and working example of a traffic manager II file, as it can be used with FlightGear 1.9.0 and later: | Below is a complete and working example of a traffic manager II file, as it can be used with FlightGear 1.9.0 and later: | ||
<syntaxhighlight lang="xml"> | |||
<?xml version="1.0"?> | <?xml version="1.0"?> | ||
<trafficlist> | <trafficlist> | ||
| Line 135: | Line 135: | ||
</flight> | </flight> | ||
</trafficlist> | </trafficlist> | ||
</syntaxhighlight> | |||
== Dissecting the traffic file == | == Dissecting the traffic file == | ||
Here I will discuss the general structure of a traffic file in more detail. As discussed, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections. | Here I will discuss the general structure of a traffic file in more detail. As discussed, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections. | ||
| Line 141: | Line 141: | ||
=== General layout === | === General layout === | ||
The general layout of each file should look like the above example. | The general layout of each file should look like the above example. | ||
<syntaxhighlight lang="xml"> | |||
<?xml version="1.0"?> | <?xml version="1.0"?> | ||
<trafficlist> | <trafficlist> | ||
</trafficlist> | </trafficlist> | ||
</syntaxhighlight> | |||
The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a '''<trafficlist>''' statement. Also, the last line in the file should close off the trafficlist section using the '''</trafficlist>''' statement. As will be illustrated below, between these two statements can be one or more aircraft definitions. | The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a '''<trafficlist>''' statement. Also, the last line in the file should close off the trafficlist section using the '''</trafficlist>''' statement. As will be illustrated below, between these two statements can be one or more aircraft definitions. | ||
=== Defining the aircraft === | === Defining the aircraft === | ||
<syntaxhighlight lang="xml"> | |||
<?xml version="1.0"?> | <?xml version="1.0"?> | ||
<trafficlist> | <trafficlist> | ||
| Line 169: | Line 171: | ||
</aircraft> | </aircraft> | ||
</trafficlist> | </trafficlist> | ||
</syntaxhighlight> | |||
The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics. | The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics. | ||
| Line 198: | Line 200: | ||
=== Defining a flight === | === Defining a flight === | ||
The original traffic file format contained a series of flights enclosed within the <aircraft> section, e.g., | The original traffic file format contained a series of flights enclosed within the <aircraft> section, e.g., | ||
<syntaxhighlight lang="xml"> | |||
<aircraft> | <aircraft> | ||
... | ... | ||
| Line 204: | Line 206: | ||
</flight> | </flight> | ||
</aircraft> | </aircraft> | ||
</syntaxhighlight> | |||
One major difference from this format is that the traffic manager II file formats now contain separate sections for aircraft and flight information, with the common denominator being a shared key that links aircraft and flight information together. In other words, the general layout of a traffic manager II file looks something like this: | One major difference from this format is that the traffic manager II file formats now contain separate sections for aircraft and flight information, with the common denominator being a shared key that links aircraft and flight information together. In other words, the general layout of a traffic manager II file looks something like this: | ||
<syntaxhighlight lang="xml"> | |||
<aircraft> | <aircraft> | ||
... | ... | ||
| Line 218: | Line 220: | ||
... | ... | ||
</flight> | </flight> | ||
</syntaxhighlight> | |||
Each flight is defined between the '''<flight>''' and '''</flight>''' statements. For example, let's have a look at a randomly selected flight from our KLM.xml example. | Each flight is defined between the '''<flight>''' and '''</flight>''' statements. For example, let's have a look at a randomly selected flight from our KLM.xml example. | ||
<syntaxhighlight lang="xml"> | |||
<flight> | <flight> | ||
<callsign>KLM0769</callsign> | <callsign>KLM0769</callsign> | ||
| Line 236: | Line 238: | ||
<repeat>WEEK</repeat> | <repeat>WEEK</repeat> | ||
</flight> | </flight> | ||
</syntaxhighlight> | |||
The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels, however, these should mostly be self-explanatory. The following keywords should be specified: | The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels, however, these should mostly be self-explanatory. The following keywords should be specified: | ||
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords. | * '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords. | ||
| Line 247: | Line 249: | ||
* '''<repeat>''' Repeat period. This can be either the keyword ''WEEK'', or a number followed by ''Hr''. ''WEEK'' means that the whole schedule repeats itself on a weekly basis. ''Hr'' means that the whole schedule repeats after the number of hours specified directly before it (e.g. ''24Hr'' means that the schedule repeats after 24 hours). With traffic manager II, it is generally recommended not to mix schedules that rotate on different frequencies. In general, the best results are obtained when using only weekly rotating flights. For flights that are in reality operated on a daily basis, it is recommended to just specify multiple entries, i.e. one separate flight for every weekday. | * '''<repeat>''' Repeat period. This can be either the keyword ''WEEK'', or a number followed by ''Hr''. ''WEEK'' means that the whole schedule repeats itself on a weekly basis. ''Hr'' means that the whole schedule repeats after the number of hours specified directly before it (e.g. ''24Hr'' means that the schedule repeats after 24 hours). With traffic manager II, it is generally recommended not to mix schedules that rotate on different frequencies. In general, the best results are obtained when using only weekly rotating flights. For flights that are in reality operated on a daily basis, it is recommended to just specify multiple entries, i.e. one separate flight for every weekday. | ||
* '''<port>''' This should be the international ICAO airport code. This keyword should be specified only within the '''<departure>''' or '''<arrival>''' sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes. | * '''<port>''' This should be the international ICAO airport code. This keyword should be specified only within the '''<departure>''' or '''<arrival>''' sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes. | ||
* '''<time>''' Used to specify the '''<departure>''' or '''<arrival>''' time. The format of this string is ''hour:minute:second''. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6). | * '''<nowiki><time></nowiki>''' Used to specify the '''<departure>''' or '''<arrival>''' time. The format of this string is ''hour:minute:second''. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6). | ||
== Putting it all together: Including a traffic file == | == Putting it all together: Including a traffic file == | ||