FlightGear wiki - User contributions [en]

AI Traffic

2016-03-09T06:29:31Z

Durk: Random developer chat does not belong in a summary / tutorial article.

{{AI Navbar}}

'''Interactive Traffic''', or '''AI-Traffic''' (Artificial Intelligence) has come to life with [[FlightGear]] version 0.9.5. Since then FlightGear has an interactive traffic system that is based on the AI-Models subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
# Create Traffic files,
# Build ground networks for the Airports containing traffic.
# Create the appropriate Departure / Arrival procedures for each airport involved.

Notice that the "Download all AI aircraft" is no longer necessary, because most, if not all, AI aircraft are now part of the base package.

== Building Traffic Files ==
Traffic patterns are stored in data files in extended markup language (.xml) format. The actual location of these files are version dependent. For FlightGear 0.9.x, traffic files are stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<tt>[[$FG ROOT]]/Traffic/</tt>

In FlightGear 1.0, the traffic files can be found in a subdirectory of:

<tt>[[$FG ROOT]]/AI/Aircraft/</tt>

For example, traffic belonging to a united airlines 737 would be located in: <tt>[[$FG ROOT]]/AI/Aircraft/737/737-UnitedAirlines-traffic.xml</tt>

FlightGear 1.9.0 has seen yet another move. In this version, the traffic files can be located in:

<tt>[[$FG ROOT]]/AI/Traffic/</tt>

