185
edits
AI Traffic: Difference between revisions
m
→Defining a flight: capitalize proper name, remove extraneous spaces, add formatting spaces
m (→Defining the aircraft: into -> in and capitalize proper name and spelling) |
m (→Defining a flight: capitalize proper name, remove extraneous spaces, add formatting spaces) |
||
| Line 181: | Line 181: | ||
</aircraft> | </aircraft> | ||
</syntaxhighlight> | </syntaxhighlight> | ||
One major difference from this format is that the | 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"> | <syntaxhighlight lang="xml"> | ||
<aircraft> | <aircraft> | ||
| Line 190: | Line 190: | ||
<flight> | <flight> | ||
... | |||
<required-aircraft>MD11KLM</required-aircraft> | |||
... | |||
</flight> | </flight> | ||
</syntaxhighlight> | </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"> | <syntaxhighlight lang="xml"> | ||
<flight> | |||
<callsign>KLM0769</callsign> | |||
<required-aircraft>MD11KLM</required-aircraft> | |||
<fltrules>IFR</fltrules> | |||
<departure> | |||
<port>EHAM</port> | |||
<time>2/12:35:00</time> | |||
</departure> | |||
<cruise-alt>330</cruise-alt> | |||
<arrival> | |||
<port>TNCB</port> | |||
<time>2/22:15:00</time> | |||
</arrival> | |||
<repeat>WEEK</repeat> | |||
</flight> | |||
</syntaxhighlight> | </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: | ||
| Line 221: | Line 221: | ||
* '''<cruise-alt>''' Cruising altitude for this flight. This is a bit of a simplification from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions. | * '''<cruise-alt>''' Cruising altitude for this flight. This is a bit of a simplification from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions. | ||
* '''<arrival>''' Same as '''<departure>''', but now defining the port of arrival. | * '''<arrival>''' Same as '''<departure>''', but now defining the port of arrival. | ||
* '''<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 | * '''<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. | ||
* '''<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 | * '''<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 unpredictable. Times should be in UTC. Weekdays start on Sunday (0) and end on Saturday (6). | ||
== Putting it all together: Including a traffic file == | == Putting it all together: Including a traffic file == | ||