8,695
edits
(→Ground networks: Update to the not so new naming conventions.) |
m (Correct table of contents) |
||
Line 112: | Line 112: | ||
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. | ||
== General | === 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. | ||
<?xml version="1.0"?> | <?xml version="1.0"?> | ||
Line 121: | Line 121: | ||
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 === | ||
<?xml version="1.0"?> | <?xml version="1.0"?> | ||
<trafficlist> | <trafficlist> | ||
Line 169: | Line 169: | ||
* '''<heavy>''' Can be true or false. Reserved for future use by ATC, to determine whether the postfix "Heavy" should be appended to the aircraft's callsign. | * '''<heavy>''' Can be true or false. Reserved for future use by ATC, to determine whether the postfix "Heavy" should be appended to the aircraft's callsign. | ||
== 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., | ||
Line 225: | Line 225: | ||
After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In earlier versions of FlightGear, this used to involve quite a bit of editing, because every file had to be referenced in a master traffic file, named fgtraffic.xml. | After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In earlier versions of FlightGear, this used to involve quite a bit of editing, because every file had to be referenced in a master traffic file, named fgtraffic.xml. | ||
Those days are gone, however, since FlightGear 1.0.0, when a directory scanning mechanism was put in place. Both FlightGear 1.0.0., and 1.9.0 and beyond use this directory scanning mechanims, however, in order to separate between the traffic manager 1 format used by FlightGear 1.0.0, and the traffic manager II format used by later versions, these files are located in two different locations. In FlightGear 1.0.0, traffic files should be located in a subdirectory of the | Those days are gone, however, since FlightGear 1.0.0, when a directory scanning mechanism was put in place. Both FlightGear 1.0.0., and 1.9.0 and beyond use this directory scanning mechanims, however, in order to separate between the traffic manager 1 format used by FlightGear 1.0.0, and the traffic manager II format used by later versions, these files are located in two different locations. In FlightGear 1.0.0, traffic files should be located in a subdirectory of the [[$FG_ROOT]]/AI/Aircraft directory. For example, traffic for a Boeing 737 could be located in in an xml file in [[$FG_ROOT]]/AI/Aircraft/737, and traffic for a 747 should be located in [[$FG_ROOT]]/AI/Aircraft/747. | ||
Since traffic files for FlightGear 1.9.0 are stricktly speaking no longer tied to one particular aircraft, or aircraft type, the traffic files were moved to a different directory, namely | Since traffic files for FlightGear 1.9.0 are stricktly speaking no longer tied to one particular aircraft, or aircraft type, the traffic files were moved to a different directory, namely [[$FG_ROOT]]/AI/Traffic. Again, the actual traffic files should be stored in a subdirectory one level below /AI/Traffic. In the demo that is provided with FlightGear 1.9.0, all traffic is organized by airline, and stored in a single letter directory. For example, KLM traffic can be found in [[$FG_ROOT]]/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in [[$FG_ROOT]]/AI/Traffic/U/UAL.xml. Although currently no formal definition exists for military or general aviation traffic, a similar scheme could be adapted. For instance, military traffic could be placed in [[$FG_ROOT]]/AI/Traffic/mil/USAF.xml | ||
== Tools == | == Tools == | ||
Line 283: | Line 283: | ||
The [[AI Schedule manager]] is a GUI based application that uses a database backend to store and perform operations on flights, fleets and aircraft for airlines. | The [[AI Schedule manager]] is a GUI based application that uses a database backend to store and perform operations on flights, fleets and aircraft for airlines. | ||
= Ground networks = | == Ground networks == | ||
The next major aspect of the AI traffic system contains taxiway information. Although the physical layout of each airport is contained in FlightGear's airport database, this information is not sufficient to provide taxiway information. Therefore AI aircraft pickup this type of routing information from an xml file inside the <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/</tt> directory/. Currently, this information is provided on a one file per airport basis, that can be found in a file called <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml</tt>, where ICAO stands for the 4 letter ICAO code for the airport in question. | The next major aspect of the AI traffic system contains taxiway information. Although the physical layout of each airport is contained in FlightGear's airport database, this information is not sufficient to provide taxiway information. Therefore AI aircraft pickup this type of routing information from an xml file inside the <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/</tt> directory/. Currently, this information is provided on a one file per airport basis, that can be found in a file called <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml</tt>, where ICAO stands for the 4 letter ICAO code for the airport in question. | ||
Line 290: | Line 290: | ||
FlightGear versions older than 2.4.0 look up the ground network in <tt>[[$FG_ROOT]]/AI/Airports/[ICAO]/parking.xml</tt>. | FlightGear versions older than 2.4.0 look up the ground network in <tt>[[$FG_ROOT]]/AI/Airports/[ICAO]/parking.xml</tt>. | ||
== A technical perspective == | === A technical perspective === | ||
A ground network file consists of four major sections: | A ground network file consists of four major sections: | ||
* The first section is optional, although recent versions of TaxiDraw add this section automatically. This section contains a list of all the radio frequencies for the airport in question. FlightGear currently (as of 1.9.0) uses these frequencies to display some ATC messages. As of FlightGear 1.9.0, only startup approval requests are implemented. You can "hear" these by tuning to the first ground frequency listed in the frequencies section. | * The first section is optional, although recent versions of TaxiDraw add this section automatically. This section contains a list of all the radio frequencies for the airport in question. FlightGear currently (as of 1.9.0) uses these frequencies to display some ATC messages. As of FlightGear 1.9.0, only startup approval requests are implemented. You can "hear" these by tuning to the first ground frequency listed in the frequencies section. | ||
Line 333: | Line 333: | ||
* '''name''' Name of the taxiway. | * '''name''' Name of the taxiway. | ||
== Creating a ground network, a practical approach == | === Creating a ground network, a practical approach === | ||
Having finished the technical description of the parking file format, the good news is that one probably doesn't need to know too much about the technical side of the file structure to create a ground network. Advanced editing capabilities are currently available in TaxiDraw, a separately available utility for airport layout, and ground network editing. This document describes the functionality of the NEW_GUI_CODE version of TaxiDraw. | Having finished the technical description of the parking file format, the good news is that one probably doesn't need to know too much about the technical side of the file structure to create a ground network. Advanced editing capabilities are currently available in TaxiDraw, a separately available utility for airport layout, and ground network editing. This document describes the functionality of the NEW_GUI_CODE version of TaxiDraw. | ||
== TaxiDraw == | === TaxiDraw === | ||
Although currently no officially released version of [[TaxiDraw]] exists with the ground editing capability, the current CVS version is capable of doing so. Network editing capabilities in TaxiDraw are currently about as stable as the other editing features, however, the ground network module is still somewhat separate from the rest of the airport project code, and ground networks will 'not' automatically be saved together with the airport project. Therefore, do regular exports while editing, to prevent loss of work. | Although currently no officially released version of [[TaxiDraw]] exists with the ground editing capability, the current CVS version is capable of doing so. Network editing capabilities in TaxiDraw are currently about as stable as the other editing features, however, the ground network module is still somewhat separate from the rest of the airport project code, and ground networks will 'not' automatically be saved together with the airport project. Therefore, do regular exports while editing, to prevent loss of work. | ||
Line 395: | Line 395: | ||
* '''Check and set pushback nodes''' this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency. | * '''Check and set pushback nodes''' this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency. | ||
== Editing the startup location parameters == | === Editing the startup location parameters === | ||
Once you have created a ground network, you'll find that it probably won't work yet in FlightGear. The main reason for this is that the default gate | Once you have created a ground network, you'll find that it probably won't work yet in FlightGear. The main reason for this is that the default gate | ||
size is set to a fairly small size, and most aircraft won't fit into the gate. Therefore, you'd need to edit the parking parameters. In addition, | size is set to a fairly small size, and most aircraft won't fit into the gate. Therefore, you'd need to edit the parking parameters. In addition, | ||
Line 405: | Line 405: | ||
You can edit the remaining parameters by loading this groundnet.xml file into a text editor. Once you are done editing make sure you import these changes into TaxiDraw immediately. Do this by going to [File| Import FlightGear AI Network]. This will open a file selection dialog. Choose the file you just edited and click okay. TaxiDraw will ask for confirmation to overwrite existing ground network data and confirm this by clicking on "yes". | You can edit the remaining parameters by loading this groundnet.xml file into a text editor. Once you are done editing make sure you import these changes into TaxiDraw immediately. Do this by going to [File| Import FlightGear AI Network]. This will open a file selection dialog. Choose the file you just edited and click okay. TaxiDraw will ask for confirmation to overwrite existing ground network data and confirm this by clicking on "yes". | ||
== Copying the ground network into FlightGear's scenery directory == | === Copying the ground network into FlightGear's scenery directory === | ||
Finally, once you have finished creating a groundnet work you can test it in FlightGear. Create a directory in your <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/</tt> directory, with the three first letters of the ICAO code of your airport. For example <tt>[[$FG_SCENERY]]/Airports/E/H/A/</tt>. Next, locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to <tt>[ICAO].groundnet.xml</tt>. | Finally, once you have finished creating a groundnet work you can test it in FlightGear. Create a directory in your <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/</tt> directory, with the three first letters of the ICAO code of your airport. For example <tt>[[$FG_SCENERY]]/Airports/E/H/A/</tt>. Next, locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to <tt>[ICAO].groundnet.xml</tt>. | ||
== Testing the network == | === Testing the network === | ||
Startup flightGear at the airport for which you have just created the network, and make sure you have traffic for that aircraft. FlightGear will check the network and report errors on the console. Aircraft than can't be placed at one of the parking locations will be placed at a default location. | Startup flightGear at the airport for which you have just created the network, and make sure you have traffic for that aircraft. FlightGear will check the network and report errors on the console. Aircraft than can't be placed at one of the parking locations will be placed at a default location. | ||
If the FlightGear AI system can't find a valid route between startup location and runway, it will list which nodes are not connected and exit. | If the FlightGear AI system can't find a valid route between startup location and runway, it will list which nodes are not connected and exit. | ||
= SIDs / STARs = | == SIDs / STARs == | ||
SID is an acronym for Standard Instrument Departure. Likewise, STAR is an acronym for [[Standard Terminal Arrival Route]]. Directly after takeoff, in particular at busy airports, aircraft follow a standard flightpath, that will keep them safely separated from arriving traffic, avoid ground obstructions, and also keeps traffic away from populated areas as much as possible. Currently, steps are in progress to allow FlightGear traffic to follow SIDs. Ultimately, the plan is to provide SID and star data in a format that can also be used by the user controlled Aircraft's Flight Management Computer. Currently, some sample data exist in the form of a PropertyList formatted xml file that contains a list of waypoints. | SID is an acronym for Standard Instrument Departure. Likewise, STAR is an acronym for [[Standard Terminal Arrival Route]]. Directly after takeoff, in particular at busy airports, aircraft follow a standard flightpath, that will keep them safely separated from arriving traffic, avoid ground obstructions, and also keeps traffic away from populated areas as much as possible. Currently, steps are in progress to allow FlightGear traffic to follow SIDs. Ultimately, the plan is to provide SID and star data in a format that can also be used by the user controlled Aircraft's Flight Management Computer. Currently, some sample data exist in the form of a PropertyList formatted xml file that contains a list of waypoints. | ||
This section of the AI Traffic documentation is meant as a stub that keeps track of the current development. At the moment of writing, some proof-of-principle data for EHAM SIDs will be committed to the World Scenery Repository, along with some experimental code in FlightGear to make use of these data. Note that these data are meant to be just that; a proof of principle. User contributions will be accepted as soon as the format has stabilized. | This section of the AI Traffic documentation is meant as a stub that keeps track of the current development. At the moment of writing, some proof-of-principle data for EHAM SIDs will be committed to the World Scenery Repository, along with some experimental code in FlightGear to make use of these data. Note that these data are meant to be just that; a proof of principle. User contributions will be accepted as soon as the format has stabilized. | ||
= Appendix: Special Notes = | == Appendix: Special Notes == | ||
== Realism == | === Realism === | ||
With [[FGFS 1.0.0]] Interactive Traffic also responds to other Non-AI aircraft. | With [[FGFS 1.0.0]] Interactive Traffic also responds to other Non-AI aircraft. | ||
The [[Airbus A320|A320]] ( and maybe some others) has working flaps and gears. | The [[Airbus A320|A320]] ( and maybe some others) has working flaps and gears. | ||
== Perfomance == | === Perfomance === | ||
With the recent versions, we have much better performance than before, so realistic density of traffic is currently possible even for slower computers. For those who are still afraid, there is an, as of yet, unpublished feature: set a new property "/sim/traffic-manager/proportion" to any value between 0 and 1 in your preferences.xml. During program start up, the traffic manager draws a random number (between 0 and 1) for each aircraft, and if that random number is smaller than the value specified in /sim/traffic-manager/proportion, the aircraft is added, otherwise it is discarded. In essence, only the specified proportion of aircraft will be loaded. | |||
Unfortunately you can't change this at runtime yet, so you need a little bit trial and error! However, it should allow the combination of slower computers and dense traffic files. | Unfortunately you can't change this at runtime yet, so you need a little bit trial and error! However, it should allow the combination of slower computers and dense traffic files. | ||
Line 430: | Line 430: | ||
== External links == | == External links == | ||
* [http://www.xs4all.nl/~dtalsma/FlightGear.html The FlightGear AI aircraft download page] | * [http://www.xs4all.nl/~dtalsma/FlightGear.html The FlightGear AI aircraft download page] | ||
* [http://www.ilovelinux.de/svn/fgfs-ffm/user/ | * [http://www.ilovelinux.de/svn/fgfs-ffm/user/[[$FG_ROOT]]/AI/ Created a dense AI traffic for EDDF, LSZH and a lot of other airports depending on real timetables. More to come!] | ||
[[Category:FlightGear feature]] |