For FlightGear 1.9.0 and later, a new traffic file format was introduced (henceforth referred to as "traffic manager II" format (TM-II), in which aircraft and flights are no longer directly coupled, leading to more flexibility.

Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==
As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by [[McDonnell Douglas MD11]] aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database was originally constructed on the basis of a fixed routing table that was assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and these FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remained the same, unless a major update to the database were to take place. Real aircraft require maintenance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintenance in this respect.

There were still some significant drawbacks to this approach, nevertheless. Consider the MD11 a little further. In real life, KLM operates this aircraft on many routes that are serviced at relatively irregular intervals. For example, many flights to the Carribean are served only two or three times a week, making it extremely complicated to build completely accurate traffic files for these routes.

To circumvent these problems, a new database format was introduced in FlightGear 1.9.0. In this new format, flights are no longer directly and rigidly assigned to specific aircraft. Instead, a more generic description of a fleet is given, along with a series of flights that need to be carried out. The routing is then taken care of by FlightGear itself.

== An example of a traffic file ==

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"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>
</aircraft>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCB</registration>
<heavy>true</heavy>
</aircraft>

<flight>
<callsign>KLM0765</callsign>
<required-aircraft>MD11KLM</required-aircraft>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/12:35:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>TNCM</port>
<time>0/21:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0769</callsign>
<required-aircraft>MD11KLM</required-aircraft>
<fltrules>IFR</fltrules>
<departure>
<port>TNCM</port>
<time>3/01:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/10:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</trafficlist>
</syntaxhighlight>
== 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.

=== General layout ===
The general layout of each file should look like the above example.
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<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.

=== Defining the aircraft ===
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>
</aircraft>
<aircraft>
...
</aircraft>
</trafficlist>
</syntaxhighlight>
The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter [[ICAO]] airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
* '''<home-port>''' Each FlightGear aircraft is assigned to a home airport. Internally, this is used to ensure that routes are setup that will eventually lead back to the home airport. This is done to maintain some sensibility into the routing algorithm. '''[New for traffic manager II]'''
* '''<required-aircraft>''' This value is a key that binds aircraft and flights together. In case of this example, the key MD11KLM. Indicates that this aircraft will only carry out flights containing the same key. Usually, a combination of aircraft type, and airline will suffice for this key. In some cases, in particular, when specific aircraft / airlines are distributed across multiple hubs (i.e. home ports), it may be necessary to specify a key containing the home airport as well. For example, Delta Airlines operates 767's out of Atlanta, as well as out of New York. To separate between these two cases, it would be advisable to use two keys; one for KATL (e.g. 767DALKATL), and one for KJFK (e.g., 767DALKJFK). '''[NEW for traffic manager II]'''
* '''<actype>''' A description of the aircraft type reserved for future use in [[ATC]].
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' In the near future, this keyword will be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures. This line is also used for gate assignments and should be one of the following:
** '''ga''' (general aviation),
** '''cargo''' (cargo)
** '''gate''' (commercial passenger traffic)
** '''mil-fighter''' (military fighter)
** '''mil-cargo''' (military transport)
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:
** '''light_aircraft''' (prop driven single or twin),
** '''ww2_fighter''' (world war two fighter),
** '''jet_transport''' (modern commercial jet),
** '''jet_fighter''' (modern fighter aircraft)
** '''tanker''' (tanker aircraft), or.
** '''ufo''' (allows extreme accel/decel capabilities).
* '''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.
* '''<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 ===
The original traffic file format contained a series of flights enclosed within the <aircraft> section, e.g.,
<syntaxhighlight lang="xml">
<aircraft>
...
<flight>
</flight>
</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:
<syntaxhighlight lang="xml">
<aircraft>
...
<required-aircraft>MD11KLM</required-aircraft>
...
</aircraft>

<flight>
...
<required-aircraft> MD11KLM </required-aircraft>
...
</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.
<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>
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.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<required-aircraft>''' The key that links this flight to a particular aircraft. The see explanation in the ''aircraft'' section.
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<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.
* '''<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.
* '''<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 ==
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 [[$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 [[$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 ==
One major motivation for introducing the traffic manager II file format is to make it easier for FlightGear users to contribute to the traffic database. To further motivate this, some tools are currently in development that aim to make user interaction even easier. Although most of these tools are not ready for public use yet, it is probably worth mentioning some of these developments. First of all, the custom scenery project is working on extending their scenemodel database to store traffic. A web based front end will allow users to enter their favorite flight, and thus collect an extensive amount of traffic data. Users will be able to download the collected results and place the downloaded files in their traffic directory or get it via Terrasync.

Secondly, the author of the traffic manager code has written some scripts, mainly for private use, that will allow one to input the flight data into a simple text format and then convert the resulting text file to xml. The most important of these scripts can be found in the flightgear source package under scripts/perl/traffic/.

Creating AI traffic files this way is easy. First, you need to define the aircraft for each fleet (data taken from the June 2010 Malayasian project):

###HOMEP RegNo TypeCode Type AirLine Livery Offset Radius FltType Perf.Class Heavy Model
############################################################################################################################################

AC WMKK TF-ARN 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml
AC WMKK TF-ARJ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml
AC WMKK TF-ATZ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml

Then, you need to define all the flights according to the following layout:

########Flt.No Flt.Rules Days Departure Arrival FltLev. A/C type
################### ######### ####### ############### ############### #################

# London Heathrow (EGLL; UTC+1 ) to Kuala Lumpur (WMKK +8:00) vv.
FLIGHT Malaysian0001 IFR 0123456 21:00 EGLL 09:25 WMKK 360 747MAS
FLIGHT Malaysian0002 IFR 0123456 15:40 WMKK 04:50 EGLL 360 747MAS
FLIGHT Malaysian0003 IFR 0123456 11:00 EGLL 23:25 WMKK 360 747MAS
FLIGHT Malaysian0004 IFR 0123456 09:05 WMKK 08:15 EGLL 360 747MAS

# Frankfurt (EDDF; UTC+2 ) to Kuala Lumpur (WMKK +8:00) vv.
FLIGHT Malaysian0005 IFR 0.2.456 10:30 EDDF 22:25 WMKK 360 777MAS
FLIGHT Malaysian0006 IFR .1.3456 15:50 WMKK 04:25 EDDF 360 777MAS

Note that the flight information laid out above resembles that of a standard airline schedule table as close as possible, with a few known exceptions:
- Weekdays are in the range 0 to 6, but do follow standard airline conventions (0 = monday; 6 is sunday)
- All times in the table are in UTC; to convert from local time, as given in the airline table, subtract the airport in question's UTC offset).
- The last entry in each line (A/C type) should correspond to the ''combination'' of the '''TypeCode''' and '''Airline''' entries in the aircraft sections.

The resulting table can now easily be converted to xml output by running the conf2xml.pl (conv2xml.pl - check) script.

For Operating Systems of the Unix family, simply run conf2xml.pl from the directory where you unpacked the trafficdata.zip archive:

./conf2xml.pl

will give the output:

Writing to ADR.xml
Writing to AFL.xml
...
Writing to VLG.xml
Writing to VLM.xml

When the script encounters an error, it will stop prematurely.

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 ==
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.

For example, see the ground network for EHAM, which is found in <tt>[[$FG_SCENERY]]/Airports/E/H/A/EHAM.groundnet.xml</tt>. See the end of this page for a small excerpt from this file.

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 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 second section of the file contains the parameters of the airport's parking locations.
* The third section contains a list of all the nodes in the ground network.
* The fourth and final section contains a list of segments, or "arcs" as David Luff called them initially, which basically describe which node is connected to which other node.

Each parking and AI node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
* '''index (unique, consecutively numbered id)
* '''lat''' (latitude in decimal minutes format, for example <code>N50 56.988</code>)
* '''lon''' (longitude in decimal minutes format, for example <code>W01 21.756</code>)
* '''name''' (name as found on airport charts, for example <code>D23</code> or <code>C1</code>).

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay. See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison. Valid values for this parameter are:
** '''ga''' (general aviation),
** '''cargo''' (cargo)
** '''gate''' (commercial passenger traffic)
** '''mil-fighter''' (military fighter)
** '''mil-cargo''' (military transport)

* '''number:''' Currently used in combination with the <name> parameter to determine the full name of the gate.
* '''heading:''' The heading at which the aircraft are parked in this bay.
* '''radius:''' A value used to determine whether the aircraft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above. FlightGear uses a standard list of [[aircraft radii]] for gate assignment.
* '''airlineCodes:''' a comma-separated list of ICAO airline codes used to indicate which airlines should park here. Leave this field blank if you want any aircraft to park here.
* '''pushBackRoute:''' A number that refers to another node in the network. In a correctly configured network, the AI aircraft will taxi to this node in reverse, thus simulating being pushed back. See the documentation for the PushBack hold point type below.

Taxiway nodes contain two additional parameters:
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, or 0 otherwise
* '''holdPointType''' Describes wether the current point should be considered a holding point. This parameter can have the following values:
** '''none''' No holding point
** '''normal''' A regular holding point. This point should be placed just before the runway entrance / exit points, so that traffic will not enter the runway before receiving clearance to enter the runway. Note that support for this type of holding point is not implemented yet, but should appear sometime during 2009.
** '''CAT II/III''' A special holding point for IFR conditions. Currently not supported yet.
** '''PushBack''' A push back hold point type. Each parking can be connected to maximally one push back point, connected through a series of push back routes. Note that a push back point is optional, but that there can maximally only be one connected to each gate.

Finally, the taxiway segments contain three parameters.
* '''begin''' The id of the parking or AINode where this segment starts
* '''end''' The id of the parking or AINode where this segment ends
* '''IsPushBackRoute''' a logical value. Should be one if the current segment is part of a route connecting a gate to a push back hold point, or 0 otherwise.
* '''name''' Name of the taxiway.

=== 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.

=== 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.

See the [[TaxiDraw]] article for instructions on how to obtain a working copy of TaxiDraw.

=== Getting good reference material ===
The first step in preparation of creating a ground network consists of getting some reference material. Ideally, You'd like to find a good satellite or aerial image. If you can't find that, using a schematic diagram might also work. For airports in the United States, you can simply load USGS imagery by clicking the "USGS" button, however, for the rest of the world, this service is not available. Perhaps the best way to get a decent reference image is to use the standalone GoogleEarth program. GoogleEarth lets you zoom in to any location of the world. Center your view on the airport, and zoom to encompass the entire area. Then, save a jpg snapshot of the screen. This image can be imported in TaxiDraw. After importing, right click, goto the "lock layers" submenu and unselect the background image. Next, select the background image, right click and select the "calibrate background image". Typically, the "Uniform scale / rotation option" works best.

Although a google earth snapshot will usually give a good reference for the actual location of airport parkings, it still doesn't give much information about some of the logical aspects of the parking infrastructure. In particular, information about gate names / airline operations is not provided. Typically, this information is hard to find, but can be compiled from various sources, including wikipedia, random airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!

=== Creating the network ===
The current documentation describes the procedure for the TaxiDraw NEW_GUI_CODE branch, which is rather drastically different from the procedure used by the original TaxiDraw, previously documented here. This section describes some of the general procedures involved in building a ground network.

Note: export your work regularly: Although ground network editing capabilities have improved dramatically, this part of TaxiDraw is still somewhat separate from the rest of the code, and ground networks are not automatically saved together with the project. When exporting, TaxiDraw asks wether the ground network should be saved directly into FlightGear's data directory. Usually, this is okay, so just clicking "yes" takes care of saving the file in the correct location. Likewise, while importing an existing network, TaxiDraw first looks in FlightGear's data directory, to check for an existing default file to be inported.

[Scenery v2]: For 850 Airports, a python script is available, to automatically create a basic groundnet out of WED's earth.wed file. It converts Yellow Markings and Park Positions into a groundnet which can be read, and refined by Taxidraw. Note that both Centerline and borders are converted (remove border nodes once in Taxidraw) See [http://forum.flightgear.org/viewtopic.php?f=23&t=17990 HERE]

==== Set up a rough outline ====
To make best use of the background image, right click, choose the "view" menu, and unselect "taxiways", this way, all network drawing can be based on the real airport location. First, select the "Insert startup location" edit mode. This way, each left mouse click will place a startup location at the position of the mouse cursor. Once the major startup locations have been placed, switch back to "selection" mode, by clicking the little arrow button.

Next, start editing all the relevant startup location parameters. Parking heading can be changed by dragging the little red circular heading indicator. The parking's radius can be changed by clicking anywhere on the big red circle allows one to change the parking's radius by dragging the mouse. Although this usually works for setting up a rough draft, these parameters can directly be changed in the properties dialog. If the properties dialog is not visible, press [cntrl-p] to bring it up. It is possible to select multiple startup locations by pressing the shift key while selecting, and the parameters for each selected startup location can be changed at the same time. This is a powerful feature for editing the parameters of a whole series of parking locations, and also for equating and orienting gate radius and heading.

With the startup locations in place, select one of them. The next step will be to connect this parking area to each runway end. After selecting the parking, click on the "insert bidirectionally connected network nodes" (the two green dots icon), and start drawing. Place nodes at strategic locations, such as intersections, corners, and arcs. finally, place one node at the centerline of one of the runways. Once this is finished, one gate is connected to one end of one runway. The next job is to extend the network by connecting more gates and more runways.

Create a second branch from the existing route, which goes to another runway. To do so, press [cntrl-a] to deselect all objects. Then, select the point where you want to branch off from. Select this point using a left mouse click, while holding down the shift key. Since TaxiDraw is still in node connect mode, simply left-clicking would have resulted in placing a new node. With this node selected, continue drawing. Repeat this procedure until all runways are connected.

Then, start adding the additional gates to the network. Press [cntrl-a] to deselect all objects. Then select a gate by pressing [shift-left mouse, and start drawing unil the the gate in question is one segment away from being connected. Then, [shift left-click] the network node that this route segment should be connected to, and make sure that the correct node is selected. Then, right click, and select "connect nodes bidirectionally" from the AI nodes menu.

Repeat this procedure until all parking locations are connected to each runway.

==== Refining the network: Mark points on the runway as such ====
With the basic infrastructure in place, the next step is to fine-tune the network. The first step in this process is to mark the network nodes that are located on a runway. This is important for a number of reasons: Taxidraw needs these OnRunway points for it's network verification tool. Secondly, the use of the type of runway marking will be used in future versions of FlightGear for runway entrance / exit calculations, in addition to a host of other possible uses in routing (such as blocking a certain node then a crossing runway is in use, etc, etc).

It should be noted that there is no reason why TaxiDraw should not be able to mark the runway points as such automatically. After all, the geometry information of both runways and AI nodes is available. Although this automatic feature is planned, the TaxiDraw developers have as of yet not found the opportunity to implement this feature. Until that time, on runway marking has to be done by hand.

==== Refining the network: Set Holding points ====
Holding points are nodes in the network that do something special. They can be used by FlightGear to make traffic wait at certain specific locations. As a matter of fact, the 'normal' and 'Cat II/III' hold points are not yet used by FlightGear, but are part of the development plan. Currently, hold points are implicitly assigned by the FlightGear AI code. For instance, traffic waiting for takeoff clearance is holding at the first point before the runway. Likewise, traffic can receive a hold position instruction just before an intersection in the taxiway system, when traffic is approaching at the other leg. While these implicit hold points work reasonably, there are some limitations. Consider for example runway 07 at CYYC (Calgary Intl, Canada). In the FlightGear rendition of this airport, there are no taxiways leading to this runway, so departing aircraft should back track the runway from an entrance point at the middle of the runway. Currently that point will also become the runway entrance holding point. This is clearly undesirable, because it means that traffic is actually waiting ''on the runway'' in order to get clearance to enter it. For this reason, airport ground network designers should have a means to have explicit control over holding points. The normal hold point is meant for just that.

The Cat II/III hold point type is meant as an extension to this scheme for special IFR conditions. Support for these types in FlightGear is planned for a later stage of development though.

==== Refining the network: Pushback routes ====
With the above-mentioned refinements, the ground network should be fully working, with one notable exception. Aircraft will be driving forward when leaving the gate, making a sharp turn (while probably destroying themselves and the terminal building in the process). To prevent this, a ''push back'' route should be created. A push back route consists of at least one or more taxiway segments that have the "PushBack Route" property set to true. The last of these segments should be terminated by a PushBack HoldPoint network node.

Notice that a push back route is optional, but that parkings may never have more than one push back route. The formal criterium for a valid push back route is that each gate should have a maximum of one pushback node associated with it, which can be reached using one route only. From an editing point of view, it is sufficient to just mark a number of taxiway segments as push back, and mark the ending node as such as well.

It is important to note that the "Verify Ground network" process ''should be run'' in order to get a correctly working push back system, because this function runs some internal consistency checks. Push back routes can be very simple, from just one route segment, to fairly complex, as illustrated below. Shown here are 3 examples from the EHAM ground network. 1) Shows a fairly complex example, where all aircraft from one side of the E terminal are being linked to one shared push back point. In the example, the push back route of an aircraft departing from gate E20 is illustrated. 2) Shows a simple example, where one aircraft is being pushed back, and makes a left turn. In essence, 3) shows a similar example, but now in a slightly more crowded space, where pushback nodes are overlapping. The current push back system allows for fairly complicated behavior. To get a full understanding of it's workings, it is advisable to play with some of the existing ground networks. EHAM and KFSO currently provide the most complex setups.

Finally, please notice that you need a version of TaxiDraw with a build date of February 5, 2009, or later, for this to work correctly. Earlier version did not export the pushBackRoute attribute correctly. Support for this functionality was introduced late January 2009, but versions earlier than February 4 contain a potentially fatal bug, that may seriously damage your work.

[[File:TaxiDraw2.png|500px]]

==== Verifying the network ====
Finally, with a network complete, it is important to verify it! The verification function not only detects obvious problems with the network, it also updates some internal states that FlightGear relies. on. Presumably, an automatic verification process will be added to the export function, but until that is the case, make sure to do this manually. The verify network function can be found in the "Tools" menu.

Notice that TaxiDraw does not automatically fix problems. It is left to the user to fix the problems manually. TaxiDraw does select the offending node(s) / segments(s) for easier identification. Also note that TaxiDraw stops verifying at the first problem encountered, so it is worthwhile to continue checking until no further errors are found. Currently, the following checks are performed.

* '''On runway points''' Added on January 24, 2009, this check is most likely not yet available in any distributed version. This is currently just a very lame check to see if any point in the network has been marked as such. This check is not exhaustive, but simply meant as a reminder to the editor that the OnRunway points should still be marked. Ultimately, this check should be replaced by the aformentioned automatic geometry function.
* '''Duplicate Taxiway Segments''' It's easy to connect two network nodes twice. While this doesn't really hurt, it does add dead weight, so checking for duplicates is not a bad thing.
* '''Routing''' One of the most persisting problems, headache causing problems is that of a disconnected parking in the network. FlightGear will happily place an aircraft there, but bail out when that aircraft cannot reach the runway. The routing check attempts to prevent this. Notice that it is of utmost importance that the OnRunway points are set correctly, because TaxiDraw relies on these points for it's route finding algorithm. Because the route finding algorithm is rather computationally intensive, some progress information is currently written to the console (a proper progress bar would be nice). When a disconnected parking is found, TaxiDraw selects both the parking and the runway node. It is still left to the user to trace a route between these two points and find where the two pieces are disconnected.
* '''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 ===
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,
you'd also need to give each parking a name, and a heading, and probably airlines codes. Changing name, and heading can be done in TaxiDraw, by right
clicking on the startup location. This will bring up a dialog, in which you can change latitude, longitude, heading, and name. Once you're done editing, click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack parameters is not yet possible in TaxiDraw. So changing these requires saving the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (TaxiDraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

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 ===
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 ===
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.

=== Airports with ground networks ===
As of Sep.2015 Flightgear has 90 airports that were made with Taxidraw.
Here is a List: [[Airports with ground networks]]

[[user:laserman]] is offering additional groundnet.xml files for 7976 airports that were automatically converted from apt.dat at this URL: http://media.lug-marl.de/flightgear/7976groundnets.tgz

900 airports have a complete groundnet, the rest has only parking positions. They(and also those 90 airports that were made with taxidraw) are distributed via Terrasync since January 2016.

== 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.

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 ==
=== Realism ===
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.

=== 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.

== Related content ==
* [[Flightplan XML formats]]
* [[Status of AI in FlightGear]]

== External link ==
* [http://www.xs4all.nl/~dtalsma/FlightGear.html The FlightGear AI aircraft download page]{{dead link|2012-11}}

[[de:Interaktiver Verkehr]]

[[Category:Artificial intelligence]]
[[Category:FlightGear feature]]

FSweekend 2014

2014-10-04T08:03:58Z

Durk: new FSWeekend 2014 page.

[[File:FSweekend banner 2012.jpg|right]]
This wiki page lists all information related to [[FlightGear]]'s [[FSweekend]] 2014 attendance. FlightGear will be represented by a team of regular FlightGear developers.

'''<daysuntil in="days">01-November-2014</daysuntil>''' until the FSweekend at 1&2 November 2014.

== Booth information ==
This year will mark the start of a (hopefully long and fruitful collaboration with a big partner in the airracing world). After several years of demonstrating FlightGear in the Amsterdam / Lelystad area, and following a short stint at Innsbruck last year, this year we'll be visiting the Las Vegas / Grand Canyon area. Demo flights will be conducted off the various airorts in the area, and we'll be aiming to have a WIFI lan connection available. The main demo equipment will consist of a regular (AMD quad core) 3-monitor / 1 projector PC (DTs setup), and the 10 CPU/12 monitor "Thomas-Krenn hardware" mainframe.

=== Equipment Checklist ===
* CH Yoke (GdR) (- tentative)
* CH Rudder Pedals (GdR)(-tentative)
** Core i7 + GTX 680 + 24"
** Saitek X52 throttle and stick

* One Linux-based PC (DT)
** Three monitors
** Saitek Joystick
** Saitek Rudder Pedals
** Headset
** Sound system
* Projector and backup screen (plus center pole(!!!) (DT)
* Projector screen (TD).
* Pairs of anaglyph 3D-glasses:
** One (GdR)
** One (DT)
* Business cards

* Thomas Krenn machine with 10 monitors (TD)

== Flight information ==
=== Airports ===
Activities will mainly take place around Las Vegas and the Surrounding Areas (Grand Canyon, etc). There are several airports in the Vincity of Las Vegas, including Mccurran International Airport, Nellis Airforce Base, Grand Canyon International, as well as several regional airports in the area around the Canyon.

== External links==
* [http://www.fsweekend.com Official FSweekend website]
* [https://www.facebook.com/events/618419781560871/ Facebook event page]
* [https://plus.google.com/u/0/events/ctr3pnig5mnp9q94p23gvcc8vus Google+ event page]

[[Category:FSweekend]]

FSweekend

2014-10-04T07:03:20Z

Durk: Added a link to a (future) FSWeekend 2014 page

The '''FS Weekend''' event is the largest flight simulator event in the world. Each year it takes place at the first or second weekend of November. The event is held in the [[Aviodrome]] musuem, located at [[Lelystad Airport]], The Netherlands. Since 2006 [[FlightGear]] has been represented each year, by a small team of enthusiastics. If you like to join the team, write an email to the [http://flightgear.org/mail.html mailinglist].

Keep an eye on the [[current events]] to see what dates this years event will take place.

* [[FSweekend 2009]]
* [[FSweekend 2010]]
* [[FSweekend 2011]]
* [[FSweekend 2012]]
* [[FSweekend 2013]]
* [[FSWeekend 2014]]

== Related content ==
* [[Current events]]
* [[FlightGear Expo Checklist]]
* [[Presentation Recipe]]

== External links ==
* [http://www.fsweekend.com/ FSWeekend.com]
* [http://www.aviodrome.nl/ Aviodrome]

[[Category:FSweekend]]

FlightGear Newsletter January 2012

2012-01-05T20:35:10Z

Durk: /* Interview with a contributor (Durk Talsma) (first draft; still needs some copyediting */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== Development news ==

= Experiment: A new bounty system =

If somebody would like a specific feature implemented, it will be posted in the wiki (because there is no forum). Then if somebody wants to take on the development, they can start it and if they feel they have fulfilled the requirements, they submit the project to the person who is offering the bounty.
If it is a feature that many people want, quite often more people are adding to the bounty and then each person decides individually if the result fits their ideas and if they want to pay the bounty.
A bounty is a specific amount of money for completing a specific task which can be claimed by an individual or group which completed that task.

Read on here [[Bounty (Overview)]]

== Interview with a contributor (Durk Talsma) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* What is your forum nickname?

Hehe, guess once. ☺

* How long have you been involved in FlightGear?

Almost since the beginning, actually. I first heard about the project in 1997, when I got an email from Curt Olson, in response to a posting on the usenet newsgroup rec.aviation.simulators.

* What are your major interests in FlightGear?
I like the open nature of the project and the possibility to contribute at various levels.

* What projects are you working on right now?
I am actually doing several different things for FlightGear. My main project is developing a fully integrated AI air traffic system that contains autonomous vehicles, an ATC system that interacts with both AI controlled aircraft and with the user controlled aircraft. In addition to that, I am one of the editors of the main website, editor of the FlightGear facebook page, involved in the release process, code committer, and organizer of the annual FlightGear booth at FSWeekend in Lelystad (EHLE). In addition, I have recently taken over the administrator role for taxidraw.

* What do you plan on doing in the future?
I don’t expect the AI system ever to be finished, so I’m fully concentrating my coding efforts on this project.

* Why is it that you are interested in flight simulation or aviation in general?
As a kid I was fascinated by space travel, the Apollo missions to the moon, etc, watching every program on TV, and reading every book I could lay my hands on. As a six-year old, I visited Schiphol (EHAM) airport for the first time, and that sparked my fascination for the big jet airliners. Kind of like every kid at one stage, I wanted to become a pilot. My real interest in aviation didn’t start until I was nearly 20 though, after visiting an airshow at Leeuwarden airforce base (EHLE). This was around the same time as when I got my first PC, a second hand 286DX, which I bought from a relative living in Germany, with a 40 Mb hard disk and 1 Mb of ram. It had a German version of Microsoft Flight Simulator 4.0 preinstalled. So, in addition to learning to “fly” I learned the German word for “crash” as well.

* Are you happy with the way the FlightGear project is going?
Yes absolutely. We are currently in the process of further improving our infrastructure, by setting up things like the release plan, formalizing the rules for commit access, aircraft maintenance, and we’re brainstorming about feature requirements for the long term. Firm ideas are present for modularization of the FlightGear code, and some ideas for an integrated launcher GUI have recently been coined in a very informal setting. It will certainly take quite some time before these plans are all realized, but I think that the project is more vital and alive as ever. I’m also just amazed at some of the recent developments, such as Frederic Bouvier’s project Rembrandt, Thorsten Renk’s, local weather system, or Martin Spott’s ongoing efforts to build a unified infrastructure for scenery generation.

* What do you enjoy most about contributing to FlightGear?
I think there are a number of aspects that I really enjoy. One of them is the collaboration with other people. Being part of the development team, we’re all pretty much equals, and regardless of one’s age, background, occupation, political or religious conviction, we all share something we like and like to collaborate on. That is really enjoyable. It may also happen that somebody just jumps in and finds a solution in no time for a problem that has been cracking my brain for ages. For example, Adrian Musceac, recent work on generating AI traffic patterns was really something amazing. Likewise, I enjoy the interaction with many other talented people, such as Brett Harrison, who’s just so amazing at making convincing liveries. Obviously there are many other talented people around whom I really enjoy working with and it’s a shame I can’t name them all. Secondly, I also really enjoy having the privilege of being the first to experience a new feature for the first time. I was the first person ever to see the sun and moon appear in a desktop Flight Simulator, and that is a little bit special.

* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
Yes, my original contribution to FlightGear was some code to calculate the position of the Sun, Moon, and even the planets. Both the sun and moon are pretty much taken for granted now, but back then (in 1997) FlightGear was the first PC based simulator that actually had a physical rendering of the sun and moon! Nobody will probably even see the planets, but I got the code almost for free, once I figured our how to calculate the solar and lunar positions, so their a little bit of an Easter egg. After finishing the celestial code, and before starting the AI traffic system, I initiated many projects that I subsequently handed over to others. As such, I have extended the time calculation code to deal with local time, and to allow the user control over the time of day, and implemented the original graphical user interface (GUI) system, and the original 2D cloud layers.

* What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?
Be optimistic, be naïve, be realistic, and start modestly. Set yourself an attainable goal! I should probably explain what I mean by this. When we started out, back in 1996-1997, we were what I would now describe as incredibly optimistic in the sense that we believed that we could pull this off, but we were also somewhat naïve in the sense that we really didn’t have any firm idea about the challenges that lay ahead. But, we were able to pull it off, so this shows that we were right after all. But, if you want to contribute don’t start with your magnum opus. Before starting out, take some time to familiarize yourself with the project, get to know the code base, data structure or workflow. In addition, making a good first impression helps. Over the years we’ve seen a tremendous amount of grand ideas and not many of them have materialized, so we’re naturally a little apprehensive you may not find an immediate warm welcome, but if you do come up with a well thought-out idea, you may convince the development team, especially if you can substantiate your ideas with some working code to back it up.

* Have you previously used other flight simulators or simulation software in general?
Well, as mentioned before, I started out with FS4, and have pretty much had every version since then, until FS2004. The latter version got me interested in the AI system. When I started playing with the FS2004 equivalent of the ATC system I and began to notice its programming flaws. Determined that I could do this better, I started drawing out my own plans, and since than, I haven’t really touched any other simulator.

* How does FlightGear compare in your opinion?
I like FlightGear better because it’s a platform that is constantly moving. I almost exclusively run the cutting edge development version, so occasionally you’re in for a little surprise. Be it positive or negative. But that keeps things a little exciting to me.

* Do you remember what first got you interested in FlightGear? How did you learn about FlightGear? In other words, why did you actually download and try FG?
Yeah, that’s a long story. I was reading the usenet rec.aviation.simulators quite frequently at the time, had been exploring Linux for a few years, and finished my C++ programming course at university. This was around 1997, so the Linux distros weren’t as advanced as they are these days, and you still had to do quite a lot yourselves. One particular afternoon, I came across a usenet posting, which read “OPEN LETTER TO ALL FLIGHTSIMULATOR DEVELOPERS”. This was around the time that Microsoft FS97 was the latest version, and many users were dissatisfied. The original poster wanted to write a letter, on behalf of every dissatisfied user, to ask for a better version, asking the big game companies to incorporate their wish list. I responded to the thread, stating that if we really wanted a sim of our own, we should probably do it ourselves. I remember being a little anxious, because I wasn’t sure whether I would actually be able to substantiate that claim, if we were to follow it up. So, a few days later, I was actually a little apprehensive when I opened up my mailbox and found an email from a guy named Curt Olson, inviting me to have a look at, what would eventually become the flightgear.org website. Well, the rest is history I guess...

* What was your first impression about FlightGear?
That’s a really interesting question, because there was no FlightGear so to speak of. When I joined, Curt had hacked together a few proof-of-principle demos; the one I downloaded was called linux-demo-0.0.7.tar.gz, if I recall correctly, and it consisted of a small sample of elevation data from a chuck of terrain near Arizona, source code of a primitve (by today’s standards) OpenGL based viewer, a copy of Bruce Jackson’s larcsim FDM, and a simple keyboard interface. But it was exciting to get it to compile, and run!

* Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?
It’s scalability, open architecture, and the fact that it can be a great test bed for ideas, as well as the fact that there is no need for third party add-ons. By bringing every suitable user contribution into a single repository, we essentially create our own add-ons, and in the long run that should remove the burden from the end user to search for extensions.

* Do you think it is necessary to know how to program in order to contribute to FlightGear?
No way. In fact it never really has been a requirement, even in the old days when there was a lot more emphasis on C++ development, we already had a need for non-coding developers. Think about documentation writers, etc. These days, the balance is actually really shifting away from programming to artwork. The FlightGear world is essentially still largely an empty place, so we really have a need for high-quality buildings. Many of the exciting developments going on right now are in the development of new scenery textures, 3D modeling, and livery painting. These are actually skills that I essentially lack, so I have a lot of respect for the people working in these areas.

* Have you ever used FlightGear professionally or for educational purposes?
I once tried in my previous job, but the computer we bought for the project had serious overheating issues, so the project never really came off the ground. In the mean time, I found a different job, so the project was shelved.

* What about FlightGear as a "game", do you think it can be used as such?
Probably, I like to use FlightGear purely for fun, so usually I just make up my own challenges, such as performing a bad weather landing, taking off and landing on an aircraft carrier, or playing with my latest AI/ATC code. Once finished, the ATC code will add a little bit of a game element, because it will expect you to fly specific routes, arrive at specific locations at a specific time, so as not to clash with other traffic etc etc. The system isn’t finished yet, but with some hacking I did quite recently manage to complete a traffic circuit under guidance of the ATC system, and it’s quite tricky to do right. So, there are some “gamey” aspects of FlightGear that are quite realistic and hopefully challenging. Having said that, I see absolutely no need for any formal gaming rules, or game like features such as setting off explosives and the like. Like many of the other developers, I like to keep FlightGear civil(ized). I don’t object to simulating military aviation though, as long as it doesn’t serve the purpose of glorifying death and destruction.

* On average, how much time do you spend working with/contributing to FlightGear?
Hard to say, it varies quite a bit with my day job requirements, but I think on average maybe one or two hours a day.

* Which of the more recent FlightGear developments do you consider most interesting/appealing?
There are quite a few. Of the individual projects, I really think that project Rembrandt (Frederic Bouvier’s shadow rendering code) is really exciting. But so is the new effort to unify all the shaders, the atmospheric haze and scattering, and Thorsten Renk’s local weather. I’m also quite happy with the progress we made with the AI traffic/ATC system, even though it’s not finished yet. But, what I think is perhaps even more exciting are some of the long-term infrastructural changes we have recently discussed. I can’t say too much about that yet, because many of the ideas haven’t been formalized yet, but making FlightGear more modularized by making use of HLA technology, and perhaps a more integrated GUI and launcher program are some of the exciting developments that I can see happening in a few years from now.

* Is there some feature that you'd truly like to see in FlightGear one day?
Yeah, there are some. Obviously, I’d like to see my own project come to it’s full potential, but in addition to that, I would like to see full scenery development of the polar regions of our planet. One year ago I visited Antarctica in real life, and this is just a very exciting area for flying. I’d also like to see the possibility of lower earth orbital space flight, more seamless terrain textures.

* What do you think could be done to attract even more new users and contributors to FlightGear?
Establish a good balance between developing new stuff and doing some public relations work. For the project the key question for survival is not to attract many users, but to attract potential contributors. Obviously, the way to do this is to attract many users, and to hope that there will be a few potential contributors among them.

* What about interacting with the FlightGear community? Any tips/experiences you'd like to share?
Nothing really special; just use your everyday courtesy, and keep realizing that we’re all volunteers. I’m usually not that active on the forum or mailing list, but I can tell from 15 years of experience that an intelligent and reasonable response is far more likely to create some momentum than a hurried response that is written in a spur of emotion. Also, I have observed that there is hardly any relation between action and words on either the mailing list or the forum. So when your new to the community, just hang around, get to know the characters and try to establish whom you can trust to be a knowledgeable source of information and who just raises a lot of dust.

* Have you ever recommended FlightGear to other users, friends/family?
Not really, my friends and family aren’t really into flight simulation.

* Is there anything else you'd like to share with us?
Yeah, have a lot of fun, and if you can try to contribute something to the project.

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Snapshot releases ==
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshots depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].

The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.

=== New aircraft ===

=== Updated aircraft ===

=== Liveries ===

== Scenery corner ==
=== Dutch windturbines ===
The Netherlands have ca. 1800 windturbines at the moment. Since this month, 624 of them are in FlightGear!

Adding them is relatively easy. Since we have a generic windturbine model available (<tt>Models/Power/windturbine.xml</tt>), it's just a matter of finding the GPS coordinates. Some of the larger windparks list locations on their websites. Other windturbines can be positioned based on the FlightGear scenery (with [[CORINE]] data, for more accuracy), or via satellite imagery. [http://www.w-i-n-d.nl A website] from the Dutch government has a map that shows the locations of all windturbine(park)s.

Locations for windturbines and other shared objects can be easily submitted via [http://scenemodels.flightgear.org/submission/shared/ the new submission form], that we mentioned in last month's newsletter.

=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==
[[File:C172p-SanFrancisco.png|800px]]

Cessna c172p near San Francisco flying over the ocean.

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==
=== FlightGear on youtube ===
12 Days of Flight Tips - by [http://www.youtube.com/user/osjcag oscar]

{| class="vatop" valign="top"
! align="left" |
! align="left" |
|valign="top"|
*[http://www.youtube.com/watch?v=RbB5Sn_ag-A Day 1 - FG 2.4 Map]
*[http://www.youtube.com/watch?v=hLB7jui1U5c Day 2 - Useful Keys]
*[http://www.youtube.com/watch?v=L1aNBV7JBIs Day 3 - Animated Jetways]
*[http://www.youtube.com/watch?v=hz1c8nuY62U Day 4 - Approach & Landing tips!]
*[http://www.youtube.com/watch?v=CeFpvAR6sqg Day 5 - Wiki & Newsletter]
*[http://www.youtube.com/watch?v=0HjkFHatYMI Day 6 - Rendering Options]
|valign="top"|
*[http://www.youtube.com/watch?v=_LcZ93Q33D4 Day 7 - Cockpit Instruments]
*[http://www.youtube.com/watch?v=rITkJyTb5-Q Day 8 - Brake After Landing]
*[http://www.youtube.com/watch?v=CLCXwuWvDGQ Day 9 - Virtual Airlines]
* Day 10 - ?
* Day 11 - ?
* Day 12 - ?
|}

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

=== Call for volunteers ===
* The [[OpenRadar]] project is looking for a new maintainer.
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===

[[Category:FlightGear Newsletter|2012 01]]

FlightGear Git: splitting FGData

2011-12-12T10:22:29Z

Durk: /* A new plan for splitting fgdata */

= To Split or not to Split, that's the question =

After much discussion on the mailing list, it was decided to put the existing attempt to split FGdata on hold until further notice. The main reason for postponing the split was that, while it was considered a well intended initiative, the end result of the splitting process itself left the FlightGear fgdata project in a less than desirable state. For this reason, before another splitting attempt is to be undertaken, the pro's and con's of each step should be carefully evaluated. This article discusses some of our options and will formulate a plan of approach that can be presented to -and discussed in further depth- on the developers mailing list. Several reasons have been put forth to split fgdata:

== Reasons to split fgdata ==
* '''Advantages'''
** Aircraft authors can get commit access to their own aircraft, without granting them global fgdata access.
** When pulling fgdata, one won't have to download several gigs of aircraft data. People will have to pull the base package, but any additional aircraft will be optional.
** It will be easier for aircraft authors to check the history of their aircraft.
** Commiting will go faster, because Git will no longer have to check those thousands of files to see whether they were edited. NOTE: Can't reproduce even on really old, slow (7.2k SATA) disks.
** fgdata size decreases from 5,6 GB to 1 GB (see statistics below).

It should also be noted, however, that a split is not without potential problems:

* '''Disadvantages'''
** It will be harder to keep a local up to date copy of all aircraft. No more "git pull" to fetch all the latest updates.
*** Might be fixed by using Git submodules.<ref>[http://book.git-scm.com/5_submodules.html Git Community Book: Submoduldes]</ref>
** How to deal with licences? Until now there was a COPYING file in fgdata. When aircraft are split in separate repositories, they'll likely need to include a license reference themselves.
** Need a concept for release management, maintaining version numbers, release branches, release tags et. al.
** Quite a few unmaintained aircraft got adopted after one of the developers accidentially tripped over them. Need a plan how this would be supposed to work with split aircraft repositories, otherwise the project would axe one of the substantial principles which contributed to its success.
** Need an idea about how to subsitute the the previous "starter" package which was offered via HTTP for those who'd like to have the entire repository.

One of the most prominent reasons brought forth in favor of splitting fgdata is related to the relatively large size of the initial clone of the git repository, the relatively slow download size of gitorious, and the observation that interrupted downloads cannot be resumed. Before discussing possible alternatives to this problem, a few observations should be made with respect to the actual size of the downloaded git package:

* '''Statistics''': To obtain proper GIT repository size statistics, make sure to only check the size of the ".git" folder - which contains the history that belongs to the archive and needs to be downloaded. Once you check out a branch as a "working copy" locally, the total size of your actual file system folder increases (likely doubles), since the check-out creates a working ''copy'' of all files by ''extracting'' data from the ''compressed'' archive.
** Size of original fgdata GIT repository: 5.6GB
** Size of fgdata core GIT repository without aircraft: 1GB
** Total size of all aircraft repositories: 3.1GB
** Number of aircraft: 385

It should be noted that interrupted downloads are a potential problem; however there are a number of viable workarounds for these:
** Download an initial clone using a more robust download system, such as a bittorrent
** Download a snapshot without full project history.
** Clone the repository from a faster mirror, such as the mapserver.

It should further be noticed that git's merging and update algoritms are sufficiently efficient to deal with our ever increasing repository, so no immediate problems are to be expected in this area. Given these considerations, it appears that there are sufficient alternatives to circumvent the initial clone problem, and that the size of the git repository as such poses no immediate problem. That said, there are a number of additional reasons that make it desireable to split the fgdata repository in smaller, more manageable chunks. Splitting off the aircraft directory from the rest is a logical first step, and the main question is how to proceed with this. There are a number of possible alternatives: 1) Split off all aircraft and keep then all in a single, but separate repository. 2) Move each aircraft to its own repository, and 3), organize aircraft by logical units. Here are the advantages and disadvantages of keeping all aircaft in a single repository:

=== Keeping all aircraft under a single project ===
* '''Advantages'''
** The current fgdata-developers team can access any single aircraft, for easy/quick fixes. For example when something is found to be wrong and copied among several aircraft (which happens due to copy&paste). Or when something about the sim itself changes and aircraft msut be adapted to run on an upcoming release.
** When an aircraft developers decides to leave, the repo can easily be taken over by other developers. If the author set up his own repository, we'd have to create a new repository (and thus change all references/links).
** It allows us to use [http://flightgear-bugs.googlecode.com the bug tracker] for aircraft. Most developers won't clone aircraft repos from all kind of places, just to help fixing bugs.
* '''Disadvantages'''
** Authors won't be able to choose their own license.
*** The FlightGear Aircraft project has been set to "License: Other/Multiple". This allows (in theory, we first need to agree on this) any aircraft author to add whatever license file to his/her aircraft and still put it under the project.

=== Organizing Aircraft by Logical units ===
* '''Advantages'''
** Logical ordering units remain manageble both in terms of the number of them as well as their size
* '''Disadvantages'''
** It is difficult to come up with a good set of criteria to define the aircraft categories.

=== Assigning each aircraft to its own project ===
* '''Advantages'''
** Each aircraft developer can get commit rights to his or her own project.
* '''Disadvantages'''
** It will become increasingly difficult to maintain abandoned aircraft, or conduct maintanance
** With over 500 individual repositories it will become increasingly difficult to keep track of new developments.

Given these considerations, it can be concluded that it is desirable to separate the aircraft from the main repository. It should also be pointed out that seperating out the aircraft, and moving them all into a single repository is the sole action addressing the most urgent reason for the split, namely giving the opportunity to be more liberal in granting aircraft developers commit rights, without having to consider the integrity of the base package as such. It should furthermore be noticed that while it is technically possible to remove an entire subdirectory from a project without losing its history, it is undesirable to do so. Every split done in this manner would force every user to reclone the entire repository in question. Additionally, it is considerably more difficult to combine repositories again once they have been split. Therefore, we should be cautious in performing split operations. For this reason, the most feasible action appears to be to just separate the aircraft directory from fgdata and move this in it's entirety to a new subproject. There it can live until a new and agreed upon classification scheme for separate repositories has been developed.

Finally, the following considerations should be taken into account.
* FlightGear's release distributions are steadily increasing in size. With the proposed fgdata split, we should consider removing all aircraft, except the default cessna 172p from the base package. All others can simply be downloaded from the website. Considering that the c172p is and integral part of FlightGear, it should remain the ONLY aircraft that remains in the base package, and wich is is not moved to the new fgaircraft repository.
* It should be emphasized that GIT is a distributed revision control system, and that our current use of git is insufficient.Aircraft developers should be encouraged to set up their own personal clone on gitorious, and we should encourage aircraft developers to post more merge requests.
* As more and more people gain commit rights, some rules and guidelines are in order. We currently have a largely unwritten code of conduct that has proven to work well. With new people entering the scene, it will become necessary to put them in writing however.

= A new plan for splitting fgdata =

# Create a new git repository: fgaircraft. This repository will -for the time being- contain all current and new FlightGear aircraft except the default c172p.
# Provide images of the git repository, to alleviate the initial clone problem. Preferably, this should be done using bittorrent, or another interruptable download source, so that people with limited bandwidth, can monitor their data consumption more flexibly.
# After a few days of testing, remove all aircraft from the main fgdata repository.
# Formalize the status of the new aircraft repositories by formalizing our existing, but unwritten, code of conduct and granting new aircraft authors who agree to this code of conduct commit rights.
# Because the new system can allow us to grant a potentially large number of aircraft developers commit access, we deem it desireabe to formulate an explicit set of rules with regard to the contributor's rights and obligations. It should be noted that the following rules are not really new, but merely formalizations of our existing code of conduct. By explicitly formulating them, our main goal is to avoid misunderstanding, and to provide clear guidelines in the unlikely event of misuse of commit rights.
# Post these rule on a relatively prominent location on the main FlightGear.org website.
# Formulate and discuss plans for further separation into logical categories.
# Once a consensus has been reached further split operations can be conducted.

The rules describing the rights and obligations of committers are as follows:
# Authors who obtain commit rights to fgaircraft retain the rights to handle their own work.
# The FlightGear fgaircraft administrators are allowed to update aircraft files, but only
## to enable the use of new FlightGear features (such as adding a necessary include file or set a few property switches),
## to fix small and obvious bugs (such as fixing a misspelled property or file name), or
## to apply changes necessary to keep aircraft compatible with an upcoming FlightGear release.
# The FlightGear fgaircraft repository maintainers reserve the right to revoke commit access of an individual committer. They can only exercise their right after consensus has been reached among the maintainers, and only in cases of
## misuse of commit rights by the offending developer, or
## prolonged inactivity of the committer (more than a year of inactivity)
# Aircraft that have not been maintained by the prime committer for a prolonged period of time are considered to have been abandoned and may be assigned to a different committer. The obvious exception to this rule is formed by aircraft that have a high level of completeness that are maintained by committers who are still very active in other areas of FlightGear's development.
# Commit rights will be given after the authors have shown a reasonable level of competence in both aircraft development and GIT usage. While the aircraft developer is still in the process of obtaining the required skills, he or she can seek a mentor who will handle any merge requests.
# If the aircraft developer is uncomfortable in working with GIT he or she can also opt to choose a "mentor" who will handle the merge requests for them.
# In addition to these rules, anybody contributing to the FlightGear project is encouraged to work with personal clones and submit merge requests.

===Comments on the new plan===

(HHS comments)
That sounds like the situation we already have - the only difference: the aircraft are just splitted from FGData, and the maintainer of an Aircraft-project can get the rights to commit without any magic.
But with that there are lot of rules with exceptions. From my daily real life job I do know, that many rules with exceptions may make things more complicated and provoke discussions and conflicts.
So my question is: How can we see that "a reasonable level of competence in both aircraft development and GIT usage" is there? Does he has to be checked? Which level of competence is needed for making an aircraft?

(some answers from TorstenD)
I'd define "reasonable level of competence" for GIT as "be able be familiar with the basic everyday GIT workflow". If [http://cs.swan.ac.uk/~csoliver/ok-sat-library/internet_html/doc/doc/Git/1.7.4.1/Documentation/everyday.html everyday git] is understandable, I'd say OK.
And for aircraft development: Be able to stay in your sandbox, don't mess with other's files, be able to reuse existing (common) files, create reasonable file sizes, accept naming conventions etc. Most important: nobody is perfect, but be able to fix what you broke ;-)

--[[User:ThorstenB|ThorstenB]] 17:57, 11 December 2011 (EST): It's a huge improvement to split aircraft from the main fgdata repo. Any change to an aircraft will only affect a single aircraft. But changes to the rest of fgdata (the central Nasal, Shader, GUI directories etc) can have a massive impact: on all other aircraft, on the simulator core, or on the design/direction/structure of core parts. So, it's good to have these things separated. And I think we can allow a lot more people direct commit access once aircraft are separated - even if they all share a repo. I don't think we would see many (or any) cases of authors messing with other people's work.
And I think the rules are fine and simple enough - actually almost "common sense" when working in a collaborative environment.

--[[User:Durk|Durk]] 05:02, 12 December 2011 (EST) I would also like to mention that we don't consider the initial split to be the final stage. Additional splits are possible, but we need to carefully evaluate how we should do that. Once we do have a decent plan we can continue with phase b) of the operation. I will add that to the plan later.

--[[User:Durk|Durk]] 05:22, 12 December 2011 (EST) Oh, and before I forget: James Turner is working on providing the infrastructure for aircraft meta-data. Once this in place, we would be much more flexible in splitting, but I would be cautious to not step beyond the initial stage before James is finished with that.

(hvengel comments)
Having well defined rules it a good thing. Some (perhaps many) of the aircraft devs have little or no experience with normal software development work flows and they will need well defined rules to help them do the right thing. Reading through the proposed rules I don't see too much room for things to be incorrectly used. However because the level of experience with software work flows will be all over the place (IE. some aircraft devs are also experienced software developers/engineers and some have absolutely no experience with this type of thing) the rules should be a simple and as clear and complete as possible. Nothing should be open to interpretation.

I don't see the concern over determining GIT and/or aircraft development competence to be a significant issue. I am sure that there are a significant number of aircraft devs who are currently using merge requests who would be given commit rights right from the get go. Newer aircraft devs can work with a mentor with commit rights while they are learning GIT and aircraft development and the mentor can determine when they are ready for commit rights. However I think having a documented process for this might be a good idea.

(HHS comments)
It is good to see that the existing rules are finally formalized, so we get a clear guideline.
It is also good to see that people should be more encouraged to submit merge requests. But this also means that those with commit rights should be more encouraged to review those merge requests and commit them!

--[[User:T3r|T3r]] 15:06, 11 December 2011 (EST): Absolutely - however: as most commiters are as lazy as I am, they do not regularly check for merge requests. Picking your most trustworthy commiter from the list and asking him to handle the requests for you is probably a good idea. Reminders by PM are always welcome.

--[[User:Durk|Durk]] 05:02, 12 December 2011 (EST) Which is actually why we introduced the notion of a mentor. The primary purpose is that more one-to-one work relations between committers and contributers will be established. This will certainly benefit the overall workflow.

{{Appendix}}

FlightGear Git: splitting FGData

2011-12-12T10:02:11Z

Durk: /* Comments on the new plan */

= To Split or not to Split, that's the question =

After much discussion on the mailing list, it was decided to put the existing attempt to split FGdata on hold until further notice. The main reason for postponing the split was that, while it was considered a well intended initiative, the end result of the splitting process itself left the FlightGear fgdata project in a less than desirable state. For this reason, before another splitting attempt is to be undertaken, the pro's and con's of each step should be carefully evaluated. This article discusses some of our options and will formulate a plan of approach that can be presented to -and discussed in further depth- on the developers mailing list. Several reasons have been put forth to split fgdata:

== Reasons to split fgdata ==
* '''Advantages'''
** Aircraft authors can get commit access to their own aircraft, without granting them global fgdata access.
** When pulling fgdata, one won't have to download several gigs of aircraft data. People will have to pull the base package, but any additional aircraft will be optional.
** It will be easier for aircraft authors to check the history of their aircraft.
** Commiting will go faster, because Git will no longer have to check those thousands of files to see whether they were edited. NOTE: Can't reproduce even on really old, slow (7.2k SATA) disks.
** fgdata size decreases from 5,6 GB to 1 GB (see statistics below).

It should also be noted, however, that a split is not without potential problems:

* '''Disadvantages'''
** It will be harder to keep a local up to date copy of all aircraft. No more "git pull" to fetch all the latest updates.
*** Might be fixed by using Git submodules.<ref>[http://book.git-scm.com/5_submodules.html Git Community Book: Submoduldes]</ref>
** How to deal with licences? Until now there was a COPYING file in fgdata. When aircraft are split in separate repositories, they'll likely need to include a license reference themselves.
** Need a concept for release management, maintaining version numbers, release branches, release tags et. al.
** Quite a few unmaintained aircraft got adopted after one of the developers accidentially tripped over them. Need a plan how this would be supposed to work with split aircraft repositories, otherwise the project would axe one of the substantial principles which contributed to its success.
** Need an idea about how to subsitute the the previous "starter" package which was offered via HTTP for those who'd like to have the entire repository.

One of the most prominent reasons brought forth in favor of splitting fgdata is related to the relatively large size of the initial clone of the git repository, the relatively slow download size of gitorious, and the observation that interrupted downloads cannot be resumed. Before discussing possible alternatives to this problem, a few observations should be made with respect to the actual size of the downloaded git package:

* '''Statistics''': To obtain proper GIT repository size statistics, make sure to only check the size of the ".git" folder - which contains the history that belongs to the archive and needs to be downloaded. Once you check out a branch as a "working copy" locally, the total size of your actual file system folder increases (likely doubles), since the check-out creates a working ''copy'' of all files by ''extracting'' data from the ''compressed'' archive.
** Size of original fgdata GIT repository: 5.6GB
** Size of fgdata core GIT repository without aircraft: 1GB
** Total size of all aircraft repositories: 3.1GB
** Number of aircraft: 385

It should be noted that interrupted downloads are a potential problem; however there are a number of viable workarounds for these:
** Download an initial clone using a more robust download system, such as a bittorrent
** Download a snapshot without full project history.
** Clone the repository from a faster mirror, such as the mapserver.

It should further be noticed that git's merging and update algoritms are sufficiently efficient to deal with our ever increasing repository, so no immediate problems are to be expected in this area. Given these considerations, it appears that there are sufficient alternatives to circumvent the initial clone problem, and that the size of the git repository as such poses no immediate problem. That said, there are a number of additional reasons that make it desireable to split the fgdata repository in smaller, more manageable chunks. Splitting off the aircraft directory from the rest is a logical first step, and the main question is how to proceed with this. There are a number of possible alternatives: 1) Split off all aircraft and keep then all in a single, but separate repository. 2) Move each aircraft to its own repository, and 3), organize aircraft by logical units. Here are the advantages and disadvantages of keeping all aircaft in a single repository:

=== Keeping all aircraft under a single project ===
* '''Advantages'''
** The current fgdata-developers team can access any single aircraft, for easy/quick fixes. For example when something is found to be wrong and copied among several aircraft (which happens due to copy&paste). Or when something about the sim itself changes and aircraft msut be adapted to run on an upcoming release.
** When an aircraft developers decides to leave, the repo can easily be taken over by other developers. If the author set up his own repository, we'd have to create a new repository (and thus change all references/links).
** It allows us to use [http://flightgear-bugs.googlecode.com the bug tracker] for aircraft. Most developers won't clone aircraft repos from all kind of places, just to help fixing bugs.
* '''Disadvantages'''
** Authors won't be able to choose their own license.
*** The FlightGear Aircraft project has been set to "License: Other/Multiple". This allows (in theory, we first need to agree on this) any aircraft author to add whatever license file to his/her aircraft and still put it under the project.

=== Organizing Aircraft by Logical units ===
* '''Advantages'''
** Logical ordering units remain manageble both in terms of the number of them as well as their size
* '''Disadvantages'''
** It is difficult to come up with a good set of criteria to define the aircraft categories.

=== Assigning each aircraft to its own project ===
* '''Advantages'''
** Each aircraft developer can get commit rights to his or her own project.
* '''Disadvantages'''
** It will become increasingly difficult to maintain abandoned aircraft, or conduct maintanance
** With over 500 individual repositories it will become increasingly difficult to keep track of new developments.

Given these considerations, it can be concluded that it is desirable to separate the aircraft from the main repository. It should also be pointed out that seperating out the aircraft, and moving them all into a single repository is the sole action addressing the most urgent reason for the split, namely giving the opportunity to be more liberal in granting aircraft developers commit rights, without having to consider the integrity of the base package as such. It should furthermore be noticed that while it is technically possible to remove an entire subdirectory from a project without losing its history, it is undesirable to do so. Every split done in this manner would force every user to reclone the entire repository in question. Additionally, it is considerably more difficult to combine repositories again once they have been split. Therefore, we should be cautious in performing split operations. For this reason, the most feasible action appears to be to just separate the aircraft directory from fgdata and move this in it's entirety to a new subproject. There it can live until a new and agreed upon classification scheme for separate repositories has been developed.

Finally, the following considerations should be taken into account.
* FlightGear's release distributions are steadily increasing in size. With the proposed fgdata split, we should consider removing all aircraft, except the default cessna 172p from the base package. All others can simply be downloaded from the website. Considering that the c172p is and integral part of FlightGear, it should remain the ONLY aircraft that remains in the base package, and wich is is not moved to the new fgaircraft repository.
* It should be emphasized that GIT is a distributed revision control system, and that our current use of git is insufficient.Aircraft developers should be encouraged to set up their own personal clone on gitorious, and we should encourage aircraft developers to post more merge requests.
* As more and more people gain commit rights, some rules and guidelines are in order. We currently have a largely unwritten code of conduct that has proven to work well. With new people entering the scene, it will become necessary to put them in writing however.

= A new plan for splitting fgdata =

# Create a new git repository: fgaircraft. This repository will -for the time being- contain all current and new FlightGear aircraft except the default c172p.
# Provide images of the git repository, to alleviate the initial clone problem. Preferably, this should be done using bittorrent, or another interruptable download source, so that people with limited bandwidth, can monitor their data consumption more flexibly.
# After a few days of testing, remove all aircraft from the main fgdata repository.
# Formalize the status of the new aircraft repositories by formalizing our existing, but unwritten, code of conduct and granting new aircraft authors who agree to this code of conduct commit rights.
# Because the new system can allow us to grant a potentially large number of aircraft developers commit access, we deem it desireabe to formulate an explicit set of rules with regard to the contributor's rights and obligations. It should be noted that the following rules are not really new, but merely formalizations of our existing code of conduct. By explicitly formulating them, our main goal is to avoid misunderstanding, and to provide clear guidelines in the unlikely event of misuse of commit rights.
# Post these rule on a relatively prominent location on the main FlightGear.org website.

The rules describing the rights and obligations of committers are as follows:
# Authors who obtain commit rights to fgaircraft retain the rights to handle their own work.
# The FlightGear fgaircraft administrators are allowed to update aircraft files, but only
## to enable the use of new FlightGear features (such as adding a necessary include file or set a few property switches),
## to fix small and obvious bugs (such as fixing a misspelled property or file name), or
## to apply changes necessary to keep aircraft compatible with an upcoming FlightGear release.
# The FlightGear fgaircraft repository maintainers reserve the right to revoke commit access of an individual committer. They can only exercise their right after consensus has been reached among the maintainers, and only in cases of
## misuse of commit rights by the offending developer, or
## prolonged inactivity of the committer (more than a year of inactivity)
# Aircraft that have not been maintained by the prime committer for a prolonged period of time are considered to have been abandoned and may be assigned to a different committer. The obvious exception to this rule is formed by aircraft that have a high level of completeness that are maintained by committers who are still very active in other areas of FlightGear's development.
# Commit rights will be given after the authors have shown a reasonable level of competence in both aircraft development and GIT usage. While the aircraft developer is still in the process of obtaining the required skills, he or she can seek a mentor who will handle any merge requests.
# If the aircraft developer is uncomfortable in working with GIT he or she can also opt to choose a "mentor" who will handle the merge requests for them.
# In addition to these rules, anybody contributing to the FlightGear project is encouraged to work with personal clones and submit merge requests.

===Comments on the new plan===

(HHS comments)
That sounds like the situation we already have - the only difference: the aircraft are just splitted from FGData, and the maintainer of an Aircraft-project can get the rights to commit without any magic.
But with that there are lot of rules with exceptions. From my daily real life job I do know, that many rules with exceptions may make things more complicated and provoke discussions and conflicts.
So my question is: How can we see that "a reasonable level of competence in both aircraft development and GIT usage" is there? Does he has to be checked? Which level of competence is needed for making an aircraft?

(some answers from TorstenD)
I'd define "reasonable level of competence" for GIT as "be able be familiar with the basic everyday GIT workflow". If [http://cs.swan.ac.uk/~csoliver/ok-sat-library/internet_html/doc/doc/Git/1.7.4.1/Documentation/everyday.html everyday git] is understandable, I'd say OK.
And for aircraft development: Be able to stay in your sandbox, don't mess with other's files, be able to reuse existing (common) files, create reasonable file sizes, accept naming conventions etc. Most important: nobody is perfect, but be able to fix what you broke ;-)

--[[User:ThorstenB|ThorstenB]] 17:57, 11 December 2011 (EST): It's a huge improvement to split aircraft from the main fgdata repo. Any change to an aircraft will only affect a single aircraft. But changes to the rest of fgdata (the central Nasal, Shader, GUI directories etc) can have a massive impact: on all other aircraft, on the simulator core, or on the design/direction/structure of core parts. So, it's good to have these things separated. And I think we can allow a lot more people direct commit access once aircraft are separated - even if they all share a repo. I don't think we would see many (or any) cases of authors messing with other people's work.
And I think the rules are fine and simple enough - actually almost "common sense" when working in a collaborative environment.

--[[User:Durk|Durk]] 05:02, 12 December 2011 (EST) I would also like to mention that we don't consider the initial split to be the final stage. Additional splits are possible, but we need to carefully evaluate how we should do that. Once we do have a decent plan we can continue with phase b) of the operation. I will add that to the plan later.

(hvengel comments)
Having well defined rules it a good thing. Some (perhaps many) of the aircraft devs have little or no experience with normal software development work flows and they will need well defined rules to help them do the right thing. Reading through the proposed rules I don't see too much room for things to be incorrectly used. However because the level of experience with software work flows will be all over the place (IE. some aircraft devs are also experienced software developers/engineers and some have absolutely no experience with this type of thing) the rules should be a simple and as clear and complete as possible. Nothing should be open to interpretation.

I don't see the concern over determining GIT and/or aircraft development competence to be a significant issue. I am sure that there are a significant number of aircraft devs who are currently using merge requests who would be given commit rights right from the get go. Newer aircraft devs can work with a mentor with commit rights while they are learning GIT and aircraft development and the mentor can determine when they are ready for commit rights. However I think having a documented process for this might be a good idea.

(HHS comments)
It is good to see that the existing rules are finally formalized, so we get a clear guideline.
It is also good to see that people should be more encouraged to submit merge requests. But this also means that those with commit rights should be more encouraged to review those merge requests and commit them!

--[[User:T3r|T3r]] 15:06, 11 December 2011 (EST): Absolutely - however: as most commiters are as lazy as I am, they do not regularly check for merge requests. Picking your most trustworthy commiter from the list and asking him to handle the requests for you is probably a good idea. Reminders by PM are always welcome.

--[[User:Durk|Durk]] 05:02, 12 December 2011 (EST) Which is actually why we introduced the notion of a mentor. The primary purpose is that more one-to-one work relations between committers and contributers will be established. This will certainly benefit the overall workflow.

{{Appendix}}

FlightGear Git: splitting FGData

2011-12-09T21:25:05Z

Durk: /* Towards a plan */

FlightGear Newsletter November 2011

2011-12-01T19:11:38Z

Durk:

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

'''This newsletter contains some very important information for contributors, so read it carefully!'''

Since we publish our newsletters at the end of the month, I'd like to wish you all a very merry Christmas and a happy new year! An early present is waiting for you at the end of this page, but don't open it before December 11. ;-)

== Development news ==
=== 2.6.0 release preparations ===
{{Main article|Release plan}}
On December 17, our [[Git]] repository will be declared "frozen". This means that no new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.

Contrary to the last release cycle, aircraft in fgdata may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.

Keep in mind that the people that are able to commit your stuff are just as busy finishing their own work as you are! Therefore it is important that you create merge requests for everything that you'd like to see included in the upcoming release, as soon as possible. This includes new aircraft and large updates to existing aircraft.

Don't let it wait for tomorrow, do it today!

=== Splitting fgdata: on hold until further notice ===
{{Main article|FlightGear Git: splitting fgdata}}
After much discussion on the [[mailing list]], it was decided to put the existing attempt to split fgdata on hold until further notice. The main reason for postponing the split was that, while it was considered a well intended initiative, the end result of the splitting process itself left the FlightGear fgdata project in a less than desirable state.

For this reason, before another splitting attempt is to be undertaken, the pro's and con's of each step should be carefully evaluated. The split article has been updated to discuss some of our options and formulate a plan of approach that can be presented to -and discussed in further depth- on the developers mailing list.

Those of you that started using the [http://gitorious.org/flightgear-aircraft FlightGear Aircraft repositories], make sure to commit your updates to fgdata, or create a merge request. The FlightGear Aircraft project will '''not''' be used for the FlightGear 2.6.0 release and will likely be re-created when we reach that step in the split-plan.

=== Shaders ===
[[Image:Wakes.jpg|thumb|[[Aircraft carrier|USS Vinson]] (CVN-70) and USS Lake Champlain (CG-57)]]
Emilian and Vivian have been very busy over the last months updating and improving our [[shaders]]. The plan is to rationalize some into one "aircraft" shader, to use just one method of computing fog, and to improve the appearance of the sea by adding foam and aligning the waves with the surface wind. Along the way the appearance of wakes was improved. There is still much to be done, but the work should start to be uploaded to git soon.

It's not without cost to the frame rate, so you will need a pretty powerful video card to run all the features at the same time with the slider set to high quality: nVidia GTX 260, or the ATI equivalent is probably the minimum. By selecting a lower quality vs performance slider setting the old shaders will still be available.

== Interview with a contributor (Stuart Buchanan) ==
''Since the previous edition, we try to have a monthly interview with a contributor. Questions are available on [[interview questions]] and anyone is free to write an interview (with him-/herself) for next month's newsletter!''

* '''How long have you been involved in FlightGear?'''
I've been contributing for the last 5 or so years, and was using it before that.

* '''What are your major interests in FlightGear?'''
I dip in and out of lots of things. I've spent a lot of time in the last couple of years working on the 3D clouds, and before that random vegetation. I've created a couple of aircraft ([[Avro Vulcan|vulcanb2]], [[Mainair Flash 2 Alpha|flash2a]], [[Pitts S1C|pittss1c]]), and maintain a couple more ([[c172p]], [[Douglas A-4 Skyhawk|a4f]], [[Cub]]). I also help maintain The Manual. I'm one of the moderators on the forums, and I sometimes remember to write something for the Newsletter.

Like many contributors I spend way more time messing around with things rather than actually doing flights! I enjoy warbirds (the p51d is a big challenge for me), and the c172p or Cub for some easier flying.

* '''What project are you working on right now?'''
Trying to get more performance out of the [[3D clouds]]! I'm also looking at improving the HTML output of The Manual, so it's easier to use online.

* '''What do you plan on doing in the future?'''
Less fiddling, more flying! I have a 14 month old daughter so my FG time has been constrained, and will become more so in the future.

* '''Are you happy with the way the FlightGear project is going?'''
Absolutely. FG has never been healthier. With all the hard work people like James Turner and others have put into our Jenkins build server we're now able to produce releases every 6 months. That's a massive step forward from even two years ago. The range and quality of aircraft in the hangar continues to increase, and Martin's continual work on improving our scenery infrastructure will pay huge dividends in the future.

* '''What do you enjoy most about developing for FlightGear?'''
Getting the chance to work with a great group of people, even if I never get the chance to meet them in real life. Coming across a really nicely modelled aircraft or some new feature I never knew existed.

* '''Are there any "hidden features" you have worked on in FlightGear that new users may miss?'''
Well given the number of people that fail to RTFM, my work on The Manual :)

I also think people get used to new features very quickly, so they effectively disappear. When I created the first proper forests (with a lot of help from Tim Moore), it was pretty exciting as we'd never been able to have that density of foliage before. Nowadays we all take it for granted.

* '''What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?'''
Start small. Modify an existing aircraft rather than create a new one from scratch. It's tempting to start something new, but the amount of time and effort required to actually create a worthwhile aircraft with any realism is huge. We stand on the shoulders of giants in FG, so you might as well take advantage as much as possible!

== In the hangar ==
=== Liveries ===
The [[FlightGear livery database]] is re-opened for contributions! Due to some problems in the uploadscript no submissions were accepted for several weeks. The uploadform has been redesigned, to allow quicker and easier processing of livery packages. Comments and ideas are highly appreciated. And so are liveries of course, [http://liveries.flightgear.org/contribute.php at this link]!

At the same time, the airlines page received a new "paging", based on first letter of the airlines. This allows you to find what you're looking for in an instant.

== Scenery corner ==
[[Image:2011-11-20_-_scenery_buckets.png|thumb|Scenery buckets of FG mapserver.]]
As of November 20th, there are 1,122,603 objects positions known in [[FlightGear Scenery Database|FlightGear's scenery database]].
It is now possible to show on FG scenery map the scenery buckets. This may be useful for our fellow contributors. Thanks to Martin, Tuxklok and Elmaxo for this nice and useful update. Never seen FG's scenery mapserver? [http://mapserver.flightgear.org/map/?lon=-3.77802&lat=48.29945&zoom=9&layers=B00000TTFFTFFFTTTFTF Click here] to see how it looks like and play with the different layers to the upper right. Enjoy!

== Suggested flights ==
=== Ketchikan to Juneau ===
It's cold where we will go so dress up warm and if we are lucky we might see whales during our flight. Don't fly too high to enjoy the amazing views, and there is a small challenge at the end. The runways we will use are long enough for bigger aircraft (7000+). Total length of the trip will be around 245 NM. So, hop in the cockpit of your favourite airliner.

Alaska, here we come! Enjoy!
#Park your aircraft on PAKT, [http://www.borough.ketchikan.ak.us/airport/airport_history.htm Ketchikan International], runway 11. The wind is coming from '''South''', change the weather if needed (SE is ok too).
#Fly North towards [[NDB]] Fredericks Point on 372.0 for 94 NM.
#Fly towards [[NDB]] Five Fingers on 295.0 for 39 NM.
#Fly towards [[NDB]] Gustavus on 219.0 for 77 NM.
#Fly towards [[NDB]] Coghlan Island on 212.0 for 32 NM.
#Set the [[ILS]] on 109.9 and land your aircraft (after 4 NM) on PAJN, [http://www.juneau.org/airport/ Juneau International], runway 08.
If you feel warm after this landing, you just crossed a NORAD microwave site, so that is why.

More amazing flights can be found at [[Suggested Flights]].

== Wiki updates ==
=== Aircraft status categories ===
Now that aircraft [[Formalizing Aircraft Status|can be rated]] (on completeness/status), it made sense to put these aircraft into categories, based on their status. A small adjustment to the [[:Template:Infobox Aircraft|aircraft infobox]] made this process completely automated. All you, as wiki-aircraft-article author need to do is add the ratings to the infobox.

All status categories can be found under [[:Category:Aircraft status]].

=== Images requested ===
"A picture is worth a thousand words", as they say. Yet, lots of wiki articles lack (sufficient) imagery. To get you going, a [[:Category:Image requested|special category]] has been created, which lists articles that are in desperate need for images.

Besides missing images, there are alos quite some outdated images lying around. As time goes by, FlightGear's visuals improve. Especially over the past year or so we've seen some big improvements. When you stumble accross an out of date image, you can replace it by an up to date one:
# Click the thumbnail to go to the image's page.
# Click the "Upload a new version of this file" link, located underneath the image. This brings you to the usual upload form.
# Browse to the new image and click the upload button. You'll get asked whether you really want to overwrite an existing file. Say yes. Don't worry if you make a mistake, the wiki moderators can retrieve overwritten files easily.
# Refresh your browser (F5), to show the new image.

== Community news ==
=== FSweekend ===
[[File:FSweekend 2011 group picture.jpg|thumb|300px|Proudly presenting FlightGear, from left to right: Gijs, Lindsay, Jorg, Mathias, Durk, ThorstenB, TorstenD, Martin, and Hans.]]
This month, on November 5, and 6 the worlds’ largest annual FlightSimulator event was organized again at the Aviodrome aviation museum at Lelystad Airport, the Netherlands. Continuing our tradition, FlightGear had a strong representation, demonstrating the latest features of the upcoming FlightGear 2.6 release. During the 2-day event, we showed the latest experimental scenery developments, Thorsten Rennk's [[A local weather system|local weather]] system, an early release of the wonderful [[Douglas C-47|DC-3]] from the FlightGear france development team, as well as many other goodies. Continuing our development from last year, we now had a fully working high-end computer, provided by Thomas-Krenn computing, that was running flightgear on no less than 10 monitors and 24 CPU-cores.

In addition to presenting FlightGear on our booth, one of our team members, Durk Talsma, was also given a one hour slot to present the history of the FlightGear project, as well as it’s current state-of-the-art to a small but interested audience. As always, it’s nice to talk to the many visitors at our booth, and every year we begin to notice more recognition from the audience. As a consequence the team has gotten a number of invitations to present FlightGear among Flight Simulator clubs in the Netherlands and Belgium. The fact that [[FSweekend]] is a great place to meet people was again exemplified by the fact that we met FlightGear contributer David Van Mosselbeen, who had traveled from Belgium to catch up with the team. But perhaps the greatest surprise of the weekend was the fact that our team was met by a DC3 captain, who offered us a discount on a flight with the real DC-3, the PH-PBA ([http://liveries.flightgear.org/liveries.php?id=590 FlightGear livery]), formerly owned by his royal highness, prince Bernhard of the Netherlands, and once the first official aircraft of the Dutch government. Details of the plan are currently being worked out, so stay tuned for a short update once we have flown.

* [https://www.dropbox.com/gallery/7455889/1/FSWeekend2011?h=67c6de# Our own picture gallery]
* [http://www.youtube.com/watch?feature=player_detailpage&v=UJ8hH7uOsiE#t=82s A video, shot by a visitor], featuring our 10 screen [[Howto: Build your own procedure trainer|procedure trainer]] setup.
* [http://www.simflight.nl/2011/11/05/fsweekend-de-fotos-3/#more-29284 Various pictures] of FSweekend exhibitors (including two of our booth, all the way at the end).

=== FlightGear on YouTube ===
* A video on draoi99's Youtube channel showing some scenes of [http://youtu.be/4M-lYYkPaaw various aircraft flying in coastal areas]. The video has a "weather forecast" theme and a new feature in development - white wave tips in stormy weather - can be seen.

=== FlightGear on Google+ ===
Since this month, FlightGear is also [https://plus.google.com/111978238381658236898/ active on Google+]! Another way to reach users and promote FlightGear.

=== Forum news ===
Five years ago, on November 29 2006 the [http://flightgear.org/forums FlightGear forum] was created! In five years time:
* 4,885 '''users'''
* created 11,452 '''topics'''
* together holding 137,057 '''posts'''
* that's an average of 75.03 posts a day (taken over the whole five year period)

=== FlightGear FGPanel in Action ===
==== C172 Mini Cockpit Project ====
[[File:C172MiniCockpit1.jpg|thumb|Completed [[Cessna C172P]] Mini Cockpit using FGPanel.]]
[[File:C172MiniCockpit2.jpg|thumb|Mini Cockpit - behind the scenes...]]
[[FGPanel]], the new FlightGear utility to drive cockpit instrument panels like the [[Howto:_Build_your_own_procedure_trainer | PMPT]], has been used in another cockpit project: the ''C172p Mini Cockpit'' by ThorstenB. The project used the "standard" [[Howto:_Build_your_own_procedure_trainer#The_Almighty_USB_HID_Controller | ATMEL USB HID controller]], a second-hand TFT (13€), a piece of wood, some paint - and lots of buttons and switches. The project literally finished the night before FSWeekend - ready to be added as another exhibit at the FlightGear booth.

More photos documenting the making of the C172p Mini Cockpit are available
[http://www.flickr.com/photos/70866411@N05/sets/72157628178412177/detail/ here].

''Prize picture puzzle'': if you spot the tiny detail revealing that some photos were taken just before FSWeekend, which took place on November 5-7th in Lelystad/the Netherlands, then write to the author or newsletter editor. First correct reply wins a (now famous!) ''virtual FlightGear bottle of finest Scotch whisky'' (no "e")... ;-)

==== FGPanel Live System ====
As a byproduct of the ''C172p Mini Cockpit'', a ''[[FGPanel]] Live System'' is available now. The ''Live System'' is a complete, stand-alone software setup, including FGPanel, (partial) FGData, Linux operating system and necessary start-up scripts. The ISO image (350MB download) needs to be programmed on a CD/DVD, USB flash or hard disk drive. Just insert the CD/DVD or connect the USB/HDD drive to your (old) PC, add an (old) 3D graphics card, and an (old) TFT or monitor - and you've made the first step to your own cockpit home setup! The PC boots the image, immediately starts FGPanel and displays C172p cockpit instruments. Run the FlightGear Simulator on your main PC and enable the C172 FGPanel Protocol to transmit data to your cockpit panel PC.

The live CD is a freely available SUSE Studio project. It can also be cloned/modified/adapted to personal needs via SUSE Studio (web interface). Operating system is based on OpenSuSE Linux 12.1. FlightGear binaries (fgpanel) are directly pulled from the OpenSuSE build service (OBS).

More information available at the [http://susestudio.com/a/sBTdmU/flightgear-fgpanel SUSEStudio FGPanel] project.

=== Virtual airlines ===
==== TSA - Tristar Airlines ====
[[File:TSA1.png|thumb]]
Tristar Airlines (TSA) opened a new site to the public featuring [http://www.phpvms.net phpVMS]. We now give an even greater experience to FlightGear pilots.

TSA flies to the Caribbean islands and surrounding places. Our hub at TNCC - Curacao Hato Airport modeled by Horacio (who also modeled [[RJGG]]) is one of the most beautiful projects in FlightGear. We fly a fleet of [[Embraer]]'s and [[Cessna]]'s.

More info on the site. We hope to see you there!

[http://tsavirtual.fr.nf/index.php Tristar Airlines website]

== FlightGear in the news ==
=== LINUX Format ===
FlightGear 2.4 is featured in the December issue of [http://http://www.linuxformat.com/ LINUX Format], published in the UK, the software is included on the cover disc and there is a 1-page review in the magazine. FlightGear got an overall rating of 8/10: 9/10 for Ease of use and Documentation and 6/10 and 7/10, respectively, for Performance and Features. See the review below:

[[File:Lxformatdecllfg.jpg|300px|LINUX Format Review|alt=LINUX Format Review]]

=== MicroSim ===
As promised in the previous edition, French magazine [http://microsim.over-blog.com/ MicroSim] published a tutorial for new Flightgear users.

[[File:MicroSim_nov2011_1.png|300px]]
[[File:MicroSim_nov2011_2.png|300px]]

[[File:MicroSim_nov2011_3.png|300px]]
[[File:MicroSim_nov2011_4.png|300px]]

== And finally ... ==
===A christmas present for you===
[[File:Gerbrandytoren_christmas.jpg|thumb|World's (and thus FlightGear's) largest Christmas tree.|270px]]
Do not forget to pay a visit to the [http://en.wikipedia.org/wiki/Gerbrandy_Tower Gerbrandytoren] in the Netherlands. With a height of 366.8m and 120 lights, it is the world's largest Christmas tree between December 11 and January 6. The tower is located 21 nm South East (HDG 120h) of [[Amsterdam Airport Schiphol]] ([http://mpmap02.flightgear.org/?ll=52.009982,5.053582&z=15 location on MPMap]) and accurately modeled in FlightGear, including the Christmas decoration!

Sadly the tower won't be decorated in real life this year; due to construction work after a fire earlier this year. Luckily FlightGear is not affected :-)

=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

=== Call for volunteers ===
* The [[OpenRadar]] project is looking for a new maintainer.
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

[[Category:FlightGear Newsletter|2011 11]]

FlightGear Newsletter November 2011

2011-11-28T19:28:28Z

Durk: /* FSweekend */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

'''This newsletter contains some very important information for contributors, so read it carefully!'''

== Development news ==
=== 2.6.0 release preparations ===
{{Main article|Release plan}}
On December 17, our [[Git]] repository will be declared "frozen". This means that no new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.

Keep in mind that the people that are able to commit your stuff are just as busy finishing their own work as you are! Therefore it is important that you create merge requests for everything that you'd like to see included in the upcoming release, as soon as possible. This includes new aircraft and large updates to existing aircraft.

Don't let it wait for tomorrow, do it today!

=== Splitting fgdata: on hold until further notice ===
{{Main article|FlightGear Git: splitting fgdata}}
After much discussion on the [[mailing list]], it was decided to put the existing attempt to split fgdata on hold until further notice. The main reason for postponing the split was that, while it was considered a well intended initiative, the end result of the splitting process itself left the FlightGear fgdata project in a less than desirable state.

For this reason, before another splitting attempt is to be undertaken, the pro's and con's of each step should be carefully evaluated. The split article has been updated to discuss some of our options and formulate a plan of approach that can be presented to -and discussed in further depth- on the developers mailing list.

Those of you that started using the [http://gitorious.org/flightgear-aircraft FlightGear Aircraft repositories], make sure to commit your updates to fgdata, or create a merge request. The FlightGear Aircraft project will '''not''' be used for the FlightGear 2.6.0 release and will likely be re-created when we reach that step in the split-plan.

=== Shaders ===
[[Image:Wakes.jpg|thumb|[[Aircraft carrier|USS Vinson]] (CVN-70) and USS Lake Champlain (CG-57)]]
Emilian and Vivian have been very busy over the last months updating and improving our [[shaders]]. The plan is to rationalize some into one "aircraft" shader, to use just one method of computing fog, and to improve the appearance of the sea by adding foam and aligning the waves with the surface wind. Along the way the appearance of wakes was improved. There is still much to be done, but the work should start to be uploaded to git soon.

It's not without cost to the frame rate, so you will need a pretty powerful video card to run all the features at the same time with the slider set to high quality: nVidia GTX 260, or the ATI equivalent is probably the minimum. By selecting a lower quality vs performance slider setting the old shaders will still be available.

=== Realistic radio simulation===
Work is currently underway to add realistic [[radio propagation]] for [[ATC]] communications, by implementing the well-known Irregular Terrain Model which uses electromagnetic theory and terrain analysis for signal strength prediction.

== Interview with a contributor (NAME) ==
See [[FlightGear Newsletter: Interview questions]] for more questions.

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

== Snapshot releases ==

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==
=== New aircraft ===

=== Updated aircraft ===

=== Liveries ===
The [[FlightGear livery database]] is re-opened for contributions! Due to some problems in the uploadscript no submissions were accepted for several weeks. The uploadform has been redesigned, to allow quicker and easier processing of livery packages. Comments and ideas are highly appreciated. And so are liveries of course, [http://liveries.flightgear.org/contribute.php at this link]!

At the same time, the airlines page received a new "paging", based on first letter of the airlines. This allows you to find what you're looking for in an instant.

== Scenery corner ==
[[Image:2011-11-20_-_scenery_buckets.png|thumb|Scenery buckets of FG mapserver.]]
As of November 20th, there are 1,122,603 objects positions known in [[FlightGear Scenery Database|FlightGear's scenery database]].
It is now possible to show on FG scenery map the scenery buckets. This may be useful for our fellow contributors. Thanks to Martin, Tuxklok and Elmaxo for this nice and useful update. Never seen FG's scenery mapserver? [http://mapserver.flightgear.org/map/?lon=-3.77802&lat=48.29945&zoom=9&layers=B00000TTFFTFFFTTTFTF Click here] to see how it looks like and play with the different layers to the upper right. Enjoy!

=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
'''Ketchikan to Juneau'''

It's cold where we will go so dress up warm and if we are lucky we might see whales during our flight. Don't fly too high to enjoy the amazing views, and there is a small challenge at the end. The runways we will use are long enough for bigger aircraft (7000+). Total length of the trip will be around 245 NM. So, hop in the cockpit of your favourite airliner.

Alaska, here we come! Enjoy!
#Park your aircraft on PAKT, [http://www.borough.ketchikan.ak.us/airport/airport_history.htm Ketchikan International], runway 11. The wind is coming from '''South''', change the weather if needed (SE is ok too).
#Fly North towards [[NDB]] Fredericks Point on 372.0 for 94 NM.
#Fly towards [[NDB]] Five Fingers on 295.0 for 39 NM.
#Fly towards [[NDB]] Gustavus on 219.0 for 77 NM.
#Fly towards [[NDB]] Coghlan Island on 212.0 for 32 NM.
#Set the [[ILS]] on 109.9 and land your aircraft (after 4 NM) on PAJN, [http://www.juneau.org/airport/ Juneau International], runway 08.
If you feel warm after this landing, you just crossed a NORAD microwave site, so that is why.

More amazing flights can be found at [[Suggested Flights]].

== Aircraft reviews ==

== Wiki updates ==
=== Aircraft status categories ===
Now that aircraft [[Formalizing Aircraft Status|can be rated]] (on completeness/status), it made sense to put these aircraft into categories, based on their status. A small adjustment to the [[:Template:Infobox Aircraft|aircraft infobox]] made this process completely automated. All you, as wiki-aircraft-article author need to do is add the ratings to the infobox.

All status categories can be found under [[:Category:Aircraft status]].

=== Images requested ===
"A picture is worth a thousand words", as they say. Yet, lots of wiki articles lack (sufficient) imagery. To get you going, a [[:Category:Image requested|special category]] has been created, which lists articles that are in desperate need for images.

Besides missing images, there are alos quite some outdated images lying around. As time goes by, FlightGear's visuals improve. Especially over the past year or so we've seen some big improvements. When you stumble accross an out of date image, you can replace it by an up to date one:
# Click the thumbnail to go to the image's page.
# Click the "Upload a new version of this file" link, located underneath the image. This brings you to the usual upload form.
# Browse to the new image and click the upload button. You'll get asked whether you really want to overwrite an existing file. Say yes. Don't worry if you make a mistake, the wiki moderators can retrieve overwritten files easily.
# Refresh your browser (F5), to show the new image.

===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==
=== FSweekend ===
[[File:FSweekend 2011 group picture.jpg|thumb|300px|Proudly presenting FlightGear, from left to right: Gijs, Lindsay, Jorg, Mathias, Durk, ThorstenB, TorstenD, Martin, and Hans.]]

This month, on November 5, and 6 the worlds’ largest annual FlightSimulator event was organized again at the Aviodrome aviation museum at Lelystad Airport, the Netherlands. Continuing our tradition, FlightGear had a strong representation, demonstrating the latest features of the upcoming FlightGear 2.6 release. During the 2-day event, we showed the latest experimental scenery developments, Thorsten Rennk's local weather system, an early release of the wonderful DC-3 from the flightgear france development team, as well as many other goodies. Continuing our development from last year, we now had a fully working high-end computer, provided by Thomas-Krenn computing, that was running flightgear on no less than 10 monitors and 24 CPU-cores.

In addition to presenting FlightGear on our booth, one of our team members, Durk Talsma, was also given a one hour slot to present the history of the FlightGear project, as well as it’s current state-of-the-art to a small but interested audience. As always, it’s nice to talk to the many visitors at our booth, and every year we begin to notice more recognition from the audience. As a consequence the team has gotten a number of invitations to present FlightGear among Flight Simulator clubs in the Netherlands and Belgium. The fact that FSWeekend is a great place to meet people was again exemplified by the fact that we met FlightGear contributer David Vanmosselbeen, who had traveled from Belgium to catch up with the team. But perhaps the greatest surprise of the weekend was the fact that our team was met by a DC3 captain, who offered us a discount on a flight with the real DC-3, the PH-PBA, formerly owned by his royal highness, prince Bernhard of the Netherlands, and once the first official aircraft of the Dutch government. Details of the plan are currently being worked out, so stay tuned for a short update once we have flown.

* [http://www.youtube.com/watch?feature=player_detailpage&v=UJ8hH7uOsiE#t=82s A video, shot by a visitor], featuring our 10 screen [[Howto: Build your own procedure trainer|procedure trainer]] setup.
* [http://www.simflight.nl/2011/11/05/fsweekend-de-fotos-3/#more-29284 Various pictures] of FSweekend exhibitors (including two of our booth, all the way at the end).

=== FlightGear on YouTube ===

A video on draoi99's Youtube channel showing some scenes of [http://youtu.be/4M-lYYkPaaw various aircraft flying in coastal areas]. The video has a "weather forecast" theme and a new feature in development - white wave tips in stormy weather - can be seen.

=== FlightGear on Google+ ===
Since this month, FlightGear is also [https://plus.google.com/111978238381658236898/ active on Google+]! Another way to reach users and promote FlightGear.

=== New tutorials and screencasts ===
=== Forum news ===
Five years ago, on November 29 2006 the [http://flightgear.org/forums FlightGear forum] was created.

'''ADD STATISTICS'''

=== FlightGear FGPanel in Action ===
==== C172 Mini Cockpit Project ====
[[File:C172MiniCockpit1.jpg|thumb|right|Completed [[Cessna C172P]] Mini Cockpit using FGPanel.]]
[[FGPanel]], the new FlightGear utility to drive cockpit instrument panels like the [[Howto:_Build_your_own_procedure_trainer | PMPT]], has been used in another cockpit project: the ''C172p Mini Cockpit'' by ThorstenB. The project used the "standard" [[Howto:_Build_your_own_procedure_trainer#The_Almighty_USB_HID_Controller | ATMEL USB HID controller]], a second-hand TFT (13€), a piece of wood, some paint - and lots of buttons and switches. The project literally finished the night before FSWeekend - ready to be added as another exhibit at the FlightGear booth.

More photos documenting the making of the C172p Mini Cockpit are available
[http://www.flickr.com/photos/70866411@N05/sets/72157628178412177/detail/ here].
[[File:C172MiniCockpit2.jpg|thumb|right|Mini Cockpit - behind the scenes...]]

''Prize picture puzzle'': if you spot the tiny detail revealing that some photos were taken just before FSWeekend, which took place on November 5-7th in Lelystad/the Netherlands, then write to the author or newsletter editor. First correct reply wins a (now famous!) ''virtual FlightGear bottle of finest Scotch whisky'' (no "e")... ;-)

==== FGPanel Live System ====
As a byproduct of the ''C172p Mini Cockpit'', a ''[[FGPanel]] Live System'' is available now. The ''Live System'' is a complete, stand-alone software setup, including FGPanel, (partial) FGData, Linux operating system and necessary start-up scripts. The ISO image (350MB download) needs to be programmed on a CD/DVD, USB flash or hard disk drive. Just insert the CD/DVD or connect the USB/HDD drive to your (old) PC, add an (old) 3D graphics card, and an (old) TFT or monitor - and you've made the first step to your own cockpit home setup! The PC boots the image, immediately starts FGPanel and displays C172p cockpit instruments. Run the FlightGear Simulator on your main PC and enable the C172 FGPanel Protocol to transmit data to your cockpit panel PC.

The live CD is a freely available SUSE Studio project. It can also be cloned/modified/adapted to personal needs via SUSE Studio (web interface). Operating system is based on OpenSuSE Linux 12.1. FlightGear binaries (fgpanel) are directly pulled from the OpenSuSE build service (OBS).

More information available at the [http://susestudio.com/a/sBTdmU/flightgear-fgpanel SUSEStudio FGPanel] project.

=== Multiplayer ===
=== Virtual airlines ===
==== TSA - Tristar Airlines ====
[[File:TSA1.png|thumb]]
Tristar Airlines (TSA) opened a new site to the public featuring [http://www.phpvms.net phpVMS]. We now give an even greater experience to FlightGear pilots.

TSA flies to the Caribbean islands and surrounding places. Our hub at TNCC - Curacao Hato Airport modeled by Horacio (who also modeled [[RJGG]]) is one of the most beautiful projects in FlightGear. We fly a fleet of [[Embraer]]'s and [[Cessna]]'s.

More info on the site. We hope to see you there!

[http://tsavirtual.fr.nf/index.php Tristar Airlines website]

=== FlightGear events ===

== Useful links ==

== FlightGear in the news ==
=== LINUX Format ===
FlightGear 2.4 is featured in the December issue of [http://http://www.linuxformat.com/ LINUX Format], published in the UK, the software is included on the cover disc and there is a 1-page review in the magazine. FlightGear got an overall rating of 8/10: 9/10 for Ease of use and Documentation and 6/10 and 7/10, respectively, for Performance and Features. See the review below:

[[File:Lxformatdecllfg.jpg|300px|LINUX Format Review|alt=LINUX Format Review]]

=== MicroSim ===
As promised in the previous edition, French magazine [http://microsim.over-blog.com/ MicroSim] published a tutorial for new Flightgear users.

[[File:MicroSim_nov2011_1.png|300px]]
[[File:MicroSim_nov2011_2.png|300px]]

[[File:MicroSim_nov2011_3.png|300px]]
[[File:MicroSim_nov2011_4.png|300px]]

== And finally ... ==
===A christmas present for you===
[[File:Gerbrandytoren_christmas.jpg|thumb|World's (and thus FlightGear's) largest Christmas tree.|270px]]
Do not forget to pay a visit to the [http://en.wikipedia.org/wiki/Gerbrandy_Tower Gerbrandytoren] in the Netherlands. With a height of 366.8m and 120 lights, it is the world's largest Christmas tree between December 11 and January 6. The tower is located 21 nm South East (HDG 120h) of [[Amsterdam Airport Schiphol]] ([http://mpmap02.flightgear.org/?ll=52.009982,5.053582&z=15 location on MPMap]) and accurately modeled in FlightGear, including the Christmas decoration!

Sadly the tower won't be decorated in real life this year; due to construction work after a fire earlier this year. Luckily FlightGear is not affected :-)

=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

=== Call for volunteers ===
* The [[OpenRadar]] project is looking for a new maintainer.
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===

[[Category:FlightGear Newsletter]]

FlightGear Newsletter November 2011

2011-11-28T19:26:44Z

Durk: /* FSweekend report */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

'''This newsletter contains some very important information for contributors, so read it carefully!'''

== Development news ==
=== 2.6.0 release preparations ===
{{Main article|Release plan}}
On December 17, our [[Git]] repository will be declared "frozen". This means that no new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.

Keep in mind that the people that are able to commit your stuff are just as busy finishing their own work as you are! Therefore it is important that you create merge requests for everything that you'd like to see included in the upcoming release, as soon as possible. This includes new aircraft and large updates to existing aircraft.

Don't let it wait for tomorrow, do it today!

=== Splitting fgdata: on hold until further notice ===
{{Main article|FlightGear Git: splitting fgdata}}
After much discussion on the [[mailing list]], it was decided to put the existing attempt to split fgdata on hold until further notice. The main reason for postponing the split was that, while it was considered a well intended initiative, the end result of the splitting process itself left the FlightGear fgdata project in a less than desirable state.

For this reason, before another splitting attempt is to be undertaken, the pro's and con's of each step should be carefully evaluated. The split article has been updated to discuss some of our options and formulate a plan of approach that can be presented to -and discussed in further depth- on the developers mailing list.

Those of you that started using the [http://gitorious.org/flightgear-aircraft FlightGear Aircraft repositories], make sure to commit your updates to fgdata, or create a merge request. The FlightGear Aircraft project will '''not''' be used for the FlightGear 2.6.0 release and will likely be re-created when we reach that step in the split-plan.

=== Shaders ===
[[Image:Wakes.jpg|thumb|[[Aircraft carrier|USS Vinson]] (CVN-70) and USS Lake Champlain (CG-57)]]
Emilian and Vivian have been very busy over the last months updating and improving our [[shaders]]. The plan is to rationalize some into one "aircraft" shader, to use just one method of computing fog, and to improve the appearance of the sea by adding foam and aligning the waves with the surface wind. Along the way the appearance of wakes was improved. There is still much to be done, but the work should start to be uploaded to git soon.

It's not without cost to the frame rate, so you will need a pretty powerful video card to run all the features at the same time with the slider set to high quality: nVidia GTX 260, or the ATI equivalent is probably the minimum. By selecting a lower quality vs performance slider setting the old shaders will still be available.

=== Realistic radio simulation===
Work is currently underway to add realistic [[radio propagation]] for [[ATC]] communications, by implementing the well-known Irregular Terrain Model which uses electromagnetic theory and terrain analysis for signal strength prediction.

== Interview with a contributor (NAME) ==
See [[FlightGear Newsletter: Interview questions]] for more questions.

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

== Snapshot releases ==

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==
=== New aircraft ===

=== Updated aircraft ===

=== Liveries ===
The [[FlightGear livery database]] is re-opened for contributions! Due to some problems in the uploadscript no submissions were accepted for several weeks. The uploadform has been redesigned, to allow quicker and easier processing of livery packages. Comments and ideas are highly appreciated. And so are liveries of course, [http://liveries.flightgear.org/contribute.php at this link]!

At the same time, the airlines page received a new "paging", based on first letter of the airlines. This allows you to find what you're looking for in an instant.

== Scenery corner ==
[[Image:2011-11-20_-_scenery_buckets.png|thumb|Scenery buckets of FG mapserver.]]
As of November 20th, there are 1,122,603 objects positions known in [[FlightGear Scenery Database|FlightGear's scenery database]].
It is now possible to show on FG scenery map the scenery buckets. This may be useful for our fellow contributors. Thanks to Martin, Tuxklok and Elmaxo for this nice and useful update. Never seen FG's scenery mapserver? [http://mapserver.flightgear.org/map/?lon=-3.77802&lat=48.29945&zoom=9&layers=B00000TTFFTFFFTTTFTF Click here] to see how it looks like and play with the different layers to the upper right. Enjoy!

=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
'''Ketchikan to Juneau'''

It's cold where we will go so dress up warm and if we are lucky we might see whales during our flight. Don't fly too high to enjoy the amazing views, and there is a small challenge at the end. The runways we will use are long enough for bigger aircraft (7000+). Total length of the trip will be around 245 NM. So, hop in the cockpit of your favourite airliner.

Alaska, here we come! Enjoy!
#Park your aircraft on PAKT, [http://www.borough.ketchikan.ak.us/airport/airport_history.htm Ketchikan International], runway 11. The wind is coming from '''South''', change the weather if needed (SE is ok too).
#Fly North towards [[NDB]] Fredericks Point on 372.0 for 94 NM.
#Fly towards [[NDB]] Five Fingers on 295.0 for 39 NM.
#Fly towards [[NDB]] Gustavus on 219.0 for 77 NM.
#Fly towards [[NDB]] Coghlan Island on 212.0 for 32 NM.
#Set the [[ILS]] on 109.9 and land your aircraft (after 4 NM) on PAJN, [http://www.juneau.org/airport/ Juneau International], runway 08.
If you feel warm after this landing, you just crossed a NORAD microwave site, so that is why.

More amazing flights can be found at [[Suggested Flights]].

== Aircraft reviews ==

== Wiki updates ==
=== Aircraft status categories ===
Now that aircraft [[Formalizing Aircraft Status|can be rated]] (on completeness/status), it made sense to put these aircraft into categories, based on their status. A small adjustment to the [[:Template:Infobox Aircraft|aircraft infobox]] made this process completely automated. All you, as wiki-aircraft-article author need to do is add the ratings to the infobox.

All status categories can be found under [[:Category:Aircraft status]].

=== Images requested ===
"A picture is worth a thousand words", as they say. Yet, lots of wiki articles lack (sufficient) imagery. To get you going, a [[:Category:Image requested|special category]] has been created, which lists articles that are in desperate need for images.

Besides missing images, there are alos quite some outdated images lying around. As time goes by, FlightGear's visuals improve. Especially over the past year or so we've seen some big improvements. When you stumble accross an out of date image, you can replace it by an up to date one:
# Click the thumbnail to go to the image's page.
# Click the "Upload a new version of this file" link, located underneath the image. This brings you to the usual upload form.
# Browse to the new image and click the upload button. You'll get asked whether you really want to overwrite an existing file. Say yes. Don't worry if you make a mistake, the wiki moderators can retrieve overwritten files easily.
# Refresh your browser (F5), to show the new image.

===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==
=== FSweekend ===
[[File:FSweekend 2011 group picture.jpg|thumb|300px|Proudly presenting FlightGear, from left to right: Gijs, Lindsay, Jorg, Mathias, Durk, ThorstenB, TorstenD, Martin, and Hans.]]

This month, on November 5, and 6 the worlds’ largest annual FlightSimulator event was organized again at the Aviodrome aviation museum at Lelystad Airport, the Netherlands. Continuing our tradition, FlightGear had a strong representation, demonstrating the latest features of the upcoming FlightGear 2.6 release. During the 2-day event, we showed the latest experimental scenery developments, an early release of the wonderful DC-3 from the flightgear france development team, as well as many other goodies. Continuing our development from last year, we now had a fully working high-end computer, provided by Thomas-Krenn computing, that was running flightgear on no less than 10 monitors and 24 CPU-cores.

In addition to presenting FlightGear on our booth, one of our team members, Durk Talsma, was also given a one hour slot to present the history of the FlightGear project, as well as it’s current state-of-the-art to a small but interested audience. As always, it’s nice to talk to the many visitors at our booth, and every year we begin to notice more recognition from the audience. As a consequence the team has gotten a number of invitations to present FlightGear among Flight Simulator clubs in the Netherlands and Belgium. The fact that FSWeekend is a great place to meet people was again exemplified by the fact that we met FlightGear contributer David Vanmosselbeen, who had traveled from Belgium to catch up with the team. But perhaps the greatest surprise of the weekend was the fact that our team was met by a DC3 captain, who offered us a discount on a flight with the real DC-3, the PH-PBA, formerly owned by his royal highness, prince Bernhard of the Netherlands, and once the first official aircraft of the Dutch government. Details of the plan are currently being worked out, so stay tuned for a short update once we have flown.

* [http://www.youtube.com/watch?feature=player_detailpage&v=UJ8hH7uOsiE#t=82s A video, shot by a visitor], featuring our 10 screen [[Howto: Build your own procedure trainer|procedure trainer]] setup.
* [http://www.simflight.nl/2011/11/05/fsweekend-de-fotos-3/#more-29284 Various pictures] of FSweekend exhibitors (including two of our booth, all the way at the end).

=== FlightGear on YouTube ===

A video on draoi99's Youtube channel showing some scenes of [http://youtu.be/4M-lYYkPaaw various aircraft flying in coastal areas]. The video has a "weather forecast" theme and a new feature in development - white wave tips in stormy weather - can be seen.

=== FlightGear on Google+ ===
Since this month, FlightGear is also [https://plus.google.com/111978238381658236898/ active on Google+]! Another way to reach users and promote FlightGear.

=== New tutorials and screencasts ===
=== Forum news ===
Five years ago, on November 29 2006 the [http://flightgear.org/forums FlightGear forum] was created.

'''ADD STATISTICS'''

=== FlightGear FGPanel in Action ===
==== C172 Mini Cockpit Project ====
[[File:C172MiniCockpit1.jpg|thumb|right|Completed [[Cessna C172P]] Mini Cockpit using FGPanel.]]
[[FGPanel]], the new FlightGear utility to drive cockpit instrument panels like the [[Howto:_Build_your_own_procedure_trainer | PMPT]], has been used in another cockpit project: the ''C172p Mini Cockpit'' by ThorstenB. The project used the "standard" [[Howto:_Build_your_own_procedure_trainer#The_Almighty_USB_HID_Controller | ATMEL USB HID controller]], a second-hand TFT (13€), a piece of wood, some paint - and lots of buttons and switches. The project literally finished the night before FSWeekend - ready to be added as another exhibit at the FlightGear booth.

More photos documenting the making of the C172p Mini Cockpit are available
[http://www.flickr.com/photos/70866411@N05/sets/72157628178412177/detail/ here].
[[File:C172MiniCockpit2.jpg|thumb|right|Mini Cockpit - behind the scenes...]]

''Prize picture puzzle'': if you spot the tiny detail revealing that some photos were taken just before FSWeekend, which took place on November 5-7th in Lelystad/the Netherlands, then write to the author or newsletter editor. First correct reply wins a (now famous!) ''virtual FlightGear bottle of finest Scotch whisky'' (no "e")... ;-)

==== FGPanel Live System ====
As a byproduct of the ''C172p Mini Cockpit'', a ''[[FGPanel]] Live System'' is available now. The ''Live System'' is a complete, stand-alone software setup, including FGPanel, (partial) FGData, Linux operating system and necessary start-up scripts. The ISO image (350MB download) needs to be programmed on a CD/DVD, USB flash or hard disk drive. Just insert the CD/DVD or connect the USB/HDD drive to your (old) PC, add an (old) 3D graphics card, and an (old) TFT or monitor - and you've made the first step to your own cockpit home setup! The PC boots the image, immediately starts FGPanel and displays C172p cockpit instruments. Run the FlightGear Simulator on your main PC and enable the C172 FGPanel Protocol to transmit data to your cockpit panel PC.

The live CD is a freely available SUSE Studio project. It can also be cloned/modified/adapted to personal needs via SUSE Studio (web interface). Operating system is based on OpenSuSE Linux 12.1. FlightGear binaries (fgpanel) are directly pulled from the OpenSuSE build service (OBS).

More information available at the [http://susestudio.com/a/sBTdmU/flightgear-fgpanel SUSEStudio FGPanel] project.

=== Multiplayer ===
=== Virtual airlines ===
==== TSA - Tristar Airlines ====
[[File:TSA1.png|thumb]]
Tristar Airlines (TSA) opened a new site to the public featuring [http://www.phpvms.net phpVMS]. We now give an even greater experience to FlightGear pilots.

TSA flies to the Caribbean islands and surrounding places. Our hub at TNCC - Curacao Hato Airport modeled by Horacio (who also modeled [[RJGG]]) is one of the most beautiful projects in FlightGear. We fly a fleet of [[Embraer]]'s and [[Cessna]]'s.

More info on the site. We hope to see you there!

[http://tsavirtual.fr.nf/index.php Tristar Airlines website]

=== FlightGear events ===

== Useful links ==

== FlightGear in the news ==
=== LINUX Format ===
FlightGear 2.4 is featured in the December issue of [http://http://www.linuxformat.com/ LINUX Format], published in the UK, the software is included on the cover disc and there is a 1-page review in the magazine. FlightGear got an overall rating of 8/10: 9/10 for Ease of use and Documentation and 6/10 and 7/10, respectively, for Performance and Features. See the review below:

[[File:Lxformatdecllfg.jpg|300px|LINUX Format Review|alt=LINUX Format Review]]

=== MicroSim ===
As promised in the previous edition, French magazine [http://microsim.over-blog.com/ MicroSim] published a tutorial for new Flightgear users.

[[File:MicroSim_nov2011_1.png|300px]]
[[File:MicroSim_nov2011_2.png|300px]]

[[File:MicroSim_nov2011_3.png|300px]]
[[File:MicroSim_nov2011_4.png|300px]]

== And finally ... ==
===A christmas present for you===
[[File:Gerbrandytoren_christmas.jpg|thumb|World's (and thus FlightGear's) largest Christmas tree.|270px]]
Do not forget to pay a visit to the [http://en.wikipedia.org/wiki/Gerbrandy_Tower Gerbrandytoren] in the Netherlands. With a height of 366.8m and 120 lights, it is the world's largest Christmas tree between December 11 and January 6. The tower is located 21 nm South East (HDG 120h) of [[Amsterdam Airport Schiphol]] ([http://mpmap02.flightgear.org/?ll=52.009982,5.053582&z=15 location on MPMap]) and accurately modeled in FlightGear, including the Christmas decoration!

Sadly the tower won't be decorated in real life this year; due to construction work after a fire earlier this year. Luckily FlightGear is not affected :-)

=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

=== Call for volunteers ===
* The [[OpenRadar]] project is looking for a new maintainer.
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===

[[Category:FlightGear Newsletter]]

FlightGear Git: splitting FGData

2011-11-16T23:16:56Z

Durk:

Talk:FlightGear Git: splitting FGData

2011-11-16T23:16:05Z

Durk:

Moved some text that was clearly part of a plan that is currently not very likely to be continued into the discussion page:

== Starting new aircraft ==
New aircraft should not be commited to fgdata. A separate repository should be created instead. Contact a FlightGear Aircraft admin to get your repository included in the FlightGear Aircraft project. You, as author, will get commit rights for that repository.

The current fgdata developers will have access to every single aircraft repository. In order to maintain aircraft that no longer have an active author, fix global bugs etc. Other users can create merge requests to get their fixes/improvements commited.

== Step 1: Split aircraft into separate repositories (DONE) ==
Aircraft are split into "private" repositories, under the [https://gitorious.org/flightgear-aircraft FlightGear Aircraft project]. Repositories for all aircraft in current fgdata have been created as of 17 October. Repository names equal directory-names (with the exceptions of dots (.) and capitals (ABC), as those are not supported by Gitorious.

There are two workflows that both do the trick:

=== Method 1 ===
'''Note:''' the split branch (<tt>737-300-split</tt> in this example) must NOT exist beforehand.

cd $FG_ROOT
git subtree split -P Aircraft/737-300 -b 737-300-split
mkdir -p ../split-aircraft/737-300
cd ../split-aircraft/737-300
git init
git fetch $FG_ROOT 737-300-split
git checkout -b master FETCH_HEAD
git push git@gitorious.org:flightgear-aircraft/737-300.git master

=== Method 2 ===
(need to check this one)
cd fgdata
git clone --no-hardlinks /fgdata /737-300
git filter-branch --subdirectory-filter Aircraft/737-300 HEAD -- --all
git reset --hard
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --aggressive --prune=now

Then all aircraft should be pushed to their new repositories. A script will take care of that.

== Step 2: Remove all aircraft from fgdata ==
A new fgdata repository without any aircraft is created, pushed to gitorious and tested.

== Step 3: Write/update manuals ==
Since the aircraft development flow will be different, we should teach our developers how to use the new system.

'''To be written:'''
* [[FlightGear Git: aircraft authors]]

'''To be updated:'''
* [[FlightGear and Git]]
* [[FlightGear Git on Mac OS X]]
* [[FlightGear Git on Windows]]

== Step 4: Switch fgdata ==
Once tests show that the new repository is working fine and no data has been lost, the repositories will be switched.
The exisiting repository is renamed, and the new repository takes its place and access to the new repository is setup.
The historic fgdata is kept but stays frozen, at least until we're sure everything is safe. It may also be a good idea to keep the existing repo, since it contains release branches - which are not part of the new repository and would be lost otherwise.

== Step 5: Inform the crowd ==
Post an announcement at the mailing list, forum, Facebook (?) and in the [[FlightGear Newsletter October 2011|upcoming newsletter edition]]. Link to the respective wiki articles (see [[#Step 3: Write/update manuals|Step 3]]) that contain details on how to work with the new system.

== Questions ==
* What to do with Aircraft/UIUC should it be placed like "one" aircraft in a aircraft-repository? Or each individual?
** An flightgear-aircraft/UIUC repo has been created, we can delete it if needed later on.
* Gitorious does not support dots in repository names.
** For now we just skipped dots, so Supermarine-S.6B has a repo called <tt>supermarine-s6b</tt> (note that Gitorious also does not distinct capitals. This does not seem to be a problem though, since git clone uses the original directory name).
* What rights should aircraft authors get?
** Commit/review might be best. If they are granted admin rights, they can delete the repo and remove the fgdata-developers as collaborators. When they do the later, there's no way we can regain control over the repo. We won't even be able to delete it from the FlightGear Aircraft project.
* Should we support multiple licenses under the FlightGear Aircraft project?
** Possible, but then the Aircraft Downloadpage would maybe need an update. Better create one Place for GNU-GPL and one for other licences.
*How long should we test? FGData is increasing again as new aircraft are continuously added again.

--[[User:Durk|Durk]] 17:48, 16 November 2011 (EST)

FlightGear Git: splitting FGData

2011-11-16T23:14:30Z

Durk: /* Initial draft of a plan towards splitting fgdata. Please don't mind the typos' */

Talk:FlightGear Git: splitting FGData

2011-11-16T22:48:18Z

Durk: /* Moved some stuff that doesn't seem viable anymore to the talk page */

Talk:FlightGear Git: splitting FGData

2011-11-16T22:47:55Z

Durk: /* Moved some stuff that doesn't seem viable anymore to the talk page */

FlightGear Newsletter October 2011

2011-10-30T18:57:14Z

Durk: /* Flying lessons for AI pilots */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== Development news ==

=== FGdata split ===
A team of developers started preparing the FlightGear [[git]] repositories for a significant change. Aircraft will be split of from fgdata, in order to ease development of aircraft and data as a whole. At the moment (of publication of this newsletter) we're in the testing phase; inviting anyone to test out the new system and report any bugs, comments and questions.

We would like to emphasize that those testing repositories are not meant to replace the "old" fgdata yet! There are various ways of splitting (eg. all aircraft in one big repository, repositories per author), so until we've settled on what way to go, things might (and will) change.

Details can be found on the special wiki page: [[FlightGear Git: splitting fgdata]].

=== Move to CMake ===



=== New Replay System ===
The [[Instant Replay]] system has received a major overhaul. The existing system worked well with specific types of aircraft only, since it relied on a hard-coded set of properties to be recorded/replayed, mainly covering propeller aircraft. Jet engines (thrust-reversers, N1/N2 rpm), or non-standard gears (i.e. a Concorde with 4 landing gears) were not working well though. The new system can be adapted to any kind of aircraft and any kind of custom property or animation.

[[File:FG-instant-replay-new.png|thumb|500px|The new instant replay dialog.]]

Most obvious change is probably an improved replay dialog: the video player-like GUI provides play/pause/skip buttons and also controls replay speed. During replay use the 4 arrow keys as controls (left/right to skip, up/down to speed-up/slow-down). Also new: ''slow-motion playback'' is now supported!

Another new feature is the option of taking controls at any point during replay. Use the ''Instant Replay'' to go back in time, then hit the "My controls!" button to regain controls and continue the flight from the current position. You may find this to be useful to train particular flight phases, such as flying the same approach again and again, maybe using different weather/wind conditions. Even if you messed up an approach: go back, try again, until you're getting better! :) Currently this particular feature is only available for YASim aircraft - except helicopters. JSBSim support is likely to be available soon.

The first step to adapt an aircraft to the improved recording system is to pick one of the ready-to-use configuration files, depending on aircraft/engine/.. type. The configuration file only needs to be included in the aircraft's ...-set.xml file. As an optional second step, you can add more custom properties to cover aircraft-specific effects. For more details, see the [https://www.gitorious.org/fg/fgdata/blobs/master/Docs/README.flightrecorder README.flightrecorder] in the fgdata/Docs folder.

A few adapted aircraft examples showing different levels of customization are already present in current git/fgdata:
* ASK13 (glider)
* c172p (propeller/piston)
* b1900d (turboprop)
* UH-1 (helicopter)
* 777-200ER (jet).

Furthermore, the replay system's buffers are now fully configurable (see /sim/replay/buffer properties). If you have enough memory, you could increase the buffer recording durations and rates.

Work on the replay system isn't finished yet. However, have a test flight with the current state in current git ;-).

=== Flying Lessons for AI pilots ===

This month FlightGear's virtual, AI controlled, pilots have received extensive training with regard to their landing skills. Whereas in older versions AI aircraft had a tendency to approach too high, drop dead onto the runway, and taxi all the way to the opposite end of the runway before vacating it, the current development version of FlightGear as largely addressed all these issues. Pilots now make a much more realistic approach, and vacate the runway when able. The corresponding AI control code was implemented in October. Additionally, work has started on a new traffic flow regulation algorithm to guide ground traffic.

=== The bombable addon has been updated ===
[[File:bombable4_4_800.png]]

Flug's [[Bombable]] addon received a number of major updates, among them:

* '''AI aircraft move vertically -- and do loops''': AI aircraft now move much more realistically in the vertical direction. They do loops, dive, and all the rest. Their behavior (climb rates, dive rates, and so on) matches those of the corresponding FG aircraft. This makes for a much more realistic 3-D dogfighting experience in FlightGear.
* '''Realistic roll rates for AI aircraft''': Roll rates are one the most important factors determining the effectiveness of fighter aircraft-- aircraft that can roll faster can turn faster. Now the roll rate for AI aircraft in scenarios can be customized, and bugs in the roll & turn routines for AI aircraft have been fixed.
* '''Significant performance improvements''': Bombable now makes much less of an impact on your framerate, and much less stuttering & slowdown at key points, like when numerous machine gun rounds are impacting.
* '''Damage impact detection is the most advanced element in Bombable'''. It is greatly improved over FG's native impact detection system, and the framework is in place for further refinements or as a model for FG to implement more refined impact detection internally. Damage tracking and communication over Multiplayer works well in a very lightweight with a very low data rate. However, only a general damage percentage is tracked and communicated. Damage to different locations or systems is not simulated. Proof of concept for explosions, fires, weapons damage animations, and crash animations is in place. All these elements could be refined for greater realism.
* '''Relocate any scenario to your location''': Have an AI scenario based in San Francisco, but want to fly in London? No problem, just hit a button in the Bombable menu and your scenario comes to you, wherever you are. Damage levels for AI aircraft and objects are re-set. It's like loading a new scenario without having to re-start FlightGear.
* '''Re-spawn AI aircraft and objects''': After you have shot down (or been shot down by!) AI aircraft or objects in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)

The last two are kind of game changers--it's like being able to re-start/re-load a scenario instantly without having to re-start FG.

In addition, there have been some feature requests to make the bombable addon more challenging by improving its AI. This spawned an interesting discussion about possible ways to make the AI even smarter than it is already [http://flightgear.org/forums/viewtopic.php?f=6&t=5742&start=300#p140013]. Also see [[Howto: Neural networks in Nasal]].

For a nice video demo created by Vodoun da Vinci, please see [[FlightGear Newsletter October 2011#Community news|community news]].

== Interview with a contributor: Gijs de Rooy ==
''From this month onwards, we'd like to see a monthly interview with a contributor. Questions are available on [[interview questions]] and anyone is free to write an interview (with him-/herself) for next month's newsletter!''

* '''How long have you been involved in FlightGear? What was it that made you join?'''
According to the forum software I joined all the way back in July 2007. One year earlier I was one of the first users of Google SketchUp, free 3D modelling software. After modelling several buildings in my home town, Amsterdam (and placing them in Google Earth) I started working on Amsterdam Airport Schiphol. By then, Google Earth had a (simple) built-in flight simulator. Amsterdam would be the first airport to be modelled especially for that, that was my plan at least...

While modelling Schiphol, I stumbled across this free flight sim, called FlightGear, that wasn't a game, unlike Google's. In [http://flightgear.org/forums/viewtopic.php?f=5&t=473 one of my first posts] on the FlightGear forum I asked for someone to place my models into FlightGear's scenery. Georg (Heliflyer) placed my first buildings. I took some effort, but I finally managed to place buildings myself. Sadly the guy that introduced me to FlightGear and gave me a hobby that would last up till today, passed away in 2009.

* '''Do you have real world connections with aviation or IT?'''
Since two months I'm studying Aerospace Engineering at the University of Delft. So far I really like this mix of hobby and study.

* '''What are your major interests in FlightGear?'''
One of the things I like about FlightGear is the wide range of things one can get involved with: modelling, texturing, writing manuals, collecting data etc. and of course flying itself. Therefore I have a very long list of interests. However, there are three key parts that I particularly enjoy; being the development of scenery and aircraft and helping others by writing wiki articles and replying to questions at the forum.

* '''What project(s) are you working on right now?'''
My main development projects right now are the Boeing [[747-400]] and Dutch scenery. Both can be considered as never finished; there are always things to add/improve.

* '''On average, how much time do you spend working with/contributing to FlightGear?'''
Until this year I spent roughly 4 to 5 hours a day on FlightGear related things. Now that I'm studying I have less free time, but still several hours a day on average. Most of that time is taken up by non-development stuff, like the forum, wiki and livery database. Over the years I've been spending way too litle time on the actual flying.

* '''What do you plan on doing in the future?'''
I would really like to bring the 744 to a state where a real pilot cannot spot a thing that is missing in the simulation.

* '''What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?'''
Starting something new is easy, completing it is much harder. I could have never guessed I would still be working on the 744, three years after I started!

I've always been telling newcomers to start improving existing features. It's a great way to familiarize yourself with the project. By looking into existing aircraft's files for example, you will quickly find out how those files are linked together and what their purpose is.

== Snapshot releases ==

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==
All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.
=== New aircraft ===

=== Updated aircraft ===
The [[Learjet 35-A]] has been updated. Several minor errors have been fixed and improvements have been put in-place. The [[Learjet 35-A]] is the only business jet with a functional autopilot. It is a gem to fly and perfect for beginners and experts to try [[radio navigation]], autopilot control and [[ILS]] procedures. Thanks Xsaint and PH-JBO for the work done.

=== Livery database reaches 600 ===
On October 8, the [[FlightGear livery database]] welcomed its 600th livery! Thanks to 70 authors, the virtual skies are more colourful than ever.

At the moment the contribution system is being rewritten. For the time being, new liveries are only accepted via direct email to [http://www.flightgear.org/forums/memberlist.php?mode=viewprofile&u=510 Gijs].

== Scenery corner ==

=== Support for 8.50 airport data ===
[[File:EHAM_overview_night.png|thumb|270px|[[Amsterdam Airport Schiphol]] by night, with the new 8.50 lighting.]]
[[File:EHAM_gate_D.png|thumb|270px|Schiphol's D gates, in combination with AI traffic.]]
As mentioned in the previous newsletter; efforts are made to bring [[TerraGear]] up to a level where it supports the 8.50 apt.dat format, nowadays used by X-Plane. This new format has all kind of exciting features like curved taxiways and accurate lining/lighting (not just "ordinary" taxiway lines, but also markings like hold lines). Furthermore, seperate runway end definitions so it is now possible to create runways with different markings on both ends (including "empty ends" for runways being only used into one direction).

We'd like to thank Christian (papillon81), Pete (Psadro GM) and Emmilian (i4dnf) for their hard work. It's probably legitimate to say that this is the biggest improvements in FlightGear scenery over the past years!

=== Airports ===

Work progressed on a line of higher detailed service vehicle scenery models.

[[File:Fgfs 2011-10-29 13-41-16-88.jpg|400px|Service vehicles lineup]][[File:Fgfs 2011-10-23 18-02-20-12.jpg|400px|Baggege trailer lineup]]

[[File:Fgfs 2011-10-26 20-46-13-55.jpg|400px|ULD Container trailer linup]][[File:Fgfs 2011-10-16 04-35-08-94.jpg|400px|Short version of the Volvo-FM airport fuel truck]]

Currently the line includes a small tow truck, Baggage trailer, ULD container trailers, Catering Trucks and a Fuel Truck.

You can follow the development on the forum: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=13472]

== Aircraft of the month ==

Diamond DA42 Twin Star

[[File:Fgfs-screen-032.png|600px]]

http://en.wikipedia.org/wiki/Diamond_DA42

== Glider of the month ==

Jean Astir Grob G102

[[File:Astir.png|600px]]
[[File:Fgfs-screen-026.png|600px]]

== Airport of the month ==
[[File:FJDG.jpg|600px]]

The nearest airport is about 700 NM away. Around us are about 30 small islands, none with [[radio beacons]], none with an airport but some with a small beach. This Airport has four odd looking pillboxes. If you click they will open, very slowly. Now if you would have a [[Northrop B-2 Spirit |B2 bomber]] you could park your aircraft in it. If you don't have a [[Northrop B-2 Spirit|B2]] you are allowed to land, but only in an emergency. Fake an emergency and get here, bring piña colada and have a party on the beach!

*It is sooo beautiful here. Oh, where? FJDG, [http://en.wikipedia.org/wiki/Chagos_Archipelago Diego Garcia at Point Marianne]. Perfect for [[VFR]] tours, and a piña colada on the beach.

== Screenshot of the month ==
[[File:Mount Everest VNTR.jpg]]
*[[Learjet 35-A]] and [http://en.wikipedia.org/wiki/Mount_Everest Mount Everest] viewed from West towards East. Atlas image of the route to [http://en.wikipedia.org/wiki/Tumlingtar_Airport VNTR]. I could see the direction of NDB and knew the altitude of the RW. The RW was not visible till the absolute last moment racing down with airbrakes at max. The landing was a success but I had to change underwear and clean the seat.

== Suggested flights ==
It's cold where we will go so dress up warm and if we are lucky we might see whales during our flight. Don't fly too high to enjoy the amazing views, and there is a small challenge at the end. The runways we will use are long enough for bigger aircraft (7000+). Total length of the trip will be around 245 NM. So, hop in the cockpit of your favourite airliner.

Alaska, here we come! Enjoy!
#Park your aircraft on PAKT, [http://www.borough.ketchikan.ak.us/airport/airport_history.htm Ketchikan International], runway 11. The wind is coming from '''South''', change the weather if needed (SE is ok too).
#Fly North towards [[NDB]] Fredericks Point on 372.0 for 94 NM.
#Fly towards [[NDB]] Five Fingers on 295.0 for 39 NM.
#Fly towards [[NDB]] Gustavus on 219.0 for 77 NM.
#Fly towards [[NDB]] Coghlan Island on 212.0 for 32 NM.
#Set the [[ILS]] on 109.9 and land your aircraft (after 4 NM) on PAJN, [http://www.juneau.org/airport/ Juneau International], runway 08.
If you feel warm after this landing, you just crossed a NORAD microwave site, so that is why.
*More amazing flights can be found at [[Suggested Flights]].

== Aircraft reviews ==

== Wiki updates ==
=== 10,000,000 pageviews ===
On October 29, the FlightGear wiki welcomed it's 10,000,000th (10 millionth) pageview! Coming from five million in October 2010, we doubled in just 12 months time. That is a proof that FlightGear has more users than ever and more users are able to find their way to the wiki. Both things are very nice of course!

We'd like to thank everyone that donated some free time to create/improve/correct articles and upload images to the wiki. As the wiki is (just like FlightGear) completely dependant on the community we'd like to emphasize that anyone is welcome to help! You can find a short introduction to the wiki at [[Help:Your first article]].

To 20 million and beyond! We're already well on our way, with {{NUMBEROFVIEWS}} views at this very moment. More statistics are available at [[Special:Statistics]].

=== Nasal documentation ===
Flug and Hooray revamped the [[Nasal]] documentation, to make it hopefully more comprehensive and more accessible to new programmers. If you think, anything is unclear or missing, please leave a remark at the article's talk page or [http://flightgear.org/forums/viewtopic.php?f=30&t=13811 the forum topic].

===New articles===
*The article about [[altitude]] has received an update and a fresh lick of paint. Please help to correct the German version.
*[[Aircraft speed]] is a bit more up-to speed now.
*Places to fly, Suggested Flights, Suggested Flights from newsletters and the flights from the main website have all been merged into one gathering place of amazing places you really have to visit one day, soon. Check out [[Suggested Flights]] and feel free to add your secret pearls!

===New aircraft articles===
===Most popular newsletters===

== Community news ==
===Reminder: FSweekend===
A team of FlightGear developers will promote FlightGear to the public at the [[FSweekend]] (5 and 6 November 2011), the largest flight simulator event in the world. They highly appreciate it if you are able to stop by. If you are unable to visit [[Lelystad Airport]] (EHLE) in real life, make sure you pay a virtual visit!

A visit is definitely worth it. The more knowing that Durk Talsma, one of our longtime core developers, will do a one hour presentation on FlightGear.

[[File:Fgfs-screen-028.png|x125px]][[File:FSweekend_banner_2011.jpg|x125px|link=http://www.fsweekend.com]]

More information can be found at the event's wiki page: [[FSweekend 2011]].

=== FlightGear on YouTube ===
Vodoun da Vinci has [http://flightgear.org/forums/viewtopic.php?f=19&t=13823 uploaded a new movie] complete with music soundtrack to demonstrate the latest [[Bombable]] addon. This one primarily features head on attacks by custom [[P-51D Mustang]]s over Sochi, Russia.

The code in the Mustangs has been hacked to make them aggressive in attacking head on. My favorite style with my FW-190 D9 Dora supplied by Detlef Faber. The clips have been recorded with time set to evening and morning (dusk and dawn) as this provides the kind of dark and contrasting sky that best suits me for hunting.

=== FlightGear on Facebook ===
Started in December 2010, [http://www.facebook.com/FlightGear the FlightGear Facebook page] welcomed its 6000th "liker" on October 7! The original plan was to outnumber the likers of [[Pro Flight Simulator]] and the like, but now that we've outnumbered them by far, the Facebook page can be seen as a way to provide a periodic dose of what's new, cool or fun in FlightGear. Over the past months, we've been frequently posting nice screenshots from forummembers.

Speaking of which, [http://flightgear.org/forums the forum] is still the place to be when you're looking for support.

=== New tutorials and screencasts ===
[http://icestar-fghangar.web44.net/web/ Icecode's and Star's hangar] which was created on February 2011, is now bringing a new [http://icestar-fghangar.web44.net/web/?q=node/51 Tutorials section] where a new tutorial will be uploaded each week (sometimes more often). Starting with this week's tutorial "[http://icestar-fghangar.web44.net/web/?q=node/54 VOR navigation]". The tutorials are not going to be only limited on how to fly aircrafts but also we'll be showing you tips on how to develop aircrafts, scenery, liveries and many other things. Have fun reading and enjoy your flights!

=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===

== FlightGear in the news==
FlightGear was featured in the October edition of [http://microsim.over-blog.com/ MicroSim], a French flight simulation magazine. The two paged article (click images below to open larger versions) discussed our latest release 2.4.0. Altough MSFS and X-Plane have better graphics and more complete aircraft, the writer considers FlightGear a worthwhile alternative.

The next edition of MicroSim will include a tutorial, to guide new users through the program.

[[File:MicroSim_oct2011_1.png|300px]]
[[File:MicroSim_oct2011_2.png|286px]]

== Useful links ==
== And finally ... ==
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

=== Call for volunteers ===
*[[Translation requests| To '''translate''' (wiki) we must '''translate translate'''!]] so, Help and translate [[Translation requests| translate]] Wenn Sie Aus Deutschland sind or Jeśli jesteś z Polski, and from anywhere!
**Special thanks to Alexmdv and Michat for their translation work! (And Hamster and so many others)

* The [[OpenRadar]] project is looking for a new maintainer.
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===
...that you can comment on the newsletter in the [http://www.flightgear.org/forums/viewforum.php?f=50 forums]? Help us improve *your* newsletter! Give comments, suggestions and feedback!

[[Category:FlightGear Newsletter]]

FSweekend 2011

2011-10-08T14:49:02Z

Durk: /* updated equipment list */

[[File:FSweekend_banner_2011.jpg|right|350px|link=http://www.fsweekend.com]]
This wiki page lists all information related to [[FlightGear]]'s [[FSweekend]] attendance, as well as information for those that'd like to pay a virtual visit. FlightGear will be represented by a team of regular FlightGear developers and users.

<eventcountdown date="05-November-2011">'''<daysuntil in="days">05-November-2011</daysuntil>''' until the FSweekend</eventcountdown>

== Booth information ==
This year's booth will probably exist of:
[[File:LinuxTag2011_LargeSetup.jpg|220px|thumb|right|FlightGear setup at LinuxTag 2011]]
* a FlightGear based [[Howto: Build your own procedure trainer|procedure trainer]] with 10 monitors and dual control (as shown at LinuxTag 2011).
* a Linux-based triple-screen PC, with a generic set of input devices for general purpose flight demonstrations

=== Equipment Checklist ===
* One main power extension cord (JVDV: red)
* One main power extension cord (DT: Green)
* One Linux-based PC (JVDV)
** Three monitors
** Thrustmaster HOTAS Cougar
** Saitek Rudder Pedals
** USB Headset
** 3D glasses
* One Linux-based PC (DT)
** Three monitors
** Saitek Joystick
** Saitek Rudder Pedals
** Headset
** Sound system
* a projector-screen (TD) - no projector!
* yet another projector-screen - this time with a projector (DT).
* My (TD) last 2 (two!) remaining pairs of anaglyph 3d-glasses
[[File:Anaglyph-glasses.jpg|right]]

* "Team FlightGear" T-shirts (TD)
* Aviation themed Belgian Chocolade in sufficient quantities (DT).
* Senseo coffee maker (TD)

== Flight information ==
=== Airports ===
Activities will mainly take place at and around [[Amsterdam Airport Schiphol]] (EHAM), [[Lelystad Airport]] (EHLE), [[Volkel Air Base]] (EHVK) and the [[VU University Medical Center|VU University Medical Center Helipad]] (EH0001).

=== Charts ===
All charts that you may have to use on your flights are available at http://ais-netherlands.nl (AIS Publications > Integrated Package). Please note that these are the most up to date charts available, so certain situations might not have been changed in FlightGear (EHAM, EHLE and EHVK taxiways should be correct though).

Parking positions have been created for most of the Dutch airports including EHAM, EHRD, EHVK and EHLE (A1-A6, B1 and B2).

All named airports are for civil usage, except for [[Volkel Air Base]] (EHVK). This base will be occupied by the (AI) F-16 squadrons and likely one setup in Lelystad. Feel free to join with your F-16 or other Dutch/NATO [[:Category:Military aircraft|military aircraft]]. For EHVK specific departure and recovery procedures please visit http://cenor.org/pages/proc_eh.html and dowload the corresponding .pdf file.

=== Weather information ===
Reallife weather information can be found at the KNMI (Dutch Meteorological institute) website.
* [http://knmi.nl/actueel/metar.html METAR] current weather at airports
* [http://knmi.nl/waarschuwingen_en_verwachtingen/luchtvaart/nederlandse_vliegveldverwachtingen.html TAF] expected weather at airports
If the weather is really bad, it is likely that the FSweekend guys will use a preset weather scenario.

=== Scenery ===
We will be using newly generated scenery in Lelystad, showing the latest&greatest possible in FlightGear. Including OSM roads/canals, Corine landclassing and updated airport layouts.

== External links==
* [http://www.fsweekend.com Official FSweekend website]
* [http://www.facebook.com/event.php?eid=156455921107827 FlightGear's FSweekend page at Facebook]

[[Category:FSweekend]]

FSweekend 2011

2011-09-25T20:58:40Z

Durk: /* Equipment Checklist */

[[File:FSweekend_banner_2011.jpg|right|350px|link=http://www.fsweekend.com]]
This wiki page lists all information required for participants to the [[FSweekend]]. [[FlightGear]] will be represented by a team of regular FlightGear developers and users.

<eventcountdown date="05-November-2011">'''<daysuntil in="days">05-November-2011</daysuntil>''' until the FSweekend</eventcountdown>

== Booth information ==
This year's booth will probably exist of:
[[File:Anaglyph-glasses.jpg|right]]
* a FlightGear based [[Howto: Build your own procedure trainer|procedure trainer]].
* a Linux-based triple-screen PC, with a generic set of input devices for general purpose flight demonstrations

=== Equipment Checklist ===
* One main power extension cord (JVDV: red)
* One main power extension cord (DT: Green)
* One Linux-based PC (JVDV)
** Three monitors
** Thrustmaster HOTAS Cougar
** Saitek Rudder Pedals
** USB Headset
** 3D glasses
* One Linux-based PC (DT)
** Three monitors
** Saitek Joystick
** Saitek Rudder Pedals
** Headset
** Sound system

* Aviation themed Belgian Chocolade in sufficient quantities (DT).

== Flight information ==
=== Airports ===
Activities will mainly take place at and around [[Amsterdam Airport Schiphol]] (EHAM), [[Lelystad Airport]] (EHLE), [[Volkel Air Base]] (EHVK) and the VU University Medical Center Helipad [[EH0001]].

=== Charts ===
All charts that you may have to use on your flights are available at http://ais-netherlands.nl (AIS Publications > Integrated Package). Please note that these are the most up to date charts available, so certain situations might not have been changed in FlightGear (EHAM, EHLE and EHVK taxiways should be correct though).

Parking positions have been created for most of the Dutch airports including EHAM, EHRD, EHVK and EHLE (A1-A6, B1 and B2).

All named airports are for civil usage, except for [[Volkel Air Base]] (EHVK). This base will be occupied by the (AI) F-16 squadrons and likely one setup in Lelystad. Feel free to join with your F-16 or other Dutch/NATO [[:Category:Military aircraft|military aircraft]]. For EHVK specific departure and recovery procedures please visit http://cenor.org/pages/proc_eh.html and dowload the corresponding .pdf file.

=== Weather information ===
Reallife weather information can be found at the KNMI (Dutch Meteorological institute) website.
* [http://knmi.nl/actueel/metar.html METAR] current weather at airports
* [http://knmi.nl/waarschuwingen_en_verwachtingen/luchtvaart/nederlandse_vliegveldverwachtingen.html TAF] expected weather at airports
If the weather is really bad, it is likely that the FSweekend guys will use a preset weather scenario.

=== Scenery ===
We will be using newly generated scenery in Lelystad, showing the latest&greatest possible in FlightGear. Including OSM roads/canals, Corine landclassing and updated airport layouts.

== External links==
* [http://www.fsweekend.com Official FSweekend website]
* [http://www.facebook.com/event.php?eid=156455921107827 FlightGear's FSweekend page at Facebook]

[[Category:FSweekend]]

FlightGear Newsletter September 2011

2011-09-25T20:23:30Z

Durk: /* --parkpos=AVAILABLE */

FlightGear Newsletter September 2011

2011-09-19T19:50:02Z

Durk: /* AI Traffic updates */

File:Fgfs-screen-334.png

2011-09-19T19:47:00Z

Durk: Busy Traffic at KSFO

Busy Traffic at KSFO

FlightGear Newsletter September 2011

2011-09-19T19:41:30Z

Durk: /* Adding AI Traffic */

Talk:AI Traffic

2011-09-19T15:52:04Z

Durk: TODO

The article's TODO list:

I just noticed that the flightgear source code also contains a "ul" traffic type, which isn't documented. Likewise, the vtol traffic type must be described in the article, as it gets updated.

[[User:Durk|Durk]] 11:52, 19 September 2011 (EDT)

FlightGear Newsletter August 2011

2011-08-31T21:38:01Z

Durk: /* Screenshot of the month */

FlightGear Newsletter August 2011

2011-08-31T21:33:57Z

Durk: /* Screenshot of the month */

File:FlightGear sun halo.JPG

2011-08-31T21:30:11Z

Durk: Dated March 18, 1999, his little gem is one of the oldest surviving screenshots of FlightGear. Relatively pale compared to current versions of flightgear, this image shows a very basic landscape, a newly textured sun (with halo), and a very small cresent

Dated March 18, 1999, his little gem is one of the oldest surviving screenshots of FlightGear. Relatively pale compared to current versions of flightgear, this image shows a very basic landscape, a newly textured sun (with halo), and a very small cresent moon. Back then, flightgear was the only PC based flight simulator rendering the Sun, Moon, and celestial objects at the correct position, and under the correct lighting conditions, in the sky.

AI Traffic

2011-08-29T20:24:44Z

Durk: /* Remove the link to my now deceased xs4all website */

{{UpdateToGit}}

'''Interactive Traffic''', or '''AI-Traffic''' (Artificial Intelligence) has come to life with [[FlightGear]] version 0.9.5. Since then FlightGear has an interactive traffic system that is based on the AI-Models subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
# Create Traffic files,
# Build ground networks for the Airports containing traffic.
# Create the appropriate Departure / Arrival procedures for each airport involved.

Notice that the "Download all AI aircraft" is no longer necessary, because most, if not all, AI aircraft are now part of the base package.

== Building Traffic Files ==
Traffic patterns are stored in data files in extended markup language (.xml) format. The actual location of these files are version dependent. For FlightGear 0.9.x, traffic files are stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<tt>[[$FG ROOT]]/Traffic/</tt>

In FlightGear 1.0, the traffic files can be found in a subdirectory of:

<tt>[[$FG ROOT]]/AI/Aircraft/</tt>

For example, traffic belonging to a united airlines 737 would be located in: <tt>[[$FG ROOT]]/AI/Aircraft/737/737-UnitedAirlines-traffic.xml</tt>

FlightGear 1.9.0 has seen yet another move. In this version, the traffic files can be located in:

<tt>[[$FG ROOT]]/AI/Traffic/</tt>

For FlightGear 1.9.0 and later, a new traffic file format was introduced (henceforth referred to as "traffic manager II" format (TM-II), in which aircraft and flights are no longer directly coupled, leading to more flexibility.

Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==
As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by [[McDonnell Douglas MD11]] aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database was originally constructed on the basis of a fixed routing table that was assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and these FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remained the same, unless a major update to the database were to take place. Real aircraft require maintenance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintenance in this respect.

There were still some significant drawbacks to this approach, nevertheless. Consider the MD11 a little further. In real life, KLM operates this aircraft on many routes that are serviced at relatively irregular intervals. For example, many flights to the Carribean are served only two or three times a week, making it extremely complicated to build completely accurate traffic files for these routes.

To circumvent these problems, a new database format was introduced in FlightGear 1.9.0. In this new format, flights are no longer directly and rigidly assigned to specific aircraft. Instead, a more generic description of a fleet is given, along with a series of flights that need to be carried out. The routing is then taken care of by FlightGear itself.

== An example of a traffic file ==

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:

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>
</aircraft>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCB</registration>
<heavy>true</heavy>
</aircraft>

<flight>
<callsign>KLM0765</callsign>
<required-aircraft>MD11KLM</required-aircraft>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/12:35:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>TNCM</port>
<time>0/21:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0769</callsign>
<required-aircraft>MD11KLM</required-aircraft>
<fltrules>IFR</fltrules>
<departure>
<port>TNCM</port>
<time>3/01:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/10:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</trafficlist>

== 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.

== General Layout ==
The general layout of each file should look like the above example.
<?xml version="1.0"?>
<trafficlist>

</trafficlist>

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 ==
<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>
</aircraft>
<aircraft>
...
</aircraft>
</trafficlist>

The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter [[ICAO]] airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
* '''<home-port>''' Each FlightGear aircraft is assigned to a home airport. Internally, this is used to ensure that routes are setup that will eventually lead back to the home airport. This is done to maintain some sensibility into the routing algorithm. '''[New for traffic manager II]'''
* '''<required-aircraft>''' This value is a key that binds aircraft and flights together. In case of this example, the key MD11KLM. Indicates that this aircraft will only carry out flights containing the same key. Usually, a combination of aircraft type, and airline will suffice for this key. In some cases, in particular, when specific aircraft / airlines are distributed across multiple hubs (i.e. home ports), it may be necessary to specify a key containing the home airport as well. For example, Delta Airlines operates 767's out of Atlanta, as well as out of New York. To separate between these two cases, it would be advisable to use two keys; one for KATL (e.g. 767DALKATL), and one for KJFK (e.g., 767DALKJFK). '''[NEW for traffic manager II]'''
* '''<actype>''' A description of the aircraft type reserved for future use in [[ATC]].
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' In the near future, this keyword will be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures. This line is also used for gate assignments and should be one of the following:
** '''ga''' (general aviation),
** '''cargo''' (cargo)
** '''gate''' (commercial passenger traffic)
** '''mil-fighter''' (military fighter)
** '''mil-cargo''' (military transport)
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:
** '''light_aircraft''' (prop driven single or twin),
** '''ww2_fighter''' (world war two fighter),
** '''jet_transport''' (modern commercial jet),
** '''jet_fighter''' (modern fighter aircraft)
** '''tanker''' (tanker aircraft), or.
** '''ufo''' (allows extreme accel/decel capabilities).
* '''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.
* '''<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 ==
The original traffic file format contained a series of flights enclosed within the <aircraft> section, e.g.,

<aircraft>
...
<flight>
</flight>
</aircraft>

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:

<aircraft>
...
<required-aircraft>MD11KLM</required-aircraft>
...
</aircraft>

<flight>
...
<required-aircraft> MD11KLM </required-aircraft>
...
</flight>

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.

<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>

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.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<required-aircraft>''' The key that links this flight to a particular aircraft. The see explanation in the ''aircraft'' section.
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<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.
* '''<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.
* '''<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).

== Putting it all together: Including a traffic file ==
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 data/AI/Aircraft directory. For example, traffic for a Boeing 737 could be located in in an xml file in data/AI/Aircraft/737, and traffic for a 747 should be located in data/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 data/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 data/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in data/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 data/AI/Traffic/mil/USAF.xml

== Tools ==
One major motivation for introducing the traffic manager II file format is to make it easier for FlightGear users to contribute to the traffic database. To further motivate this, some tools are currently in development that aim to make user interaction even easier. Although most of these tools are not ready for public use yet, it is probably worth mentioning some of these developments. First of all, the custrom scenery project is working on extending their scene model database to store traffic. A web based front end will allow users to enter their favorite flight, and thus collect an extensive amount of traffic data. Users will be able to download the collected results and place the downloaded files in their traffic directory.

Secondly, the author of the traffic manager code has written some scripts, mainly for private use, that will allow one to input the flight data into a simple text format and then convert the resulting text file to xml. The most important of these scripts can be found in the flightgear source package under scripts/perl/traffic/.

Creating AI traffic files this way is easy. First, you need to define the aircraft for each fleet (data taken from the June 2010 Malayasian project):

###HOMEP RegNo TypeCode Type AirLine Livery Offset Radius FltType Perf.Class Heavy Model
############################################################################################################################################

AC WMKK TF-ARN 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml
AC WMKK TF-ARJ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml
AC WMKK TF-ATZ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml

Then, you need to define all the flights according to the following layout:

########Flt.No Flt.Rules Days Departure Arrival FltLev. A/C type
################### ######### ####### ############### ############### #################

# London Heathrow (EGLL; UTC+1 ) to Kuala Lumpur (WMKK +8:00) vv.
FLIGHT Malaysian0001 IFR 0123456 21:00 EGLL 09:25 WMKK 360 747MAS
FLIGHT Malaysian0002 IFR 0123456 15:40 WMKK 04:50 EGLL 360 747MAS
FLIGHT Malaysian0003 IFR 0123456 11:00 EGLL 23:25 WMKK 360 747MAS
FLIGHT Malaysian0004 IFR 0123456 09:05 WMKK 08:15 EGLL 360 747MAS

# Frankfurt (EDDF; UTC+2 ) to Kuala Lumpur (WMKK +8:00) vv.
FLIGHT Malaysian0005 IFR 0.2.456 10:30 EDDF 22:25 WMKK 360 777MAS
FLIGHT Malaysian0006 IFR .1.3456 15:50 WMKK 04:25 EDDF 360 777MAS

Note that the flight information laid out above resembles that of a standard airline schedule table as close as possible, with a few known exceptions:
- Weekdays are in the range 0 to 6, but do follow standard airline conventions (0 = monday; 6 is sunday)
- All times in the table are in UTC; to convert from local time, as given in the airline table, subtract the airport in question's UTC offset).
- The last entry in each line (A/C type) should correspond to the ''combination'' of the '''TypeCode''' and '''Airline''' entries in the aircraft sections.

The resulting table can now easily be converted to xml output by running the conf2xml.pl (conv2xml.pl - check) script.

For unix based operating systems, simply run conf2xml.pl from the directory where you unpacked the trafficdata.zip archive:

./conf2xml.pl

will give the output:

Writing to ADR.xml
Writing to AFL.xml
...
Writing to VLG.xml
Writing to VLM.xml

When the script encounters an error, it will stop prematurely.

= 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 data/AI/Airports directory/. Currently, this information is provided on a one file per airport basis, that can be found in a file called data/AI/Airports/[ICAO]/parking.xml, where ICAO stands for the 4 letter ICAO code for the airport in question.

For example, see the ground network for EHAM, which is found in <tt>data/Airports/AI/EHAM/parking.xml</tt>. See the end of this page for a small
excerpt from this file. It should be noted that current development work is planned that aims to move these files from the base package to the scenery repository, so that ground network information and the physical layout of the airport can be updated in parallel. Once this is done, the new location / name for the file will be [fg-scenery]/Airports/[ICAO1]/[ICAO2]/[ICA03]/[ICAO].groundnet.xml. Here [ICAO] stands for the 4 letter ICAO code of the airport in question, and [ICAO1], [ICAO2], and [ICAO3] for the first to third letter of this code.

'''NOTE:''' Taxidraw versions with a build date of Feb. 5, or later, 2009 support the new naming convention. To make use of this new functionality, make sure to set the FlightGear scenery directory in TaxiDraw (tab 4 in the preferences menu). The directory specified here should be the top level directory, i.e. the one that contains the "Airports", "Objects", and "Terrain" subdirectory. Note that support for this naming convention was introduced somewhat earlier, but versions of TaxiDraw before Feb 5 contain a potentially fatal bug that might ruin your work.

In addition, FlightGear cvs of approximately the same date also has support for reading the ground networks from the scenery directory. This feature is not enabled by default. To enable, make sure the property /sim/traffic-manager/use-custom-scenery-data is set to true. This can be done by editing preferences.xml or specifying this property on the command line.

== A technical perspective ==
A ground network file consists of 4 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 second section of the file contains the parameters of the airport's parking
locations. The third section contains a list of all the nodes in the ground
network, and the fourth and final section contains a list of segments, or "arcs" as David
Luff called them initially, which basically describe which node is connected
to which other node.

Each parking and AI node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
* '''index (unique, consecutively numbered id)
* '''lat''' (position in latitude)
* '''lon''' (position in longitude)
* '''name''' (name as found on airport charts: e.g. D23, or C1).

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay. See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison. Valid values for this parameter are:
** '''ga''' (general aviation),
** '''cargo''' (cargo)
** '''gate''' (commercial passenger traffic)
** '''mil-fighter''' (military fighter)
** '''mil-cargo''' (military transport)

* '''number:''' Currently used in combination with the <name> parameter to determine the full name of the gate.
* '''heading:''' The heading at which the aircraft are parked in this bay.
* '''radius:''' A value used to determine whether the aircraft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above. FlightGear uses a standard list of [[aircraft radii]] for gate assignment.
* '''airlineCodes:''' a comma-separated list of ICAO airline codes used to indicate which airlines should park here. Leave this field blank if you want any aircraft to park here.
* '''pushBackRoute:''' A number that refers to another node in the network. In a correctly configured network, the AI aircraft will taxi to this node in reverse, thus simulating being pushed back. See the documentation for the PushBack hold point type below.

Taxiway nodes contain two additional parameters:
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, or 0 otherwise
* '''holdPointType''' Describes wether the current point should be considered a holding point. This parameter can have the following values:
** '''none''' No holding point
** '''normal''' A regular holding point. This point should be placed just before the runway entrance / exit points, so that traffic will not enter the runway before receiving clearance to enter the runway. Note that support for this type of holding point is not implemented yet, but should appear sometime during 2009.
** '''CAT II/III''' A special holding point for IFR conditions. Currently not supported yet.
** '''PushBack''' A push back hold point type. Each parking can be connected to maximally one push back point, connected through a series of push back routes. Note that a push back point is optional, but that there can maximally only be one connected to each gate.

Finally, the taxiway segments contain three parameters.
* '''begin''' The id of the parking or AINode where this segment starts
* '''end''' The id of the parking or AINode where this segment ends
* '''IsPushBackRoute''' a logical value. Should be one if the current segment is part of a route connecting a gate to a push back hold point, or 0 otherwise.
* '''name''' Name of the taxiway.

== 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. The current document describes the functionality of the NEW_GUI_CODE version of TaxiDraw.

== TaxiDraw ==
Although currently no officially released version of [[TaxiDraw]] (http://TaxiDraw.sourceforge.net/) 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.

=== Obtaining TaxiDraw ===
Until an official release has been done, linux users can try to check out a version of TaxiDraw from CVS by following
the instructions on http://TaxiDraw.sourceforge.net/#download

[[Ubuntu]] or [[Debian]] users may look at the [[Ubuntu fg tools]] page to have TaxiDraw installed in a easy way.

Windows users can also do this either by using the free winCVS program or
using the free cygwin environment. Another possibility is to look on [ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32]- here you can find the last build of Taxidraw.

=== Getting good reference material ===
The first step in preparation of creating a ground network consists of getting some reference material. Ideally, You'd like to find a good satellite or aerial image. If you can't find that, using a schematic diagram might also work. For airports in the United States, you can simply load USGS imagery by clicking the "USGS" button, however, for the rest of the world, this service is not available. Perhaps the best way to get a decent reference image is to use the standalone GoogleEarth program. GoogleEarth lets you zoom in to any location of the world. Center your view on the airport, and zoom to encompass the entire area. Then, save a jpg snapshot of the screen. This image can be imported in TaxiDraw. After importing, right click, goto the "lock layers" submenu and unselect the background image. Next, select the background image, right click and select the "calibrate background image". Typically, the "Uniform scale / rotation option" works best.

Although a google earth snapshot will usually give a good reference for the actual location of airport parkings, it still doesn't give much information about some of the logical aspects of the parking infrastructure. In particular, information about gate names / airline operations is not provided. Typically, this information is hard to find, but can be compiled from various sources, including wikipedia, random airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!

=== Creating the network ===
The current documentation describes the procedure for the TaxiDraw NEW_GUI_CODE branch, which is rather drastically different from the procedure used by the original TaxiDraw, previously documented here. This section describes some of the general procedures involved in building a ground network.

Note: export your work regularly: Although ground network editing capabilities have improved dramatically, this part of TaxiDraw is still somewhat separate from the rest of the code, and ground networks are not automatically saved together with the project. When exporting, TaxiDraw asks wether the ground network should be saved directly into FlightGear's data directory. Usually, this is okay, so just clicking "yes" takes care of saving the file in the correct location. Likewise, while importing an existing network, TaxiDraw first looks in FlightGear's data directory, to check for an existing default file to be inported.

==== Set up a rough outline ====
To make best use of the background image, right click, choose the "view" menu, and unselect "taxiways", this way, all network drawing can be based on the real airport location. First, select the "Insert startup location" edit mode. This way, each left mouse click will place a startup location at the position of the mouse cursor. Once the major startup locations have been placed, switch back to "selection" mode, by clicking the little arrow button.

Next, start editing all the relevant startup location parameters. Parking heading can be changed by dragging the little red circular heading indicator. The parking's radius can be changed by clicking anywhere on the big red circle allows one to change the parking's radius by dragging the mouse. Although this usually works for setting up a rough draft, these parameters can directly be changed in the properties dialog. If the properties dialog is not visible, press [cntrl-p] to bring it up. It is possible to select multiple startup locations by pressing the shift key while selecting, and the parameters for each selected startup location can be changed at the same time. This is a powerful feature for editing the parameters of a whole series of parking locations, and also for equating and orienting gate radius and heading.

With the startup locations in place, select one of them. The next step will be to connect this parking area to each runway end. After selecting the parking, click on the "insert bidirectionally connected network nodes" (the two green dots icon), and start drawing. Place nodes at strategic locations, such as intersections, corners, and arcs. finally, place one node at the centerline of one of the runways. Once this is finished, one gate is connected to one end of one runway. The next job is to extend the network by connecting more gates and more runways.

Create a second branch from the existing route, which goes to another runway. To do so, press [cntrl-a] to deselect all objects. Then, select the point where you want to branch off from. Select this point using a left mouse click, while holding down the shift key. Since TaxiDraw is still in node connect mode, simply left-clicking would have resulted in placing a new node. With this node selected, continue drawing. Repeat this procedure until all runways are connected.

Then, start adding the additional gates to the network. Press [cntrl-a] to deselect all objects. Then select a gate by pressing [shift-left mouse, and start drawing unil the the gate in question is one segment away from being connected. Then, [shift left-click] the network node that this route segment should be connected to, and make sure that the correct node is selected. Then, right click, and select "connect nodes bidirectionally" from the AI nodes menu.

Repeat this procedure until all parking locations are connected to each runway.

==== Refining the network: Mark points on the runway as such ====
With the basic infrastructure in place, the next step is to fine-tune the network. The first step in this process is to mark the network nodes that are located on a runway. This is important for a number of reasons: Taxidraw needs these OnRunway points for it's network verification tool. Secondly, the use of the type of runway marking will be used in future versions of FlightGear for runway entrance / exit calculations, in addition to a host of other possible uses in routing (such as blocking a certain node then a crossing runway is in use, etc, etc).

It should be noted that there is no reason why TaxiDraw should not be able to mark the runway points as such automatically. After all, the geometry information of both runways and AI nodes is available. Although this automatic feature is planned, the TaxiDraw developers have as of yet not found the opportunity to implement this feature. Until that time, on runway marking has to be done by hand.

==== Refining the network: Set Holding points ====
Holding points are nodes in the network that do something special. They can be used by FlightGear to make traffic wait at certain specific locations. As a matter of fact, the 'normal' and 'Cat II/III' hold points are not yet used by FlightGear, but are part of the development plan. Currently, hold points are implicitly assigned by the FlightGear AI code. For instance, traffic waiting for takeoff clearance is holding at the first point before the runway. Likewise, traffic can receive a hold position instruction just before an intersection in the taxiway system, when traffic is approaching at the other leg. While these implicit hold points work reasonably, there are some limitations. Consider for example runway 07 at CYYC (Calgary Intl, Canada). In the FlightGear rendition of this airport, there are no taxiways leading to this runway, so departing aircraft should back track the runway from an entrance point at the middle of the runway. Currently that point will also become the runway entrance holding point. This is clearly undesirable, because it means that traffic is actually waiting ''on the runway'' in order to get clearance to enter it. For this reason, airport ground network designers should have a means to have explicit control over holding points. The normal hold point is meant for just that.

The Cat II/III hold point type is meant as an extension to this scheme for special IFR conditions. Support for these types in FlightGear is planned for a later stage of development though.

==== Refining the network: Pushback routes ====
With the above-mentioned refinements, the ground network should be fully working, with one notable exception. Aircraft will be driving forward when leaving the gate, making a sharp turn (while probably destroying themselves and the terminal building in the process). To prevent this, a ''push back'' route should be created. A push back route consists of at least one or more taxiway segments that have the "PushBack Route" property set to true. The last of these segments should be terminated by a PushBack HoldPoint network node.

Notice that a push back route is optional, but that parkings may never have more than one push back route. The formal criterium for a valid push back route is that each gate should have a maximum of one pushback node associated with it, which can be reached using one route only. From an editing point of view, it is sufficient to just mark a number of taxiway segments as push back, and mark the ending node as such as well.

It is important to note that the "Verify Ground network" process ''should be run'' in order to get a correctly working push back system, because this function runs some internal consistency checks. Push back routes can be very simple, from just one route segment, to fairly complex, as illustrated below. Shown here are 3 examples from the EHAM ground network. 1) Shows a fairly complex example, where all aircraft from one side of the E terminal are being linked to one shared push back point. In the example, the push back route of an aircraft departing from gate E20 is illustrated. 2) Shows a simple example, where one aircraft is being pushed back, and makes a left turn. In essence, 3) shows a similar example, but now in a slightly more crowded space, where pushback nodes are overlapping. The current push back system allows for fairly complicated behavior. To get a full understanding of it's workings, it is advisable to play with some of the existing ground networks. EHAM and KFSO currently provide the most complex setups.

Finally, please notice that you need a version of TaxiDraw with a build date of February 5, 2009, or later, for this to work correctly. Earlier version did not export the pushBackRoute attribute correctly. Support for this functionality was introduced late January 2009, but versions earlier than February 4 contain a potentially fatal bug, that may seriously damage your work.

[[File:TaxiDraw2.png|500px]]

==== Verifying the network ====
Finally, with a network complete, it is important to verify it! The verification function not only detects obvious problems with the network, it also updates some internal states that FlightGear relies. on. Presumably, an automatic verification process will be added to the export function, but until that is the case, make sure to do this manually. The verify network function can be found in the "Tools" menu.

Notice that TaxiDraw does not automatically fix problems. It is left to the user to fix the problems manually. TaxiDraw does select the offending node(s) / segments(s) for easier identification. Also note that TaxiDraw stops verifying at the first problem encountered, so it is worthwhile to continue checking until no further errors are found. Currently, the following checks are performed.

* '''On runway points''' Added on January 24, 2009, this check is most likely not yet available in any distributed version. This is currently just a very lame check to see if any point in the network has been marked as such. This check is not exhaustive, but simply meant as a reminder to the editor that the OnRunway points should still be marked. Ultimately, this check should be replaced by the aformentioned automatic geometry function.
* '''Duplicate Taxiway Segments''' It's easy to connect two network nodes twice. While this doesn't really hurt, it does add dead weight, so checking for duplicates is not a bad thing.
* '''Routing''' One of the most persisting problems, headache causing problems is that of a disconnected parking in the network. FlightGear will happily place an aircraft there, but bail out when that aircraft cannot reach the runway. The routing check attempts to prevent this. Notice that it is of utmost importance that the OnRunway points are set correctly, because TaxiDraw relies on these points for it's route finding algorithm. Because the route finding algorithm is rather computationally intensive, some progress information is currently written to the console (a proper progress bar would be nice). When a disconnected parking is found, TaxiDraw selects both the parking and the runway node. It is still left to the user to trace a route between these two points and find where the two pieces are disconnected.
* '''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 ==
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,
you'd also need to give each parking a name, and a heading, and probably airlines codes. Changing name, and heading can be done in TaxiDraw, by right
clicking on the startup location. This will bring up a dialog, in which you can change latitude, longitude, heading, and name. Once you're done editing, click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack parameters is not yet possible in TaxiDraw. So changing these requires saving the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (TaxiDraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

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 data directory ==
Finally, once you have finished creating a groundnet work you can test it in FlightGear. Create a directory in FlightGear's <tt>data/Airports/AI</tt> directory, with the name of the ICAO code of your airport. For example <tt>[[$FG ROOT]]/Airports/AI/EHAM</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 "parking.xml".

== 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.

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 =
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.

= Appendix: Special Notes =
== Realism ==
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.

== Perfomance ==
With FGFS 1.0.0, the AI Interactive Traffic needs a lot of CPU-power. With the current CVS-versions, however, we now have much better performance 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.

== External links ==
* [http://www.xs4all.nl/~dtalsma/FlightGear.html The FlightGear AI aircraft download page]
* [http://www.ilovelinux.de/svn/fgfs-ffm/user/data/AI/ Created a dense AI traffic for EDDF, LSZH and a lot of other airports depending on real timetables. More to come!]

Initial Starting Positions

2011-08-29T17:49:05Z

Durk: /* Starting-Position at a Terminal, Gate, Parking-lot, etc. */

You can define any point on Earth as the Initial-Starting-Position for your Flight Gear-Session, as well on airports as outside, ashore or in the mids of the oceans, even somewhere in the air above. You even do not need to have the Sceneries installed for that Starting-Position! ''(But if the scenery is not available you will see nothing but a big blue water around you – wherever you are! Of course you could load that scenery then by [[TerraSync]]'')

If you are flying just by yourself (i.e. without having [[Howto: Multiplayer|Multiplayer]] activated) you may just choose an airport and leave it up to FlightGear to place you somewhere onto a runway. That is the most easiest procedure at all – but absolutely unrealistic – '''and if done, while others are around, it is absolutely recklessness against those already there!''' Because if you start FlightGear with the [[Howto: Multiplayer|MP-Options]] directly on a runway you cannot watch for somebody being there already, or being on short final to it, or if there is an [[:Howto: Be a controller|ATC]] who may start to dislike you a lot, or … or ...! Best is you just use proper procedures and always start at a parking-position, gate, or terminal when you are not alone! That way you even have the advantage of getting accustomed to the controls and instruments again while taxiing to the runway.

'''So please consider the following procedures to define your start-position in FlightGear:'''

== Starting-Position at a Terminal, Gate, Parking-lot, etc. ==
This option is the only one that meets reality! And should always be used when flying amongst others.
* '''With [[FlightGear Launch Control|FGrun]]''' you find the available Starting-Positions on the page where you define the Airport, on the right side underneath the Runways.
* '''Without [[FlightGear Launch Control|FGrun]]''' you find these places inside the file “parking.xml” for each airport, where those are available. See e.g. ''''$FG_Root\Airports\K\O\A\KOAK.parking.xml''''.

:There you will find e.g. the position:
::<Parking index="2"
:::type="gate"
:::name="747f1"
:::number="1"
:::lat="N37 42.807"
:::lon="W122 12.963"
:::heading="130"
:::radius="39"
:::airlineCodes=""
::/>

:Thus you could define this “Gate” by adding the options
::''''--airport=KOAK --parkpos=747f1''''
:to your start-command.

:Of course you also could use the above shown “lat/lon/heading”-values to define that position in [[GPS]] (see next chapter) – but you would have to convert those from Decimal to Grad° (You could do that with e.g. http://www.fcc.gov/mb/audio/bickel/DDDMMSS-decimal.html).

Sorry enough: Those Starting-Points are not defined for all airports - due to the limited availability of unpaid volunteers. But You can define your own “parking.xml” or add parking-lots to an existing one according to the above scheme – for HowTo get additional [[GPS]]-data see the next chapter! That way you could create your own personal “VIP-Parking” for your most favorite airports! Save the new "parking.xml"-file into the ''''$FG_ROOT/AI/Airports/ICAO-Code/'''' (or if you use FlightGear 2.4.0 or newer into'''$FG_ROOT/Scenery/Airports/[i]/[C]/[A]/ICAO.groundnet.xml''') directory. Please note, however, that parking positions are defined as part of a ground network file that was originally designed for FlightGear's AI system. Checkout the [[Interactive_Traffic]] page for more information on ground networks.

And if you do that for yourself, why not add a few more statements and make them available to everybody! See e.g. the http://wiki.flightgear.org/index.php/Volunteer and airport-diagrams, which are available in the Internet.

== Starting-Position per GPS-Data ==
You always have 3 possibilities to define your Starting-Positions by [[GPS]]:
[[File:KRHV-startpoistion.png|250px|thumb|left|]]1. Open [[MPmap]] and zoom into the airport you wish. Move your Mouse-pointer to the place you want – e.g. to the place on KRHV where “jomo” is parked now. And then read the lat/lon-data in the upper right corner (see the big red arrow). In addition decide on the direction you want to view: In the example on the left that is parallel to runway 31R, i.e. 310°+14°=324°. (The 14° are the difference between the magnetic and the cartographic North-pole in that area – if you do not know it: Just try e.g. the 310° and vary the heading until you are satisfied – or try the next item!)

2. You could also just land on that airport and taxi to a parking-lot you like and park there. After parking open inside your cockpit ''''Menü → File → Browse Internal Properties → position'''' and note down the „latitude-deg“ and „longitude-deg“ (up to 6 decimal places is enough!). The needed heading you can take directly from your Compass.

3. Of course you could also get that data by any atlas or navigation system and convert the data if needed!

* If you start '''with [[FlightGear Launch Control|FGrun]]''' input those data into ''''“Advanced” → “Initial Position”''''. Watch out: The sequence of the lon/lat input-fields in FGrun are just reverse to MPmap.

* If you start '''with a command or a command-file''' just add the options, eg.:
:''''--lat=37.334047 --lon=-121.816320 --heading=324''''

''If after that you end up in KSFO instead of where you wanted, then you probably have mixed up the Longitude and Latitude – or mistyped - or you found a new way to define a non existing place on earth!''

== Starting-Position in relation to navigational points ==
This is a wonderful way to test unique parts of a flight: With that Option you can start at unique locations and start your exercise, e.g. a “final approach”, or flying towards a NDB under different wind-conditions, etc.

As reference-point you can choose any navigational aid available in FlightGear, e.g. VOR, NDB, FIX, Carrier, airports – whatever! But watch out: For some VOR's and NDB's there may exist multiple stations with the same ID! e.g. there is a VOR “RIED” with the ID=”RID” southwest of EDDF (Germany). Another VOR “RID” exists in Richmond (Indiana, USA) - thus you never know where you end up. That does not happen very often – but you should be aware of that “mishap”! More secure in this cases is the above GPS-procedure!

* '''With [[FlightGear Launch Control|FGrun]]''' you can (since version 2) input the needed data direct into ''''“Advanced” → “Initial Position”''''.
* '''For a command file''' add options like:
::--vor or --ndb or --fix or --carrier or --airport
::--offset-distance and --offset-azimuth (if wanted)
::--on-ground or --altitude=feet
:Try e.g. ''''--fix=FITKI --heading=276 --vc=100 --altitude=1500''''
:that will place you directly over a FIX for the ILS approach for runway 27R at KOAK. The speed (vc=100) fits to a C172 and the altitude (1500) is the proper altitude on the glide-slope for that. So this is a good Start for training visual Approaches (and or ILS). Other FIX-points you may find by opening [[MPmap]] in the area you are interested in and search for “all fixes”. (ref. http://wiki.flightgear.org/index.php/Mpmap )

== Starting-Position direct on a Runway ==
This is the easiest way to start – and thus often used to get beginners into the air for the first time! But as I pointed out at the beginning you should use this option only when you are all by yourself, that means without [[Howto: Multiplayer|Multiplayer]] activated! And all of us will be very thankful if you promote not to use this option when other [[Howto: Multiplayer|Multiplayer]] are in the area!

Anyhow there exist 2 possibilities for this:
=== Starting-position by defining just the airport ===
In this case FlightGear choses a runway itself according to wind-direction etc. - and thus assigns the very same place for everybody ''(that wants to be piled up one above the other!)''. This usually end's up with lots of bad words by
* pilots just being on short final and suddenly see some obstacle appearing on their runway! Not every pilot is then cool enough to continue going through that other guy
* pilots suddenly sitting in their plane within your plane!
* an [[Howto: Be a controller|ATC]] whom you just destroyed all his efforts in trying hard to get some order into all that “flying objects”

You have no ideas about what kind of nice words those guys are able to use for you in such cases – you better switch off your FGCOM and/or MPchat if kids are around!

So we definitely do not suggest to use this option – but if you want to use it (when you are alone!):
* '''in [[FlightGear Launch Control|FGrun]]:''' Just pick an Airport
* '''for a command-file''' add e.g. the option:
::''''--airport=KOAK''''
 
=== Starting-position by defining an airport and a runway ===
This is even worse than the above! To all that bad happenings from before you are now even prone to start in a different direction to the other traffic! And thus those others would not just use even worse words – they would even laugh about you, that “stupid that does not know that you must start against the wind!”

This option may be useful only for real beginners, that cannot yet perform above possibilities. These poor guys can choose a small, usually unused runway as their Starting-Position. As I said: As long as they still are “bloody beginners”!

In that case:
* '''in [[FlightGear Launch Control|FGrun]]''' select in addition to the wanted Airport also the wanted runway
* '''for a command-file''' add e.g. the option:
::''''--airport=KOAK --runway=33''''
You can find available and fitting Runways in [[MPmap]] by selecting the Airport wanted and zooming in.
[[de:Initial Starting Positions]]

Initial Starting Positions

2011-08-29T17:43:53Z

Durk: /* Starting-Position at a Terminal, Gate, Parking-lot, etc. */

You can define any point on Earth as the Initial-Starting-Position for your Flight Gear-Session, as well on airports as outside, ashore or in the mids of the oceans, even somewhere in the air above. You even do not need to have the Sceneries installed for that Starting-Position! ''(But if the scenery is not available you will see nothing but a big blue water around you – wherever you are! Of course you could load that scenery then by [[TerraSync]]'')

If you are flying just by yourself (i.e. without having [[Howto: Multiplayer|Multiplayer]] activated) you may just choose an airport and leave it up to FlightGear to place you somewhere onto a runway. That is the most easiest procedure at all – but absolutely unrealistic – '''and if done, while others are around, it is absolutely recklessness against those already there!''' Because if you start FlightGear with the [[Howto: Multiplayer|MP-Options]] directly on a runway you cannot watch for somebody being there already, or being on short final to it, or if there is an [[:Howto: Be a controller|ATC]] who may start to dislike you a lot, or … or ...! Best is you just use proper procedures and always start at a parking-position, gate, or terminal when you are not alone! That way you even have the advantage of getting accustomed to the controls and instruments again while taxiing to the runway.

'''So please consider the following procedures to define your start-position in FlightGear:'''

== Starting-Position at a Terminal, Gate, Parking-lot, etc. ==
This option is the only one that meets reality! And should always be used when flying amongst others.
* '''With [[FlightGear Launch Control|FGrun]]''' you find the available Starting-Positions on the page where you define the Airport, on the right side underneath the Runways.
* '''Without [[FlightGear Launch Control|FGrun]]''' you find these places inside the file “parking.xml” for each airport, where those are available. See e.g. ''''$FG_Root\Airports\K\O\A\KOAK.parking.xml''''.

:There you will find e.g. the position:
::<Parking index="2"
:::type="gate"
:::name="747f1"
:::number="1"
:::lat="N37 42.807"
:::lon="W122 12.963"
:::heading="130"
:::radius="39"
:::airlineCodes=""
::/>

:Thus you could define this “Gate” by adding the options
::''''--airport=KOAK --parkpos=747f1''''
:to your start-command.

:Of course you also could use the above shown “lat/lon/heading”-values to define that position in [[GPS]] (see next chapter) – but you would have to convert those from Decimal to Grad° (You could do that with e.g. http://www.fcc.gov/mb/audio/bickel/DDDMMSS-decimal.html).

Sorry enough: Those Starting-Points are not defined for all airports - due to the limited availability of unpaid volunteers. But You can define your own “parking.xml” or add parking-lots to an existing one according to the above scheme – for HowTo get additional [[GPS]]-data see the next chapter! That way you could create your own personal “VIP-Parking” for your most favorite airports! Save the new "parking.xml"-file into the ''''$FG_ROOT/AI/Airports/ICAO-Code/'''' (or if you use FlightGear 2.4.0 or newer into'''$FG_ROOT/Scenery/Airports/[i]/[C]/[A]/ICAO.groundnet.xml) directory

And if you do that for yourself, why not add a few more statements and make them available to everybody! See e.g. the http://wiki.flightgear.org/index.php/Volunteer and airport-diagrams, which are available in the Internet.

== Starting-Position per GPS-Data ==
You always have 3 possibilities to define your Starting-Positions by [[GPS]]:
[[File:KRHV-startpoistion.png|250px|thumb|left|]]1. Open [[MPmap]] and zoom into the airport you wish. Move your Mouse-pointer to the place you want – e.g. to the place on KRHV where “jomo” is parked now. And then read the lat/lon-data in the upper right corner (see the big red arrow). In addition decide on the direction you want to view: In the example on the left that is parallel to runway 31R, i.e. 310°+14°=324°. (The 14° are the difference between the magnetic and the cartographic North-pole in that area – if you do not know it: Just try e.g. the 310° and vary the heading until you are satisfied – or try the next item!)

2. You could also just land on that airport and taxi to a parking-lot you like and park there. After parking open inside your cockpit ''''Menü → File → Browse Internal Properties → position'''' and note down the „latitude-deg“ and „longitude-deg“ (up to 6 decimal places is enough!). The needed heading you can take directly from your Compass.

3. Of course you could also get that data by any atlas or navigation system and convert the data if needed!

* If you start '''with [[FlightGear Launch Control|FGrun]]''' input those data into ''''“Advanced” → “Initial Position”''''. Watch out: The sequence of the lon/lat input-fields in FGrun are just reverse to MPmap.

* If you start '''with a command or a command-file''' just add the options, eg.:
:''''--lat=37.334047 --lon=-121.816320 --heading=324''''

''If after that you end up in KSFO instead of where you wanted, then you probably have mixed up the Longitude and Latitude – or mistyped - or you found a new way to define a non existing place on earth!''

== Starting-Position in relation to navigational points ==
This is a wonderful way to test unique parts of a flight: With that Option you can start at unique locations and start your exercise, e.g. a “final approach”, or flying towards a NDB under different wind-conditions, etc.

As reference-point you can choose any navigational aid available in FlightGear, e.g. VOR, NDB, FIX, Carrier, airports – whatever! But watch out: For some VOR's and NDB's there may exist multiple stations with the same ID! e.g. there is a VOR “RIED” with the ID=”RID” southwest of EDDF (Germany). Another VOR “RID” exists in Richmond (Indiana, USA) - thus you never know where you end up. That does not happen very often – but you should be aware of that “mishap”! More secure in this cases is the above GPS-procedure!

* '''With [[FlightGear Launch Control|FGrun]]''' you can (since version 2) input the needed data direct into ''''“Advanced” → “Initial Position”''''.
* '''For a command file''' add options like:
::--vor or --ndb or --fix or --carrier or --airport
::--offset-distance and --offset-azimuth (if wanted)
::--on-ground or --altitude=feet
:Try e.g. ''''--fix=FITKI --heading=276 --vc=100 --altitude=1500''''
:that will place you directly over a FIX for the ILS approach for runway 27R at KOAK. The speed (vc=100) fits to a C172 and the altitude (1500) is the proper altitude on the glide-slope for that. So this is a good Start for training visual Approaches (and or ILS). Other FIX-points you may find by opening [[MPmap]] in the area you are interested in and search for “all fixes”. (ref. http://wiki.flightgear.org/index.php/Mpmap )

== Starting-Position direct on a Runway ==
This is the easiest way to start – and thus often used to get beginners into the air for the first time! But as I pointed out at the beginning you should use this option only when you are all by yourself, that means without [[Howto: Multiplayer|Multiplayer]] activated! And all of us will be very thankful if you promote not to use this option when other [[Howto: Multiplayer|Multiplayer]] are in the area!

Anyhow there exist 2 possibilities for this:
=== Starting-position by defining just the airport ===
In this case FlightGear choses a runway itself according to wind-direction etc. - and thus assigns the very same place for everybody ''(that wants to be piled up one above the other!)''. This usually end's up with lots of bad words by
* pilots just being on short final and suddenly see some obstacle appearing on their runway! Not every pilot is then cool enough to continue going through that other guy
* pilots suddenly sitting in their plane within your plane!
* an [[Howto: Be a controller|ATC]] whom you just destroyed all his efforts in trying hard to get some order into all that “flying objects”

You have no ideas about what kind of nice words those guys are able to use for you in such cases – you better switch off your FGCOM and/or MPchat if kids are around!

So we definitely do not suggest to use this option – but if you want to use it (when you are alone!):
* '''in [[FlightGear Launch Control|FGrun]]:''' Just pick an Airport
* '''for a command-file''' add e.g. the option:
::''''--airport=KOAK''''
 
=== Starting-position by defining an airport and a runway ===
This is even worse than the above! To all that bad happenings from before you are now even prone to start in a different direction to the other traffic! And thus those others would not just use even worse words – they would even laugh about you, that “stupid that does not know that you must start against the wind!”

This option may be useful only for real beginners, that cannot yet perform above possibilities. These poor guys can choose a small, usually unused runway as their Starting-Position. As I said: As long as they still are “bloody beginners”!

In that case:
* '''in [[FlightGear Launch Control|FGrun]]''' select in addition to the wanted Airport also the wanted runway
* '''for a command-file''' add e.g. the option:
::''''--airport=KOAK --runway=33''''
You can find available and fitting Runways in [[MPmap]] by selecting the Airport wanted and zooming in.
[[de:Initial Starting Positions]]

FlightGear Newsletter August 2011

2011-08-28T19:50:11Z

Durk: /* AI/ATC interactions: Update: Past tense sounds better for a news letter coming out after the release. Also actualized the current development status a bit. */

FlightGear Newsletter August 2011

2011-08-10T20:19:46Z

Durk: Added an image of the ongoing AI/ATC interaction tests.

File:Ehamrwyblock.png

2011-08-10T20:15:50Z

Durk: Image of the overloaded taxiways at Amsterdam Schiphol airport (EHAM) after blocking active runway 24 for approximately 4 hours. This was part of an AI/ATC subsytems test.

Image of the overloaded taxiways at Amsterdam Schiphol airport (EHAM) after blocking active runway 24 for approximately 4 hours. This was part of an AI/ATC subsytems test.

FlightGear Newsletter August 2011

2011-08-07T21:33:57Z

Durk: /* AI/ATC interactions */

FlightGear Newsletter November 2010

2010-12-01T16:42:35Z

Durk: /* 737NG Series */

{{newsletter}}
{{TOC_right}}
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== FlightGear events ==
== Call for volunteers ==
The [[OpenRadar]] project is looking for a new maintainer.

The [[TerraGear GUI]] project is looking for programmers to help create a GUI frontend for [[TerraGear]] [http://flightgear.org/forums/viewtopic.php?f=5&t=7485#p102005].

== Development news ==
Anders Gidenstam has continued to develop Walkview which opens up all sorts of exciting possibilites. Here is a short video of Walkview being used to give a different perspective on starting the Sopwith Camel [http://www.youtube.com/watch?v=KAQT2s7pFJs]. In addition to the rectangular plane that we have had for some time, we can now define the area in which we can "walk" as a line, polyline, or circle.

We use the new definitions in Multi Player Carrier Carl Vinson to move around the Goofer's deck while we are goofing, or to seek a more advantageous view from PriFly, or to inspect the Flight deck as the Flight Deck Officer, as seen in [http://www.youtube.com/watch?v=h9MUT7GfzBs this video].

Meanwhile, in other news, Tim Moore has fixed the condition tag in the Material Animation. We can combine these two facilites to generate some more interesting views - [http://www.youtube.com/watch?v=1YmJN9o6TBc]. Alexis Bory has said that he will see if he can produce some more models with which to populate the hangar. Let's hope he finds something!

== Shader requests ==
We have added a new page to the wiki titled [[shader requests]]. This is intended to provide a place for people to post ideas related to new shaders for use in FlightGear. But this is also meant to be place for aspiring shader developers to find interesting ideas for new shaders. In the past, these ideas were often spread over many different places, such as forum or mailing list discussions, and often ended up getting hidden rather quickly. So if you have ideas related to improving existing shaders or creating completely new ones, please add your ideas to the [[Shader requests]] page. And if you are aware of any ongoing shader development efforts, please also add those there. Consequently, if you want to get started creating shaders for FlightGear, please make sure to check out this page.

== Known problems ==
Though working perfectly for years, the "live weather" feature in FlightGear 1.9.x and 2.0 is now broken. Unfortunately, the FlightGear code of past releases contains minor problem which so far remained undetected and without effect. Since early November, probably caused by a server upgrade at the weather services, the FlightGear weather requests are now being rejected due to this problem. To revive live weather you have the following options:
* As a workaround, configure a proxy-server on the fgfs command-line. Relaying the request through a proxy solves the issue (see [http://www.flightgear.org/forums/viewtopic.php?t=10002 forum topic]).
** A description on "How To Fix (temporarily)" you can find under http://www.emmerich-j.de/FGFS/METAR-fix.html
* Experts being able to patch and recompile FlightGear may try to apply a patch (also see forum).
* Developers can use FlightGear's latest developer version from GIT, which already contains the required bugfix.
* Otherwise please stick with manual weather configuration and wait for the next FlightGear release (won't be too long).

== Nasal for newbies ==
== New software tools and projects ==

== FlightGear addons and mods ==
== In the hangar ==
=== New aircraft ===

====Boeing 737NG Series====

Three out of four models from Innis Cunningham's Boeing 737NG series have been included in FlightGear's GIT repository. Despite being an initial release, the models are characterized by great attention to detail in the 3D cockpit, with some of the more advanced systems such as the autopilot and autobrake systems already fully operational. The models are further characterized by excellent Flight Dynamics Models (FDMs), co-developed and tested by real-life 737 pilot David Culp, and excellent exterior texturing, provided by FlightGear's very own texture master Gooneybird. Included are the 600, 800, and 900 variants. The 737-700 is expected to follow soon.

====DC-8-63====
Isix and Armchair Ace have recently unveiled a DC-8-63. You can follow the progress on the [http://www.flightgear.org/forums/viewtopic.php?f=4&t=10228 development thread].
[[File:Fgfs-screen-178.png|thumb|left|The DC-8-63 in KLM colours.]]

=== Updated aircraft ===

[[File:ZF_Navy_free_balloon-2.jpg|thumb|The ZF Navy free balloon with the envelope shader enabled.]]
====ZF Navy free balloon====
The [[ZF Navy free balloon]] has been updated with a custom shader effect that changes the shape of the balloon envelope according to its gas content.

====IAR 80====
The [[IAR_80|IAR 80]] beta has seen some updates, with new features added in the eyecandy department, as well as some refining of the [[Nasal_scripting_language|Nasal]] code and a revamped [[FDM]].

====Boeing 757 and 717====
[[User:Skyop|Skyop]] has picked up development of the [[Boeing 757-200]] and the [[Boeing 717]]. New features included generic autostart systems, improved models, new instruments and new [[YASim]] [[FDM]]s. New and improved cockpits and aircraft systems are planned. Skyop is requesting livery makers to start painting their favorite airlines and submitting their textures to the [http://liveries.flightgear.org official FlightGear livery database].

Follow further progress at the [http://flightgear.org/forums/viewtopic.php?t=9944 757-200 development thread] and the [http://flightgear.org/forums/viewtopic.php?t=6145 717 development thread].

====Boeing 777-200====
The [[Boeing_777-200|777-200ER]] received a cockpit and systems upgrade.
Extensions by Syd Adams and ThorstenB include better [[GPWS]] integration, improvements for cockpit instruments, sounds, textures, key/mouse bindings and many bug fixes.
The upgraded 777-200ER also features brake temperature monitoring.
Pilots are advised to also use spoilers and thrust-reversers for deceleration to avoid overheated brakes - especially when landing a heavily loaded plane.
The new auto spoilers, automatically deploying on touch-down when armed, provide some assistance here.

[[File:B777-200_RTO.jpg|thumb|Smoking brakes after a 777-200ER had to execute a rejected takeoff.
The airline declined to comment on the reason for the takeoff problem, but assured no one on board was injured.]]

====Douglas DC-8-73F====
[[File:DC8pit.png|thumb|left|The cockpit as it was on the 29th of November.]]
[[User:Armchair Ace|Armchair Ace]] has been developing the DC-8-73's cockpit, which has also been used in the new DC-8-63.

=== Liveries ===

==Scenery corner==
===New Bangkok International Airport===
[[File:VTBD_wip01.jpg|thumb|Bangkok Int'l Airport - work in progress.]]
Mike (aka D-Sky1) is busy again. This time he is working on Suvarnabhumi Airport (VTBD, also known as New Bangkok International Airport) in Thailand) as the architecture of the airport buildings is very beautiful. It will sure take some time but a first glance at the work in progress is already possible. Discuss the progress with us in [http://www.flightgear.org/forums/viewtopic.php?f=5&t=10075 the forum].
After the airport is finished, placed and available, AI traffic will follow (mainly Thai Airways).

AI traffic arrives at [[RPLL]] (Manila, Philippines): Mike created a comprehensive list of AI traffic of Cebu Pacific Airlines. Soon available via GIT, Cebu Pacific Airlines will provide domestic and international flights to the most important destinations. AI for the second big carrier of the Philippines (Philippine Airways) will follow later.

===Land cover updates===
Detailed land cover data for Vermont has been added to the map server. This state in the northeast United States will be a part of the next world scenery release.

Work continues on hand-created, detailed land cover data for northern Switzerland. Photos of landmark buildings or airport buildings in Switzerland would be welcome as we try to model this beautiful country.

===NASA Interactive Launch Complexes===
[[File:mercuryredstone3.png|thumb|Mercury Redstone 3 Rocket ready for launch.]]
Jack Mermod has released the first of many NASA Interactive Launch Complexes. This first release is based on Launch Complex 5 and the [http://en.wikipedia.org/wiki/Mercury-Redstone_3 Mercury-Redstone 3] launch. The model should be in the official database soon, for now you can download the scenery [http://alphashangar.co.nr/ here].

=== Jet d'Eau in Geneva ===
[[File:Geneva fountain.jpg|thumb|Jet d'Eau in Geneva.]]
The Jet d'Eau in Geneva is with 140m height a recognisable landmark. Ot-666 created the fountain and the pier it is located on in the Lake Geneva.
The model features night illumination for the fountain.

=== Airports ===
Looking for new airports to visit? Try a Dublin (EIDW) to Aalesund (ENSD) flight! These two airports, along with Sandane airport in Anda, Norway (ENVA), have recently had models added to the database to make them a more interesting place to fly.

===I.C.E.J.A.W===
[[File:ICEJAW_snowcover.jpg|thumb|Demonstration of ICEJAW depicting buildings with and without snow cover.]]
In an effort to improve the cities in FlightGear, Daniel Strawn (aka "Intel-Qube") has modeled a simple "one size fits all" city. Affectionately codenamed "ICEJAW", the city, still in development, features tangible helipads to land on, billboards and snow cover for heavy snow-fall.
Follow development in the [http://www.flightgear.org/forums/viewtopic.php?f=5&t=10016 forum topic].

=== TerraGear-CS ===
After attempts to provide a new World Scenery build in sync with the 2.0 software release failed miserably (due to software deficiencies), some effort has been expended into investigations, experiments (some of which ended up in filing bug-reports for related software) and large-scale tests for replacing the entire polygon processing in TerraGear by the use of [http://grass.osgeo.org/ GRASS GIS]. Just to give an idea about the term "large scale": The procedure to turn the Europe-wide CORINE CLC2000 vector data set into a topologically consistent coverage is taking several weeks on a 3 GHz Xeon machine.

The "*-decode" commands and old-style work directories are affected by this change as well as all polygon-mangling routines in "construct". The GRASS toolbox provides all the features we need for ''reliable'', topologically correct polygon handling (cleaning, clipping and the like). Those (early) steps of the new toolchain which have proven to be rather stable are available [http://mapserver.flightgear.org/git/?p=terragear-cs;a=tree;f=gisscripts here] (GRASS7 required for certain features).

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
A beautiful flight is from Prince George, ICAO: CYXS, to Calgary Springbank, ICAO: CYBW, under the route created by reed, which can be seen at [http://flightgear.org/forums/viewtopic.php?f=10&t=9772 the forums]

== Aircraft review ==
[[Image:Beechcraft_B1900D.JPG|thumb|Cockpit of the B1900D]]
The [[Beechcraft B1900D]] is a twin-engine turboprop aircraft, designed to be an all-weather regional airliner. It's been used by U.S. military and many other governments. In total, 695 very produced until 2002, and it's one of the default aircrafts in FlightGear and has been available since version 0.9.8.

With a well-implemented cockpit and fully functional GPS, it is one of the better developed aircraft within FlightGear.

== Wiki updates ==
===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==

=== FSweekend ===
As in previous year's FlightGear organized a booth at the annual [[FSweekend]] event in Lelystad, the Netherlands. [[FSweekend 2010|This year's edition of FSweekend]] came and went by before we realized it. Although there was initially skepticism as to whether we would be able to top last year's presentation, we did so, by quite a large margin. Main attractions this year were our Thomas-Krenn sponsored server, driving 10 monitors, and our near continuous use of [[Anaglyph (3D)|anaglyphic 3D]]. Although we had considered it to be a neat gadget, running flightgear in 3D analglyphic mode turned out to be a brilliant move. Not only did it draw a lot of people to our booth who wanted to check it out, handing out 3D glasses also worked as an extremely good vehicle to start a conversation with them.

Some assorted highlights include:
*Our Thomas-Krenn AG machine has been running for 8 hours straight, on both days, without a single glitch. At one point Torsten ran out of fuel, because he hadn't realized that FlightGear had been running for so long continuously. The machine ran in three 3D mode most of the time, and the way the screens were set up gave the impression that the were just holes in a wall though which you could see a (virtual) reality known as FlightGear. Very nicely done.
*Very positive comments on the Lockheed Constellation's artwork, particularly because that model is really shining when presented in 3D (probably the best cockpit we have for a 3D demo).
*Also very postive comments on the advance copy of the 737NG (800) that Innis Cunningham sent me. Also in particular due to the fact that the switches on the overhead panel look very real in 3D.
*Booth members Gijs and Jorg trying to outperform each other in terms of their helicopter flying skills (trying to land it on a chimney, once they found the helipad to easy).
*A number of people claiming that our booth was the best one at FSWeekend this year.
*Our aerotowing demo involving all of our major demonstration machines (my machine as the glider, Jorg's computer as the tow plane, and our sponsor's machine as a joint (3D) model viewer.
*Some people just not believing that a single machine could drive 10 monitors and actively checking where all the monitor cables actually went to.
*Another opportunity to meet FlightGear developers (one expected encounter: Geoff McLane, and one totally unexpected meeting with Thorsten Brehm). Thanks guys for showing up!

And last, but not least, everybody involved in getting this year's booth organized. It's been a lot of fun. Some pictures of the event can be found [http://www.dropbox.com/gallery/7455889/1/FSWeekend2010?h=0e9825 here]

=== FlightGear on youtube ===
[http://www.flightgear.org/forums/memberlist.php?mode=viewprofile&u=8726 Sealbhach] has made an [http://www.youtube.com/watch?v=zveiKtooXs0 excellent video] showcasing the great scenery at LOWI.

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===

== Useful links ==
== And finally ... ==
===A christmas present for you===
[[File:Gerbrandytoren_christmas.jpg|thumb|World's largest Christmas tree.]]
Do not forget to pay a visit to the [http://en.wikipedia.org/wiki/Gerbrandy_Tower Gerbrandytoren] in the Netherlands. With a height of 366.8m and 120 lights, it is the world's largest Christmas tree between December 11 and January 6. The tower is located 21 nm South East (HDG 120h) of [[Amsterdam Airport Schiphol]] ([http://mpmap02.flightgear.org/?ll=52.009982,5.053582&z=15 location on MPMap]).

=== Contributing ===
One of the regular thoughts expressed on the FlightGear forum is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

=== Reminder: Google's Summer of Code 2011 ===
We would like to remind all readers that the FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].

=== Amateur Built Collimated Display ===
''Contributed by Gene Buckle''

A couple of months ago, my friend Wayne and I embarked on the development of a fully functional collimated display system for our DIY flight simulators. A collimated display has been the holy grail of DIY cockpit builders because of the image it generates. Collimated displays are also known as "infinity" displays. It's described that way because the focus point to your eye becomes "infinity" when you're located at the right spot when viewing the mirror. The exact details of how they work are beyond this article, but you can learn more at [http://en.wikipedia.org/wiki/Full_flight_simulator Wikipedia]; see the section marked "Collimated Cross-Cockpit Displays".

Building the display successfully is a pretty big deal. Up until we completed the proof-of-concept project, collimated displays were the sole domain of multi-million dollar flight simulators from the likes of CAE, FlightSafety and others. It was declared too complex and too costly by just about everyone that ever approached the problem. Fortunately for us, all the "experts" were wrong. Not only did we build a fully functional collimating display, but we did it with off the shelf materials and very, very little expenditure. Total material costs for the mirror and projection screen is under $100.

The test mirror was built using an 8 foot diameter spherical shape. The framework itself describes a 60 degree wide by 40 degree high "slice" of that shape. The mirror itself is made of a 48" wide, 2mm thickness of Mylar sheet. In order to properly stretch the mirror, a set of "ears" had to be added to the framework.

This shows the frame prior to the mirror being glued into place:

[[File:mirror_frame.jpg|200px|Collimating Mirror Framework]]

The framework itself is made from 12mm Baltic Birch and is under 36" tall. The arcs defined by the "inside" ribs show where the spherical section mirror will form. In order to form the mirror, vacuum must be applied. This will stretch the mirror into a spherical section shape.

Attaching the Mylar:

[[File:attaching_mylar.jpg|200px|Attaching the Mylar to the framework]]

The Mylar is attached to the oval ring by a high-tack spray on adhesive made by 3M.

In order to test the visual properties of the system, we set it up on a platform I'd built some time ago to use with racing games:

[[File:mirror_test.jpg|200px|Test setup]]

The mirror just reflects what is on the screen above it - the test screen in this case is just a bit less than half the radius of the mirror and is 17" tall. In order to start testing as soon as possible, Wayne skinned the screen with kraft paper. It's very wrinkly, but it did an adequate job of being a screen. It's also what we had handy at the time. :)

Here's the complete test configuration:

[[file:test_config.jpg|200px|Test configuration]]

We used a Fein Turbo III dust collector as our vac source and it pulls the mirror down very well! It's pulling about 5 PSI in order to force the Mylar into the correct shape. Below is a picture of the mirror after being pulled down.

[[file:formed_mirror.jpg|200px|Formed mirror]]

Photographs and video cannot do this justice! It's just incredible to look at!

Here's a pic of Wayne performing the first test flight:

[[file:test_flight.jpg|200px|Test Flight]]

...and thus was born the world's very first amateur built fully collimated display for DIY flight simulators. I can't stress enough how thankful I am for Wayne and his skills. Were it not for his deep understanding of the math involved, this would have never been built.

Here are a few YouTube videos of the system in operation:
* [http://www.youtube.com/watch?v=y67TAo9Lv5g First draw down of the mirror]
* [http://www.youtube.com/watch?v=8yaDnXYlf8k My badly narrated test flight]
* [http://www.youtube.com/watch?v=zogFny49zrI A walk-around of the setup taken the next day]

The [http://www.diy-cockpits.org/coll/collimated_display.html project site] has more pictures and details on the current state of the project. Work has already begun on a 180 degree version!

=== Did you know ===
* You can act as an [[ATC|air traffic controller]] on the multiplayer servers by downloading the [[ATC-aircraft|ATC aircraft]]?
* That Luiz Jazbinsek, known as Cael in the FlightGear forums, is doing a [http://flightgear.org/forums/viewtopic.php?f=10&t=10126 world circumnavigation] with the [[Beechcraft B1900D]]?

[[Category:FlightGear Newsletter|2010 11]]

FlightGear Newsletter November 2010

2010-11-28T10:45:31Z

Durk: /* FSWeekend2010 */

FSweekend 2010

2010-10-10T06:42:16Z

Durk: /* Equipment Checklist */

This wiki page lists all information required for participants to the [[FSweekend]] and the attached multiplayer event(s). [[FlightGear]] will be represented by a team of seven regular FlightGear developers and users.

==Booth information==
This year's booth will probably exist of:
[[image:Anaglyph-glasses.jpg|right]]
* an UMTS usb stick for unlimited date use at high speed, so users from all over the world can visit us virtually.
* a bunch of 3D glasses, to demo the [[Anaglyph (3D)|anaglyph]] ability of FlightGear.
* a FlightGear based [[Howto:_Build_your_own_procedure_trainer|procedure trainer]].
* a Linux-based triple-screen PC, with a generic set of input devices for general purpose flight demonstrations.

=== Equipment Checklist ===
* One main power extension cord (DT: yellow)
* One main power extension cord (DT: green)

* One Linux-based PC (DT)
+ 3 Monitors
+ Saitek Joystick
+ Saitek Rudder Pedals
+ Headset
+ Sound System

* One Macbook Pro (DT)
+ simple joystick

* One Thomas-Krens-AG server (TD)
+ Eight monitors

==Flight information==
===Airports===
Activities will mainly take place at and around [[Amsterdam Airport Schiphol]] (EHAM), [[Lelystad Airport]] (EHLE), [[Volkel Air Base]] (EHVK) and the VU University Medical Center Helipad [[EH0001]].

===Charts===
All charts that you may have to use on your flights are available at http://ais-netherlands.nl (AIS Publications > Integrated Package). Please note that these are the most up to date charts available, so certain situations might not have been changed in FlightGear (EHAM, EHLE and EHVK taxiways should be correct though).

Parking positions have been created for most of the Dutch airports including EHAM, EHRD, EHVK and EHLE (A1-A6, B1 and B2).

All named airports are for civil usage, except for [[Volkel Air Base]] (EHVK). This base will be occupied by the (AI) F-16 squadrons and likely one setup in Lelystad. Feel free to join with your F-16 or other Dutch mil aircraft.

===Weather information===
Reallife weather information can be found at the KNMI (Dutch Meteological institute) website.
* [http://knmi.nl/actueel/metar.html METAR] current weather at airports
* [http://knmi.nl/waarschuwingen_en_verwachtingen/luchtvaart/nederlandse_vliegveldverwachtingen.html TAF] expected weather at airports

==Scenery==
We will be using newly generated scenery in Lelystad.

==Events==
We are currently discussing the possibility of a special [[TransGear]](-like) event throughout the weekend.

FSweekend 2010

2010-10-10T06:41:17Z

Durk: /* Equipment Checklist */

FSweekend 2010

2010-09-24T06:48:45Z

Durk: The introductory note sounded a bit awkward we can just keep it generic.

This wiki page lists all information required for participants to the [[FSweekend]] and the attached multiplayer event(s). [[FlightGear]] will be represented by a team of seven regular FlightGear developers and users.

==Booth information==
This year's booth will probably exist of:
[[image:Anaglyph-glasses.jpg|right]]
* an UMTS usb stick for unlimited date use at high speed, so users from all over the world can visit us virtually.
* a bunch of 3D glasses, to demo the [[Anaglyph (3D)|anaglyph]] ability of FlightGear.
* a FlightGear based [[Howto:_Build_your_own_procedure_trainer|procedure trainer]].
* a Linux-based triple-screen PC, with a generic set of input devices for general purpose flight demonstrations.

=== Equipment Checklist ===
* One main power extension cord (yellow)
* One main power extension cord (green)

==Flight information==
===Airports===
Activities will mainly take place at and around [[Amsterdam Airport Schiphol]] (EHAM), [[Lelystad Airport]] (EHLE), [[Volkel Air Base]] (EHVK) and the VU University Medical Center Helipad [[EH0001]].

===Charts===
All charts that you may have to use on your flights are available at http://ais-netherlands.nl (AIS Publications > Integrated Package). Please note that these are the most up to date charts available, so certain situations might not have been changed in FlightGear (EHAM, EHLE and EHVK taxiways should be correct though).

Parking positions have been created for most of the Dutch airports including EHAM, EHRD, EHVK and EHLE (A1-A6, B1 and B2).

All named airports are for civil usage, except for [[Volkel Air Base]] (EHVK). This base will be occupied by the (AI) F-16 squadrons and likely one setup in Lelystad. Feel free to join with your F-16 or other Dutch mil aircraft.

===Weather information===
Reallife weather information can be found at the KNMI (Dutch Meteological institute) website.
* [http://knmi.nl/actueel/metar.html METAR] current weather at airports
* [http://knmi.nl/waarschuwingen_en_verwachtingen/luchtvaart/nederlandse_vliegveldverwachtingen.html TAF] expected weather at airports

==Scenery==
We will be using newly generated scenery in Lelystad.

==Events==
We are currently discussing the possibility of a special [[TransGear]](-like) event throughout the weekend.

FSweekend 2010

2010-09-24T06:34:15Z

Durk: /* Airports */

This wiki page lists all information required for participants to the [[FSweekend]] and the attached multiplayer event(s). [[FlightGear]] will be represented by a team of five and two half developers.

==Booth information==
This year's booth will probably exist of:
[[image:Anaglyph-glasses.jpg|right]]
* an UMTS usb stick for unlimited date use at high speed, so users from all over the world can visit us virtually.
* a bunch of 3D glasses, to demo the [[Anaglyph (3D)|anaglyph]] ability of FlightGear.
* a FlightGear based [[Howto:_Build_your_own_procedure_trainer|procedure trainer]].
* a Linux-based triple-screen PC, with a generic set of input devices for general purpose flight demonstrations.

=== Equipment Checklist ===
* One main power extension cord (yellow)
* One main power extension cord (green)

==Flight information==
===Airports===
Activities will mainly take place at and around [[Amsterdam Airport Schiphol]] (EHAM), [[Lelystad Airport]] (EHLE), [[Volkel Air Base]] (EHVK) and the VU University Medical Center Helipad [[EH0001]].

===Charts===
All charts that you may have to use on your flights are available at http://ais-netherlands.nl (AIS Publications > Integrated Package). Please note that these are the most up to date charts available, so certain situations might not have been changed in FlightGear (EHAM, EHLE and EHVK taxiways should be correct though).

Parking positions have been created for most of the Dutch airports including EHAM, EHRD, EHVK and EHLE (A1-A6, B1 and B2).

All named airports are for civil usage, except for [[Volkel Air Base]] (EHVK). This base will be occupied by the (AI) F-16 squadrons and likely one setup in Lelystad. Feel free to join with your F-16 or other Dutch mil aircraft.

===Weather information===
Reallife weather information can be found at the KNMI (Dutch Meteological institute) website.
* [http://knmi.nl/actueel/metar.html METAR] current weather at airports
* [http://knmi.nl/waarschuwingen_en_verwachtingen/luchtvaart/nederlandse_vliegveldverwachtingen.html TAF] expected weather at airports

==Scenery==
We will be using newly generated scenery in Lelystad.

==Events==
We are currently discussing the possibility of a special [[TransGear]](-like) event throughout the weekend.

FSweekend 2010

2010-09-24T06:33:15Z

Durk: Equipment checklist.

This wiki page lists all information required for participants to the [[FSweekend]] and the attached multiplayer event(s). [[FlightGear]] will be represented by a team of five and two half developers.

==Booth information==
This year's booth will probably exist of:
[[image:Anaglyph-glasses.jpg|right]]
* an UMTS usb stick for unlimited date use at high speed, so users from all over the world can visit us virtually.
* a bunch of 3D glasses, to demo the [[Anaglyph (3D)|anaglyph]] ability of FlightGear.
* a FlightGear based [[Howto:_Build_your_own_procedure_trainer|procedure trainer]].
* a Linux-based triple-screen PC, with a generic set of input devices for general purpose flight demonstrations.

=== Equipment Checklist ===
* One main power extension cord (yellow)
* One main power extension cord (green)

==Flight information==
===Airports===
Activities will mainly take place at and around [[Amsterdam Airport Schiphol]] (EHAM), [[Lelystad Airport]] (EHLE), [[Volkel Air Base]] (EHVK) and [[EH0001]].

===Charts===
All charts that you may have to use on your flights are available at http://ais-netherlands.nl (AIS Publications > Integrated Package). Please note that these are the most up to date charts available, so certain situations might not have been changed in FlightGear (EHAM, EHLE and EHVK taxiways should be correct though).

Parking positions have been created for most of the Dutch airports including EHAM, EHRD, EHVK and EHLE (A1-A6, B1 and B2).

All named airports are for civil usage, except for [[Volkel Air Base]] (EHVK). This base will be occupied by the (AI) F-16 squadrons and likely one setup in Lelystad. Feel free to join with your F-16 or other Dutch mil aircraft.

===Weather information===
Reallife weather information can be found at the KNMI (Dutch Meteological institute) website.
* [http://knmi.nl/actueel/metar.html METAR] current weather at airports
* [http://knmi.nl/waarschuwingen_en_verwachtingen/luchtvaart/nederlandse_vliegveldverwachtingen.html TAF] expected weather at airports

==Scenery==
We will be using newly generated scenery in Lelystad.

==Events==
We are currently discussing the possibility of a special [[TransGear]](-like) event throughout the weekend.

FSweekend

2010-09-23T07:12:56Z

Durk: Undo revision 24195 by Fa11 (Talk) (We don't need spam on our pages!

The '''FS Weekend''' event is the largest flight simulator event in the world. Each year it takes place at the first or second weekend of November. The event is held in the [[Aviodrome]] musuem, located at [[Lelystad Airport]], The Netherlands. Since 2006 [[FlightGear]] has been represented each year, by a small team of enthusiastics. If you like to join the team, write an email to the [http://flightgear.org/mail.html mailinglist].

Keep an eye on the [[current events]] to see what dates this years event will take place.

==Related content==
*[[Current events]]
*[[Presentation Recipe]]

==External links==
*[http://www.fsweekend.com/ FSWeekend.com]
*[http://www.aviodrome.nl/ Aviodrome]

[[Category:Community]]

FlightGear Newsletter August 2010

2010-08-29T19:48:54Z

Durk:

AI Traffic

2010-06-23T05:49:14Z

Durk: /* Tools */

'''Interactive Traffic''', or '''AI-Traffic''' (Artificial Intelligence) has come to life with [[FlightGear]] version 0.9.5. Since then FlightGear has an interactive traffic system that is based on the AI-Models subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
# Create Traffic files,
# Build ground networks for the Airports containing traffic.
# Create the appropriate Departure / Arrival procedures for each airport involved.

Notice that the "Download all AI aircraft" is no longer necessary, because most, if not all, AI aircraft are now part of the base package.

== Building Traffic Files ==
Traffic patterns are stored in data files in extended markup language (.xml) format. The actual location of these files are version dependent. For FlightGear 0.9.x, traffic files are stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<tt>[[$FG_ROOT]]/Traffic/</tt>

In FlightGear 1.0, the traffic files can be found in a subdirectory of:

<tt>[[$FG_ROOT]]/AI/Aircraft/</tt>

For example, traffic belonging to a united airlines 737 would be located in: <tt>[[$FG_ROOT]]/AI/Aircraft/737/737-UnitedAirlines-traffic.xml</tt>

FlightGear 1.9.0 has seen yet another move. In this version, the traffic files can be located in:

<tt>[[$FG_ROOT]]/AI/Traffic/</tt>

For FlightGear 1.9.0 and later, a new traffic file format was introduced (henceforth referred to as "traffic manager II" format (TM-II), in which aircraft and flights are no longer directly coupled, leading to more flexibility.

Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==
As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by [[McDonnell Douglas MD11]] aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database was originally constructed on the basis of a fixed routing table that was assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and these FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remained the same, unless a major update to the database were to take place. Real aircraft require maintenance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintenance in this respect.

There were still some significant drawbacks to this approach, nevertheless. Consider the MD11 a little further. In real life, KLM operates this aircraft on many routes that are serviced at relatively irregular intervals. For example, many flights to the Carribean are served only two or three times a week, making it extremely complicated to build completely accurate traffic files for these routes.

To circumvent these problems, a new database format was introduced in FlightGear 1.9.0. In this new format, flights are no longer directly and rigidly assigned to specific aircraft. Instead, a more generic description of a fleet is given, along with a series of flights that need to be carried out. The routing is then taken care of by FlightGear itself.

== An example of a traffic file ==

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:

<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>
</aircraft>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCB</registration>
<heavy>true</heavy>
</aircraft>

<flight>
<callsign>KLM0765</callsign>
<required-aircraft>MD11KLM</required-aircraft>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/12:35:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>TNCM</port>
<time>0/21:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0769</callsign>
<required-aircraft>MD11KLM</required-aircraft>
<fltrules>IFR</fltrules>
<departure>
<port>TNCM</port>
<time>3/01:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/10:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</trafficlist>

== Disecting 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.

== General Layout ==
The general layout of each file should look like the above example.
<?xml version="1.0"?>
<trafficlist>

</trafficlist>

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 ==
<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>
</aircraft>
<aircraft>
...
</aircraft>
</trafficlist>

The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter [[ICAO]] airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
* '''<home-port>''' Each FlightGear aircraft is assigned to a home airport. Internally, this is used to ensure that routes are setup that will eventually lead back to the home airport. This is done to maintain some sensibility into the routing algorithm. '''[New for traffic manager II]'''
* '''<required-aircraft>''' This value is a key that binds aircraft and flights together. In case of this example, the key MD11KLM. Indicates that this aircraft will only carry out flights containing the same key. Usually, a combination of aircraft type, and airline will suffice for this key. In some cases, in particular, when specific aircraft / airlines are distributed across multiple hubs (i.e. home ports), it may be necessary to specify a key containing the home airport as well. For example, Delta Airlines operates 767's out of Atlanta, as well as out of New York. To separate between these two cases, it would be advisable to use two keys; one for KATL (e.g. 767DALKATL), and one for KJFK (e.g., 767DALKJFK). '''[NEW for traffic manager II]'''
* '''<actype>''' A description of the aircraft type reserved for future use in [[ATC]].
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' In the near future, this keyword will be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures. This line is also used for gate assignments and should be one of the following:
** '''ga''' (general aviation),
** '''cargo''' (cargo)
** '''gate''' (commercial passenger traffic)
** '''mil-fighter''' (military fighter)
** '''mil-cargo''' (military transport)
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:
** '''light_aircraft''' (prop driven single or twin),
** '''ww2_fighter''' (world war two fighter),
** '''jet_transport''' (modern commercial jet),
** '''jet_fighter''' (modern fighter aircraft)
** '''tanker''' (tanker aircraft), or.
** '''ufo''' (allows extreme accel/decel capabilities).
*'''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.
*'''<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 ==
The original traffic file format contained a series of flights enclosed within the <aircraft> section, e.g.,

<aircraft>
...
<flight>
</flight>
</aircraft>

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:

<aircraft>
...
<required-aircraft>MD11KLM</required-aircraft>
...
</aircraft>

<flight>
...
<required-aircraft> MD11KLM </required-aircraft>
...
</flight>

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.

<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>

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.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<required-aircraft>''' The key that links this flight to a particular aircraft. The see explanation in the ''aircraft'' section.
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<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.
* '''<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.
* '''<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).

== Putting it all together: Including a traffic file ==
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 data/AI/Aircraft directory. For example, traffic for a Boeing 737 could be located in in an xml file in data/AI/Aircraft/737, and traffic for a 747 should be located in data/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 data/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 data/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in data/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 data/AI/Traffic/mil/USAF.xml

== Tools ==
One major motivation for introducing the traffic manager II file format is to make it easier for FlightGear users to contribute to the traffic database. To further motivate this, some tools are currently in development that aim to make user interaction even easier. Although most of these tools are not ready for public use yet, it is probably worth mentioning some of these developments. First of all, the custrom scenery project is working on extending their scene model database to store traffic. A web based front end will allow users to enter their favorite flight, and thus collect an extensive amount of traffic data. Users will be able to download the collected results and place the downloaded files in their traffic directory.

Secondly, the author of the traffic manager code has written some scripts, mainly for private use, that will allow one to input the flight data into a simple text format and then convert the resulting text file to xml. The most important of these scripts is now available for download [http://www.xs4all.nl/~dtalsma/trafficdata.zip trafficdata.zip]. This zip archive contains a collection of traffic configuration files, along with a perl script to convert these scripts to xml.

Creating AI traffic files this way is easy. First, you need to define the aircraft for each fleet (data taken from the June 2010 Malayasian project):

###HOMEP RegNo TypeCode Type AirLine Livery Offset Radius FltType Perf.Class Heavy Model
############################################################################################################################################

AC WMKK TF-ARN 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml
AC WMKK TF-ARJ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml
AC WMKK TF-ATZ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml

Then, you need to define all the flights according to the following layout:

########Flt.No Flt.Rules Days Departure Arrival FltLev. A/C type
################### ######### ####### ############### ############### #################

# London Heathrow (EGLL; UTC+1 ) to Kuala Lumpur (WMKK +8:00) vv.
FLIGHT Malaysian0001 IFR 0123456 21:00 EGLL 09:25 WMKK 360 747MAS
FLIGHT Malaysian0002 IFR 0123456 15:40 WMKK 04:50 EGLL 360 747MAS
FLIGHT Malaysian0003 IFR 0123456 11:00 EGLL 23:25 WMKK 360 747MAS
FLIGHT Malaysian0004 IFR 0123456 09:05 WMKK 08:15 EGLL 360 747MAS

# Frankfurt (EDDF; UTC+2 ) to Kuala Lumpur (WMKK +8:00) vv.
FLIGHT Malaysian0005 IFR 0.2.456 10:30 EDDF 22:25 WMKK 360 777MAS
FLIGHT Malaysian0006 IFR .1.3456 15:50 WMKK 04:25 EDDF 360 777MAS

Note that the flight information laid out above resembles that of a standard airline schedule table as close as possible, with a few known exceptions:
- Weekdays are in the range 0 to 6, but do follow standard airline conventions (0 = monday; 6 is sunday)
- All times in the table are in UTC; to convert from local time, as given in the airline table, subtract the airport in question's UTC offset).
- The last entry in each line (A/C type) should correspond to the ''combination'' of the '''TypeCode''' and '''Airline''' entries in the aircraft sections.

The resulting table can now easily be converted to xml output by running the conf2xml.pl script.

For unix based operating systems, simply run conf2xml.pl from the directory where you unpacked the trafficdata.zip archive:

./conf2xml.pl

will give the output:

Writing to ADR.xml
Writing to AFL.xml
...
Writing to VLG.xml
Writing to VLM.xml

When the script encounters an error, it will stop prematurely.

= 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 data/AI/Airports directory/. Currently, this information is provided on a one file per airport basis, that can be found in a file called data/AI/Airports/[ICAO]/parking.xml, where ICAO stands for the 4 letter ICAO code for the airport in question.

For example, see the ground network for EHAM, which is found in <tt>data/Airports/AI/EHAM/parking.xml</tt>. See the end of this page for a small
excerpt from this file. It should be noted that current development work is planned that aims to move these files from the base package to the scenery repository, so that ground network information and the physical layout of the airport can be updated in parallel. Once this is done, the new location / name for the file will be [fg-scenery]/Airports/[ICAO1]/[ICAO2]/[ICA03]/[ICAO].groundnet.xml. Here [ICAO] stands for the 4 letter ICAO code of the airport in question, and [ICAO1], [ICAO2], and [ICAO3] for the first to third letter of this code.

'''NOTE:''' Taxidraw versions with a build date of Feb. 5, or later, 2009 support the new naming convention. To make use of this new functionality, make sure to set the FlightGear scenery directory in TaxiDraw (tab 4 in the preferences menu). The directory specified here should be the top level directory, i.e. the one that contains the "Airports", "Objects", and "Terrain" subdirectory. Note that support for this naming convention was introduced somewhat earlier, but versions of TaxiDraw before Feb 5 contain a potentially fatal bug that might ruin your work.

In addition, FlightGear cvs of approximately the same date also has support for reading the ground networks from the scenery directory. This feature is not enabled by default. To enable, make sure the property /sim/traffic-manager/use-custom-scenery-data is set to true. This can be done by editing preferences.xml or specifying this property on the command line.

== A technical perspective ==
A ground network file consists of 4 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 second section of the file contains the parameters of the airport's parking
locations. The third section contains a list of all the nodes in the ground
network, and the fourth and final section contains a list of segments, or "arcs" as David
Luff called them initially, which basically describe which node is connected
to which other node.

Each parking and AI node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
* '''index (unique, consecutively numbered id)
* '''lat''' (position in latitude)
* '''lon''' (position in longitude)
* '''name''' (name as found on airport charts: e.g. D23, or C1).

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay. See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison. Valid values for this parameter are:
** '''ga''' (general aviation),
** '''cargo''' (cargo)
** '''gate''' (commercial passenger traffic)
** '''mil-fighter''' (military fighter)
** '''mil-cargo''' (military transport)

* '''number:''' Currently used in combination with the <name> parameter to determine the full name of the gate.
* '''heading:''' The heading at which the aircraft are parked in this bay.
*'''radius:''' A value used to determine whether the aircaft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above. FlightGear uses a standard list of [[aircraft radii]] for gate assignment.
*'''airlineCodes:''' a comma-separated list of ICAO airline codes used to indicate which airlines should park here. Leave this field blank if you want any aircraft to park here.
*'''pushBackRoute:''' A number that refers to another node in the network. In a correctly configured network, the AI aircraft will taxi to this node in reverse, thus simulating being pushed back. See the documentation for the PushBack hold point type below.

Taxiway nodes contain two additional parameters:
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, or 0 otherwise
* '''holdPointType''' Describes wether the current point should be considered a holding point. This parameter can have the following values:
** '''none''' No holding point
** '''normal''' A regular holding point. This point should be placed just before the runway entrance / exit points, so that traffic will not enter the runway before receiving clearance to enter the runway. Note that support for this type of holding point is not implemented yet, but should appear sometime during 2009.
** '''CAT II/III''' A special holding point for IFR conditions. Currently not supported yet.
** '''PushBack''' A push back hold point type. Each parking can be connected to maximally one push back point, connected through a series of push back routes. Note that a push back point is optional, but that there can maximally only be one connected to each gate.

Finally, the taxiway segments contain three parameters.
* '''begin''' The id of the parking or AINode where this segment starts
* '''end''' The id of the parking or AINode where this segment ends
* '''IsPushBackRoute''' a logical value. Should be one if the current segment is part of a route connecting a gate to a push back hold point, or 0 otherwise.
* '''name''' Name of the taxiway.

== 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. The current document describes the functionality of the NEW_GUI_CODE version of TaxiDraw.

== TaxiDraw ==
Although currently no officially released version of [[TaxiDraw]] (http://TaxiDraw.sourceforge.net/) 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.

=== Obtaining TaxiDraw ===
Until an official release has been done, linux users can try to check out a version of TaxiDraw from CVS by following
the instructions on http://TaxiDraw.sourceforge.net/#download

[[Ubuntu]] or [[Debian]] users may look at the [[Ubuntu_fg_tools]] page to have TaxiDraw installed in a easy way.

Windows users can also do this either by using the free winCVS program or
using the free cygwin environment. Another possibility is to look on [ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32]- here you can find the last build of Taxidraw.

=== Getting good reference material ===
The first step in preparation of creating a ground network consists of getting some reference material. Ideally, You'd like to find a good satellite or aerial image. If you can't find that, using a schematic diagram might also work. For airports in the United States, you can simply load USGS imagery by clicking the "USGS" button, however, for the rest of the world, this service is not available. Perhaps the best way to get a decent reference image is to use the standalone GoogleEarth program. GoogleEarth lets you zoom in to any location of the world. Center your view on the airport, and zoom to encompass the entire area. Then, save a jpg snapshot of the screen. This image can be imported in TaxiDraw. After importing, right click, goto the "lock layers" submenu and unselect the background image. Next, select the background image, right click and select the "calibrate background image". Typically, the "Uniform scale / rotation option" works best.

Although a google earth snapshot will usually give a good reference for the actual location of airport parkings, it still doesn't give much information about some of the logical aspects of the parking infrastructure. In particular, information about gate names / airline operations is not provided. Typically, this information is hard to find, but can be compiled from various sources, including wikipedia, random airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!

=== Creating the network ===
The current documentation describes the procedure for the TaxiDraw NEW_GUI_CODE branch, which is rather drastically different from the procedure used by the original TaxiDraw, previously documented here. This section describes some of the general procedures involved in building a ground network.

Note: export your work regularly: Although ground network editing capabilities have improved dramatically, this part of TaxiDraw is still somewhat separate from the rest of the code, and ground networks are not automatically saved together with the project. When exporting, TaxiDraw asks wether the ground network should be saved directly into FlightGear's data directory. Usually, this is okay, so just clicking "yes" takes care of saving the file in the correct location. Likewise, while importing an existing network, TaxiDraw first looks in FlightGear's data directory, to check for an existing default file to be inported.

==== Set up a rough outline ====
To make best use of the background image, right click, choose the "view" menu, and unselect "taxiways", this way, all network drawing can be based on the real airport location. First, select the "Insert startup location" edit mode. This way, each left mouse click will place a startup location at the position of the mouse cursor. Once the major startup locations have been placed, switch back to "selection" mode, by clicking the little arrow button.

Next, start editing all the relevant startup location parameters. Parking heading can be changed by dragging the little red circular heading indicator. The parking's radius can be changed by clicking anywhere on the big red circle allows one to change the parking's radius by dragging the mouse. Although this usually works for setting up a rough draft, these parameters can directly be changed in the properties dialog. If the properties dialog is not visible, press [cntrl-p] to bring it up. It is possible to select multiple startup locations by pressing the shift key while selecting, and the parameters for each selected startup location can be changed at the same time. This is a powerful feature for editing the parameters of a whole series of parking locations, and also for equating and orienting gate radius and heading.

With the startup locations in place, select one of them. The next step will be to connect this parking area to each runway end. After selecting the parking, click on the "insert bidirectionally connected network nodes" (the two green dots icon), and start drawing. Place nodes at strategic locations, such as intersections, corners, and arcs. finally, place one node at the centerline of one of the runways. Once this is finished, one gate is connected to one end of one runway. The next job is to extend the network by connecting more gates and more runways.

Create a second branch from the existing route, which goes to another runway. To do so, press [cntrl-a] to deselect all objects. Then, select the point where you want to branch off from. Select this point using a left mouse click, while holding down the shift key. Since TaxiDraw is still in node connect mode, simply left-clicking would have resulted in placing a new node. With this node selected, continue drawing. Repeat this procedure until all runways are connected.

Then, start adding the additional gates to the network. Press [cntrl-a] to deselect all objects. Then select a gate by pressing [shift-left mouse, and start drawing unil the the gate in question is one segment away from being connected. Then, [shift left-click] the network node that this route segment should be connected to, and make sure that the correct node is selected. Then, right click, and select "connect nodes bidirectionally" from the AI nodes menu.

Repeat this procedure until all parking locations are connected to each runway.

==== Refining the network: Mark points on the runway as such ====
With the basic infrastructure in place, the next step is to fine-tune the network. The first step in this process is to mark the network nodes that are located on a runway. This is important for a number of reasons: Taxidraw needs these OnRunway points for it's network verification tool. Secondly, the use of the type of runway marking will be used in future versions of FlightGear for runway entrance / exit calculations, in addition to a host of other possible uses in routing (such as blocking a certain node then a crossing runway is in use, etc, etc).

It should be noted that there is no reason why TaxiDraw should not be able to mark the runway points as such automatically. After all, the geometry information of both runways and AI nodes is available. Although this automatic feature is planned, the TaxiDraw developers have as of yet not found the opportunity to implement this feature. Until that time, on runway marking has to be done by hand.

==== Refining the network: Set Holding points ====
Holding points are nodes in the network that do something special. They can be used by FlightGear to make traffic wait at certain specific locations. As a matter of fact, the 'normal' and 'Cat II/III' hold points are not yet used by FlightGear, but are part of the development plan. Currently, hold points are implicitly assigned by the FlightGear AI code. For instance, traffic waiting for takeoff clearance is holding at the first point before the runway. Likewise, traffic can receive a hold position instruction just before an intersection in the taxiway system, when traffic is approaching at the other leg. While these implicit hold points work reasonably, there are some limitations. Consider for example runway 07 at CYYC (Calgary Intl, Canada). In the FlightGear rendition of this airport, there are no taxiways leading to this runway, so departing aircraft should back track the runway from an entrance point at the middle of the runway. Currently that point will also become the runway entrance holding point. This is clearly undesirable, because it means that traffic is actually waiting ''on the runway'' in order to get clearance to enter it. For this reason, airport ground network designers should have a means to have explicit control over holding points. The normal hold point is meant for just that.

The Cat II/III hold point type is meant as an extension to this scheme for special IFR conditions. Support for these types in FlightGear is planned for a later stage of development though.

==== Refining the network: Pushback routes ====
With the above-mentioned refinements, the ground network should be fully working, with one notable exception. Aircraft will be driving forward when leaving the gate, making a sharp turn (while probably destroying themselves and the terminal building in the process). To prevent this, a ''push back'' route should be created. A push back route consists of at least one or more taxiway segments that have the "PushBack Route" property set to true. The last of these segments should be terminated by a PushBack HoldPoint network node.

Notice that a push back route is optional, but that parkings may never have more than one push back route. The formal criterium for a valid push back route is that each gate should have a maximum of one pushback node associated with it, which can be reached using one route only. From an editing point of view, it is sufficient to just mark a number of taxiway segments as push back, and mark the ending node as such as well.

It is important to note that the "Verify Ground network" process ''should be run'' in order to get a correctly working push back system, because this function runs some internal consistency checks. Push back routes can be very simple, from just one route segment, to fairly complex, as illustrated below. Shown here are 3 examples from the EHAM ground network. 1) Shows a fairly complex example, where all aircraft from one side of the E terminal are being linked to one shared push back point. In the example, the push back route of an aircraft departing from gate E20 is illustrated. 2) Shows a simple example, where one aircraft is being pushed back, and makes a left turn. In essence, 3) shows a similar example, but now in a slightly more crowded space, where pushback nodes are overlapping. The current push back system allows for fairly complicated behavior. To get a full understanding of it's workings, it is advisable to play with some of the existing ground networks. EHAM and KFSO currently provide the most complex setups.

Finally, please notice that you need a version of TaxiDraw with a build date of February 5, 2009, or later, for this to work correctly. Earlier version did not export the pushBackRoute attribute correctly. Support for this functionality was introduced late January 2009, but versions earlier than February 4 contain a potentially fatal bug, that may seriously damage your work.

[[Image:TaxiDraw2.png|500px]]

==== Verifying the network ====
Finally, with a network complete, it is important to verify it! The verification function not only detects obvious problems with the network, it also updates some internal states that FlightGear relies. on. Presumably, an automatic verification process will be added to the export function, but until that is the case, make sure to do this manually. The verify network function can be found in the "Tools" menu.

Notice that TaxiDraw does not automatically fix problems. It is left to the user to fix the problems manually. TaxiDraw does select the offending node(s) / segments(s) for easier identification. Also note that TaxiDraw stops verifying at the first problem encountered, so it is worthwhile to continue checking until no further errors are found. Currently, the following checks are performed.

* '''On runway points''' Added on January 24, 2009, this check is most likely not yet available in any distributed version. This is currently just a very lame check to see if any point in the network has been marked as such. This check is not exhaustive, but simply meant as a reminder to the editor that the OnRunway points should still be marked. Ultimately, this check should be replaced by the aformentioned automatic geometry function.
* '''Duplicate Taxiway Segments''' It's easy to connect two network nodes twice. While this doesn't really hurt, it does add dead weight, so checking for duplicates is not a bad thing.
* '''Routing''' One of the most persisting problems, headache causing problems is that of a disconnected parking in the network. FlightGear will happily place an aircraft there, but bail out when that aircraft cannot reach the runway. The routing check attempts to prevent this. Notice that it is of utmost importance that the OnRunway points are set correctly, because TaxiDraw relies on these points for it's route finding algorithm. Because the route finding algorithm is rather computationally intensive, some progress information is currently written to the console (a proper progress bar would be nice). When a disconnected parking is found, TaxiDraw selects both the parking and the runway node. It is still left to the user to trace a route between these two points and find where the two pieces are disconnected.
* '''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 ==
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,
you'd also need to give each parking a name, and a heading, and probably airlines codes. Changing name, and heading can be done in TaxiDraw, by right
clicking on the startup location. This will bring up a dialog, in which you can change latitude, longitude, heading, and name. Once you're done editing, click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack parameters is not yet possible in TaxiDraw. So changing these requires saving the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (TaxiDraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

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 data directory ==
Finally, once you have finished creating a groundnet work you can test it in FlightGear. Create a directory in FlightGear's <tt>data/Airports/AI</tt> directory, with the name of the ICAO code of your airport. For example <tt>[[$FG_ROOT]]/Airports/AI/EHAM</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 "parking.xml".

== 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.

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 =
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.

= Appendix: Special Notes =
== Realism ==
With [[FGFS 1.0.0]] Interactive Traffic also responds to other Non-AI aicraft.
The [[Airbus A320|A320]] ( and maybe some others) has working flaps and gears.

==Perfomance==
With FGFS 1.0.0, the AI Interactive Traffic needs a lot of CPU-power. With the current CVS-versions, however, we now have much better performance 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.

==External links==
* [http://www.xs4all.nl/~dtalsma/FlightGear.html The FlightGear AI aircraft download page]
* [http://www.ilovelinux.de/svn/fgfs-ffm/user/data/AI/ Created a dense AI traffic for EDDF, LSZH and a lot of other airports depending on real timetables. More to come!]

AI Traffic

2010-06-23T05:40:00Z

Durk: Updated documentation on creating traffic.

AI Systems

2010-06-14T19:22:06Z

Durk: Remove out of date note. The information here is actually more accurate / up to date than that of the HOWTO.

== AI Systems in FlightGear ==
[[FlightGear]] has a number of more or less independently operating systems for simulating semi- intelligent interaction with the environment. Because there oftentimes exists some confusion regarding to which system does what, one should take notice of the differences between them: The major distinction is that between an older ATC/AI system, and a newer AIModels system. The AIModels system can, in turn, be controlled in at least three different ways; directly, using a script, through the multiplayer system, and through a subsystem known as the traffic manager.

To enable/disable the ATC/AI system: use --prop:/sim/ai-traffic/enabled=[1|0]
To enable/disable the AIModels system: use --prop:/sim/ai/enabled=[1|0]

== ATC/AI ==
The [[ATC|Air Traffic Control]] system simulates interaction between the user and a number of AI controlled cessna and piper aircraft. This system can be controlled using the GUI from within FlightGear. The ATC/AI system is no longer maintained and marked for deprecation. Recent reports have indicated that the ATC/AI system may be causing numerical computation problems in some cases, resulting in a flurry of NaN warning messages on the FlightGear console. If you experience this, you might consider shutting down the ATC/AI system

For airports with a tower frequency, if that frequency is tuned in to your radio, you may contact ATC.

To obtain the tower frequencies for an airport within range of ATC, go to the ATC/AI menu, choose Frequencies to display the dialog. If there are any airports within 40nm range, a button with the airport designation will appear. Click see the frequencies. Tune the tower frequency in on the COM1 radio and then hit the single quote key to open the ATC window.

Points:
* Untowered airports are not supported in any way by ATC.
* You must be within 40 nautical miles of an ATC facility (towered airport with tower frequencies) to contact ATC.

== AI Models ==
Starting with FlightGear version 0.9.4 you can place AI objects in the "FlightGear world". In version 0.9.4 the AI objects can be defined in the preferences.xml file, or in an airplane's *-set.xml file. In later versions they are defined in a "scenario file" only. The types of AI objects you can have are airplanes, ships, thunderstorms, thermals/sinks, static and ballistic objects. AI objects have some things in common: The have a location in the "FlightGear world", they can have an associated exterior 3D model, and they can move according to an internal [[FDM]] (flight dynamics model). As of now, these objects are created at simulator start-up by adding some XML code to a scenario file. The scenario file must be in the data/AI directory. You select which scenario files you want to use by naming it in the preferences.xml file. The preferences.xml file has an entry that looks like this (FlightGear versions newer than 0.9.4, including CVS):

<ai>
<enabled type="bool">true</enabled>
<scenario>aircraft_demo</scenario>
</ai>

The above bit of XML enables the AI system and selects a scenario file called aircraft_demo.xml.

''Notes:
*XML tags are case-sensitive.
*Introducing certain characters into the XML file, even as part of a comment, will cause the file to choke. These include &, <, and --.''

The scenario file contains one entry for each AI object. The entry specifies what kind of object to create, what its initial conditions will be, and optionally (for aircraft and ships) a flight plan. The entry for a sailboat could look like this:

<entry>
<type>ship</type>
<model>models/geometry/sailboat.xml</model>
<speed-ktas type="double">12.0</speed-ktas>
<altitude-ft type="double">0.0</altitude-ft>
<longitude type="double">-122.33333</longitude>
<latitude type="double">37.61667</latitude>
<heading type="double">20.0</heading>
</entry>

Most of the parameters are self-explanitory. The "type" of object can be one of "aircraft", "ship", "carrier", "thunderstorm", "thermal", "ballistic" or "static". The rest of the items give the AI object a model, a starting location, and a starting speed and direction. You use the <MODEL> item to give the object any valid exterior model. You can even make the ship look like an airplane if you want! Note that the speed of the AI object is true airspeed, and since AI aircraft and ships don't feel wind or current then this also the ground speed. The "ship" type can also have a <RUDDER> value specified, which will cause the ship to move in a circle (HINT: use small values, five degrees or less, and right rudder is positive). Here is an example of how to create an aircraft AI object:


<entry>
<type>aircraft</type>
<class>light</class>
<model>Aircraft/a4/Models/a4-blue.xml</model>
<speed-ktas type="double">320.0</speed-ktas>
<altitude-ft type="double">7000.0</altitude-ft>
<longitude type="double">-122.6</longitude>
<latitude type="double">37.9</latitude>
<heading type="double">210.0</heading>
<bank type="double">-15.0</bank>
</entry>

It looks much the same as the ship AI code. There are two differences, the <class> item and the <bank> item. If the class is set to "tanker" the airplane will allow you to refuel if you can get close behind it. The bank is of course similar to the ship's rudder. In the above example the A-4 will be orbiting to the left at 15 degrees of bank. You can also create a ship or airplane with a flight plan. In this case the object will follow the flight plan, and then delete itself when it reaches the end. The flight plans are kept in data/Data/AI/FlightPlans. To create an airplane with a flightplan do this:

<entry>
<type>aircraft</type>
<class>jet-transport</class>
<model>Aircraft/737/Models/737.xml</model>
<flightplan>ksfo_ils28l.xml</flightplan>
</entry>

To make a thunderstorm, use this:


<entry>
<type>storm</type>
<model>Models/Geometry/thunderstorm.xml</model>
<speed-ktas type="double">20.0</speed-ktas>
<altitude-ft type="double">4000.0</altitude-ft>
<latitude type="double">37.3917</latitude>
<longitude type="double">-122.2817</longitude>
<heading type="double">90</heading>
</entry>

There's not much to it. No, they don't turn :) To create a thermal, use this:

<entry>
<type>thermal</type>
<latitude type="double">37.61633</latitude>
<longitude type="double">-122.38334</longitude>
<strength-fps type="double">8.33</strength-fps>
<diameter-ft type="double">4000</diameter-ft>
<height-msl>6000</height-msl>
<model>Models/Geometry/thermalcap.xml</model>
</entry>

The AI thermals don't move, they are invisible, and they don't "lean" downwind. The <strength-fps> defines the maximum vertical velocity of the airmass at the center of the thermal. The strength decreases to zero at the thermal's edge. A
model can be assigned to the thermal, and usually this will be a small cloud to mark the thermal's location. To create a sink, just give a "thermal" a negative strength, and give it a null model. Please see the demo scenario (thermal_demo.xml) for examples.

A ballistic AI object starts with an initial azimuth, elevation and speed, then follows a ballistic path from there (with air resistance and wind included). Try this:

<entry>
<type>ballistic</type>
<model>Models/Geometry/rocket.xml</model>
<speed-fps type="double">500.0</speed-fps>
<altitude-ft type="double">50.0</altitude-ft>
<longitude type="double">-122.39</longitude>
<latitude type="double">37.62</latitude>
<heading type="double">200.0</heading>
<azimuth type="double">70.0</azimuth>
<elevation type="double">45.0</elevation>
</entry>

Note that the speed is now in feet per second.

The AI storm objects can be displayed on weather radar. See the Aircraft/Instruments/wxradar.xml file for details. The AI aircraft objects can be displayed on radar. See the Aircraft/Instruments/radar.xml file for details.

You can make your own AI scenario file, called say my_scenario.xml, and cut/paste entries from the other scenario files to build an AI scenario as complicated as you like.

The following how-to shows you how to animate a tail-dragger airplane so that its pitch attitude looks proper for the AI aircraft's airpeed. This is not needed for aircraft with tricycle landing gear.

=== Using Interpolation Tables ===
Interpolation tables are very handy for effecting animations that are non-linear in relation to the property they are referenced to.

They save the use of factors, offsets and min/max values.

For example; relating flap extension to airspeed of an AI model. Typically an aircraft will extend flaps on final approach to control Indicated Airspeed (IAS) and stall speed to affect a low speed controlled landing. Upon touchdown the extra lift efficiency introduced by the flaps is no longer required or desirable, hence the flaps will be retracted ASAP after touch down.

This is relatively simple in a sim aircraft as the /surface-positions/flap-pos-norm property is a normalised indicator of the flap setting chosen by the pilot.

AI aircraft have no pilots to control flaps nor does the flight plan <flaps-down>true/false</flaps-down> parameter effect the /AI property tree parameter, a relationship to the IAS is the next best choice.

To effect this relationship (IAS/flap-position) using factors/offsets and min/max would be quite difficult and non-intuitive. Using interpolation tables allows the following scenario to be setup very easily and intuitively:

: '''C172P'''
{| border="1"
|-
| Max
| 123 KIAS
|-
| Cruise
| 90 KIAS
|-
| Stall (no flaps)
| 50 KIAS
|-
| Flaps
| 0, 10, 20, 30 deg.
|-
| Approach
| 90 KIAS
|-
| 10° flaps
| 90 KIAS
|-
| 20° flaps
| 70 KIAS
|-
| 30° flaps
| 60 KIAS
|-
| Flare & touch down
| 50 KIAS
|-
| Brake
| 45 KIAS
|-
| Retract flaps
| 45 KIAS
|}

'''Table IAS/flap extension'''
{| border="2"
|+
| IAS (kt) || Flaps
|-
| 90
| 0
|-
| 70 - 89
| 10
|-
| 60-69
| 20
|-
| 45-59
| 30
|-
| < 45
| 0
|}

When the pilot extends the flaps "one notch" they will extend to "10°" etc. In the property tree, these 4 steps will typically be normalised to 0.00, 0.33, 0.66, 1.00. This will differ from aircraft to aircraft. If the aircraft does not have equal extensions for each "notch" of flaps, the values observed may be; 0.00, 0.10, 0.30, 0.66, 1.00. Modeling this non-linear extension using "factor, offset, min/max" would be extremely difficult if not impossible. Modeling it using interpolation tables is very easy, as you shall see.

For sim animations, the actual physical rotation of the control surface in the real world needs to be researched; this may reveal a linear or non-linear relationship between "nominal flap extension indicator" and physical rotation of the surface. That is, "10 degrees of flap" might only involve rotating the flap surface 5 degrees around its axis in the wing structure. In our 0,10,20,30 scenarios, assuming a linear relationship, 30 degrees of flap would result in the flap being rotated 15 degrees around its wing axis. Therefore the normalised /surface-positions/flap-pos-norm property would have a factor of 15 applied to the rotate animation

The way to change a linear relationship that uses "factor, offset, min/max" in the sim animation to a interpolation table in the AI animation is best understood by examining how "factor, offset, min/max" approach works:

# Take normalised value of the flaps (0=retracted, 1=extended)
# Apply the factor.
# Apply the offset
# Apply the min/max values

e.g.
factor=60
offset= -30
min=-10
max+10

these figures are nonsense but are used to illustrate a point:

flaps retracted(0°) = 0 x 60 = 0, (offset=-30) = -30, (min= -10) = -10
flaps extended(10°) = 0.33 x 60 = 20, (offset=-30) = -10, (min= -10) = -10
flaps extended(20°) = 0.66 x 60 = 40, (offset=-30) = 10, (min= -10/max=10) = 10
flaps extended(30°) = 1.00 x 60 = 60, (offset=-30) = 30, (max=10) = 10

more realistically, offset and min max are not used for flaps, only a factor.

say 27°, this represents the maximum rotation of the 3-D component in the model around its defined axis.

flaps retracted(0°) = 0 x 27 = 0
flaps extended(10°) = 0.33 x 27 = 9
flaps extended(20°) = 0.66 x 27 = 18
flaps extended(30°) = 1.00 x 27 = 27

from this it can be seen that the 3-D object will be rotated 0°, 9°, 18° & 27° to represent the 0°, 10°, 20° & 30° deployment of the flaps.

Relating this back to the speeds above:

{| border="1"
|+
| IAS (kt)
| <rotate> value
|-
| 0
| 0
|-
| 44
| 0
|-
| 45
| 27
|-
| 59
| 27
|-
| 60
| 18
|-
| 69
| 18
|-
| 70
| 9
|-
| 89
| 9
|-
| 90
| 0
|-
| 100
| 0
|}

this gives a stepped effect, where the movement is limited to 1knt of airspeed. That is the 3-D object will linearly move from 9° to 18° while the aircraft looses speed from 70 knots to 69 knots. This behaviour will make the need for an upper and lower limit of a stepped value obvious.

a simplified table of:

{| border="1"
|+
| IAS (kt)
| <rotate> value
|-
| 0
| 0
|-
| 45
| 27
|-
| 60
| 18
|-
| 70
| 9
|-
| 90
| 9
|-
| 100
| 0
|}

will cause the flaps to start extending at the rate of 1/45 x 27 degrees per knot of airspeed gained until 45 knots when the rate of change will adjust to the new gradient. This is not how flaps behave, but can be used to good effect with "tail dragger" animations where at a certain IAS the tail starts rising, maybe at an increasing rate, until flying attitude is reached when it stops rising any further. The tail rising is not a stepped function of IAS.

Now we have the basic ideas behind interpolation tables, the question is how are they implemented…answer;…easy ….an example of the stepped flaps animation above

<interpolation>
<entry><ind>0.000></ind><dep>0.000</dep></entry>
<entry><ind>44.00></ind><dep>0.000</dep></entry>
<entry><ind>45.00></ind><dep>27.00</dep></entry>
<entry><ind>59.00></ind><dep>27.00</dep></entry>
<entry><ind>59.00></ind><dep>27.00</dep></entry>
<entry><ind>60.00></ind><dep>18.00</dep></entry>
<entry><ind>69.00></ind><dep>18.00</dep></entry>
<entry><ind>70.00></ind><dep>9.000</dep></entry>
<entry><ind>89.00></ind><dep>9.000</dep></entry>
<entry><ind>90.00></ind><dep>0.000</dep></entry>
<entry><ind>100.0></ind><dep>0.000</dep></entry>
</interpolation>

Here endth Interpolation tables 101
:-Dene

=== Submodels ===
Submodels are AI ballistic objects that emanate from, fall from, or launch from the user aircraft. They are presently used to model smoke, contrails, flares, tracers, bombs, drop tanks and flight path markers.

Submodels are controlled by the submodel manager. The manager reads a submodel configuration file at the start of the sim session. This configuration file is written by the aircraft author and defines all the submodels for that particular aircraft.

As an example examine the submodels file in the Aircraft/737-300 directory. This file creates two submodels which will become the airplane's left and right engine contrails. Each contrail needs its own submodel definition because the contrails begin at different locations. Each contrail consists of a train of individual "puff" models that are released in rapid succession as long as the "trigger" property is true. We ensure an unlimited supply of puffs by setting the "count" parameter to -1. The individual puffs, being AIBallistic objects, will follow their own ballistic paths once released. In this case we have used the "bouyancy" parameter to negate gravity in the ballistic path. The puffs have been given a life span of eight seconds. At cruising speed the [[Boeing 737|737]] will thus have about 400 puffs behind it at any moment.

* [http://wiki.flightgear.org/images/0/0f/Submodels.txt This annotated submodels.xml file] gives a good idea about how to create submodel files, what parameters are available and how to use them, and also the type of research needed to make sure the information and models are accurate historically.

=== Multiplayer Controlled Traffic ===

FlightGear's multiplayer system also makes use of the AIModels subsystem. See the [[Multiplayer]] page for more information.

=== Traffic Manager Controlled Traffic ===
Traffic Manager Controlled Input to the AIModels subsystem is also known as Interactive Traffic. See: [[Interactive Traffic]] for more information.

==External links==
* [http://www.xs4all.nl/~dtalsma/flightgear.html The FlightGear AI aircraft download page]

[[Category:FlightGear feature]]

FlightGear Newsletter April 2010

2010-04-14T05:49:27Z

Durk: Add a little snipped about my pending AI improvements

{{newsletter}}

(Feel free to contribute to next month's newsletter. Have a look at [[:Category:FlightGear Newsletter|the archive]] and in the forum for ideas on what can be included.)

==In the hangar==
===Aircraft===
====Fokker 50====
The F50 hasn't got totally new functions, but Gijs [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7542 spotted a problem] with the .xml files in the plane, thus making it unable to fly on version 2.0. The .xml files have been patched and are available at the forum. In the mean time both Gijs and gooneybird have created a bunch of excellent new [http://flightgear.org/forums/viewtopic.php?f=13&t=7604 liveries which can be found in the forum].

====IL-96-400====
The IL96-400 [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7439 was released] on 06 Apr 2010, and is downloadable from UnitedFreeWorld.

====Boeing 747SP====
The Boeing 747SP, a special ultra-long-haul version of the B747, is being developed by shervin88 on [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7572 the forum]. It is still at an alpha stage.

====VMX22 Osprey====
The Osprey [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7205 is being revamped] by ot-666, with a totally new model and FDM.

====Boeing 717====
The 717 is still at a pre-alpha stage at the forum.

====North American P-51D====
The P-51D, a legendary fighter, was [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7494 remodeled] under JSBSim only by hvengel.

====C-5====
The C-5 [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7557 is being modeled] by jonbourg.

====IAR80====
The IAR80 prop [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7225 is near completion].

====747-8I====
The Boeing 747-8 Intercontinental is being modeled by MOJO.

====A318====
The A318 is being modeled from the A319. Read more about this project at [http://www.flightgear.org/forums/viewtopic.php?f=4&t=6524 the forum].

====C-17====
The awesome C-17 has been in work by jonbourg for a while now and it looks great. The model is fantastic and it includes a working cargo door, animation and now fully operating thrust reverse. Upcoming updates will include an airdrop feature and 3D cockpit instrumentation. Also in the works is DATCOM information for a realistic flying experience.

====P-47N====
Jon Bourgeois (jonbourg) also is currently working on the P-47N from [http://home.comcast.net/~davidculp2/hangar/hangar.html Dave Culp's hangar].

====Quest Kodiak 100====
The Quest Kodiak is a modern STOL turboprop single built to be a back-country aircraft to help in areas in which humanitarian help is needed. At the moment exists a basic FDM and an outside 3D model with animations of it. We are currently working on the cockpit. If you want to help developing please write a mail to not.everyone.lives [at] googlemail [dot] com. You can download the Kodiak [http://takhadnotor.github.com/kodiak/ from here]. Also a [http://www.flightgear.org/forums/viewtopic.php?f=4&t=6804 forum thread] represents the project.

====B-29 Superfortress====
The original author of the B-29 model is not active in FlightGear at the moment due to the pressures of real-life work. So Vivian Meazza has been busy with bringing the B-29 model up-to-date. The ambient light levels have been brought into line with current practice and the YASim FDM has been lightly worked over. Some effects have been added: the reflective effect, exhaust staining, and contrails.

====ASK-13 Glider====
[[Image:ASK13.jpg|thumb|The ASK-13 by Patrice Poly. ]]

The gliders fleet is growing, with this Schleicher twin seat glider. It has a accurate fdm based on real experiences of the author. It contains the new bumbspec shader, detailled interior with AmbientShadows baked, DualCockpit over MP and many things more. See [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7531 this thread] for details and download. It is available in CVS as well now!

====Piper J3 Cub====
[[Image:J3cup.1.jpg|thumb|New Piper J3 Cub by Don Lavelle. Custom Scenery "France" in the background.]]
This taildragger has been now completly remodelled in Blender by Don Lavelle. It features an accurate 3d-modell, high resolution textures, paintkit, pilotmodel, smoke effect and detailled interior. The new Piper J3 Cub is now available in the [http://www.flightgear.org/forums/viewtopic.php?f=4&t=6890&start=0&st=0&sk=t&sd=a forum] or in CVS.

===Liveries===
Just two months after its (re)launch, the [http://liveries.flightgear.org livery database] has been visited by more than a 1000 unique visitors, from 74 different countries. Together they have viewed over 22.000 pages. As of April, more than 200 liveries are available and the database is still expanding.

==CVS news==

=== New and improved shaders===
[[Image:B29 shader.jpg|thumb|New Reflection Shader applied to the B29. It shows a shiny, high-reflective blank metal, which can be achieved now with the new shader.]]

[[Image:EC135 shader2.jpg|thumb|New Reflection Shader applied to the Ec135 for testing. It is here controlled by a greymap, but could be controlled by the materials setting as well]]

Frederic Bouvier improved the Urban Shader - it now supports nightlighting and snow as well. He improved the landmass-shader too, which gives us a more realistic 3d-look to the forest. There is also a new slider in the rendering settings to adjust the level of eye-candy to the available hardware power.

Vivian Meazza added a Reflection Shader. This now gives us shiny surfaces on any object. So you can now have shiny blank metals, or a glossy coating like we can see on cars and modern aircraft, or shiny windows, which even show a nice rainbow effect (like the Airbus shows). These effects are completely configurable and can be controlled in many ways.

It support Cubemaps as well, and as this influences the look of the shader effect a lot, people are invited to create as many and different as we could need.

Finally, there is a wiki article ([[Howto:_Use_The_Normal_Map_Effect_in_Aircraft]]) on using the normal mapping shader, which is very useful for adding bump maps to aircraft. The standard Cessna 172p already uses this effect to show the rivets on the wings and fuselage.

===Weather development very active===
In the end of March and start of April, lots of developers have released, [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358 in the forum], contributions to a local weather system.

The aim of a local weather system is to simulate weather phenomena tied to specific locations. Examples for this are a thunderstorm, a rainfront or thermal development. In the case of the thunderstorm, severe rain and turbulence occur in a location a few kilometers in scale, i.e. one can easily view it 'from outside' or fly in and out of this region. Similarly, the development of thermal convection clouds is strongly tied to features of the terrain - thermal development does not occur easily over open water or snow, but it is strong over rock or similar surfaces which heat in the sun. Finally, a rainfront is a phenomenon like a thunderstorm that divides the sky into two regions - one with essentially good visibility and clear sky, the other with severe clouds and rain, and both are visible at the same time.

This is in contrast to the current standard weather system of Flightgear where weather changes affect the weather everywhere in the simulated world and are (with few exceptions) not tied to specific locations. In such a system, it is impossible to observe e.g. the approach of a rainfront while flying in sunshine. In contrast, the local weather system allows for visual impressions such as the following:

<center>
[[File:Clouds-nimbostratus.jpg|500px]]
</center>

The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.51.tgz current release v0.51] is still limited to simulating weather in a 40x40 km tile, but supports placement of regions in which visibility, rain, snow and thermal lift are set, as well as interpolation of visibility, pressure, temperature and dewpoint between preset weather stations. The system also automatically creates thermals below convective clouds which can be utilized by gliders using a CVS patch, thus providing greatly enhanced soaring capability. More details in the forum or in the Wiki article [[A local weather system]].

Help with texturing cloud models, developing and improving shader effects, testing, merging with the C++ code or increasing the library of available weather tiles is highly appreciated!

===AI traffic becomes more interactive ===
Early April, a patch was was committed to TaxiDraw, FlightGear's airport design program, which allows a more thorough checking of AI ground networks for internal consistency. This patch, and the consequential improvement in ground network quality serves as a lead-up to a batch of new functionality in the AI Interactive Traffic code. Communication between taxiing AI aircraft and and ground control can be tracked by tuning your comm radios to the appropriate ground frequency. Although the system is designed to work at any airport, best chances of for witnessing this ground activity is at EHAM, by tuning into 121.7 for startup clearance procedures or 121.8 for push back approval, taxi clearance and all hold position / resume taxi instructions.

===New dogfighting scenarios available!===
Developers been interested in developing dogfighting scenarios over the month. Some AI balloon experiments have been released too.

==Scenery Corner==
===Malpensa being developed===
The Milan/Malpensa airport is being developed by brisa [http://www.flightgear.org/forums/viewtopic.php?f=5&t=2852 here].

==Multiplayer news==

==Community news==

==And finally==
Did you know, that the visibility of FlightGear's menubar can toggled by hitting the F10 key? Or start your FlightGear with --prop:/sim/menubar/autovisibility/enabled=1 once. The menubar automatically pops up when your mouse is near the top edge of the FlightGear window. A click with the left mouse button hides the menubar again. If you have autosave on (which is on by default), this feature will be enabled every time you start FlightGear.

[[Category:FlightGear Newsletter|2010 04]]

Howto:Make nice screenshots

2009-12-14T22:28:15Z

Durk: /* How to get some unusual/ interesting views */

{{stub}}

In this [[:Category:Howto|howto]] I will explain how to make nice screenshots in [[FlightGear]]. This is helpful for those who want to advertise FGFS on other sim-related forums or on booths around the world.

===Basics to know===
Good pictures:
* They appeal to us in some way, by telling a story, revealing something unexpected, or showing an interesting point of view.
* They encourage us to look at them for more than just a second, searching for more details. A good screen-shot can invite us to think about how it was made, maybe even inspire us to create images of our own.
* The best screen-shots are technically correct, the lighting and colors are right, and the composition is good.

The part of How to composite a picture is difficult to explain - so instead I suggest you to read tutorials and explanations given on many websites on the web like this one : [http://en.wikipedia.org/wiki/Composition_(visual_arts) Composition (visual arts)].

== Quality ==
A good virtual picture needs a good quality. That means:
* Use of AntiAliasing (AA)
* Appealing/true colors
* Size of the picture- not too small, not to big
* No Gui/Menu/FrameRateCounter etc. visible
* Full effects

This means you need a decent computer with middle - good specs. At least you should able to run FGFS with fluent fps with high AA-settings.
Some people don't have this, so there is another solution proposed by Melchior Franz : [http://www.opensubscriber.com/message/flightgear-devel@lists.sourceforge.net/8196594.html].

== How to get some unusual/ interesting views ==
To get some ideas, I suggest to look on the aircraft picture pages around the web like [http://www.airliners.net Airliners.net]. It will give you some ideas. In addition, it is always a good idea to think about what you actually want to show case. While a snapshot of an airliner in mid flight is -for instance- a nice way of showing it's latest features on the forum, it typically doesn't really last as an overall impressive screen shot. Placing the aircraft in a scene where some implied action is taking place will most of the time already make a huge difference. Capture the plane while it's banking, gear is retracting, etc etc, will imply some dynamic motion in your otherwise static image. In this respect, it may help to think of a little story, a scenario that you're reenacting. Trying to capture a few key scenes from that story may also help to make the difference between an average and an interesting screen shot.

===Air to Air===
* '''Helicopter View:''' This assumes that you are in a virtual, not visible helicopter besides the aircraft. You are always flying level. With the mouse you can choose the position of the "helicopter".
* '''Chase View:''' This assumes you are chasing the aircraft. It is very similar to the first one.
* '''Chase View with yaw:''' Also chasing the aircraft, but the virtual camera doesn't turn with the aircraft.
Try switching between them to see what you like more(I prefer Chase view). Playing around with position of the camera will help too. As an example if the aircraft is turning and banking, make a shot from the wing to the aircraft facing the ground. Or while approaching the runway, a shot from behind the aircraft would be good.

===Ground to Air===
[[Image:Wiki PlaceTower.jpg|thumb|270px|Setting the Tower on top of the mountain looking down to the airport with the [http://www.gidenstam.org/FlightGear/misc/place_tower.xml Place_Tower.xml]]]

For this we use the Tower view and Tower View look from. This assumes that the virtual camera is on the Airport Tower, ca. 30ft above the airport level. You can choose via the Menu which airport is used. That's nice, but limited.

Anders Gidenstam made a nice little helping nasal script, with you can choose the tower position on the ground via mouse-click.
You can grab it [http://www.gidenstam.org/FlightGear/misc/place_tower.xml here]. Copy the code between the <property-list>-tags and put in somewhere of your preferences.xml . Now by ''Ctrl + LMB-Click'' somewhere on the scenery you can set the Tower-view position. It is still ca. 30ft above the airport level- assuming you are virtual walking in the scenery, you can change the line

setprop(tower ~ "/altitude-ft", 30 + MtoFT * click_pos.alt());

to

setprop(tower ~ "/altitude-ft", 6.5 + MtoFT * click_pos.alt());

===Panorama===
[[Image:Fgfs-screen-560 stitch2.jpg|thumb|600px|180 degrees Panorama stitched with 20 images inside the C172P cockpit while flying above the Custom Scenery for South France]]

[http://en.wikipedia.org/wiki/Panorama Panorama] is a wide-angle view. With this, you can show large areas of sceneries or interiors like flightdecks.

For this use the Cockpit, Passenger-view or Tower-view, and position the virtual camera at the point you want. Pause the sim and now, while panning the virtual camera, save many screenshots so they all cover the pan.
Now use your favourite Panorama-Software and stitch it!
No software yet? Use Google, as there are several Freeware-programs outside. I can recommend [http://hugin.sourceforge.net/ Hugin], it is OpenSource, crossplatform and used by many professional photographers.

== Field of View (FoV) ==
[[Image:wiki_FoV.jpeg|thumb|270px|The difference of wide/Narrow angle. See how the background changes using a zoom!]]

You can change this by pressing X/x-key or using the Mouse-wheel in View-mode.
The FoV is per default set to 55 (degrees).

Increasing the field you get wide angle up to 120 degrees. That's interesting as it covers a whole part of the scenery but also seems to make objects appear far away. So use it for showing large parts of sceneries, or long aircraft etc... Another interesting feature of using a wide angle is that it exaggerates perspective. One effective use of this consists of using a wide angle lens combined with placing the camera near the object. This will make the object in question appear larger, more impressive than it really is. For an higher wide angle make a panorama.

Decreasing the field you get a narrow angle and a zoom-effect. This means you can take far away objects virtually close to you. An interesting effect is, that it also makes the background more "dense". Another interesting side effect is distance foreshortening, meaning that the distance between various object is becoming compressed, suggesting less space between objects than there really is.

== Lighting and Daytime ==
[[Image:Wiki low sun shaders.jpg|thumb|270px|Showing the effect of the low sun and the water shaders]]

The most appealing photos in real life are made in the morning or evening. The light has a warm color, the shadows and ambient colors are soft and long which gives fantastic impressions. The noon gives hard shadows and strong contrasts, which are hard to deal with.

This applies to FlightGear as well. So play a bit with the daytimes, especially Dawn/Morning/Afternoon and Dusk. Play with the seasons and locations as well. In the winter near the poles the sun is low, while near the equator the sun is standing high in the sky. As an example this gives nice effects with the shaders on the water.

== Weather ==
Our weather has improved much in CVS and upcoming releases. Much more realistic clouds, better sky and ambient colors and the possibility to set your own [[METAR]], clouds etc. makes it more easy to create a stunning weather background for your picture.

== Locations ==
The choice of the location depends a bit what you want to show. So what want you to show? Do you have already a theme for in mind?

As an example for showing an aircraft just for presentation, use an "empty" background like the sky, sea or desert. If you want to show the aircraft during operation you could choose some or our better airports like [[EHAM]], [[LFPG]] etc. as background, or some of the more detailed sceneries like our Custom Sceneries.

== Colors and whitebalance ==
As in real life, in FGFS the pictures often have to be corrected in colors and whitebalance. This can be done with almost any image editor. In [http://www.gimp.org GIMP] this can be done through <tt>Layers > Colors > Brightness and contrast</tt>.

== Conclusion ==
Combining all this, playing with all this you should be able to create some stunning pictures. Try and play with as much you can, look at real images to get hints or try to copy a real life image in FlightGear. All this will help you to make a good picture!

Howto:Make nice screenshots

2009-12-14T22:17:07Z

Durk: /* Field of View (FoV) */

{{stub}}

In this [[:Category:Howto|howto]] I will explain how to make nice screenshots in [[FlightGear]]. This is helpful for those who want to advertise FGFS on other sim-related forums or on booths around the world.

===Basics to know===
Good pictures:
* They appeal to us in some way, by telling a story, revealing something unexpected, or showing an interesting point of view.
* They encourage us to look at them for more than just a second, searching for more details. A good screen-shot can invite us to think about how it was made, maybe even inspire us to create images of our own.
* The best screen-shots are technically correct, the lighting and colors are right, and the composition is good.

The part of How to composite a picture is difficult to explain - so instead I suggest you to read tutorials and explanations given on many websites on the web like this one : [http://en.wikipedia.org/wiki/Composition_(visual_arts) Composition (visual arts)].

== Quality ==
A good virtual picture needs a good quality. That means:
* Use of AntiAliasing (AA)
* Appealing/true colors
* Size of the picture- not too small, not to big
* No Gui/Menu/FrameRateCounter etc. visible
* Full effects

This means you need a decent computer with middle - good specs. At least you should able to run FGFS with fluent fps with high AA-settings.
Some people don't have this, so there is another solution proposed by Melchior Franz : [http://www.opensubscriber.com/message/flightgear-devel@lists.sourceforge.net/8196594.html].

== How to get some unusual/ interesting views ==
To get some ideas, I suggest to look on the aircraft picture pages around the web like [http://www.airliners.net Airliners.net]. It will give you some ideas.

===Air to Air===
* '''Helicopter View:''' This assumes that you are in a virtual, not visible helicopter besides the aircraft. You are always flying level. With the mouse you can choose the position of the "helicopter".
* '''Chase View:''' This assumes you are chasing the aircraft. It is very similar to the first one.
* '''Chase View with yaw:''' Also chasing the aircraft, but the virtual camera doesn't turn with the aircraft.
Try switching between them to see what you like more(I prefer Chase view). Playing around with position of the camera will help too. As an example if the aircraft is turning and banking, make a shot from the wing to the aircraft facing the ground. Or while approaching the runway, a shot from behind the aircraft would be good.

===Ground to Air===
[[Image:Wiki PlaceTower.jpg|thumb|270px|Setting the Tower on top of the mountain looking down to the airport with the [http://www.gidenstam.org/FlightGear/misc/place_tower.xml Place_Tower.xml]]]

For this we use the Tower view and Tower View look from. This assumes that the virtual camera is on the Airport Tower, ca. 30ft above the airport level. You can choose via the Menu which airport is used. That's nice, but limited.

Anders Gidenstam made a nice little helping nasal script, with you can choose the tower position on the ground via mouse-click.
You can grab it [http://www.gidenstam.org/FlightGear/misc/place_tower.xml here]. Copy the code between the <property-list>-tags and put in somewhere of your preferences.xml . Now by ''Ctrl + LMB-Click'' somewhere on the scenery you can set the Tower-view position. It is still ca. 30ft above the airport level- assuming you are virtual walking in the scenery, you can change the line

setprop(tower ~ "/altitude-ft", 30 + MtoFT * click_pos.alt());

to

setprop(tower ~ "/altitude-ft", 6.5 + MtoFT * click_pos.alt());

===Panorama===
[[Image:Fgfs-screen-560 stitch2.jpg|thumb|600px|180 degrees Panorama stitched with 20 images inside the C172P cockpit while flying above the Custom Scenery for South France]]

[http://en.wikipedia.org/wiki/Panorama Panorama] is a wide-angle view. With this, you can show large areas of sceneries or interiors like flightdecks.

For this use the Cockpit, Passenger-view or Tower-view, and position the virtual camera at the point you want. Pause the sim and now, while panning the virtual camera, save many screenshots so they all cover the pan.
Now use your favourite Panorama-Software and stitch it!
No software yet? Use Google, as there are several Freeware-programs outside. I can recommend [http://hugin.sourceforge.net/ Hugin], it is OpenSource, crossplatform and used by many professional photographers.

== Field of View (FoV) ==
[[Image:wiki_FoV.jpeg|thumb|270px|The difference of wide/Narrow angle. See how the background changes using a zoom!]]

You can change this by pressing X/x-key or using the Mouse-wheel in View-mode.
The FoV is per default set to 55 (degrees).

Increasing the field you get wide angle up to 120 degrees. That's interesting as it covers a whole part of the scenery but also seems to make objects appear far away. So use it for showing large parts of sceneries, or long aircraft etc... Another interesting feature of using a wide angle is that it exaggerates perspective. One effective use of this consists of using a wide angle lens combined with placing the camera near the object. This will make the object in question appear larger, more impressive than it really is. For an higher wide angle make a panorama.

Decreasing the field you get a narrow angle and a zoom-effect. This means you can take far away objects virtually close to you. An interesting effect is, that it also makes the background more "dense". Another interesting side effect is distance foreshortening, meaning that the distance between various object is becoming compressed, suggesting less space between objects than there really is.

== Lighting and Daytime ==
[[Image:Wiki low sun shaders.jpg|thumb|270px|Showing the effect of the low sun and the water shaders]]

The most appealing photos in real life are made in the morning or evening. The light has a warm color, the shadows and ambient colors are soft and long which gives fantastic impressions. The noon gives hard shadows and strong contrasts, which are hard to deal with.

This applies to FlightGear as well. So play a bit with the daytimes, especially Dawn/Morning/Afternoon and Dusk. Play with the seasons and locations as well. In the winter near the poles the sun is low, while near the equator the sun is standing high in the sky. As an example this gives nice effects with the shaders on the water.

== Weather ==
Our weather has improved much in CVS and upcoming releases. Much more realistic clouds, better sky and ambient colors and the possibility to set your own [[METAR]], clouds etc. makes it more easy to create a stunning weather background for your picture.

== Locations ==
The choice of the location depends a bit what you want to show. So what want you to show? Do you have already a theme for in mind?

As an example for showing an aircraft just for presentation, use an "empty" background like the sky, sea or desert. If you want to show the aircraft during operation you could choose some or our better airports like [[EHAM]], [[LFPG]] etc. as background, or some of the more detailed sceneries like our Custom Sceneries.

== Colors and whitebalance ==
As in real life, in FGFS the pictures often have to be corrected in colors and whitebalance. This can be done with almost any image editor. In [http://www.gimp.org GIMP] this can be done through <tt>Layers > Colors > Brightness and contrast</tt>.

== Conclusion ==
Combining all this, playing with all this you should be able to create some stunning pictures. Try and play with as much you can, look at real images to get hints or try to copy a real life image in FlightGear. All this will help you to make a good picture!

AI Systems

2009-12-13T09:16:40Z

Durk: Some restructuring to make the internal subsystems dependency more obvious.

== AI Systems in FlightGear ==
[[FlightGear]] has a number of more or less independently operating systems for simulating semi- intelligent interaction with the environment. Because there oftentimes exists some confusion regarding to which system does what, one should take notice of the differences between them: The major distinction is that between an older ATC/AI system, and a newer AIModels system. The AIModels system can, in turn, be controlled in at least three different ways; directly, using a script, through the multiplayer system, and through a subsystem known as the traffic manager.

To enable/disable the ATC/AI system: use --prop:/sim/ai-traffic/enabled=[1|0]
To enable/disable the AIModels system: use --prop:/sim/ai/enabled=[1|0]

== ATC/AI ==
The [[ATC|Air Traffic Control]] system simulates interaction between the user and a number of AI controlled cessna and piper aircraft. This system can be controlled using the GUI from within FlightGear. The ATC/AI system is no longer maintained and marked for deprication. Recent reports have indicated that the ATC/AI system my be causing numerical computation problems in some cases, resulting in a flurry of NaN warning messages on the FlightGear console. If you experience this, you might consider shutting down the ATC/AI system

For airports with a tower frequency, if that frequency is tuned in to your radio, you may contact ATC.

To obtain the tower frequencies for an airport within range of ATC, go to the ATC/AI menu, choose Frequencies to display the dialog. If there are any airports within 40nm range, a button with the airport designation will appear. Click see the frequencies. Tune the tower frequency in on the COM1 radio and then hit the single quote key to open the ATC window.

Points:
* Untowered airports are not supported in any way by ATC.
* You must be within 40 nautical miles of an ATC facility (towered airport with tower frequencies) to contact ATC.

== AI Models ==
Starting with FlightGear version 0.9.4 you can place AI objects in the "FlightGear world". In version 0.9.4 the AI objects can be defined in the preferences.xml file, or in an airplane's *-set.xml file. In later versions they are defined in a "scenario file" only. The types of AI objects you can have are airplanes, ships, thunderstorms, thermals/sinks, static and ballistic objects. AI objects have some things in common: The have a location in the "FlightGear world", they can have an associated exterior 3D model, and they can move according to an internal [[FDM]] (flight dynamics model). As of now, these objects are created at simulator start-up by adding some XML code to a scenario file. The scenario file must be in the data/AI directory. You select which scenario files you want to use by naming it in the preferences.xml file. The preferences.xml file has an entry that looks like this (FlightGear versions newer than 0.9.4, including CVS):

<ai>
<enabled type="bool">true</enabled>
<scenario>aircraft_demo</scenario>
</ai>

The above bit of XML enables the AI system and selects a scenario file called aircraft_demo.xml.

''Notes:
*XML tags are case-sensitive.
*Introducing certain characters into the XML file, even as part of a comment, will cause the file to choke. These include &, <, and --.''

The scenario file contains one entry for each AI object. The entry specifies what kind of object to create, what its initial conditions will be, and optionally (for aircraft and ships) a flight plan. The entry for a sailboat could look like this:

<entry>
<type>ship</type>
<model>models/geometry/sailboat.xml</model>
<speed-ktas type="double">12.0</speed-ktas>
<altitude-ft type="double">0.0</altitude-ft>
<longitude type="double">-122.33333</longitude>
<latitude type="double">37.61667</latitude>
<heading type="double">20.0</heading>
</entry>

Most of the parameters are self-explanitory. The "type" of object can be one of "aircraft", "ship", "carrier", "thunderstorm", "thermal", "ballistic" or "static". The rest of the items give the AI object a model, a starting location, and a starting speed and direction. You use the <MODEL> item to give the object any valid exterior model. You can even make the ship look like an airplane if you want! Note that the speed of the AI object is true airspeed, and since AI aircraft and ships don't feel wind or current then this also the ground speed. The "ship" type can also have a <RUDDER> value specified, which will cause the ship to move in a circle (HINT: use small values, five degrees or less, and right rudder is positive). Here is an example of how to create an aircraft AI object:


<entry>
<type>aircraft</type>
<class>light</class>
<model>Aircraft/a4/Models/a4-blue.xml</model>
<speed-ktas type="double">320.0</speed-ktas>
<altitude-ft type="double">7000.0</altitude-ft>
<longitude type="double">-122.6</longitude>
<latitude type="double">37.9</latitude>
<heading type="double">210.0</heading>
<bank type="double">-15.0</bank>
</entry>

It looks much the same as the ship AI code. There are two differences, the <class> item and the <bank> item. If the class is set to "tanker" the airplane will allow you to refuel if you can get close behind it. The bank is of course similar to the ship's rudder. In the above example the A-4 will be orbiting to the left at 15 degrees of bank. You can also create a ship or airplane with a flight plan. In this case the object will follow the flight plan, and then delete itself when it reaches the end. The flight plans are kept in data/Data/AI/FlightPlans. To create an airplane with a flightplan do this:

<entry>
<type>aircraft</type>
<class>jet-transport</class>
<model>Aircraft/737/Models/737.xml</model>
<flightplan>ksfo_ils28l.xml</flightplan>
</entry>

To make a thunderstorm, use this:


<entry>
<type>storm</type>
<model>Models/Geometry/thunderstorm.xml</model>
<speed-ktas type="double">20.0</speed-ktas>
<altitude-ft type="double">4000.0</altitude-ft>
<latitude type="double">37.3917</latitude>
<longitude type="double">-122.2817</longitude>
<heading type="double">90</heading>
</entry>

There's not much to it. No, they don't turn :) To create a thermal, use this:

<entry>
<type>thermal</type>
<latitude type="double">37.61633</latitude>
<longitude type="double">-122.38334</longitude>
<strength-fps type="double">8.33</strength-fps>
<diameter-ft type="double">4000</diameter-ft>
<height-msl>6000</height-msl>
<model>Models/Geometry/thermalcap.xml</model>
</entry>

The AI thermals don't move, they are invisible, and they don't "lean" downwind. The <strength-fps> defines the maximum vertical velocity of the airmass at the center of the thermal. The strength decreases to zero at the thermal's edge. A
model can be assigned to the thermal, and usually this will be a small cloud to mark the thermal's location. To create a sink, just give a "thermal" a negative strength, and give it a null model. Please see the demo scenario (thermal_demo.xml) for examples.

A ballistic AI object starts with an initial azimuth, elevation and speed, then follows a ballistic path from there (with air resistance and wind included). Try this:

<entry>
<type>ballistic</type>
<model>Models/Geometry/rocket.xml</model>
<speed-fps type="double">500.0</speed-fps>
<altitude-ft type="double">50.0</altitude-ft>
<longitude type="double">-122.39</longitude>
<latitude type="double">37.62</latitude>
<heading type="double">200.0</heading>
<azimuth type="double">70.0</azimuth>
<elevation type="double">45.0</elevation>
</entry>

Note that the speed is now in feet per second.

The AI storm objects can be displayed on weather radar. See the Aircraft/Instruments/wxradar.xml file for details. The AI aircraft objects can be displayed on radar. See the Aircraft/Instruments/radar.xml file for details.

You can make your own AI scenario file, called say my_scenario.xml, and cut/paste entries from the other scenario files to build an AI scenario as complicated as you like.

The following how-to shows you how to animate a tail-dragger airplane so that its pitch attitude looks proper for the AI aircraft's airpeed. This is not needed for aircraft with tricycle landing gear.

=== Using Interpolation Tables ===
Interpolation tables are very handy for effecting animations that are non-linear in relation to the property they are referenced to.

They save the use of factors, offsets and min/max values.

For example; relating flap extension to airspeed of an AI model. Typically an aircraft will extend flaps on final approach to control Indicated Airspeed (IAS) and stall speed to affect a low speed controlled landing. Upon touchdown the extra lift efficiency introduced by the flaps is no longer required or desirable, hence the flaps will be retracted ASAP after touch down.

This is relatively simple in a sim aircraft as the /surface-positions/flap-pos-norm property is a normalised indicator of the flap setting chosen by the pilot.

AI aircraft have no pilots to control flaps nor does the flight plan <flaps-down>true/false</flaps-down> parameter effect the /AI property tree parameter, a relationship to the IAS is the next best choice.

To effect this relationship (IAS/flap-position) using factors/offsets and min/max would be quite difficult and non-intuitive. Using interpolation tables allows the following scenario to be setup very easily and intuitively:

: '''C172P'''
{| border="1"
|-
| Max
| 123 KIAS
|-
| Cruise
| 90 KIAS
|-
| Stall (no flaps)
| 50 KIAS
|-
| Flaps
| 0, 10, 20, 30 deg.
|-
| Approach
| 90 KIAS
|-
| 10° flaps
| 90 KIAS
|-
| 20° flaps
| 70 KIAS
|-
| 30° flaps
| 60 KIAS
|-
| Flare & touch down
| 50 KIAS
|-
| Brake
| 45 KIAS
|-
| Retract flaps
| 45 KIAS
|}

'''Table IAS/flap extension'''
{| border="2"
|+
| IAS (kt) || Flaps
|-
| 90
| 0
|-
| 70 - 89
| 10
|-
| 60-69
| 20
|-
| 45-59
| 30
|-
| < 45
| 0
|}

When the pilot extends the flaps "one notch" they will extend to "10°" etc. In the property tree, these 4 steps will typically be normalised to 0.00, 0.33, 0.66, 1.00. This will differ from aircraft to aircraft. If the aircraft does not have equal extensions for each "notch" of flaps, the values observed may be; 0.00, 0.10, 0.30, 0.66, 1.00. Modeling this non-linear extension using "factor, offset, min/max" would be extremely difficult if not impossible. Modeling it using interpolation tables is very easy, as you shall see.

For sim animations, the actual physical rotation of the control surface in the real world needs to be researched; this may reveal a linear or non-linear relationship between "nominal flap extension indicator" and physical rotation of the surface. That is, "10 degrees of flap" might only involve rotating the flap surface 5 degrees around its axis in the wing structure. In our 0,10,20,30 scenarios, assuming a linear relationship, 30 degrees of flap would result in the flap being rotated 15 degrees around its wing axis. Therefore the normalised /surface-positions/flap-pos-norm property would have a factor of 15 applied to the rotate animation

The way to change a linear relationship that uses "factor, offset, min/max" in the sim animation to a interpolation table in the AI animation is best understood by examining how "factor, offset, min/max" approach works:

# Take normalised value of the flaps (0=retracted, 1=extended)
# Apply the factor.
# Apply the offset
# Apply the min/max values

e.g.
factor=60
offset= -30
min=-10
max+10

these figures are nonsense but are used to illustrate a point:

flaps retracted(0°) = 0 x 60 = 0, (offset=-30) = -30, (min= -10) = -10
flaps extended(10°) = 0.33 x 60 = 20, (offset=-30) = -10, (min= -10) = -10
flaps extended(20°) = 0.66 x 60 = 40, (offset=-30) = 10, (min= -10/max=10) = 10
flaps extended(30°) = 1.00 x 60 = 60, (offset=-30) = 30, (max=10) = 10

more realistically, offset and min max are not used for flaps, only a factor.

say 27°, this represents the maximum rotation of the 3-D component in the model around its defined axis.

flaps retracted(0°) = 0 x 27 = 0
flaps extended(10°) = 0.33 x 27 = 9
flaps extended(20°) = 0.66 x 27 = 18
flaps extended(30°) = 1.00 x 27 = 27

from this it can be seen that the 3-D object will be rotated 0°, 9°, 18° & 27° to represent the 0°, 10°, 20° & 30° deployment of the flaps.

Relating this back to the speeds above:

{| border="1"
|+
| IAS (kt)
| <rotate> value
|-
| 0
| 0
|-
| 44
| 0
|-
| 45
| 27
|-
| 59
| 27
|-
| 60
| 18
|-
| 69
| 18
|-
| 70
| 9
|-
| 89
| 9
|-
| 90
| 0
|-
| 100
| 0
|}

this gives a stepped effect, where the movement is limited to 1knt of airspeed. That is the 3-D object will linearly move from 9° to 18° while the aircraft looses speed from 70 knots to 69 knots. This behaviour will make the need for an upper and lower limit of a stepped value obvious.

a simplified table of:

{| border="1"
|+
| IAS (kt)
| <rotate> value
|-
| 0
| 0
|-
| 45
| 27
|-
| 60
| 18
|-
| 70
| 9
|-
| 90
| 9
|-
| 100
| 0
|}

will cause the flaps to start extending at the rate of 1/45 x 27 degrees per knot of airspeed gained until 45 knots when the rate of change will adjust to the new gradient. This is not how flaps behave, but can be used to good effect with "tail dragger" animations where at a certain IAS the tail starts rising, maybe at an increasing rate, until flying attitude is reached when it stops rising any further. The tail rising is not a stepped function of IAS.

Now we have the basic ideas behind interpolation tables, the question is how are they implemented…answer;…easy ….an example of the stepped flaps animation above

<interpolation>
<entry><ind>0.000></ind><dep>0.000</dep></entry>
<entry><ind>44.00></ind><dep>0.000</dep></entry>
<entry><ind>45.00></ind><dep>27.00</dep></entry>
<entry><ind>59.00></ind><dep>27.00</dep></entry>
<entry><ind>59.00></ind><dep>27.00</dep></entry>
<entry><ind>60.00></ind><dep>18.00</dep></entry>
<entry><ind>69.00></ind><dep>18.00</dep></entry>
<entry><ind>70.00></ind><dep>9.000</dep></entry>
<entry><ind>89.00></ind><dep>9.000</dep></entry>
<entry><ind>90.00></ind><dep>0.000</dep></entry>
<entry><ind>100.0></ind><dep>0.000</dep></entry>
</interpolation>

Here endth Interpolation tables 101
:-Dene

=== Submodels ===
Submodels are AI ballistic objects that emanate from, fall from, or launch from the user aircraft. They are presently used to model smoke, contrails, flares, tracers, bombs, drop tanks and flight path markers.

Submodels are controlled by the submodel manager. The manager reads a submodel configuration file at the start of the sim session. This configuration file is written by the aircraft author and defines all the submodels for that particular aircraft.

As an example examine the submodels file in the Aircraft/737-300 directory. This file creates two submodels which will become the airplane's left and right engine contrails. Each contrail needs its own submodel definition because the contrails begin at different locations. Each contrail consists of a train of individual "puff" models that are released in rapid succession as long as the "trigger" property is true. We ensure an unlimited supply of puffs by setting the "count" parameter to -1. The individual puffs, being AIBallistic objects, will follow their own ballistic paths once released. In this case we have used the "bouyancy" parameter to negate gravity in the ballistic path. The puffs have been given a life span of eight seconds. At cruising speed the [[Boeing 737|737]] will thus have about 400 puffs behind it at any moment.

=== Multiplayer Controlled Traffic ===

FlightGear's multiplayer system also makes use of the AIModels subsystem. See the [[Multiplayer]] page for more information.

=== Traffic Manager Controlled Traffic ===
Traffic Manager Controlled Input to the AIModels subsystem is also known as Interactive Traffic. See: [[Interactive Traffic]] for more information.

==External links==
* [http://www.xs4all.nl/~dtalsma/flightgear.html The FlightGear AI aircraft download page]

[[Category:FlightGear feature]]

FlightGear Newsletter November 2009

2009-11-29T21:36:56Z

Durk: /* FSweekend */

{{newsletter}}

This is the draft of the next edition of the [[FlightGear]] Newsletter. Please feel free to edit and add your contribution.

==What's new in CVS==
===Shader support for Objects===
Tim Moore added now support for [[shaders]] on objects. This means we can have stunning effects like chrome effect, fresnel shaders etc on aircrafts in a near future. Tim has also integrated the [[3D clouds]] code as an "Effect". This makes editing the cloud shaders significantly easier.

===Trains, Boats and Planes (Vivian Meazza)===
[[File:steam1.png|thumb|Steam Train]]

As the song goes “but not for me”. But now they are for you in FlightGear. In a moment of madness on the [[IRC|IRC Channel]] I agreed to develop Ground Vehicles as an AI Class. It turned out that a few modifications to the AI Ship class would be a good jumping off point for the new class. I started with trains, because I thought they would be big enough to see easily from an aircraft. A very simple train with just 1 carriage. These are relatively common on commuter routes in the UK. Jon Stockill knew just such a train, and was familiar with a suitable route in Wakefield. (Where’s Wakefield you might well ask – I had to – it’s near Leeds in Yorshire.)

As quick as a flash, he had written a script and extracted an accurate route for the railway. Not only that, but Jon added overhead power support pylons all along the route. That was a bit of a challenge, because originally we had thought that the train could be fairly loosely guided between waypoints on the track, but now would have to run on the track accurately enough to go between them. So I had to add a cross-track error calculation, and after a bit of fine tuning:

The accurate track Jon extracts has a bit of a drawback: it isn’t the same as the one currently in the scenery. We hope that will be sorted out soon, when a few licensing issues are resolved.

Meanwhile, Jon added a nice bus and a bus route also near Wakefield.
It turned out that diesel and electric trains weren’t nearly as visible as we had thought. So why not a steam train? That should be easier to see, and there is a preserved railway up in the spectacular countryside of the North Yorkshire Moor which has just such a thing.

Next, Heiko Schulz produced a fine model of the ICE 3 train, and Jon extracted the route from Frankfurt to Essen, but with the addition that it was dual route so that we could run trains in both directions at the same time. The ICE 3 runs at high speed, but the existing train parameters has been optimised for 30 mph, so a bit more coding was needed. In particular the train does not run well at high speed in reverse, so it was necessary to have the trains reset to the start of the track at the end of their hour plus run.

All this is nice eye-candy, but what is the downside? There is a frame rate cost. Provided there are no more than 10 ground vehicles in the scenario this is usually small.

====Boats====
[[File:vinson.png|thumb|Vinson Carrier Group]]

So what about boats? It seemed like a good idea at the time to extend some of the ideas we developed for trains into the [[Carrier over MP|MP Carrier]] scenario. We had some models converted from Savage models lying around, so how about some escorts for USS Vinson. In any case Alexis Bory had a dormant plan for some low-poly aircraft models for the deck park, so it was a good time to revisit the Vinson scenario. First, we added some aircraft to the deck park. Then Alexis took and completely reworked the Oliver Hazard Perry (FFG 7) into something very nice indeed. I worked up a new class: AI Escort. This enables stationing of an escort by range and relative or true bearing. The escort can have patrol range for the station, and can carry out a random patrol of the assigned station.

Then I found a very good model of the AIM9L Sidewinder which has been lying around in cvs for years. Too good: it includes the motor and warhead, and the unseen bolts which attach the fins. Too good to waste though, so after a bit of poly reduction, they got added as well.

Next Alexis wanted a SAR helo which completes the Trains and Boats and Planes theme. So I modified the AI Escort Class (after all a helo is just a fast frigate), and between us we put together a model of the Seahawk H60B. This happily maintains a station half a mile on USS Vinson’s port side.

So, what else? There is also a close escort in the shape of a Ticonderoga class CG. This model isn’t particularly good, so I am working up a new one.

The current Battlegroup is completed by LPD17.

We also added a cruise liner, just to make the Captain of the MP Carrier think about where he was taking his Battlegroup.

What is the downside to the Vinson Battlegroup? Pretty much none. So far, on my system, I have seen no adverse effect on frame rate. Your mileage may vary of course.

Hmm, the Mk41 Launchers are fully featured with cells and hatches. I have a simple model of a TLAM. I wonder if a modification to the AI Ground Vehicle stuff …

====What next?====
[[File:Container-port-dusk.jpg|thumb|Container Port at dusk]]

What else, where next?

We have a few more goodies in the pipeline. Some US railroad models. We await Jon to extract a suitable rail line for that one. We have some wagons waiting in the wings.

And, if I can persuade Jon to use it, a whole container port. Which comes with its own container tractor, which uses the train code to pull trailers around the dockside. Container ports work around the clock, so there’s some floodlighting just to add a little more realism.

====Using the new scenarios====
All this stuff is in cvs right now.

* Trains and Bus: Select Leeds-Bradford (<tt>--airport=EGNM</tt>) airport, scenario <tt>railway_demo</tt>, fly 165 deg until you get to Wakefield. Look around: there is a railway line to the south of the city, and one to the east. The bus runs out to the west. Look carefully - the trains and bus are very hard to pick out.

* Steam Train: Select Topcliffe (<tt>--airport=EGXZ</tt>) airport, <tt>--ai-scenario=steam_train_demo</tt>, fly 082 deg distance 21 nm. Look around: the railway line runs SW from the village of Pickering. You should easily see the steam from the engine.

* ICE3: Select [[Frankfurt am Main Airport|Frankfurt]] (<tt>--airport=EDDF</tt>) airport, <tt>--ai-scenario=ICE3_demo</tt>, hang about a bit, The ICE3 runs close to the main terminal, and is relatively easy to spot.

* Vinson Battlegroup: Just use <tt>--ai-scenario=vinson_demo</tt>, the various ships are all around. If you use MPCarrier, then the Battlegroup is visible on the radar.

====And finally finally====
Thanks are due to Jon Stockill, Heiko Schulz and Alexis Bory for their contribution, and for their testing of the code.

Enjoy

Vivian Meazza

==In the hangar==

===Airbus A340-600===
[[Image:virgin2.jpg|thumb|170px|A340-600]]
{{main article|Airbus A340-600}}

The [[Airbus A340-600]] is the longest civil [[:Category:Airliners|airliner]] in the world, built by [[:Category:Airbus|Airbus Industries]] of France. It has just started early development by Liam. Currently it has been modelled, mapped, given a basic [[YASim]] [[FDM]], has an autostart feature and [[Livery over MP|livery selection dialog]], and lots of other features. Yet it is to be animated suitably before a BETA release is confirmed, which will be before Christmas, to help provide feedback for improvements. For more information on this recent but rapidly improving project, click here to access the [[A340-600]] page, where you can access more information on this promising looking airliner.

===Boeing 767-300===
[[Image:767-300_Thompson.png|thumb|170px|767-300]]
{{main article|Boeing 767-300}}

The boeing 767-300 is still under development by Liam and Prestes, and is currently undergoing animation by asdf. The airliner is starting to look brilliant thanks to the original model by veteran modeler from the [http://sketchup.google.com/3dwarehouse Google 3DWarehouse], WilliamT, and with its new default livery by Liam (Thomsonfly.com), it certainly is starting to look beautiful. Since this screenshot was taken, there have been many significant improvements still. Prestes also wants to create the whole 767 family from this model (767-200/ER 767-300/ER 767-400/ER 767F) These will be mostly based around the original 767-300 model, by editing the specifications and detail of the planes to give them the correct FDM and accuracy, shape and length. The freight version will be modelled by removing the cut windows and modifying other specifications for the plane. Animation should be fairly replicate for all of the models and creating the whole group should be a fairly rewarding project. As always, help is welcome from all who are interested- but it is certainly well gaining progress.

===Boeing 737-300 news===
{{main article|Boeing 737-300}}

The development of the 3D-cockpit has started and the first half of the mainpanel was added to CVS already. The progress is quite visible, as can be seen on [http://fgfs.i-net.hu/modules/xcgal/albums/userpics/10046/fgfs-screen-307.jpeg this screenshot].
The mainpanel will be finished in the next days, so the Overheadpanel and the Centerstand can follow.
Also the [[FDM]] was changed a bit, so it matches much more to the real perfomance datas like Vr, B2 Vref etc. It needs still work, as the pointmasses will be corrected soon to match the real locations based on free available real balance and weight sheets. Also the behavior of the speedbrakes and flightspoiler will be changed in the next days, so it comes more and more to the real behavior.
Help on programmming is always welcome, especially on the flightdirector, as this has be written completly new!

===Cessna C172p news===
{{main article|Cessna C172}}

The C172p is the default aircraft in FGFS. Though the aircraft was updated last year for the 1.9.1 release, there was still a lot of things left to do.
Thanks to Dave Perry, the aircraft has now the right position in the air and on ground, and the instruments are now lit. Stuart has added some new tutorials, and improved some of the control models in the cockpit.

That's teamwork, that's FlightGear!

==Scenery Corner==

===Airport Layouts in the Scenery Database===
As many readers will know, Martin Spott and Ralf Gerlich maintain the [http://www.custom-scenery.org/ World Custom Scenery Project], which generates the FlightGear scenery. However, the airport layout information (in apt.dat) was shared with X-Plane and maintained separately by Robin Peel. X-Plane has now moved to a new format that FG cannot currently use, and Robin is no-longer accepting layout updates in the old format (as supported by [[TaxiDraw]]). This makes including updated runway layouts in our scenery difficult.

To resolve this, Martin is now including airport layouts as part of the custom scenery. This is great news, as many of the smaller airports around the world do not have accurate taxiways, and updating the layout using [[TaxiDraw]] is straightforward.

If you have an updated layout to submit, please contact Martin Spott via the Forums or email. Note that the same restrictions on only using GPL-compatible data to generate the layouts applies - so tracing the layout on Google Earth/Maps isn't allowed.

===Dutch airports===
[[Image:EHAM_taxiways.jpg|thumb|270px|Updated taxiways at [[Amsterdam Airport Schiphol|Schiphol]].]]Gijs de Rooy has redrawn the airport layouts for some of the Netherlands' most prominent [[:Category:Airports|airports]], including [[Amsterdam Airport Schiphol]] (EHAM), [[Lelystad Airport]] (EHLE) and [[Volkel Air Base]] (EHVK). Taxiways and tarmacs are now correctly placed and up to date. A significant improvement over the previous airport layout is the use of shoulders (concrete borders around taxiways), just as you would encounter at the real airports. The groundnetworks for these airports have been updated or created as well.

Spending a couple of hours placing the taxiways and [[Interactive Traffic|AI routes]] in [[TaxiDraw]], Gijs was able to turn some gaunted airports into a living world!

==Community News==

===FSweekend===
This month we've presented FlightGear at the annual [[FSweekend]] meeting held in the Aviodrome museum at [[Lelystad Airport]], the Netherlands. This year, we (Durk Talsma, Martin Spott, Torsten Dreyer, Gijs de Rooy and Jorg van der Venne) presented FlightGear there for the fourth time, and on every occasion our presentation is getting bigger and bigger. This year we managed to bring five separate demo stations. Four of these were configured to drive three monitors each, and the fifth one was a FlightGear [[Howto: Build your own procedure trainer|procedure trainer]]. In addition, we had access to a wireless modem, and a projector. During the event, a multiplayer event was organized at [[Amsterdam Airport Schiphol|EHAM]], in which a number of booth members participated. Looking back, it seems quite unreal that we managed to bring five individual computers, more than 15 TFT monitors, yokes, joysticks, dozens of cables, several USB hubs, a projector, network switches, a UMTS router, several notebook computers and a coffee maker, hook it all up and have a working multiplayer enabled FlightGear network running.

Some pictures of the event can be found here[http://www.xs4all.nl/~dtalsma/FSWeekend/web/index.html], or alternatively check out [http://www.youtube.com/watch?v=HCTo4Pfi1Mo&feature=related] for a brief video impression.

===Multiplayer servers===
[[File:Mp number flights per week.jpg|thumb|270px]]
{{main article|Howto: Multiplayer}}

Lately the number of [[Howto: Set up a multiplayer server|multiplayer servers]] has seen a large increase. This is a good thing, as these new servers could share the workload with the "old" ones, resulting in faster multiplay. To make optimal use of this, it is neccesary however that everyone connects to the (geographically) closest located server and/or the one with the lowest latency (ping time) or the one that is the least busy. We will all benefit from doing this.

A complete list of the available servers and their location can be found in the [[Howto: Multiplayer|multiplayer howto]].

Together with the growth of the number of multiplayer servers the number of users rose. Some data:

{| class="prettytable" border="1px" cellspacing="0" cellpadding="2"
!
!2007-01-01 2007-01-06
!2009-10-25 2009-11-01
|-
|'''Number of flights'''
|2496
|22164
|-
|'''Number of pilots'''
|184
|1046
|-
|'''Flight time'''
|20 days 05:36:2
|160 days 15:30:11
|}

Data for each week can be found at http://pigeond.net/flightgear/mpstat/htmls/

===Virtual Airline News===

==Addons==

==Useful links==

==And finally....==

===UK Flight Experience Bursaries===
The [http://www.royalaeroclubtrust.org/ Royal Aero Club Trust] is a UK charity that, amongst other things, provides annual bursaries for flight simulator enthusiasts to gain their first experience of real flying. The bursaries are open to UK residents aged 16 to 21. This is a really great opportunity to try flying for real (and for free). Details can be found [http://www.royalaeroclubtrust.org/bursaries.html here], and the closing date is 31st March 2010.

[[Category:FlightGear Newsletter|2009 11]]