FlightGear wiki - User contributions [en]

FGPanel

2018-05-21T04:21:08Z

ThorstenB: /* FGPanel Live System */

[[File:FGPanel_SenecaII.png|thumb|300px|The 2D panel of a [[SenecaII]].]]
'''FGPanel''' is designed as a standalone lightweight panel rendering engine to draw 2D panels on a low-cost computer/graphic card without 3D acceleration at reasonable frame rates.

FGPanel was not part of the FlightGear 2.4.0 release for Windows. Windows users can get the executable from [http://flightgear.simpits.org:8080/job/FlightGear-Win-Cmake/lastSuccessfulBuild/artifact/install/msvc100/FlightGear/bin/fgpanel.exe Jenkins].

== FGPanel on Linux ==
[[File:C172MiniCockpit1.jpg|thumb|200px|right|A complete display setup for the [[Cessna C172P]] using FGPanel.]]
FGPanel was available as a ''OpenSUSE Live System'', a complete, stand-alone software setup, including OpenSUSE Linux operating system and all necessary start-up scripts. Unfortunately the SuseStudio service was shut down in 2018, so the ISO images are no longer available for download.

FGPanel is still part of OpenSUSE's standard FlightGear packages though. So, to run fgpanel on a separate PC, you can simply install openSUSE and download the FlightGear package from the OpenSUSE repository. See the {{flightgear source|utils/fgpanel/README|text=README}} for more.

== FGPanel on Raspberry Pi ==

FGPanel has been ported to run on a Raspberry Pi. All what you need is:
* a Raspberry Pi;
* a network to connect the Raspberry Pi with an instance of FlightGear Simulator;
* Raspbian installed on the Raspberry Pi;
* follow the procedure described in <tt>utils/fgpanel/README.RPi</tt> to build FGPanel.

This FGPanel on Raspberry Pi makes it easy and cheap to build a panel for your own procedure trainer.

== Related content ==
* [[ Howto: Build your own procedure trainer]], describes how you can create a "cheap" procedure trainer, making use of FGPanel to draw the instruments.

== External link ==
* {{flightgear source|utils/fgpanel|text=Source}}
* {{flightgear source|utils/fgpanel/README|text=README}}
* {{flightgear source|utils/fgpanel/README.RPi|text=README.RPi}}

[[Category: Software]]
[[Category:Cockpit building]]

FlightGear Newsletter January 2018

2018-01-28T18:27:42Z

ThorstenB:

{{Newsletter-header|January 2018}}
{{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) is welcome to contribute to the newsletter. 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 ==



=== Docker-based scenery toolchain ===

Torsten has recently been working on preparing and running Docker-containers for the scenery toolchain. The jenkins server responsible for maintaining the terrasync data at https://scenery.flightgear.org/jenkins/ already does some tasks within containers.

The jenkins instance itself will move into a container soon. Torsten also created a Docker image for terragear to make its usage a lot easier. The short term goal is to get all the tools required to run the scenemodels database with its web frontend, the terrasync upstream data maintenance into containers, hoping to be able to run this entire chain at any public or private cloud.

A mid term goal might be to have terragear running from Jenkins on automatically-provisioned virtual machines whenever a new scenery set needs to be rebuilt. There is still a lot to do before this becomes reality and a docker swarm or kubernetes cluster generates scenery for us regulary.

As all journeys starts with the first step, Torsten is happy to announce the public docker repository for our images and the git repository for the config files behind:

* Our official docker hub repository is at: https://hub.docker.com/u/flightgear/
* The backing Dockerfiles live at: https://sourceforge.net/p/flightgear/docker/

Anybody interested in driving this forward, willing to learn or contribute is more than welcome to do so. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36206523/
|title = <nowiki> [Flightgear-devel] Making containers fly: FlightGear scenery goes
docker </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 27th, 2018
|added = Jan 27th, 2018
|script_version = 0.36
}}</ref>

=== Oscilloscope Addon ===
[[File:Rleibner-canvas-vsd-12-2017.png|thumb|rleibner is developing a graph class that works using local (customized) coordinates and calls the plot2D helpers (see below).For testing (and as exercise) he came up with a VSD (Vertical Situation Display): <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=33457#p324637</ref>]]
rleibner is developing a graph class that works using local (customized) coordinates and calls the plot2D helpers (see below).
For testing (and as exercise) he came up with a VSD (Vertical Situation Display): <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=33457#p324637</ref>
[[File:Oscilloscope.png|thumb|rleibner's new Oscilloscope addon is working.This screenshot shows the usual c172p "magnetos checking" Channel 1 (yellow) is '''rpm''' (100 rpm / div).Channel 2 (mauve) is '''magnetos''' (1 / div).Time sweep is 200 ms / div.The idea is to share it as an addon. Mainly to have some feedback about plot2D/graph.<ref>{{cite web |url = https://forum.flightgear.org/viewtopic.php?p=325929#p325929 |title = <nowiki> Re: Plot2D and graph helpers </nowiki> |author = <nowiki> rleibner </nowiki> |date = Jan 6th, 2018 |added = Jan 6th, 2018 |script_version = 0.36 }}</ref>]]

=== Aircraft Dialogs ===
Some of you may already know that the current tool to generate the dialogs ([[PUI]]) is going to disappear in the mid-future. After some (partially controversial) discussion, there seems now to be some support for the idea that canvas is a good tool to generate aircraft-specific dialogs in the future (as it allows to tailor the dialog closely to the plane and also, canvas being canvas, the UI can smoothly mesh with the 3d models, so you can project a canvas checklist onto a 3d model in sim for instance rather than a popup window).

Thorsten would very much like to claim to be pioneering this approach, but in fact he believes the [[Extra EA-500|Extra-500 team]] is - look at the [[Extra_EA-500/failure_dialog|failure dialog of that plane]] where you can click the components you want to fail and you see what he means!

[[File:Extra500-Failuredialog-deice.png|right|thumb|500px|Extra 500 - failure dialog - de-ice]]

Anyway, Thorsten has started to roll out a few designs of his own and try to keep the tools fairly general so that they can be re-used by others- so here's the revised version of the Shuttle propellant dialog.

[[File:Propellant dlg02.jpg|thumb|right|an example of the detail dialog which allows to set levels of fuel and oxidizer separately (and the overview dialog shows the usable propellant then, i.e. the minimum of the two) - for aircraft, this would be somewhat simpler.]]

The general idea is to use semi-transparent 'content gauges' on a background raster image to show where the tank is located and how full it currently is - double-clicking any tank will bring up a detail window which allows to set the content (here propellant and oxidier separately, this is rocket fuel...) and also shows the current tank pressures and temperatures.
The whole thing can readily be applied on top of a different raster image with a different number of tanks - you just instance and position the labels and 'gauges' you need - in fact placement is probably what's going to take longest (at least for me).
The whole thing is currently in flux <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=326789&sid=c15d338facab18fb091aa0530f5dfa0f#p326789
|title = <nowiki> Aircraft-specific dialogs </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Jan 24th, 2018
|added = Jan 24th, 2018
|script_version = 0.36
}}</ref>
If anyone wants to follow the development or use the code, it's here:
https://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tree/Nasal/canvas/canvas_dialogs.nas

=== FG1000 Updates ===
[[File:Fg1000 mfd.jpg|thumb|PUI-canvas FG1000 early prototype using PUI dialog to speed up development]]

Stuart has been doing some further work on the FG1000 implementation over the christmas break 2017. Key changes are:

# Using Richard's [[Emesary]] IPC frame to link between the MFD and underlying simulation state. This should make it easy to run the MFD on a separate FG instance, and provides a good demarkation between the individual aircraft systems and the FG1000 itself.
# Create various underlying classes to support UI features - highlighting, editing. The idea here is that one can create the UI as an SVG file, and these are used to control it. For an example of this in use, see the Airport Information page. Press the CRSR knob to create a cursor on the ICAO airport ID, then use the inside FMS knob to start editing the ID. This should make creating most of the rest of the pages far easier. See [[Canvas MFD Framework]] for details of the elements now supported.

There's still a huge number of pages to write, and the pages around route planning will likely be particular "fun", but it should be far faster now these blocks are in place.

The [[FG1000]] wiki page shows the pages that have been created so far (4 out of 28!). Stuart is pretty happy with the overall architecture now, so if anyone wants to create some of the pages they are very welcome to do so!<ref>{{cite web |url = https://sourceforge.net/p/flightgear/mailman/message/36179339/ |title = <nowiki> Re: [Flightgear-devel] FG1000 Status Update </nowiki> |author = <nowiki> Stuart Buchanan </nowiki> |date = Jan 5th, 2018 |added = Jan 5th, 2018 |script_version = 0.36 }}</ref>

You can access it from the Debug menu. All the buttons and knobs are set up, though some of them don't actually do anything!
See the Garmin website for documentation, but for a quick cheat's guide:

* Use the outer FMS knob (shift-mouse wheel on the FMS knob on the bottom right) to navigate through the page groups.
* Use the inner FMS knob (mouse wheel on the FMS knob on the bottom right) to navigate through the pages within the group.
* To moved around the page, click on the FMS knob, and then use the FMS knob to navigate around the page.
* Press ENT when any frequency is highlighted to load it into the standby frequency of the NAV/COM.

<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=326383&sid=3bf022788187248462943dc0bf1a47ba#p326383
|title = <nowiki> Re: Canvas G1000 </nowiki>
|author = <nowiki> stuart </nowiki>
|date = Jan 14th, 2018
|added = Jan 14th, 2018
|script_version = 0.36
}}</ref>

Learn more at [[FG1000]] ...

=== Airbus GPWS ===
FlightGear now provides better [[GPWS]] support for Airbus aircraft - the unit which triggers voice alerts like "''Pull up!''" and altitude callouts ''...50-40-30-20-10''. The original FlightGear GPWS implementation was made to exactly match all details of a specific real-world hardware unit. The specific unit was never intended to be installed on Airbus aircraft, hence, so far lacked the Airbus-specific warnings and callouts.

Starting with FG2018.1, the FlightGear GPWS unit was extended with optional support for Airbus callouts. The short description of how to enable the Airbus mode is: set the "category-4" configuation value in the "mk-viii" section of the aircraft's "...-set.xml" file to "1000". The long and detailed description is: read the [[GPWS#Altitude_Callouts|Wiki page]]. :-) You can also improve the realism of the unit by providing more realistic Airbus-style voice samples (.wav files).

'''So, what's different with an Airbus GPWS then?'''

While some callouts may depend on an airline's company policy, there's usually several voice alerts specific to Airbus, which are not to be heard on a Boeing aircraft.

* '''2500'''!: When landing with an Airbus, you'll hear the first GPWS altitude announcement earlier - starting with an early "''2500''" callout when descending below 2500ft.
* '''Hundred above!''': An additional "''Hundred above!''" callout is issued at 100ft above the ''selected decision height''. The decision height is the altitude where the crew needs to make their final decision whether to continue with the approach or whether they need to abort due to bad visibility. The "''Hundred above!''" callout gives an Airbus crew some extra time to make up their minds. Seconds later, the actual decision height is then announced by the "Minimums!" callout - which is also common with Boeing and many other aircraft.
* '''Retard! Retard! Retard!''': Retard? Well, yes. This is the infamous Airbus-specific callout which has caused thousands of teenagers to leave more or less funny comments and questions on YouTube Airbus cockpit videos. The "''Retard!''" callout is triggered, when an Airbus decends below 20-30ft above the runway and the thrust-levers are not yet set to idle. The callouts reminds the crew to "''Retard the thrust-levers '''now'''!''". So, why did Airbus decide to use the word "retard"? Well, since the engineers certainly didn't care about teenage YouTube comments. Instead, they needed to find a word which is short and also uniquely connected to a thrust-lever. Something like "''Pull the thrust-levers all the way back to idle now!''" would have been far to long - and also "''pull''" is already associated with the yoke/stick (remember the "''Pull up! Pull up!''" alert). "Retard" is nice and short - and certainly not connected with any other control input. So, on an Airbus, you simply "''retard the thrust-levers to idle''" just before landing the aircraft...

== New software tools and projects ==
Sidi has updated the iOS version of FGYoke and make it available on AppStore recently.
For details, check [[Yoke_for_FlightGear]]
[[File:Screenshot of FGYoke in AppStore.png|thumbnail|center|Screenshot of FGYoke in AppStore]]



== In the hangar ==












== AI ==

== Scenery corner ==












== Community news ==






=== FlightGear on Facebook ===
Since early December 2010, FlightGear has an [http://www.facebook.com/FlightGear official Facebook page]. If you have a Facebook account please feel free to join the page.

=== FlightGear on Google+ ===
Since November 2011 there is a [https://plus.google.com/+flightgear FlightGear page on Google+]. If you haven't done so already, please add us to your circle and stay up to date on the latest FlightGear news, cool screenshots and release info.

== Multiplayer events ==









== Contributing ==

=== Translators needed ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====


''Thanks for reading {{PAGENAME}}!''

[[Category:FlightGear Newsletter|2018 01]]
[[Category:Changes after 2017.3]]
[[de:FlightGear Newsletter Januar 2018]]

Ground proximity warning system

2018-01-28T17:42:40Z

ThorstenB: add Airbus hint

'''Ground Proximity Warning System''' ('''GPWS''') is a system designed to alert pilots if their [[aircraft]] is in immediate danger of flying into the ground or an obstacle. Another common name for such a system is '''Ground-Collision Warning System''' ('''GCWS''').
More advanced systems, providing additional protection based on GPS position and a terrain database, are known as '''Enhanced Ground Proximity Warning Systems''' ('''EGPWS''').

The EGPWS provided by FlightGear emulates the '''MK VIII''' made by Honeywell Inc.
It provides all inputs and outputs of the original hardware.
Also the configuration categories and their encodings are modeled to match the original equipment.

Since FG2018.1 the simulation was extended with optional support for Airbus-specific callouts, which would normally not be supported by the real-world MK VIII hardware unit (which is not intended to be installed on Airbus aircraft).

= Features =
== Warnings ==
The module provides warnings for different alerting modes:

* '''Mode 1: Excessive Descent Rate'''
: Provides 'Sink rate!' and 'Pull up!' alerts based on descent rate at low radio altitudes (below 2500').

* '''Mode 2: Excessive Terrain Closure Rate'''
: Provides 'Pull up!' and 'Terrain!' callouts around rising terrain.

* '''Mode 3: Altitude Loss After Takeoff'''
: Provides alerts against altitude loss after takeoff (or a go-around). Losing altitude triggers a 'Don't sink!' alert.

* '''Mode 4: Unsafe Terrain Clearance'''
: Provides alerts against insufficient clearance, based upon the aircraft configuration and flight phase (takeoff, cruise, approach), and independent of terrain closure rate (i.e situations that modes 1 & 2 would not alert). Alerts include 'Too low - terrain!', 'Too low - gear!' and 'Too low - flaps!'. Also protects against a gear-up landing or approach without flaps in the landing configuration.

* '''Mode 5: Excessive Deviation Below Glideslope'''
: Provides 'Glideslope!' alerts when deviating below a glideslope while established on a localizer.

* '''Mode 6: Advisory Callouts'''
: Provides callouts based on the specified decision-height and radio altitude. This includes a 'Minimums' alert based upon the decision-height, and callouts while descending through various radio altitudes (1000', 500', 200', 100', 50', 40', 30', 20' and 10'). Also provides a 'Bank angle' alert based upon excessive aircraft roll.

* '''Mode 7: Windshear Protection'''
: Windshear protection is currently ''not'' implemented.

== Other ==

* '''Self-test'''
: Triggers all warnings enabled for the specific plane one by one.

* '''Status display'''
: Shows module configuration and status.

= Add to an Aircraft =
== Instrument List ==
Add the device to your plane by adding it to the sim/instrumentation section (usually in a separate instrumentation.xml file).

Example:
<PropertyList>
<sim>
<instrumentation>

'''<mk-viii>'''
'''<name>mk-viii</name>'''
'''<number>0</number>'''
'''</mk-viii>'''

</instrumentation>
</sim>
</PropertyList>
Usually planes only have a single GPWS installed - so using multiple instances wouldn't be too common.

== <Plane>-set.xml file ==
Configuration parameters are stored in a different section.
Add the following XML template to the instrumentation section of the plane's ...-set.xml file.
Do not mix up this section with the one above (section above was ''within'' the <sim> tag, this section is ''outside'' the <sim> tag).

'''Notes''':
* The values in the <tt><configuration-module></tt> section (below) list the module's default. You can omit specific <tt><category-''n''></tt> lines unless you need to change the default.
* All configuration categories require valid settings. If you do explicitly configure a category to change the default, you must provide a valid value. See sections below for valid options.
* Do ''not'' omit the <serviceable>true</serviceable> part...

=== XML Template ===
<PropertyList>
<nowiki></nowiki>

<instrumentation>
<mk-viii> <nowiki></nowiki>

<serviceable>true</serviceable> <nowiki></nowiki>

<configuration-module>
<category-1> 0 </category-1> <nowiki></nowiki>
<category-3> 2 </category-3> <nowiki></nowiki>
<category-4> 13 </category-4> <nowiki></nowiki>
<category-5> 0 </category-5> <nowiki></nowiki>
<category-6> 1 </category-6> <nowiki></nowiki>
<category-7> 124 </category-7> <nowiki></nowiki>
<category-8> 2 </category-8> <nowiki></nowiki>
<category-9> 3 </category-9> <nowiki></nowiki>
<category-10> 6 </category-10> <nowiki></nowiki>
<category-13> 7 </category-13> <nowiki></nowiki>
<category-14> 0 </category-14> <nowiki></nowiki>
</configuration-module>

<inputs> <nowiki></nowiki>
<arinc429>
<decision-height-ncd> false </decision-height-ncd>
<decision-height> 200 </decision-height>
</arinc429>
</inputs>

<speaker> <nowiki></nowiki>
<max-dist> 2 </max-dist> <nowiki></nowiki>
<reference-dist> 1 </reference-dist> <nowiki></nowiki>
<volume> 0.4 </volume> <nowiki></nowiki>
</speaker>

<voice>
<file-prefix type="string">Sounds/mk-viii/</file-prefix>
<nowiki></nowiki>
</voice>

</mk-viii>
</instrumentation>

</PropertyList>

The example above provides the decision height as a fixed value. Since this value is an input, you can also provide this value at run-time instead - e.g. depending on whether an ILS or visual approach is flown.

=== Unimplemented Categories ===
Some configuration categories are currently ''not'' implemented. The following elements are therefore omitted in the XML template:
<category-2> 1 </category-2> <nowiki></nowiki>
<category-11> 2 </category-11> <nowiki></nowiki>
<category-12> 0 </category-12> <nowiki></nowiki>
<category-15> 0 </category-15> <nowiki></nowiki>
<category-16> 0 </category-16> <nowiki></nowiki>
<category-17> 0 </category-17> <nowiki></nowiki>

== Electric Power ==
The mk-viii module needs (virtual) electric power. The module also simulates the behavior of the original hardware device when applying over or under voltage - i.e. it withstands short periods of too low or high voltage (within certain limits). Supply a nominal value of 28 volts. Usually you'll provide power via Nasal by connecting the module to the electrical bus simulation. If you're plane doesn't provide such a simulation you can also configure a fixed value (i.e. '''28''') to the following property:
/systems/electrical/outputs/''<name>''[''<num>'']
where ''<name>'' and ''<num>'' match the values you specified in the instrument list, e.g. for ''<name>=mk-viii and ''<num>''=0
/systems/electrical/outputs/mk-viii[0]

= Configuration =
== Hints ==
* Trigger the self-test to check if the EGPWS is enabled and to check which callouts are enabled for this airplane. Set the property <tt>/instrumentation/mk-viii/inputs/discretes/self-test</tt> to <tt>true</tt> to trigger the self-test. Enabling this input for 2 seconds triggers short self-test, enabling it for at least 5 seconds triggers a full self-test. The plane must be on ground and stopped, otherwise the self-test is inhibited.
* You can test EGPWS configuration without restarting FlightGear by modifying the configuration values in the Property Browser manually and then forcing the EGPWS to reload the configuration by toggling the plane's electrical power (OFF-ON).

== Configuration Categories ==
=== Aircraft Mode Select ===
<category-1> 0 </category-1> <nowiki></nowiki>
This is the device's main configuration setting. It selects the envelops for allowed speeds and minimum heights for all EGPWS modes. The envelops are configured by selecting an entire set of configuration values. This simplifies the configuration, however, new airplane types may require to modify the mk-viii sources in order to support an appropriate configuration set.

{|border="1" cellspacing="0" align="center"
!category-1
!Aircraft Type Description
!Type
!Gear down at 500ft
when slower than
!Flaps down at
!Max airspeed
flaps/gear down*
!Min Runway Length
|-
|align="right"|'''(default) 0'''
|Fast turboprop, normal flap deployment
|align="center"|T6
|align="center"|178 knots
|align="center"|170 ft / 150 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|-
|align="right"|1
|Fast turboprop, delayed flap deployment
|align="center"|T8
|align="center"|178 knots
|align="center"|150 ft / 148 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|-
|align="right"|2
|Fast turboprop (old GPWS emulation)
|align="center"|T5
|align="center"|178 knots
|align="center"|200 ft / 148 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|-
|align="right"|3
|Slow turboprop, normal flap deployment
|align="center"|T7
|align="center"|148 knots
|align="center"|170 ft / 120 knots
|align="center"|180 / 200 knots
|align="center"|2000m
|-
|align="right"|4
|Slow turboprop, delayed flap deployment
|align="center"|T9
|align="center"|148 knots
|align="center"|150 ft / 118 knots
|align="center"|180 / 200 knots
|align="center"|2000m
|-
|align="right"|254
|Fast, heavy turbofans (jets), requiring 3500m runways
|align="center"|T1
|align="center"|190 knots
|align="center"|245 ft / 159 knots
|align="center"|250 / 290 knots
|align="center"|3500m
|-
|align="right"|255
|Fast turbofans (jets), requiring 2000m runways
|align="center"|T1
|align="center"|190 knots
|align="center"|200 ft / 159 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|}
* When maximum gear down/flaps down airspeeds are exceeded for at least 60 seconds the EGPWS triggers a fault and assumes the gear down / flaps down inputs to be invalid.

=== Position Input Select ===
<category-3> 2 </category-3> <nowiki></nowiki>
Some warning modes require the plane's GPS position, e.g. in order to find the nearest runway in its internal database to provide correct height callouts.
* 1: GPS data is supplied to the inputs externally (e.g. NASAL script). You need to provide input to
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-altitude</tt>
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-latitude</tt>
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-longitude</tt>
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-vertical-figure-of-merit</tt>
* '''2 (default)''': GPS data uses internal source (enables a hard-wired connection within the simulator)

=== Altitude Callouts ===
<category-4> 13 </category-4> <nowiki></nowiki>
Select a set of callouts for the approach phase.

{|border="1" cellspacing="0" align="center"
!category-4
!Callouts
|-
|align="right"|0
|Minimums, SMART_500, 200, 100, 50, 40, 30, 20, 10. ''"SMART_500" limits the 500ft callout to non-precision approaches (when no glideslope is captured or g/s is at least 2 dots above/below).''
|-
|align="right"|1
|Minimums, SMART_500, 200
|-
|align="right"|2
|Minimums, SMART_500, 100, 50, 40, 30, 20, 10
|-
|align="right"|3
|Minimums, SMART_500
|-
|align="right"|4
|Minimums, 200, 100, 50, 40, 30, 20, 10
|-
|align="right"|5
|Minimums, 200
|-
|align="right"|6
|Minimums, 100, 50, 40, 30, 20, 10
|-
|align="right"|7
|''All call-outs disabled.''
|-
|align="right"|8
|Minimums. ''All altitude callouts disabled.''
|-
|align="right"|9
|Minimums, 500, 200, 100, 50, 40, 30, 20, 10
|-
|align="right"|10
|Minimums, 500, 200
|-
|align="right"|11
|Minimums, 500, 100, 50, 40, 30, 20, 10
|-
|align="right"|12
|Minimums, 500
|-
|align="right"|'''(default) 13'''
|Minimums, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10 ''(This option should match Boeing and most other airliners, except Airbus.)''
|-
|align="right"|14
|Minimums, 100
|-
|align="right"|15
|Minimums, 200, 100
|-
|align="right"|100
|FIELD_500. ''Provides “500” callout at an altitude 500ft above the actual runway altitude.''
|-
|align="right"|101
|FIELD_500_ABOVE. ''Provides “500 above” callout at an altitude 500ft above the actual runway altitude.''
|-
|colspan="2"|''The options below are not available with the original mk-viii hardware unit. They were added for the FlightGear simulation (with FG 2018.1 and newer) to support typical GPWS callouts of Airbus aircraft.''
|-
|align="right"|'''1000'''
|Above_100, Minimums, 2500, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10, Retard ''(This option should match most Airbus aircraft.)''
|-
|align="right"|1001
|Minimums, 2500, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10, Retard
|-
|align="right"|1002
|Minimums, 2500, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10
|-
|align="right"|1010
|Above_100, Minimums, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10, Retard
|-
|align="right"|1011
|Minimums, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10, Retard
|}

The 500ft callout is available in four options:
* "SMART_500" limits the 500ft callout to non-precision approaches (when no glideslope is captured or g/s is at least 2 dots above/below).
* "FIELD_500" configures the 500ft callout to consider the altitude above the actual runway altitude (instead of the current radio altitude).
* "FIELD_500_ABOVE" is like "FIELD_500", but triggers a "500 '''above'''" callout (instead of "500").
* "500" enables the standard callout, i.e. triggers whenever the radio altimeter reports a current altitude of 500ft.

=== Audio Menu Select ===
<category-5> 0 </category-5> <nowiki></nowiki>
Configure retractable or fixed gear aircraft.
* '''0 (default)''': Configured for retractable gear aircraft. „Too low - gear!“ and „Too low - flaps!“ callouts enabled.
* 2: Configured for fixed gear aircraft. „Too low, flaps!“ callout enabled.

=== Terrain Collision Warning ===
<category-6> 1 </category-6> <nowiki></nowiki>
Enable/disable terrain collision warnings.
* '''1 (default)''': Terrain collision warnings enabled.
* 2: Terrain collision warnings disabled.

=== Options Select ===
<category-7> 124 </category-7> <nowiki></nowiki>
Enable/disable bank angle and steep approach warnings and select flap type.
* bit 0: ''not implemented''
* bit 1: flap reversal.
: '''0 = normal logic (default)'''
: 2 = invert logic when detecting extended/retracted flaps
* bit 2: bank angle alert
: 0 = bank angle alert disabled
: '''4 = enabled (default)'''
* bit 3-5: ''not implemented but enabled by default''
* bit 6: steep approach
: 0 = steep approach warning disabled
: '''64 = steep approach warning enabled (default)'''
* bit 7: ''not implemented''

'''Example''': Value 68 (= 64+ 4) enables bank angle, steep approach alert and normal flap logic.

'''Note''': Default is 124. This also enables additional feature bits (which are currently unsupported).

=== Radio Altitude Input Select ===
<category-8> 2 </category-8> <nowiki></nowiki>
Select radio altimeter input source.

* '''2 (default)''': Altitude source is property "/position/altitude-agl-ft". Works for all FDMs - but this is ''not precise enough to drive useful 20ft and 10ft callouts'' (see below).
* 3: Altitude source is "/position/gear-agl-ft". Very precise altitude of gear-above-ground - but only available for planes with YASim FDM (so far).
* 4: Altitude source is "/instrumentation/radar-altimeter/radar-altitude-ft". A radar altimeter instrument must be installed.

'''Hint''': Most simulator altitude properties refer to the plane's center (of gravity) - but not to the altitude of the main gear. A radar altimeter on a real plane is always calibrated to the gear, hence provides precise information (yes, only within a certain degree of the angle of attack...).
Without a precise altitude source the final callouts before touch down, especially 20ft and 10ft, make no sense or may not even work - very annoying, since most aircraft require a final nose up flare at about 20ft. So precise callouts are very welcome.
Using a radar altimeter instrument is recommended since this is most realistic - and it can (and should) be calibrated to the main gear. See ...(TODO)... for a configuration example.

'''Note''': This configuration category is supported beginning with FlightGear 2.2.

=== Navigation Input Select ===
<category-9> 3 </category-9> <nowiki></nowiki>
Enable/disable glideslope warnings.
* 0: localizer input disabled (disables glideslope warnings)
* '''3 (default)''': localizer input enabled (enables glideslope warning)
: '''Note''': By default, the module is hard-wired to the NAV0 receiver for glideslope warnings, i.e. in order to use the NAV1 receiver you need to update the inputs externally through nasal, etc (see [[#Module I/O|Module I/O]]).

=== Attitude Input Select ===
<category-10> 6 </category-10> <nowiki></nowiki>
Select attitude input source.

'''Note''': This configuration category is implemented for the latest FlightGear version only (GIT sources as of ''''2010-07-30'''' or newer).
* 2: Read data from attitude instrument (requires vacuum system to work).
* '''6 (default)''': Read data from hard-wired connection within simulator.

=== Input and Output Configuration ===
<category-13> 7 </category-13> <nowiki></nowiki>
This configuration value configures the behavior of the module's outputs, usually connected to warning lamps in the cockpit, and enables inputs, which should be connected to cockpit switches.

{|border="1" cellspacing="0" align="center"
!
|colspan="2"|'''Output Lamp Configuration'''
|colspan="3"|'''Input Switch Configuration'''
When enabled, appropriate inputs are supplied to the module
(e.g. inputs should be connected to cockpit switches).
|-
!category-13
!Output
Format *
!Lamp
Flashing **
!GPWS Inhibit
Switch Enabled
!Momentary Flap
Override Switch Enabled
!Alternate Steep
Approach Switch Enabled
|-
|align="right"|0
|align="center"|warning
|align="center"|steady
|
|align="center"|x
|align="center"|x
|-
|align="right"|1
|align="center"|alert
|align="center"|steady
|
|align="center"|x
|align="center"|x
|-
|align="right"|2
|align="center"|warning
|align="center"|steady
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|3
|align="center"|alert
|align="center"|steady
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|4
|align="center"|warning
|align="center"|flashing
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|5
|align="center"|alert
|align="center"|flashing
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|6
|align="center"|warning
|align="center"|steady
|align="center"|x
|align="center"|x
|
|-
|align="right"|'''(default) 7'''
|align="center"|alert
|align="center"|steady
|align="center"|x
|align="center"|x
|
|-
|align="right"|254
|align="center"|warning
|align="center"|steady
|align="center"|x
|
|align="center"|x
|-
|align="right"|255
|align="center"|warning
|align="center"|steady
|align="center"|x
|
|align="center"|x
|}

* '''Output Format''': 'alert': caution conditions trigger the alert output lamp, otherwise caution conditions triggers warning output.

** '''Lamp Flashing''': Selects whether output lamps should flash or be lit steadily when warning/alert/caution is triggered.

=== Audio Output Level ===
<category-14> 0 </category-14> <nowiki></nowiki>
Basic audio configuration.

{|border="1" cellspacing="0"
!category-14
!Audio Relative
Volume
|-
|align="right"|'''(default) 0'''
|align="right"|0 dB
|-
|align="right"|1
|align="right"| -6 dB
|-
|align="right"|2
|align="right"| -12 dB
|-
|align="right"|3
|align="right"| -18 dB
|-
|align="right"|4
|align="right"| -24 dB
|}

== Speaker Configuration ==
The audio speaker can be configured by modifying the properties beneath <tt>/instrumentation/mk-viii/speaker</tt>.
These properties match the xmlsound properties.

For additional information, check out <tt>[[$FG_ROOT]]/Docs/README.xmlsound</tt>.

== Voice Configuration ==
The GPWS uses a fixed default voice. The voice can be changed by providing custom voice samples and providing a different path and filename prefix.

<voice>
<file-prefix type="string">Sounds/mk-viii/</file-prefix>
<nowiki></nowiki>
</voice>

'''Note:'''
* The voice configuration option is supported by FlightGear '''2.3.0''' and newer.

= Advanced =
This section lists some advanced configuration and integration options.

== Example ==
You may want to check the FG implementation of the [[Boeing 777-200]] aircraft for an extensive example of GPWS integration. This plane provides a Nasal GPWS wrapper for the mk-viii module and implements all standard (Boeing) buttons and displays, i.e.:
* Self-test push button
* Glide-slope warning disable button (e.g. to silence warnings during a visual approach)
* Flap and gear override buttons (e.g. to silence flap/gear warnings in emergency situations, like stuck gear etc).
* Terrain/GPWS disable buttons
* GPWS connection to master-warning light.
* GPWS connection to PFD (to display "PULL UP").

== Module I/O ==
* The inputs and outputs match those of the real device and are made available through the FlightGear property tree.
* Input monitoring is implemented. The loss of inputs required for a particular function is annunciated through the GPWS INOP and/or TERR FAIL lamps.
* The "Present Status" function, which enumerates current faults and lists other device details, is implemented.
* Connect outputs to cockpit instruments, e.g. the EGPWS alert and glideslope outputs to the appropriate warning lamps.
* Connect the <tt>/instrumentation/mk-viii/inputs/discretes/self-test</tt> property to the GPWS self-test button in your cockpit. Testing GPWS operation may be part of the preflight check-list.
* To assist the aircraft designer with the installation of the EGPWS, most inputs are connected to standard FlightGear properties by default. When an input feeder (<tt>...-ncd</tt> property) is set to true, the input it is associated with is automatically updated, using a standard FlightGear property. When the <tt>...-ncd</tt> property it is set to false, its associated input must be manually updated every frame, using a Nasal script or some other mechanism.
* The aircraft's decision height needs to be configured when the 'Minimums' warning is enabled. You can provide the decision height as fixed input value to <tt>/instruments/mk-viii/inputs/arinc429/decision-height</tt>:
<arinc429>
<decision-height-ncd> false </decision-height-ncd>
<decision-height> 200 </decision-height>
</arinc429>

== Module Status ==
The original MK VIII supports an RS232 interface to read the module status. Since FlightGear does not support RS232 interfaces, all data is printed to the standard output. Trigger <tt>/instrumentation/mk-viii/inputs/discretes/rs-232/present-status</tt> to print the current module configuration and status:

EGPWC CONFIGURATION
PART NUMBER: 965-1220-000
MOD STATUS: N/A
SERIAL NUMBER: N/A

APPLICATION S/W VERSION: 2.0.0
TERRAIN DATABASE VERSION: 2.0.0
ENVELOPE MOD DATABASE VERSION: N/A
BOOT CODE VERSION: 2.0.0

CURRENT FAULTS
NO FAULTS

CONFIGURATION:
AIRCRAFT TYPE = 0
AIR DATA TYPE = 1
POSITION INPUT TYPE = 2
CALLOUTS OPTION TYPE = 13
AUDIO MENU TYPE = 0
TERRAIN DISPLAY TYPE = 1
OPTIONS 1 TYPE = 124
RADIO ALTITUDE TYPE = 2
NAVIGATION INPUT TYPE = 3
ATTITUDE TYPE = 6
MAGNETIC HEADING TYPE = 2
WINDSHEAR INPUT TYPE = 0
IO DISCRETE TYPE = 7
VOLUME SELECT = 0

= External Links =
* Documentation by the original module developer [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01902.html 1] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01902/mk-viii-manual.tgz 2]
* Original manufacturer documentation
** [http://www.egpws.com/engineering_support/documents/install/060-4314-150.pdf Honeywell Inc., "MK VI, MK VIII, Enhanced Ground Proximity Warning System (Class A TAWS), Installation Design Guide", July 2003]
** [http://www51.honeywell.com/sites/aero/common/documents/Mk_VI_VIII_EGPWS.pdf Honeywell Inc., "MK VI and MK VIII Enhanced Ground Proximity Warning System Pilot's Guide", February 2002]

[[Category:Aircraft enhancement]]

Ground proximity warning system

2018-01-28T15:59:14Z

ThorstenB: /* Altitude Callouts */ add description of new configuration modes

'''Ground Proximity Warning System''' ('''GPWS''') is a system designed to alert pilots if their [[aircraft]] is in immediate danger of flying into the ground or an obstacle. Another common name for such a system is '''Ground-Collision Warning System''' ('''GCWS''').
More advanced systems, providing additional protection, are known as '''Enhanced Ground Proximity Warning Systems''' ('''EGPWS''').

The EGPWS provided by FlightGear emulates the '''MK VIII''' made by Honeywell Inc.
It provides all inputs and outputs of the original hardware.
Also the configuration categories and their encodings are modeled to match the original equipment.

= Features =
== Warnings ==
The module provides warnings for different alerting modes:

* '''Mode 1: Excessive Descent Rate'''
: Provides 'Sink rate!' and 'Pull up!' alerts based on descent rate at low radio altitudes (below 2500').

* '''Mode 2: Excessive Terrain Closure Rate'''
: Provides 'Pull up!' and 'Terrain!' callouts around rising terrain.

* '''Mode 3: Altitude Loss After Takeoff'''
: Provides alerts against altitude loss after takeoff (or a go-around). Losing altitude triggers a 'Don't sink!' alert.

* '''Mode 4: Unsafe Terrain Clearance'''
: Provides alerts against insufficient clearance, based upon the aircraft configuration and flight phase (takeoff, cruise, approach), and independent of terrain closure rate (i.e situations that modes 1 & 2 would not alert). Alerts include 'Too low - terrain!', 'Too low - gear!' and 'Too low - flaps!'. Also protects against a gear-up landing or approach without flaps in the landing configuration.

* '''Mode 5: Excessive Deviation Below Glideslope'''
: Provides 'Glideslope!' alerts when deviating below a glideslope while established on a localizer.

* '''Mode 6: Advisory Callouts'''
: Provides callouts based on the specified decision-height and radio altitude. This includes a 'Minimums' alert based upon the decision-height, and callouts while descending through various radio altitudes (1000', 500', 200', 100', 50', 40', 30', 20' and 10'). Also provides a 'Bank angle' alert based upon excessive aircraft roll.

* '''Mode 7: Windshear Protection'''
: Windshear protection is currently ''not'' implemented.

== Other ==

* '''Self-test'''
: Triggers all warnings enabled for the specific plane one by one.

* '''Status display'''
: Shows module configuration and status.

= Add to an Aircraft =
== Instrument List ==
Add the device to your plane by adding it to the sim/instrumentation section (usually in a separate instrumentation.xml file).

Example:
<PropertyList>
<sim>
<instrumentation>

'''<mk-viii>'''
'''<name>mk-viii</name>'''
'''<number>0</number>'''
'''</mk-viii>'''

</instrumentation>
</sim>
</PropertyList>
Usually planes only have a single GPWS installed - so using multiple instances wouldn't be too common.

== <Plane>-set.xml file ==
Configuration parameters are stored in a different section.
Add the following XML template to the instrumentation section of the plane's ...-set.xml file.
Do not mix up this section with the one above (section above was ''within'' the <sim> tag, this section is ''outside'' the <sim> tag).

'''Notes''':
* The values in the <tt><configuration-module></tt> section (below) list the module's default. You can omit specific <tt><category-''n''></tt> lines unless you need to change the default.
* All configuration categories require valid settings. If you do explicitly configure a category to change the default, you must provide a valid value. See sections below for valid options.
* Do ''not'' omit the <serviceable>true</serviceable> part...

=== XML Template ===
<PropertyList>
<nowiki></nowiki>

<instrumentation>
<mk-viii> <nowiki></nowiki>

<serviceable>true</serviceable> <nowiki></nowiki>

<configuration-module>
<category-1> 0 </category-1> <nowiki></nowiki>
<category-3> 2 </category-3> <nowiki></nowiki>
<category-4> 13 </category-4> <nowiki></nowiki>
<category-5> 0 </category-5> <nowiki></nowiki>
<category-6> 1 </category-6> <nowiki></nowiki>
<category-7> 124 </category-7> <nowiki></nowiki>
<category-8> 2 </category-8> <nowiki></nowiki>
<category-9> 3 </category-9> <nowiki></nowiki>
<category-10> 6 </category-10> <nowiki></nowiki>
<category-13> 7 </category-13> <nowiki></nowiki>
<category-14> 0 </category-14> <nowiki></nowiki>
</configuration-module>

<inputs> <nowiki></nowiki>
<arinc429>
<decision-height-ncd> false </decision-height-ncd>
<decision-height> 200 </decision-height>
</arinc429>
</inputs>

<speaker> <nowiki></nowiki>
<max-dist> 2 </max-dist> <nowiki></nowiki>
<reference-dist> 1 </reference-dist> <nowiki></nowiki>
<volume> 0.4 </volume> <nowiki></nowiki>
</speaker>

<voice>
<file-prefix type="string">Sounds/mk-viii/</file-prefix>
<nowiki></nowiki>
</voice>

</mk-viii>
</instrumentation>

</PropertyList>

The example above provides the decision height as a fixed value. Since this value is an input, you can also provide this value at run-time instead - e.g. depending on whether an ILS or visual approach is flown.

=== Unimplemented Categories ===
Some configuration categories are currently ''not'' implemented. The following elements are therefore omitted in the XML template:
<category-2> 1 </category-2> <nowiki></nowiki>
<category-11> 2 </category-11> <nowiki></nowiki>
<category-12> 0 </category-12> <nowiki></nowiki>
<category-15> 0 </category-15> <nowiki></nowiki>
<category-16> 0 </category-16> <nowiki></nowiki>
<category-17> 0 </category-17> <nowiki></nowiki>

== Electric Power ==
The mk-viii module needs (virtual) electric power. The module also simulates the behavior of the original hardware device when applying over or under voltage - i.e. it withstands short periods of too low or high voltage (within certain limits). Supply a nominal value of 28 volts. Usually you'll provide power via Nasal by connecting the module to the electrical bus simulation. If you're plane doesn't provide such a simulation you can also configure a fixed value (i.e. '''28''') to the following property:
/systems/electrical/outputs/''<name>''[''<num>'']
where ''<name>'' and ''<num>'' match the values you specified in the instrument list, e.g. for ''<name>=mk-viii and ''<num>''=0
/systems/electrical/outputs/mk-viii[0]

= Configuration =
== Hints ==
* Trigger the self-test to check if the EGPWS is enabled and to check which callouts are enabled for this airplane. Set the property <tt>/instrumentation/mk-viii/inputs/discretes/self-test</tt> to <tt>true</tt> to trigger the self-test. Enabling this input for 2 seconds triggers short self-test, enabling it for at least 5 seconds triggers a full self-test. The plane must be on ground and stopped, otherwise the self-test is inhibited.
* You can test EGPWS configuration without restarting FlightGear by modifying the configuration values in the Property Browser manually and then forcing the EGPWS to reload the configuration by toggling the plane's electrical power (OFF-ON).

== Configuration Categories ==
=== Aircraft Mode Select ===
<category-1> 0 </category-1> <nowiki></nowiki>
This is the device's main configuration setting. It selects the envelops for allowed speeds and minimum heights for all EGPWS modes. The envelops are configured by selecting an entire set of configuration values. This simplifies the configuration, however, new airplane types may require to modify the mk-viii sources in order to support an appropriate configuration set.

{|border="1" cellspacing="0" align="center"
!category-1
!Aircraft Type Description
!Type
!Gear down at 500ft
when slower than
!Flaps down at
!Max airspeed
flaps/gear down*
!Min Runway Length
|-
|align="right"|'''(default) 0'''
|Fast turboprop, normal flap deployment
|align="center"|T6
|align="center"|178 knots
|align="center"|170 ft / 150 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|-
|align="right"|1
|Fast turboprop, delayed flap deployment
|align="center"|T8
|align="center"|178 knots
|align="center"|150 ft / 148 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|-
|align="right"|2
|Fast turboprop (old GPWS emulation)
|align="center"|T5
|align="center"|178 knots
|align="center"|200 ft / 148 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|-
|align="right"|3
|Slow turboprop, normal flap deployment
|align="center"|T7
|align="center"|148 knots
|align="center"|170 ft / 120 knots
|align="center"|180 / 200 knots
|align="center"|2000m
|-
|align="right"|4
|Slow turboprop, delayed flap deployment
|align="center"|T9
|align="center"|148 knots
|align="center"|150 ft / 118 knots
|align="center"|180 / 200 knots
|align="center"|2000m
|-
|align="right"|254
|Fast, heavy turbofans (jets), requiring 3500m runways
|align="center"|T1
|align="center"|190 knots
|align="center"|245 ft / 159 knots
|align="center"|250 / 290 knots
|align="center"|3500m
|-
|align="right"|255
|Fast turbofans (jets), requiring 2000m runways
|align="center"|T1
|align="center"|190 knots
|align="center"|200 ft / 159 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|}
* When maximum gear down/flaps down airspeeds are exceeded for at least 60 seconds the EGPWS triggers a fault and assumes the gear down / flaps down inputs to be invalid.

=== Position Input Select ===
<category-3> 2 </category-3> <nowiki></nowiki>
Some warning modes require the plane's GPS position, e.g. in order to find the nearest runway in its internal database to provide correct height callouts.
* 1: GPS data is supplied to the inputs externally (e.g. NASAL script). You need to provide input to
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-altitude</tt>
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-latitude</tt>
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-longitude</tt>
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-vertical-figure-of-merit</tt>
* '''2 (default)''': GPS data uses internal source (enables a hard-wired connection within the simulator)

=== Altitude Callouts ===
<category-4> 13 </category-4> <nowiki></nowiki>
Select a set of callouts for the approach phase.

{|border="1" cellspacing="0" align="center"
!category-4
!Callouts
|-
|align="right"|0
|Minimums, SMART_500, 200, 100, 50, 40, 30, 20, 10. ''"SMART_500" limits the 500ft callout to non-precision approaches (when no glideslope is captured or g/s is at least 2 dots above/below).''
|-
|align="right"|1
|Minimums, SMART_500, 200
|-
|align="right"|2
|Minimums, SMART_500, 100, 50, 40, 30, 20, 10
|-
|align="right"|3
|Minimums, SMART_500
|-
|align="right"|4
|Minimums, 200, 100, 50, 40, 30, 20, 10
|-
|align="right"|5
|Minimums, 200
|-
|align="right"|6
|Minimums, 100, 50, 40, 30, 20, 10
|-
|align="right"|7
|''All call-outs disabled.''
|-
|align="right"|8
|Minimums. ''All altitude callouts disabled.''
|-
|align="right"|9
|Minimums, 500, 200, 100, 50, 40, 30, 20, 10
|-
|align="right"|10
|Minimums, 500, 200
|-
|align="right"|11
|Minimums, 500, 100, 50, 40, 30, 20, 10
|-
|align="right"|12
|Minimums, 500
|-
|align="right"|'''(default) 13'''
|Minimums, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10 ''(This option should match Boeing and most other airliners, except Airbus.)''
|-
|align="right"|14
|Minimums, 100
|-
|align="right"|15
|Minimums, 200, 100
|-
|align="right"|100
|FIELD_500. ''Provides “500” callout at an altitude 500ft above the actual runway altitude.''
|-
|align="right"|101
|FIELD_500_ABOVE. ''Provides “500 above” callout at an altitude 500ft above the actual runway altitude.''
|-
|colspan="2"|''The options below are not available with the original mk-viii hardware unit. They were added for the FlightGear simulation (with FG 2018.1 and newer) to support typical GPWS callouts of Airbus aircraft.''
|-
|align="right"|'''1000'''
|Above_100, Minimums, 2500, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10, Retard ''(This option should match most Airbus aircraft.)''
|-
|align="right"|1001
|Minimums, 2500, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10, Retard
|-
|align="right"|1002
|Minimums, 2500, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10
|-
|align="right"|1010
|Above_100, Minimums, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10, Retard
|-
|align="right"|1011
|Minimums, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10, Retard
|}

The 500ft callout is available in four options:
* "SMART_500" limits the 500ft callout to non-precision approaches (when no glideslope is captured or g/s is at least 2 dots above/below).
* "FIELD_500" configures the 500ft callout to consider the altitude above the actual runway altitude (instead of the current radio altitude).
* "FIELD_500_ABOVE" is like "FIELD_500", but triggers a "500 '''above'''" callout (instead of "500").
* "500" enables the standard callout, i.e. triggers whenever the radio altimeter reports a current altitude of 500ft.

=== Audio Menu Select ===
<category-5> 0 </category-5> <nowiki></nowiki>
Configure retractable or fixed gear aircraft.
* '''0 (default)''': Configured for retractable gear aircraft. „Too low - gear!“ and „Too low - flaps!“ callouts enabled.
* 2: Configured for fixed gear aircraft. „Too low, flaps!“ callout enabled.

=== Terrain Collision Warning ===
<category-6> 1 </category-6> <nowiki></nowiki>
Enable/disable terrain collision warnings.
* '''1 (default)''': Terrain collision warnings enabled.
* 2: Terrain collision warnings disabled.

=== Options Select ===
<category-7> 124 </category-7> <nowiki></nowiki>
Enable/disable bank angle and steep approach warnings and select flap type.
* bit 0: ''not implemented''
* bit 1: flap reversal.
: '''0 = normal logic (default)'''
: 2 = invert logic when detecting extended/retracted flaps
* bit 2: bank angle alert
: 0 = bank angle alert disabled
: '''4 = enabled (default)'''
* bit 3-5: ''not implemented but enabled by default''
* bit 6: steep approach
: 0 = steep approach warning disabled
: '''64 = steep approach warning enabled (default)'''
* bit 7: ''not implemented''

'''Example''': Value 68 (= 64+ 4) enables bank angle, steep approach alert and normal flap logic.

'''Note''': Default is 124. This also enables additional feature bits (which are currently unsupported).

=== Radio Altitude Input Select ===
<category-8> 2 </category-8> <nowiki></nowiki>
Select radio altimeter input source.

* '''2 (default)''': Altitude source is property "/position/altitude-agl-ft". Works for all FDMs - but this is ''not precise enough to drive useful 20ft and 10ft callouts'' (see below).
* 3: Altitude source is "/position/gear-agl-ft". Very precise altitude of gear-above-ground - but only available for planes with YASim FDM (so far).
* 4: Altitude source is "/instrumentation/radar-altimeter/radar-altitude-ft". A radar altimeter instrument must be installed.

'''Hint''': Most simulator altitude properties refer to the plane's center (of gravity) - but not to the altitude of the main gear. A radar altimeter on a real plane is always calibrated to the gear, hence provides precise information (yes, only within a certain degree of the angle of attack...).
Without a precise altitude source the final callouts before touch down, especially 20ft and 10ft, make no sense or may not even work - very annoying, since most aircraft require a final nose up flare at about 20ft. So precise callouts are very welcome.
Using a radar altimeter instrument is recommended since this is most realistic - and it can (and should) be calibrated to the main gear. See ...(TODO)... for a configuration example.

'''Note''': This configuration category is supported beginning with FlightGear 2.2.

=== Navigation Input Select ===
<category-9> 3 </category-9> <nowiki></nowiki>
Enable/disable glideslope warnings.
* 0: localizer input disabled (disables glideslope warnings)
* '''3 (default)''': localizer input enabled (enables glideslope warning)
: '''Note''': By default, the module is hard-wired to the NAV0 receiver for glideslope warnings, i.e. in order to use the NAV1 receiver you need to update the inputs externally through nasal, etc (see [[#Module I/O|Module I/O]]).

=== Attitude Input Select ===
<category-10> 6 </category-10> <nowiki></nowiki>
Select attitude input source.

'''Note''': This configuration category is implemented for the latest FlightGear version only (GIT sources as of ''''2010-07-30'''' or newer).
* 2: Read data from attitude instrument (requires vacuum system to work).
* '''6 (default)''': Read data from hard-wired connection within simulator.

=== Input and Output Configuration ===
<category-13> 7 </category-13> <nowiki></nowiki>
This configuration value configures the behavior of the module's outputs, usually connected to warning lamps in the cockpit, and enables inputs, which should be connected to cockpit switches.

{|border="1" cellspacing="0" align="center"
!
|colspan="2"|'''Output Lamp Configuration'''
|colspan="3"|'''Input Switch Configuration'''
When enabled, appropriate inputs are supplied to the module
(e.g. inputs should be connected to cockpit switches).
|-
!category-13
!Output
Format *
!Lamp
Flashing **
!GPWS Inhibit
Switch Enabled
!Momentary Flap
Override Switch Enabled
!Alternate Steep
Approach Switch Enabled
|-
|align="right"|0
|align="center"|warning
|align="center"|steady
|
|align="center"|x
|align="center"|x
|-
|align="right"|1
|align="center"|alert
|align="center"|steady
|
|align="center"|x
|align="center"|x
|-
|align="right"|2
|align="center"|warning
|align="center"|steady
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|3
|align="center"|alert
|align="center"|steady
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|4
|align="center"|warning
|align="center"|flashing
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|5
|align="center"|alert
|align="center"|flashing
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|6
|align="center"|warning
|align="center"|steady
|align="center"|x
|align="center"|x
|
|-
|align="right"|'''(default) 7'''
|align="center"|alert
|align="center"|steady
|align="center"|x
|align="center"|x
|
|-
|align="right"|254
|align="center"|warning
|align="center"|steady
|align="center"|x
|
|align="center"|x
|-
|align="right"|255
|align="center"|warning
|align="center"|steady
|align="center"|x
|
|align="center"|x
|}

* '''Output Format''': 'alert': caution conditions trigger the alert output lamp, otherwise caution conditions triggers warning output.

** '''Lamp Flashing''': Selects whether output lamps should flash or be lit steadily when warning/alert/caution is triggered.

=== Audio Output Level ===
<category-14> 0 </category-14> <nowiki></nowiki>
Basic audio configuration.

{|border="1" cellspacing="0"
!category-14
!Audio Relative
Volume
|-
|align="right"|'''(default) 0'''
|align="right"|0 dB
|-
|align="right"|1
|align="right"| -6 dB
|-
|align="right"|2
|align="right"| -12 dB
|-
|align="right"|3
|align="right"| -18 dB
|-
|align="right"|4
|align="right"| -24 dB
|}

== Speaker Configuration ==
The audio speaker can be configured by modifying the properties beneath <tt>/instrumentation/mk-viii/speaker</tt>.
These properties match the xmlsound properties.

For additional information, check out <tt>[[$FG_ROOT]]/Docs/README.xmlsound</tt>.

== Voice Configuration ==
The GPWS uses a fixed default voice. The voice can be changed by providing custom voice samples and providing a different path and filename prefix.

<voice>
<file-prefix type="string">Sounds/mk-viii/</file-prefix>
<nowiki></nowiki>
</voice>

'''Note:'''
* The voice configuration option is supported by FlightGear '''2.3.0''' and newer.

= Advanced =
This section lists some advanced configuration and integration options.

== Example ==
You may want to check the FG implementation of the [[Boeing 777-200]] aircraft for an extensive example of GPWS integration. This plane provides a Nasal GPWS wrapper for the mk-viii module and implements all standard (Boeing) buttons and displays, i.e.:
* Self-test push button
* Glide-slope warning disable button (e.g. to silence warnings during a visual approach)
* Flap and gear override buttons (e.g. to silence flap/gear warnings in emergency situations, like stuck gear etc).
* Terrain/GPWS disable buttons
* GPWS connection to master-warning light.
* GPWS connection to PFD (to display "PULL UP").

== Module I/O ==
* The inputs and outputs match those of the real device and are made available through the FlightGear property tree.
* Input monitoring is implemented. The loss of inputs required for a particular function is annunciated through the GPWS INOP and/or TERR FAIL lamps.
* The "Present Status" function, which enumerates current faults and lists other device details, is implemented.
* Connect outputs to cockpit instruments, e.g. the EGPWS alert and glideslope outputs to the appropriate warning lamps.
* Connect the <tt>/instrumentation/mk-viii/inputs/discretes/self-test</tt> property to the GPWS self-test button in your cockpit. Testing GPWS operation may be part of the preflight check-list.
* To assist the aircraft designer with the installation of the EGPWS, most inputs are connected to standard FlightGear properties by default. When an input feeder (<tt>...-ncd</tt> property) is set to true, the input it is associated with is automatically updated, using a standard FlightGear property. When the <tt>...-ncd</tt> property it is set to false, its associated input must be manually updated every frame, using a Nasal script or some other mechanism.
* The aircraft's decision height needs to be configured when the 'Minimums' warning is enabled. You can provide the decision height as fixed input value to <tt>/instruments/mk-viii/inputs/arinc429/decision-height</tt>:
<arinc429>
<decision-height-ncd> false </decision-height-ncd>
<decision-height> 200 </decision-height>
</arinc429>

== Module Status ==
The original MK VIII supports an RS232 interface to read the module status. Since FlightGear does not support RS232 interfaces, all data is printed to the standard output. Trigger <tt>/instrumentation/mk-viii/inputs/discretes/rs-232/present-status</tt> to print the current module configuration and status:

EGPWC CONFIGURATION
PART NUMBER: 965-1220-000
MOD STATUS: N/A
SERIAL NUMBER: N/A

APPLICATION S/W VERSION: 2.0.0
TERRAIN DATABASE VERSION: 2.0.0
ENVELOPE MOD DATABASE VERSION: N/A
BOOT CODE VERSION: 2.0.0

CURRENT FAULTS
NO FAULTS

CONFIGURATION:
AIRCRAFT TYPE = 0
AIR DATA TYPE = 1
POSITION INPUT TYPE = 2
CALLOUTS OPTION TYPE = 13
AUDIO MENU TYPE = 0
TERRAIN DISPLAY TYPE = 1
OPTIONS 1 TYPE = 124
RADIO ALTITUDE TYPE = 2
NAVIGATION INPUT TYPE = 3
ATTITUDE TYPE = 6
MAGNETIC HEADING TYPE = 2
WINDSHEAR INPUT TYPE = 0
IO DISCRETE TYPE = 7
VOLUME SELECT = 0

= External Links =
* Documentation by the original module developer [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01902.html 1] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01902/mk-viii-manual.tgz 2]
* Original manufacturer documentation
** [http://www.egpws.com/engineering_support/documents/install/060-4314-150.pdf Honeywell Inc., "MK VI, MK VIII, Enhanced Ground Proximity Warning System (Class A TAWS), Installation Design Guide", July 2003]
** [http://www51.honeywell.com/sites/aero/common/documents/Mk_VI_VIII_EGPWS.pdf Honeywell Inc., "MK VI and MK VIII Enhanced Ground Proximity Warning System Pilot's Guide", February 2002]

[[Category:Aircraft enhancement]]

Ground proximity warning system

2018-01-22T19:05:57Z

ThorstenB: /* Altitude Callouts */ explanation of the FIELD_500 and SMART_500 options

'''Ground Proximity Warning System''' ('''GPWS''') is a system designed to alert pilots if their [[aircraft]] is in immediate danger of flying into the ground or an obstacle. Another common name for such a system is '''Ground-Collision Warning System''' ('''GCWS''').
More advanced systems, providing additional protection, are known as '''Enhanced Ground Proximity Warning Systems''' ('''EGPWS''').

The EGPWS provided by FlightGear emulates the '''MK VIII''' made by Honeywell Inc.
It provides all inputs and outputs of the original hardware.
Also the configuration categories and their encodings are modeled to match the original equipment.

= Features =
== Warnings ==
The module provides warnings for different alerting modes:

* '''Mode 1: Excessive Descent Rate'''
: Provides 'Sink rate!' and 'Pull up!' alerts based on descent rate at low radio altitudes (below 2500').

* '''Mode 2: Excessive Terrain Closure Rate'''
: Provides 'Pull up!' and 'Terrain!' callouts around rising terrain.

* '''Mode 3: Altitude Loss After Takeoff'''
: Provides alerts against altitude loss after takeoff (or a go-around). Losing altitude triggers a 'Don't sink!' alert.

* '''Mode 4: Unsafe Terrain Clearance'''
: Provides alerts against insufficient clearance, based upon the aircraft configuration and flight phase (takeoff, cruise, approach), and independent of terrain closure rate (i.e situations that modes 1 & 2 would not alert). Alerts include 'Too low - terrain!', 'Too low - gear!' and 'Too low - flaps!'. Also protects against a gear-up landing or approach without flaps in the landing configuration.

* '''Mode 5: Excessive Deviation Below Glideslope'''
: Provides 'Glideslope!' alerts when deviating below a glideslope while established on a localizer.

* '''Mode 6: Advisory Callouts'''
: Provides callouts based on the specified decision-height and radio altitude. This includes a 'Minimums' alert based upon the decision-height, and callouts while descending through various radio altitudes (1000', 500', 200', 100', 50', 40', 30', 20' and 10'). Also provides a 'Bank angle' alert based upon excessive aircraft roll.

* '''Mode 7: Windshear Protection'''
: Windshear protection is currently ''not'' implemented.

== Other ==

* '''Self-test'''
: Triggers all warnings enabled for the specific plane one by one.

* '''Status display'''
: Shows module configuration and status.

= Add to an Aircraft =
== Instrument List ==
Add the device to your plane by adding it to the sim/instrumentation section (usually in a separate instrumentation.xml file).

Example:
<PropertyList>
<sim>
<instrumentation>

'''<mk-viii>'''
'''<name>mk-viii</name>'''
'''<number>0</number>'''
'''</mk-viii>'''

</instrumentation>
</sim>
</PropertyList>
Usually planes only have a single GPWS installed - so using multiple instances wouldn't be too common.

== <Plane>-set.xml file ==
Configuration parameters are stored in a different section.
Add the following XML template to the instrumentation section of the plane's ...-set.xml file.
Do not mix up this section with the one above (section above was ''within'' the <sim> tag, this section is ''outside'' the <sim> tag).

'''Notes''':
* The values in the <tt><configuration-module></tt> section (below) list the module's default. You can omit specific <tt><category-''n''></tt> lines unless you need to change the default.
* All configuration categories require valid settings. If you do explicitly configure a category to change the default, you must provide a valid value. See sections below for valid options.
* Do ''not'' omit the <serviceable>true</serviceable> part...

=== XML Template ===
<PropertyList>
<nowiki></nowiki>

<instrumentation>
<mk-viii> <nowiki></nowiki>

<serviceable>true</serviceable> <nowiki></nowiki>

<configuration-module>
<category-1> 0 </category-1> <nowiki></nowiki>
<category-3> 2 </category-3> <nowiki></nowiki>
<category-4> 13 </category-4> <nowiki></nowiki>
<category-5> 0 </category-5> <nowiki></nowiki>
<category-6> 1 </category-6> <nowiki></nowiki>
<category-7> 124 </category-7> <nowiki></nowiki>
<category-8> 2 </category-8> <nowiki></nowiki>
<category-9> 3 </category-9> <nowiki></nowiki>
<category-10> 6 </category-10> <nowiki></nowiki>
<category-13> 7 </category-13> <nowiki></nowiki>
<category-14> 0 </category-14> <nowiki></nowiki>
</configuration-module>

<inputs> <nowiki></nowiki>
<arinc429>
<decision-height-ncd> false </decision-height-ncd>
<decision-height> 200 </decision-height>
</arinc429>
</inputs>

<speaker> <nowiki></nowiki>
<max-dist> 2 </max-dist> <nowiki></nowiki>
<reference-dist> 1 </reference-dist> <nowiki></nowiki>
<volume> 0.4 </volume> <nowiki></nowiki>
</speaker>

<voice>
<file-prefix type="string">Sounds/mk-viii/</file-prefix>
<nowiki></nowiki>
</voice>

</mk-viii>
</instrumentation>

</PropertyList>

The example above provides the decision height as a fixed value. Since this value is an input, you can also provide this value at run-time instead - e.g. depending on whether an ILS or visual approach is flown.

=== Unimplemented Categories ===
Some configuration categories are currently ''not'' implemented. The following elements are therefore omitted in the XML template:
<category-2> 1 </category-2> <nowiki></nowiki>
<category-11> 2 </category-11> <nowiki></nowiki>
<category-12> 0 </category-12> <nowiki></nowiki>
<category-15> 0 </category-15> <nowiki></nowiki>
<category-16> 0 </category-16> <nowiki></nowiki>
<category-17> 0 </category-17> <nowiki></nowiki>

== Electric Power ==
The mk-viii module needs (virtual) electric power. The module also simulates the behavior of the original hardware device when applying over or under voltage - i.e. it withstands short periods of too low or high voltage (within certain limits). Supply a nominal value of 28 volts. Usually you'll provide power via Nasal by connecting the module to the electrical bus simulation. If you're plane doesn't provide such a simulation you can also configure a fixed value (i.e. '''28''') to the following property:
/systems/electrical/outputs/''<name>''[''<num>'']
where ''<name>'' and ''<num>'' match the values you specified in the instrument list, e.g. for ''<name>=mk-viii and ''<num>''=0
/systems/electrical/outputs/mk-viii[0]

= Configuration =
== Hints ==
* Trigger the self-test to check if the EGPWS is enabled and to check which callouts are enabled for this airplane. Set the property <tt>/instrumentation/mk-viii/inputs/discretes/self-test</tt> to <tt>true</tt> to trigger the self-test. Enabling this input for 2 seconds triggers short self-test, enabling it for at least 5 seconds triggers a full self-test. The plane must be on ground and stopped, otherwise the self-test is inhibited.
* You can test EGPWS configuration without restarting FlightGear by modifying the configuration values in the Property Browser manually and then forcing the EGPWS to reload the configuration by toggling the plane's electrical power (OFF-ON).

== Configuration Categories ==
=== Aircraft Mode Select ===
<category-1> 0 </category-1> <nowiki></nowiki>
This is the device's main configuration setting. It selects the envelops for allowed speeds and minimum heights for all EGPWS modes. The envelops are configured by selecting an entire set of configuration values. This simplifies the configuration, however, new airplane types may require to modify the mk-viii sources in order to support an appropriate configuration set.

{|border="1" cellspacing="0" align="center"
!category-1
!Aircraft Type Description
!Type
!Gear down at 500ft
when slower than
!Flaps down at
!Max airspeed
flaps/gear down*
!Min Runway Length
|-
|align="right"|'''(default) 0'''
|Fast turboprop, normal flap deployment
|align="center"|T6
|align="center"|178 knots
|align="center"|170 ft / 150 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|-
|align="right"|1
|Fast turboprop, delayed flap deployment
|align="center"|T8
|align="center"|178 knots
|align="center"|150 ft / 148 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|-
|align="right"|2
|Fast turboprop (old GPWS emulation)
|align="center"|T5
|align="center"|178 knots
|align="center"|200 ft / 148 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|-
|align="right"|3
|Slow turboprop, normal flap deployment
|align="center"|T7
|align="center"|148 knots
|align="center"|170 ft / 120 knots
|align="center"|180 / 200 knots
|align="center"|2000m
|-
|align="right"|4
|Slow turboprop, delayed flap deployment
|align="center"|T9
|align="center"|148 knots
|align="center"|150 ft / 118 knots
|align="center"|180 / 200 knots
|align="center"|2000m
|-
|align="right"|254
|Fast, heavy turbofans (jets), requiring 3500m runways
|align="center"|T1
|align="center"|190 knots
|align="center"|245 ft / 159 knots
|align="center"|250 / 290 knots
|align="center"|3500m
|-
|align="right"|255
|Fast turbofans (jets), requiring 2000m runways
|align="center"|T1
|align="center"|190 knots
|align="center"|200 ft / 159 knots
|align="center"|250 / 290 knots
|align="center"|2000m
|}
* When maximum gear down/flaps down airspeeds are exceeded for at least 60 seconds the EGPWS triggers a fault and assumes the gear down / flaps down inputs to be invalid.

=== Position Input Select ===
<category-3> 2 </category-3> <nowiki></nowiki>
Some warning modes require the plane's GPS position, e.g. in order to find the nearest runway in its internal database to provide correct height callouts.
* 1: GPS data is supplied to the inputs externally (e.g. NASAL script). You need to provide input to
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-altitude</tt>
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-latitude</tt>
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-longitude</tt>
:<tt>/instrumentation/mk-viii/inputs/arinc429/gps-vertical-figure-of-merit</tt>
* '''2 (default)''': GPS data uses internal source (enables a hard-wired connection within the simulator)

=== Altitude Callouts ===
<category-4> 13 </category-4> <nowiki></nowiki>
Select a set of callouts for the approach phase.

{|border="1" cellspacing="0" align="center"
!category-4
!Callouts
|-
|align="right"|0
|Minimums, SMART_500, 200, 100, 50, 40, 30, 20, 10. ''"SMART_500" limits the 500ft callout to non-precision approaches (when no glideslope is captured or g/s is at least 2 dots above/below).''
|-
|align="right"|1
|Minimums, SMART_500, 200
|-
|align="right"|2
|Minimums, SMART_500, 100, 50, 40, 30, 20, 10
|-
|align="right"|3
|Minimums, SMART_500
|-
|align="right"|4
|Minimums, 200, 100, 50, 40, 30, 20, 10
|-
|align="right"|5
|Minimums, 200
|-
|align="right"|6
|Minimums, 100, 50, 40, 30, 20, 10
|-
|align="right"|7
|''All call-outs disabled.''
|-
|align="right"|8
|Minimums. ''All altitude callouts disabled.''
|-
|align="right"|9
|Minimums, 500, 200, 100, 50, 40, 30, 20, 10
|-
|align="right"|10
|Minimums, 500, 200
|-
|align="right"|11
|Minimums, 500, 100, 50, 40, 30, 20, 10
|-
|align="right"|12
|Minimums, 500
|-
|align="right"|'''(default) 13'''
|Minimums, 1000, 500, 400, 300, 200, 100, 50, 40, 30, 20, 10
|-
|align="right"|14
|Minimums, 100
|-
|align="right"|15
|Minimums, 200, 100
|-
|align="right"|100
|FIELD_500. ''Provides “500” callout at an altitude 500ft above the actual runway altitude.''
|-
|align="right"|101
|FIELD_500_ABOVE. ''Provides “500 above” callout at an altitude 500ft above the actual runway altitude.''
|}

The 500ft callout is available in four options:
* "SMART_500" limits the 500ft callout to non-precision approaches (when no glideslope is captured or g/s is at least 2 dots above/below).
* "FIELD_500" configures the 500ft callout to consider the altitude above the actual runway altitude (instead of the current radio altitude).
* "FIELD_500_ABOVE" is like "FIELD_500", but triggers a "500 '''above'''" callout (instead of "500").
* "500" enables the standard callout, i.e. triggers whenever the radio altimeter reports a current altitude of 500ft.

=== Audio Menu Select ===
<category-5> 0 </category-5> <nowiki></nowiki>
Configure retractable or fixed gear aircraft.
* '''0 (default)''': Configured for retractable gear aircraft. „Too low - gear!“ and „Too low - flaps!“ callouts enabled.
* 2: Configured for fixed gear aircraft. „Too low, flaps!“ callout enabled.

=== Terrain Collision Warning ===
<category-6> 1 </category-6> <nowiki></nowiki>
Enable/disable terrain collision warnings.
* '''1 (default)''': Terrain collision warnings enabled.
* 2: Terrain collision warnings disabled.

=== Options Select ===
<category-7> 124 </category-7> <nowiki></nowiki>
Enable/disable bank angle and steep approach warnings and select flap type.
* bit 0: ''not implemented''
* bit 1: flap reversal.
: '''0 = normal logic (default)'''
: 2 = invert logic when detecting extended/retracted flaps
* bit 2: bank angle alert
: 0 = bank angle alert disabled
: '''4 = enabled (default)'''
* bit 3-5: ''not implemented but enabled by default''
* bit 6: steep approach
: 0 = steep approach warning disabled
: '''64 = steep approach warning enabled (default)'''
* bit 7: ''not implemented''

'''Example''': Value 68 (= 64+ 4) enables bank angle, steep approach alert and normal flap logic.

'''Note''': Default is 124. This also enables additional feature bits (which are currently unsupported).

=== Radio Altitude Input Select ===
<category-8> 2 </category-8> <nowiki></nowiki>
Select radio altimeter input source.

* '''2 (default)''': Altitude source is property "/position/altitude-agl-ft". Works for all FDMs - but this is ''not precise enough to drive useful 20ft and 10ft callouts'' (see below).
* 3: Altitude source is "/position/gear-agl-ft". Very precise altitude of gear-above-ground - but only available for planes with YASim FDM (so far).
* 4: Altitude source is "/instrumentation/radar-altimeter/radar-altitude-ft". A radar altimeter instrument must be installed.

'''Hint''': Most simulator altitude properties refer to the plane's center (of gravity) - but not to the altitude of the main gear. A radar altimeter on a real plane is always calibrated to the gear, hence provides precise information (yes, only within a certain degree of the angle of attack...).
Without a precise altitude source the final callouts before touch down, especially 20ft and 10ft, make no sense or may not even work - very annoying, since most aircraft require a final nose up flare at about 20ft. So precise callouts are very welcome.
Using a radar altimeter instrument is recommended since this is most realistic - and it can (and should) be calibrated to the main gear. See ...(TODO)... for a configuration example.

'''Note''': This configuration category is supported beginning with FlightGear 2.2.

=== Navigation Input Select ===
<category-9> 3 </category-9> <nowiki></nowiki>
Enable/disable glideslope warnings.
* 0: localizer input disabled (disables glideslope warnings)
* '''3 (default)''': localizer input enabled (enables glideslope warning)
: '''Note''': By default, the module is hard-wired to the NAV0 receiver for glideslope warnings, i.e. in order to use the NAV1 receiver you need to update the inputs externally through nasal, etc (see [[#Module I/O|Module I/O]]).

=== Attitude Input Select ===
<category-10> 6 </category-10> <nowiki></nowiki>
Select attitude input source.

'''Note''': This configuration category is implemented for the latest FlightGear version only (GIT sources as of ''''2010-07-30'''' or newer).
* 2: Read data from attitude instrument (requires vacuum system to work).
* '''6 (default)''': Read data from hard-wired connection within simulator.

=== Input and Output Configuration ===
<category-13> 7 </category-13> <nowiki></nowiki>
This configuration value configures the behavior of the module's outputs, usually connected to warning lamps in the cockpit, and enables inputs, which should be connected to cockpit switches.

{|border="1" cellspacing="0" align="center"
!
|colspan="2"|'''Output Lamp Configuration'''
|colspan="3"|'''Input Switch Configuration'''
When enabled, appropriate inputs are supplied to the module
(e.g. inputs should be connected to cockpit switches).
|-
!category-13
!Output
Format *
!Lamp
Flashing **
!GPWS Inhibit
Switch Enabled
!Momentary Flap
Override Switch Enabled
!Alternate Steep
Approach Switch Enabled
|-
|align="right"|0
|align="center"|warning
|align="center"|steady
|
|align="center"|x
|align="center"|x
|-
|align="right"|1
|align="center"|alert
|align="center"|steady
|
|align="center"|x
|align="center"|x
|-
|align="right"|2
|align="center"|warning
|align="center"|steady
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|3
|align="center"|alert
|align="center"|steady
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|4
|align="center"|warning
|align="center"|flashing
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|5
|align="center"|alert
|align="center"|flashing
|align="center"|x
|align="center"|x
|align="center"|x
|-
|align="right"|6
|align="center"|warning
|align="center"|steady
|align="center"|x
|align="center"|x
|
|-
|align="right"|'''(default) 7'''
|align="center"|alert
|align="center"|steady
|align="center"|x
|align="center"|x
|
|-
|align="right"|254
|align="center"|warning
|align="center"|steady
|align="center"|x
|
|align="center"|x
|-
|align="right"|255
|align="center"|warning
|align="center"|steady
|align="center"|x
|
|align="center"|x
|}

* '''Output Format''': 'alert': caution conditions trigger the alert output lamp, otherwise caution conditions triggers warning output.

** '''Lamp Flashing''': Selects whether output lamps should flash or be lit steadily when warning/alert/caution is triggered.

=== Audio Output Level ===
<category-14> 0 </category-14> <nowiki></nowiki>
Basic audio configuration.

{|border="1" cellspacing="0"
!category-14
!Audio Relative
Volume
|-
|align="right"|'''(default) 0'''
|align="right"|0 dB
|-
|align="right"|1
|align="right"| -6 dB
|-
|align="right"|2
|align="right"| -12 dB
|-
|align="right"|3
|align="right"| -18 dB
|-
|align="right"|4
|align="right"| -24 dB
|}

== Speaker Configuration ==
The audio speaker can be configured by modifying the properties beneath <tt>/instrumentation/mk-viii/speaker</tt>.
These properties match the xmlsound properties.

For additional information, check out <tt>[[$FG_ROOT]]/Docs/README.xmlsound</tt>.

== Voice Configuration ==
The GPWS uses a fixed default voice. The voice can be changed by providing custom voice samples and providing a different path and filename prefix.

<voice>
<file-prefix type="string">Sounds/mk-viii/</file-prefix>
<nowiki></nowiki>
</voice>

'''Note:'''
* The voice configuration option is supported by FlightGear '''2.3.0''' and newer.

= Advanced =
This section lists some advanced configuration and integration options.

== Example ==
You may want to check the FG implementation of the [[Boeing 777-200]] aircraft for an extensive example of GPWS integration. This plane provides a Nasal GPWS wrapper for the mk-viii module and implements all standard (Boeing) buttons and displays, i.e.:
* Self-test push button
* Glide-slope warning disable button (e.g. to silence warnings during a visual approach)
* Flap and gear override buttons (e.g. to silence flap/gear warnings in emergency situations, like stuck gear etc).
* Terrain/GPWS disable buttons
* GPWS connection to master-warning light.
* GPWS connection to PFD (to display "PULL UP").

== Module I/O ==
* The inputs and outputs match those of the real device and are made available through the FlightGear property tree.
* Input monitoring is implemented. The loss of inputs required for a particular function is annunciated through the GPWS INOP and/or TERR FAIL lamps.
* The "Present Status" function, which enumerates current faults and lists other device details, is implemented.
* Connect outputs to cockpit instruments, e.g. the EGPWS alert and glideslope outputs to the appropriate warning lamps.
* Connect the <tt>/instrumentation/mk-viii/inputs/discretes/self-test</tt> property to the GPWS self-test button in your cockpit. Testing GPWS operation may be part of the preflight check-list.
* To assist the aircraft designer with the installation of the EGPWS, most inputs are connected to standard FlightGear properties by default. When an input feeder (<tt>...-ncd</tt> property) is set to true, the input it is associated with is automatically updated, using a standard FlightGear property. When the <tt>...-ncd</tt> property it is set to false, its associated input must be manually updated every frame, using a Nasal script or some other mechanism.
* The aircraft's decision height needs to be configured when the 'Minimums' warning is enabled. You can provide the decision height as fixed input value to <tt>/instruments/mk-viii/inputs/arinc429/decision-height</tt>:
<arinc429>
<decision-height-ncd> false </decision-height-ncd>
<decision-height> 200 </decision-height>
</arinc429>

== Module Status ==
The original MK VIII supports an RS232 interface to read the module status. Since FlightGear does not support RS232 interfaces, all data is printed to the standard output. Trigger <tt>/instrumentation/mk-viii/inputs/discretes/rs-232/present-status</tt> to print the current module configuration and status:

EGPWC CONFIGURATION
PART NUMBER: 965-1220-000
MOD STATUS: N/A
SERIAL NUMBER: N/A

APPLICATION S/W VERSION: 2.0.0
TERRAIN DATABASE VERSION: 2.0.0
ENVELOPE MOD DATABASE VERSION: N/A
BOOT CODE VERSION: 2.0.0

CURRENT FAULTS
NO FAULTS

CONFIGURATION:
AIRCRAFT TYPE = 0
AIR DATA TYPE = 1
POSITION INPUT TYPE = 2
CALLOUTS OPTION TYPE = 13
AUDIO MENU TYPE = 0
TERRAIN DISPLAY TYPE = 1
OPTIONS 1 TYPE = 124
RADIO ALTITUDE TYPE = 2
NAVIGATION INPUT TYPE = 3
ATTITUDE TYPE = 6
MAGNETIC HEADING TYPE = 2
WINDSHEAR INPUT TYPE = 0
IO DISCRETE TYPE = 7
VOLUME SELECT = 0

= External Links =
* Documentation by the original module developer [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01902.html 1] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01902/mk-viii-manual.tgz 2]
* Original manufacturer documentation
** [http://www.egpws.com/engineering_support/documents/install/060-4314-150.pdf Honeywell Inc., "MK VI, MK VIII, Enhanced Ground Proximity Warning System (Class A TAWS), Installation Design Guide", July 2003]
** [http://www51.honeywell.com/sites/aero/common/documents/Mk_VI_VIII_EGPWS.pdf Honeywell Inc., "MK VI and MK VIII Enhanced Ground Proximity Warning System Pilot's Guide", February 2002]

[[Category:Aircraft enhancement]]

Route manager

2013-12-08T21:25:49Z

ThorstenB: /* Defining a Route */

{{forum|46|Autopilot & Route Manager}}
{{Autoflight Navigation}}

A real '''route-manager''' page!

[[File:Routemanager.jpg|thumb|270px|The route manager dialog.]]

== Introduction ==
(in the following sections, familiarity with basic [[IFR]] concepts, [[Autopilot]] usage and [[radio navigation]] is assumed)

The route-manager models part of the functionality found in real-world [[GPS]] and FMS devices, but is usable in any aircraft. Some panel instruments may provide access to the route manager via their own UI, but the route-manager is always available through a generic dialog box. The route-manager is also how a flight plan is made available to FlightGear - in the future this will hopefully permit better [[ATC]] and multi-player interactions, since [[ATC]] logic or controllers will be able to observe the filed plan associated with a pilot.

It's important to realize that the route-manager (and [[GPS]]) are pieces that a panel instrument might present as a single real world device - the mapping between C++ modules, generic user interface and in-panel instruments is very fluid, by design. In general core features exist in whichever place seems the most natural, and it's up to instruments to aggregate the core modules as they require.

== Concepts ==
The route-manager maintains a flight-plan, consisting of departure, destination, alternate airport and cruise information, as well as a list of waypoints. All information is currently optional, which is highly unrealistic, but convenient.

Route manager waypoints are entered as a [[navaid]] ident, an explicit latitude/longitude pair, or as an offset (bearing and distance) from another navaid. Each waypoint may also have an [[altitude]] associated with it, for vertical navigation modes (VNAV). In the future, other data, especially speed restrictions, may also be associated with waypoints.

The route-manager maintains a ''current waypoint'', which is shown in route-manager dialog, the GPS dialog (in LEG mode), on the default HUD, and potentially in cockpit displays in the aircraft. Normally, the route-manager moves automatically to the next waypoint after passing the current point (this is known as 'sequencing'), but if necessary the active waypoint can be manually adjusted.

An important piece of terminology is a ''leg'', which is a section of route between two waypoints. Many real-world devices deal in legs primarily, since each leg corresponds to a desired track, a distance and possibly an altitude to climb / descend. In the FlightGear route manager, the ''active leg'' is from the previous waypoint to the current waypoint - i.e the current waypoint is where you're heading to at the moment.

== Defining a Route ==
The simplest way to define a route is to add waypoints one at a time by identifier. Since navaid identifiers are not unique, the route-manager uses your departure airport or the previously defined waypoint to locate the identifier search. In practice, navaids with conflicting names are located far enough apart that this works automatically in practice.

Until departure and arrival procedures are supported, you can often define them yourself, by creating offset waypoints, as shown in the examples below.

Routes can be loaded and saved to and from a simple XML format, so you may prefer to create the routes in a text editor, and load them instead of entering them by hand. You can also use a 3rd party flight-planning tool to create the route, export the route in GPX format and load the file with the route manager (requires FlightGear >= 2.99 and the file must have the suffix ".gpx"). Contact the developer list if you are interested on working on support for further file formats.

In the future, auto-routing using airways or VOR-VOR routing will also be added.

Example waypoint definitions:

;KJFK
: airport identifier
;UW
: navaid identifier ([[NDB]], [[VOR]] or a fix/interaction)
;TLA/210/35
: offset from a [[navaid]] - in this example, the 210-degree magnetic radial from TLA VOR, 35 nautical miles out
;WOBAD@18000
: WOBAD fix, at eighteen thousand feet altitude
;SPL/050/12.3@2000
: 12.3 nautical miles from SPL VOR on the 050 magnetic radial, at two thousand feet
;-20,55
: virtual point at W020N55, eg. when flying North Atlantic Tracks

See also [[#Useful Software]]

=== SID and STAR ===
As of FlightGear 2.4.0, the route manager has basic [[SID]]/[[STAR]] support. Download the '''Level-D 767''' formatted files from http://www.navdata.at, then save it under <tt>[[$FG_SCENERY]]/Airports/I/C/A/ICAO.procedures.xml</tt> (use the correct ICAO codes!). Next time you start FlightGear, you can load them through the route manager interface.

== Activating a Route ==
Activating a route performs certain checks, and creates start and end waypoints based on the selected departure and arrival info. For the moment, that consists of adding the departure runway as waypoint zero, but in the future (when departure procedures are supported) this will create the appropriate procedure waypoints.

This will also be the hook point for calculating cruise information, such as top-of-climb and top-of-descent points in the future.

Other devices (especially a GPS/FMS) may trigger other changes based on activating a route, such as sequencing the first leg of the route, resetting internal counters / timers, and so on.

== Flying a Route ==

When a route is activated, the GPS system enters 'leg' mode, and will automatically sequence waypoints as they are overflown. Note that all aircraft can use the default route-manager and GPS functions, even aircraft that would never (historically) has such systems. This is a convenience to casual users, testing, and so on.

In particular, the GPS drives some properties of the generic autopilot, so 'true heading hold' mode can be used to fly the route manager route (or any other GPS course).

The default [[HUD]] (activated by pressing 'h') shows information about the active waypoint and leg, in the top-left corner. Notably, it includes the identifier, time and distance to the current waypoint, the magnetic bearing to the waypoint, and the current ground track, and finally the deviation (in nautical miles) from the leg course.

In aircraft with realistic navigation systems, or customised autopilots, the default behaviours above may not work; hopefully the aircraft author has provided alternative methods, such as panel instruments, to control the interaction with that aircraft's autopilot and panel.

=== Lining up with Runways ===
The route-manager only provides guidance to a particular location - to arrive on a particular heading, such as lined up with a runway or [[ILS]] localizer, it is necessary to use multiple waypoints. Virtually all ILS approaches define multiple [[fixes]] that can be used for this purpose, usually including altitude restrictions. For example, for the [http://flightaware.com/resources/airport/KPHX/IAP/ILS+OR+LOC+RWY+08 KPHX 08 approach], waypoints ALLIS, SARTE, HIKID, ILIKE, JAMIL and WAZUP are defined, extending 20nm from the threshold. Typically you enter the initial approach fix (IAF), ALLIS in this example, and as many of the intermediate waypoints as necessary, depending on required descent profile. It is helpful to include the glidepath capture waypoint (WAZUP), to provide an easy altitude reference and cross-check that your ILS receiver is working.

== Properties ==
When a route is active, the route-manage provides various pieces of information based upon current aircraft position / speed, and the route progress. These values would be calculated by the navigation computer in a real system, but are handled by route-manage in FG for convenience. Values logged include the takeoff time, estimated time enroute (ETE), distance remaining enroute, and so on - browse the property tree to see what's available.

== Useful Software ==
To easily create entries for route manager the application;
*[http://rubyforge.org/projects/fgmap Flightgear Mapping] is useful. With just a few clicks you can add navaids displayed on the map and as well a route you have defined there via waypoints. Navaids can be inserted into the list at any point, not just at the end.
*[http://sourceforge.net/projects/fgflightplanner/ Kelpie Flight Planner] appears to be a very thorough route planning tool that works on Windows, Linux and other operating systems.

== Related content ==
* For additional route managr system details, see [[Route manager internals]].
* [[Howto: Create a flightplan]]
* [[Radio beacons]]
* [[Radio navigation]]

[[Category:FlightGear feature]]
[[Category:Menubar]]

FlightGear World Scenery 2.0

2013-11-12T07:48:29Z

ThorstenB: /* Known bugs and limitations */ Norway also affected

:''Follow the dedicated forum thread: [http://forum.flightgear.org/viewtopic.php?f=5&t=21294 FG Worldwide scenery 2.0 - Return of experience]''

The '''FlightGear World Scenery 2.0''' was released during [[FSweekend]] 2013. This new scenery reflects a major improvement over the existing default world scenery and has taken over five years to complete. A [http://mapserver.flightgear.org/map/?lon=14.56652&lat=-25.18458&zoom=1&layers=B00000000000FTFFTFFTFFFFFFFF much higher level of detail] and internal consistency characterizes this new release, in addition to the fact that it will serve as a stepping-stone for further incremental refinements.

== Source data ==
This FlightGear World Scenery was compiled from:
* ViewFinderPanoramas elevation model by Jonathan de Ferranti (using 20m accuracy with terrafit.py -e 20),
* VMap0 Ed.5 Worldwide Land Cover
* CORINE Land Cover 2006v16 for Europe (Source : European Union, SOeS, CORINE Land Cover, 2006 - [http://www.ifen.fr/index.php?id=88]). See [[CORINE to materials mapping|here]] for the correspondance between CORINE and FG textures
* Several custom land cover enhancements (to be listed here...)
* The latest airports (2013.10), maintained by Robin Peel of X-Plane
* Road, rail and rivers courses line data by OpenStreetMap [http://www.openstreetmap.org]

== Distribution ==
World Scenery 2.0 is available through the usual channels:
* TerraSync (currently still under feeding)
* [http://terasaur.org/item/downloads/flightgear-v2-12/6697 Torrent]
* FlightGear main website

== Side note ==
Note that all objects elevation were recomputed. Thus, if some objects were defined with a bad elevation or bad offset, they may have taken a bit of elevation. Use [http://scenemodels.flightgear.org our webforms], if necessary, to fix this.

== Screenshots ==

== Known bugs and limitations ==
* clipping of OSM roads on water showing height glitches (due to bad coast/river lines definitions and bad clipping);
* some z-fighting (clipper is generating the correct number of contours, but the airport hole is wound as a boundary, not a hole) and/or triangles on airports (LFRH, EDWJ...);
* some troubles on very dense cities (such as Paris) leading to grey-white triangles on cities - see also yellow lines @LFPG;
* some line issues on small airfield with LTA specific runways (LEVT, LFNH, LFLI...) - the small centerlines on the runways are "floating" over the runway (20 cm to 1m), leading to some gear destructions ;-) (they didn't use lines, but surfaces that are defined as transparent and borders defined as the line type. This way you limit the number of "line features"). Probably "hot" = false would solve it. See [http://uppix.net/y1H1NB.png 1] [http://uppix.net/sMdg17.png 2] [http://uppix.net/kAXrdF.png 3] [http://uppix.net/vYuReF.png 4] [http://uppix.net/DQ4NHr.png 5]. Thanks Clément for noticing;
* airport being located over two different tiles sometimes renders bad, leading to z-fighting (LEJR, UKKE...);
* glacier landcover is missing, leading to some holes in high moutains, as seen in Switzerland (SW [http://mapserver.flightgear.org/map/?lon=8.12304&lat=46.07741&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF LSMM]), Austria ([http://mapserver.flightgear.org/map/?lon=11.3527&lat=47.25782&zoom=10&layers=B00000000000FTFFTFFTFFFFFFFF south of LOWI]) and Northern Norway (i.e. [http://mapserver.flightgear.org/map/?lon=14.210&lat=65.974&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF near ENMS]);
* on sharp cliffs, water sometimes climb over the cliffs (see e000n40/e000n49/2958056 and [http://img809.imageshack.us/img809/2082/9n96.jpg this picture] for instance). Thanks clm76 for reporting;
* terrain and ocean z-fighting such as [http://mapserver.flightgear.org/map/?lon=12.73312&lat=55.60834&zoom=15 east of EKCH]. See tile 3155042 and EDWJ;
* clipping between river and terrain is somewhat strange, making the river "climb" over the terrain, noticeably under bridges - probably due to the presence of the roads. See [http://img809.imageshack.us/img809/2082/9n96.jpg this example];
* the Moss Landing airport (on the coast a little bit south of KSFO) is partly submerged into the water and the airport's north end is elevated above the terrain around it. There is an area on the coast just to the north of the Moss Landing airport that is above sea level if you are up above 1000ft but is covered in water is you are on the deck. When flying over this you can see trees sticking up out of the water so the code that is placing random trees thinks this is above sea level. The old scenery didn't have either of these problems. Also if you fly over this at just the right altitude you can see this area switching back and forth between being water and land (thanks hvengel);
* on many airports where the taxiway signs are now taken from the apt.dat and put in the Terrain folder, the old signs still remain in the Object folder. See EDDF, ELLX;
* on ELLX there are some problems with "holes" in the pavement that flicker between grass and tarmac. I saw this (if I remember correctly) with an older development version of terragear, but this was fixed some time ago.

== Features enhancement ==
* enhance landcover data for the rest of the world (OSM?) and add more custom scenery and fixes;
* find a new svn hosting solution;
* compute the next with textures-lines option;
* add some more OSM data (secondary...);
* descent airports priority below roads, so roads and railroads can be shown over airports;
* retry multi-thread;
* enhance the "random" tree and builds placement to take OSM into account;
* .SPT file support - push Mathias' LOD ideas forward;
* landclass border blurring - Several ideas on this - It would be really nice to be able to do it;
* osm motorway_link (and the other _link) roads should probably have their own width. Perhaps grouped into a separate shapefile, or handled in ogr-decode - single lane is most likely;
* osm line data simplification / preprocessing. - We've done some experimenting, and the results are promising. This should reduce the number of triangles generated. It could create longer continuous roads, which allows better control of the generated texture coordinates - so we could, theoretically, populate the roads with traffic in the future.

== External link ==
* World Scenery 2.0 release announcement on the forum: [http://forum.flightgear.org/viewtopic.php?f=5&t=21226& FlightGear World Scenery 2.0 released]

[[Category:Scenery]]

FSweekend 2012

2012-10-25T19:35:04Z

ThorstenB: /* Equipment Checklist */

[[File:FSweekend banner 2012.jpg|right]]
This wiki page lists all information related to [[FlightGear]]'s [[FSweekend]] 2012 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.

'''<daysuntil in="days">03-November-2012</daysuntil>''' until the FSweekend at 3&4 November 2012.

== Booth information ==

=== Equipment Checklist ===
[[File:C172MiniCockpit1.jpg|140px|thumb|right]]
[[File:Anaglyph-glasses.jpg|right]]
* CH Yoke (GdR)
* CH Rudder Pedals (GdR)
* Core i7 + GTX 680 + X52 throttle and stick + 24" (AB)
* C172P Panel (FGPanel Demo) with driving PC
* Pairs of anaglyph 3D-glasses:
** One (GdR)
** One (DT)
* Business cards

'''Maybe:'''
* Thomas Krenn machine with 10 monitors (MS)

====15 years anniversary====
This year it's 15 (!) years ago that the first version of FlightGear was released (July 17, 1997). To celebrate this event, we might bring some special goodies to the booth:

* Balloons with logo to cheer up our booth.
* One (old) computer running a very old version (preferably the very first version) of FlightGear.

== Flight information ==
=== Airports ===
[[File:EHLE_schipholgebouw.png|thumb|270px|The old terminal of Schiphol (1928), now located at EHLE.]]
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 ===
For FSweekend 2012 we're planning to show consistent Scenery which has been available for testing before the show and doesn't require manual fiddling on-stage. That way we can safely show the latest scenery on every machine. Please make sure everything is in the database well before November ;-)

== External links==
* [http://www.fsweekend.com Official FSweekend website]
* [http://www.facebook.com/events/315742308452348/ Facebook event page]

[[Category:FSweekend]]

File:C172MiniCockpit1.jpg

2012-10-25T19:26:47Z

ThorstenB: uploaded a new version of "File:C172MiniCockpit1.jpg"

== Summary ==
{{File information
|description =
|Source =
|Date =
|Author =
}}

[[Category:Cockpit building images]]

Talk:Traffic alert and collision avoidance system

2012-10-09T18:39:41Z

ThorstenB:

= instruments vs. displays - tcas vs. wxradar =
You are right, and that's the most valid and most informed objection that I have seen so far. However, keep in mind that the [[wxradar]] article is just an empty placeholder at the moment. So, the MVC separation that you are referring to here, isn't done currently for the wiki article.

In fact, the "display" part of the TCAS is specifically referred to in the main [[TCAS]] article: http://wiki.flightgear.org/Traffic_alert_and_collision_avoidance_system#TCAS_display

So, I am fully aware of the difference between instruments and displays - we just don't have a separate wxradar article at the moment...
--[[User:Hooray|Hooray]] 14:15, 9 October 2012 (EDT)

I have invested lots of time to create the TCAS module. The wxradar extension to display traffic was a tiny part of the work. I wrote the wiki article since I hoped people would use the instrument. It doesn't really help if you keep sticking warning notices everywhere "''Most of the stuff here is deprecated''", basically voiding all the work and telling people not to use it - just because _you_ think that Nasal and Canvas is the one and only way ahead. Neither is it something motivating me to invest any more time into FG. When there is any other ready-to-use module available, which aircraft developers can immediately use to display TCAS traffic, then this page can well be extended. Until then, while there is no alternative available, I don't seen any reason to why people should be told to stop using it. So, I do *not* want the page to be changed with any such suggestions.
-[[User:ThorstenB|ThorstenB]] 14:39, 9 October 2012 (EDT)

Traffic alert and collision avoidance system

2012-10-09T17:28:31Z

ThorstenB: TCAS is not affected by Canvas. It's a faceless FG instrument. Canvas thing may apply to wxradar (the display)

A '''traffic collision avoidance system''' or '''traffic alert and collision avoidance system''' (both abbreviated as TCAS) is an [http://en.wikipedia.org/wiki/Aircraft_collision_avoidance_systems aircraft collision avoidance system] designed to reduce the incidence of mid-air collisions between aircraft.

FlightGear (version 2.3.0 and above) provides an instrument emulating the [http://www.arinc.com/downloads/tcas/tcas.pdf TCAS II Version 7] standard.

= Introduction =
TCAS monitors the airspace around an aircraft for other aircraft, independent of air traffic control, and warns pilots of the presence of other aircraft which may present a threat of mid-air collision. TCAS uses aural annunciation of all warnings - similar to the [[ground proximity warning system]].

Rather than using fixed distances, threats are detected on a basis of ''time to conflict''. Any aircraft on a flight path causing a conflict within the next 20-50 seconds triggers a traffic warning. Traffic coming even closer (15-35 seconds) may also trigger a resolution advisory, i.e. advise each pilot of conflicting aircraft to climb or descend to provide optimal vertical separation.

Threat detection sensitivity increases with altitude, assuming that planes should have a much higher separation at high altitudes, while only a minimum separation can be maintained when flying low - usually in the vicinity of the destination or departure airport. TCAS II increases the threat sensitivity in 7 steps: from 20 seconds at 1000ft to 50 seconds above 20000ft for traffic alerts, and from 15 to 35 seconds for resolution advisories.

== Features ==
[[File:TCAS.png|thumb|250px|TCAS display]]
The FlightGear TCAS has the following features and limitations:
* Works with [[AI Systems|AI]] and [[Howto: Multiplayer|multi-player]] traffic.
* Aural traffic alerts (TA) are issued, i.e. "''Traffic, traffic!''" warnings.
* Aural resolution advisories (RA) are issued, i.e. "''Climb, climb!''" or "''Descend, descend!''".
* Provides traffic data in order to drive a [[#Display|TCAS display]] (no threat / proximity / traffic alert / resolution alert).
* Switchable TCAS mode: off/standby/TA-only/TA-auto (to be connected to transponder cockpit switch).

'''Additional features'''
* Advisory reversion: this may be required due to late or incorrect reaction of the pilot, due to an unforeseen change of the threatening aircraft's flight path, or due to a new multi aircraft threat. In such a situation an opposite vertical movement may become necessary to provide better separation. Reversed advisories are announced by "''Climb, climb '''now'''!''" or "''Descend, descend '''now'''!''" warnings.
* Normally TCAS II avoids altitude crossing advisories, i.e. the aircraft at higher altitude is advised to climb, the aircraft at lower altitude advised to descend. However, there are specific situations where the minimum vertical separation can only be achieved by altitude crossing (e.g. since the lower aircraft is already climbing, or the higher aircraft already descending fast). TCAS uses a specific advisory annunciation for such cases ("''Climb, '''crossing''', climb!''" and "''Descend, '''crossing''', descend!''") to alert pilots of this specific situation.
* Parked/taxiing aircraft are ignored by the FlightGear TCAS (RL pilots switch their TCAS transponders off).
* Coordination of resolution advisories with AI aircraft. When a TCAS resolution advisory is issued, the conflicting AI plane moves in the opposite vertical direction (Beware: AIpilots ''always'' want to be on schedule (no exceptions! :) ), so eventually they may ignore any TCAS threat and try to return to their original flight path).
* Currently there is ''no'' coordination of resolution advisories for MP traffic in FlightGear. So with two TCAS equipped MP aircraft approaching each other, there is no guarantee that the respective resolution advisories are actually in opposite direction. However, due to the symmetry of the resolution algorithm, resolution advisories still will be in opposite direction in almost all cases.
* MP aircraft ''ignored'' in the pilot list are also ignored by the TCAS and TCAS display.

== Warnings ==
In a threat situation a traffic alert is always annunciated first. A resolution advisory may follow several seconds later when the conflicting aircraft approach even closer.

However, TCAS does not guarantee to always issue a resolution advisory:
* No advisories are issued when the TCAS is switched to "TA-only" mode (or less). TCAS cockpit switch must be set to mode 3 (named "TA/RA" or "TA-auto") to enable resolution advisories.
* Below 1000ft only traffic alerts are announced, but no advisories (TCAS II standard).
* No advisory is issued when the TCAS module is unable to determine a safe resolution based on vertical movement (i.e. no safe option due to multiple aircraft threat, or low altitude).

'''Description of Aural Alerts'''

The complete list of TCAS alerts supported by FlightGear is:
{|border="1" cellspacing="0" align="center"
!Aural annunciation
!Description
|-
|''Traffic, traffic!''
|warning, conflicting traffic
|-
|''Climb, climb!''
|advisory, climb immediately to avoid conflicting traffic
|-
|''Climb, crossing, climb!''
|advisory, climb immediately, conflicting traffic will descend - crossing altitudes
|-
|''Climb, climb now!''
|reversed advisory, ignore previous descend advisory, now climb immediately
|-
|''Descend, descend!''
|advisory, descend immediately
|-
|''Descend, crossing, descend!''
|advisory, descend immediately, conflicting traffic will climb - crossing altitudes
|-
|''Descend, descend now!''
|reversed advisory, ignore previous climb advisory, now descend immediately
|-
|''Maintain vertical speed, maintain!''
|advisory, keep climbing/descending to avoid collision
|-
|''Adjust vertical speed, adjust!''
|advisory, reduce climb or descent rate to avoid collision
|-
|''Don't climb!''
|advisory, fly level to avoid collision. Issued at low altitudes instead of a "descend" advisory. Pilots may descend if they can confirm safe terrain clearance.
|-
|''Clear of conflict.''
|All clear. Follow ATC instructions.
|}

== Display ==
[[File:TCAS_annotated.png|thumb|250px|Annotated TCAS display]]
The TCAS display shows any aircraft with enabled transponder (transponders should be switched off while taxiing or when the aircraft is parked).

The following symbols and colors are used by a TCAS display:

{|border="1" cellspacing="0" align="center"
!Color
!Symbol
!Description
|-
|blue or cyan
|open diamond
|no threat, distant traffic
|-
|blue or cyan
|filled diamond
|no threat, but proximity traffic (less than 6 nm in range and within +/-1200ft)
|-
|yellow or orange
|filled circle
|threat: traffic alert
|-
|red
|filled square
|threat: resolution advisory was issued to evade this aircraft
|}

Furtheremore, an upward or downward arrow next to any TCAS symbol shows climbing or descending traffic.

Also, the relative altitude is shown in steps of 100ft: +12 above a TCAS symbols means ''traffic 1200ft above'',
a -24 below a TCAS symbol means ''traffic is 2400ft below''.

== ATC ==
Pilots should '''always follow a TCAS resolution advisory''' - even in case it contradicts an [[ATC]] instruction (see [http://www.eurocontrol.int/msa/gallery/content/public/documents/ACAS_Bulletin%20_1_disclaimer.pdf ACAS II bulletin No 1]).

However:
* Remember to immediately report any TCAS advisory to ATC.
** [[ATC phraseology|Phraseology]]: "'''<callsign> TCAS RA'''" (pronounced "TEE-CAS-AR-AY")
* When an ATC instruction contradicts an active TCAS resolution advisory, keep following the TCAS advisory and report to ATC.
** Phraseology: "'''<callsign> Unable, TCAS RA.'''"
* Pilots must report to ATC and return to their assigned altitude as soon as the conflict is cleared.
** Phraseology: "'''<callsign> Clear of conflict, returning to <assigned clearance>'''"

A detailed description of TCAS-related ATC procedures is available in the
[http://www.eurocontrol.int/msa/gallery/content/public/documents/ACAS_Bulletins_10_disclaimer.pdf ACAS II bulletin No 10: When ATC meets TCAS II]

= Add to an airplane =
In many countries the installation of a TCAS instrument is mandatory for civil transport aircraft (Europe/EASA: mandatory for aircraft capable of carrying at least 19 passengers, USA/FAA: any aircraft capable of carrying at least 30 passengers).

== TCAS instrument ==
=== Instrument List ===
Add the device to your plane by adding it to the sim/instrumentation section (usually in a separate instrumentation.xml file).

Example:
<PropertyList>
<sim>
<instrumentation>

'''<tcas>'''
'''<name>tcas</name>'''
'''<number>0</number>'''
'''</tcas>'''

</instrumentation>
</sim>
</PropertyList>
Usually planes only have a single TCAS installed - so using multiple instances wouldn't be too common.

=== <Plane>-set.xml file ===
Configuration parameters are stored in a different section.
Add the following XML template to the instrumentation section of the plane's ...-set.xml file.
Do not mix up this section with the one above (section above was ''within'' the <sim> tag, this section is ''outside'' the <sim> tag).

XML Template:

<PropertyList>
<nowiki></nowiki>

<instrumentation>

<tcas> <nowiki></nowiki>

<serviceable type="bool">true</serviceable>
<nowiki></nowiki>

<inputs>
<mode type="int">3</mode> <nowiki></nowiki>
</inputs>

<nowiki></nowiki>
</voice>
<nowiki>--></nowiki>

<speaker> <nowiki></nowiki>
<max-dist> 2 </max-dist> <nowiki></nowiki>
<reference-dist> 1 </reference-dist> <nowiki></nowiki>
<volume> 1.0 </volume> <nowiki></nowiki>
</speaker>

</tcas>
</instrumentation>

</PropertyList>

'''Note''':
* You can connect the instrumentation/tcas/inputs/mode property to a cockpit switch (transponder mode), so the pilot can manually switch the TCAS mode.
* The instrumentation/tcas/serviceable property may be used to simulate a device failure.

== TCAS display ==
A TCAS display is implemented by a separate device which reuses information provided by the TCAS instrument.
Currently, only the [[wxradar]] instrument supports displaying traffic according to TCAS data.

The following example shows additional settings required for wxradar in order to enable the TCAS display mode:
<radar>
...
<display-controls>
...
<tcas type="bool">true</tcas>
</display-controls>
<nowiki></nowiki>
<tcas>
<color n="0"> <nowiki></nowiki>
<red type="float">0</red>
<green type="float">1</green>
<blue type="float">1</blue>
</color>
<color n="1"> <nowiki></nowiki>
<red type="float">0</red>
<green type="float">1</green>
<blue type="float">1</blue>
</color>
<color n="2"> <nowiki></nowiki>
<red type="float">1</red>
<green type="float">0.5</green>
<blue type="float">0</blue>
</color>
<color n="3"> <nowiki></nowiki>
<red type="float">1</red>
<green type="float">0</green>
<blue type="float">0</blue>
</color>
</tcas>
<nowiki></nowiki>
...
<echo-texture-path type="string">Aircraft/..../wxecho.png</echo-texture-path>
</radar>

'''Note''':
* Remember to reference a specific "wxecho.png" image providing TCAS-style symbols (see 777-200ER).
* The TCAS display mode requires the installation of a TCAS instrument.

= References =
* [http://www.arinc.com/downloads/tcas/tcas.pdf FAA: Introduction to TCAS II Version 7]
* [http://www.eurocontrol.int/msa/public/standard_page/ACAS_Startpage.html EUROCONTROL ACAS Website]
* [http://www.eurocontrol.int/msa/gallery/content/public/documents/ACAS_Bulletin%20_1_disclaimer.pdf ACAS II bulletin No 1: Follow the RA!]
* [http://www.eurocontrol.int/msa/gallery/content/public/documents/ACAS_Bulletins_10_disclaimer.pdf ACAS II bulletin No 10: When ATC meets TCAS II]

{{Understanding}}
[[Category:Aviation]]
[[Category:Aircraft instruments]]

FlightGear Git: splitting FGData

2012-09-23T15:52:23Z

ThorstenB: /* Reasons to split 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.
*** One of the main reasons for running a community owned (aircraft or source) repository, and the reason why people have "donated" (aircraft or sources) to the common repository, is to guarantee that any contributed work lives on - for as long as the (FG) project itself exists. Private repositories, even hangars run by a small number of people, are likely to become unmaintained and even lost eventually, since people's interests and hobbies change over time. Few (FG) contributors are active for more than 5-10 years. Hence, a common and well maintained community repository is essential to every open source project.
** 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 aircraft 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.
*** However, the use of a ''common'' license for all ''community aircraft'' has many advantages and has also contributed to the success of the FG project (new aircraft can be easily based on existing aircraft, can copy elements from other aircraft without triggering a complicated mixed license situation), and specifically the GPL has many advantages for the FG project (see [[Changing the FlightGear License]] for details why FG wants to stick to the GPL). Authors preferring an other license can of course already (and continue to) do so - except that their aircraft is not in the community repository.

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

2012-09-23T15:18:59Z

ThorstenB: /* Keeping all aircraft under a single project */

= 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 aircraft 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.
*** However, the use of a ''common'' license for all ''community aircraft'' has many advantages and has also contributed to the success of the FG project (new aircraft can be easily based on existing aircraft, can copy elements from other aircraft without triggering a complicated mixed license situation), and specifically the GPL has many advantages for the FG project (see [[Changing the FlightGear License]] for details why FG wants to stick to the GPL). Authors preferring an other license can of course already (and continue to) do so - except that their aircraft is not in the community repository.

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

2012-09-23T15:14:11Z

ThorstenB: /* Keeping all aircraft under a single project */

= 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 aircraft 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. However, the use of a ''common'' license for all ''community aircraft'' has many advantages and has also contributed to the success of the FG project (new aircraft can be easily based on existing aircraft, can copy elements from other aircraft without triggering a complicated mixed license situation), and specifically the GPL has many advantages for the FG project (see [[Changing the FlightGear License]] for details why FG wants to stick to the GPL). Authors preferring an other license can of course already (and continue to) do so - except that their aircraft is not in the community repository.

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

Release plan

2012-07-17T17:09:42Z

ThorstenB: /* Detailed time schedule and checklist */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General release concept ===
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 => current development stream is 2.7.0, next official release is 2.8.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed time schedule and checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state
##Create a "release preperations" topic at the forum and make it a "Global Announcement"
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.7.0 -> 2.8.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/2.8.0</tt>
##:''git tag -a version/2.8.0'' (Enter a wise comment)
##Push the branches next/master '''and''' the tags upstream
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##:for the tags (all repos): ''git push origin version/2.8.0''
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams

##Pull current Git, create the release branches (for sg/fg/fgdata):
##:''git pull
##:''git branch release/2.8.0
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.8.0 -> 2.9.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"
##:''git tag -a version/2.9.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.8.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.8.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##:for the tags (all repos): ''git push origin version/2.9.0''
##Declare dev-streams "open" or "green"
##: Ask a wiki admin to change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/2.8.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.8.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.8.0-final''
##Merge the branch release/2.8.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.8.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file

=== Definition of repository states ===
* Open/Green
*:Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].

=== Tasks and owners ===
{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
|-
! rowspan="6" |
| Announce the state-change of the dev-streams
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat
|-
| Distribute files to download servers
| Curt
|-
! Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Changelog 2.8.0]]
| All developers
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

=== Open items, questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons learned ===
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Release plan

2012-07-17T17:00:52Z

ThorstenB: /* Detailed time schedule and checklist */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General release concept ===
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 => current development stream is 2.7.0, next official release is 2.8.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed time schedule and checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state
##Create a "release preperations" topic at the forum and make it a "Global Announcement"
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.7.0 -> 2.8.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/2.8.0</tt>
##:''git tag -a version/2.8.0'' (Enter a wise comment)
##Push the branches next/master '''and''' the tags upstream
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##:for the tags (all repos): ''git push origin version/2.8.0''
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams

##Pull current Git, create the release branches (for sg/fg/fgdata):
##:''git pull
##:''git branch release/2.8.0
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.8.0 -> 2.9.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"
##:''git tag -a version/2.9.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.8.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.8.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##:for the tags (all repos): ''git push origin version/2.9.0''
##Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/2.8.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.8.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.8.0-final''
##Merge the branch release/2.8.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.8.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file

=== Definition of repository states ===
* Open/Green
*:Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].

=== Tasks and owners ===
{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
|-
! rowspan="6" |
| Announce the state-change of the dev-streams
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat
|-
| Distribute files to download servers
| Curt
|-
! Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Changelog 2.8.0]]
| All developers
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

=== Open items, questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons learned ===
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Release plan

2012-07-10T19:20:59Z

ThorstenB: /* Detailed time schedule and checklist */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General release concept ===
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 => current development stream is 2.7.0, next official release is 2.8.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed time schedule and checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state
##Create a "release preperations" topic at the forum and make it a "Global Announcement"
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.7.0 -> 2.8.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/2.8.0</tt>
##:''git tag -a version/2.8.0'' (Enter a wise comment)
##Push the branches next/master '''and''' the tags upstream
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##:for the tags (all repos): ''git push --tags origin''
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams

##Pull current Git, create the release branches (for sg/fg/fgdata):
##:''git pull
##:''git branch release/2.8.0
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.8.0 -> 2.9.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"
##:''git tag -a version/2.9.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.8.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.9.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##:for the tags (all repos): ''git push --tags origin''
##Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/2.8.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.8.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.8.0-final''
##Merge the branch release/2.8.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.8.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file

=== Definition of repository states ===
* Open/Green
*:Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].

=== Tasks and owners ===
{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
|-
! rowspan="6" |
| Announce the state-change of the dev-streams
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat
|-
| Distribute files to download servers
| Curt
|-
! Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Changelog 2.8.0]]
| All developers
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

=== Open items, questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons learned ===
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Release plan

2012-06-27T17:28:13Z

ThorstenB: /* Detailed time schedule and checklist */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General release concept ===
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 => current development stream is 2.7.0, next official release is 2.8.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed time schedule and checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state
##Create a "release preperations" topic at the forum and make it a "Global Announcement"
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.7.0 -> 2.8.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/2.8.0</tt>
##:''git tag -a version/2.8.0'' (Enter a wise comment)
##Push the branches next/master '''and''' the tags upstream
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##:for the tags (all repos): ''git push --tags origin''
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Declare the streams "closed" or "red"
##:Send a mail to the flightgear-devel mail-list, asking not to commit/push anything
##:Post an update to the forum topic
##:Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code>
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.8.0 -> 2.9.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"
##:''git tag -a version/2.9.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.8.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.9.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##:for the tags (all repos): ''git push --tags origin''
##Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/2.8.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.8.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.8.0-final''
##Merge the branch release/2.8.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.8.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file

=== Definition of repository states ===
* Open/Green
*:Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].

=== Tasks and owners ===
{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
|-
! rowspan="6" |
| Announce the state-change of the dev-streams
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat
|-
| Distribute files to download servers
| Curt
|-
! Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Changelog 2.8.0]]
| All developers
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

=== Open items, questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons learned ===
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Release plan

2012-06-27T17:18:39Z

ThorstenB: /* Detailed time schedule and checklist */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General release concept ===
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 => current development stream is 2.7.0, next official release is 2.8.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed time schedule and checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state
##Create a "release preperations" topic at the forum and make it a "Global Announcement"
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.7.0 -> 2.8.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/2.8.0</tt>
##:''git tag -a version/2.8.0'' (Enter a wise comment)
##Create the release branches on simgear, flightgear and fgdata named <tt>release/2.8.0</tt>
##:''git branch release/2.8.0''
##Push the branches next/master '''and''' the tags upstream
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"
##Post an update to the forum topic
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code>
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.8.0 -> 2.9.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"
##:''git tag -a version/2.9.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.8.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.9.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##: Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/2.8.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.8.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.8.0-final''
##Merge the branch release/2.8.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.8.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file

=== Definition of repository states ===
* Open/Green
*:Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].

=== Tasks and owners ===
{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
|-
! rowspan="6" |
| Announce the state-change of the dev-streams
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat
|-
| Distribute files to download servers
| Curt
|-
! Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Changelog 2.8.0]]
| All developers
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

=== Open items, questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons learned ===
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Release plan

2012-06-17T20:47:11Z

ThorstenB: /* Definition of repository states */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General release concept ===
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 => current development stream is 2.7.0, next official release is 2.8.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed time schedule and checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state
##Create a "release preperations" topic at the forum and make it a "Global Announcement"
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.7.0 -> 2.8.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"
##Post an update to the forum topic
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code>
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/2.8.0</tt>
##:''git tag -a version/2.8.0'' (Enter a wise comment)
##Create the release branches on simgear, flightgear and fgdata named <tt>release/2.8.0</tt>
##:''git branch release/2.8.0''
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.8.0 -> 2.9.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"
##:''git tag -a version/2.9.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.8.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.9.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##: Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/2.8.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.8.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.8.0-final''
##Merge the branch release/2.8.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.8.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file

=== Definition of repository states ===
* Open/Green
*:Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].

=== Tasks and owners ===
{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
|-
! rowspan="6" |
| Announce the state-change of the dev-streams
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat
|-
| Distribute files to download servers
| Curt
|-
! Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Changelog 2.8.0]]
| All developers
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

=== Open items, questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons learned ===
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Release plan

2012-06-17T20:46:33Z

ThorstenB: /* To bump up the version number */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General release concept ===
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 => current development stream is 2.7.0, next official release is 2.8.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed time schedule and checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state
##Create a "release preperations" topic at the forum and make it a "Global Announcement"
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.7.0 -> 2.8.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"
##Post an update to the forum topic
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code>
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/2.8.0</tt>
##:''git tag -a version/2.8.0'' (Enter a wise comment)
##Create the release branches on simgear, flightgear and fgdata named <tt>release/2.8.0</tt>
##:''git branch release/2.8.0''
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.8.0 -> 2.9.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"
##:''git tag -a version/2.9.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.8.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.9.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##: Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/2.8.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.8.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.8.0-final''
##Merge the branch release/2.8.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.8.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file

=== Definition of repository states ===
* Open/Green
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].

=== Tasks and owners ===
{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
|-
! rowspan="6" |
| Announce the state-change of the dev-streams
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat
|-
| Distribute files to download servers
| Curt
|-
! Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Changelog 2.8.0]]
| All developers
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

=== Open items, questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons learned ===
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Release plan

2012-06-17T20:43:05Z

ThorstenB: /* Detailed time schedule and checklist */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General release concept ===
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 => current development stream is 2.7.0, next official release is 2.8.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed time schedule and checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state
##Create a "release preperations" topic at the forum and make it a "Global Announcement"
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.7.0 -> 2.8.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"
##Post an update to the forum topic
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code>
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/2.8.0</tt>
##:''git tag -a version/2.8.0'' (Enter a wise comment)
##Create the release branches on simgear, flightgear and fgdata named <tt>release/2.8.0</tt>
##:''git branch release/2.8.0''
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.8.0 -> 2.9.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"
##:''git tag -a version/2.9.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.8.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.9.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##: Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/2.8.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.8.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.8.0-final''
##Merge the branch release/2.8.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.8.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file
** <s>edit ''CMakeLists.txt''</s>
**: <s>change the line '''find_package(SimGear 2.5.0 REQUIRED)'''</s>
** <s>edit ''src/Main/options.cxx''</s>
**: <s>change the line '''static char required_version[] = "2.5.0";'''</s>
** <s>edit configure.ac</s> (Obsolete, automake is gone)
**: <s>change the line '''AC_MSG_CHECKING([for SimGear 2.5.0 or newer])'''</s>

=== Definition of repository states ===
* Open/Green
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].

=== Tasks and owners ===
{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
|-
! rowspan="6" |
| Announce the state-change of the dev-streams
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat
|-
| Distribute files to download servers
| Curt
|-
! Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Changelog 2.8.0]]
| All developers
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

=== Open items, questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons learned ===
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Release plan

2012-06-17T20:42:00Z

ThorstenB: /* Detailed time schedule and checklist */ as discussed with Torsten: bump version when "next" declared frozen

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General release concept ===
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 => current development stream is 2.7.0, next official release is 2.8.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed time schedule and checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state
##Create a "release preperations" topic at the forum and make it a "Global Announcement"
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.7.0 -> 2.8.0)
##:Compile and test drive FlightGear with the new version-number
##:Commit the new version number to next (flightgear+simgear) and master(fgdata)
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"
##Post an update to the forum topic
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code>
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/2.8.0</tt>
##:''git tag -a version/2.8.0'' (Enter a wise comment)
##Create the release branches on simgear, flightgear and fgdata named <tt>release/2.8.0</tt>
##:''git branch release/2.8.0''
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.8.0 -> 2.9.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"
##:''git tag -a version/2.9.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.8.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.8.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.9.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##: Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/2.8.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.8.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.8.0-final''
##Merge the branch release/2.8.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.8.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file
** <s>edit ''CMakeLists.txt''</s>
**: <s>change the line '''find_package(SimGear 2.5.0 REQUIRED)'''</s>
** <s>edit ''src/Main/options.cxx''</s>
**: <s>change the line '''static char required_version[] = "2.5.0";'''</s>
** <s>edit configure.ac</s> (Obsolete, automake is gone)
**: <s>change the line '''AC_MSG_CHECKING([for SimGear 2.5.0 or newer])'''</s>

=== Definition of repository states ===
* Open/Green
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].

=== Tasks and owners ===
{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
|-
! rowspan="6" |
| Announce the state-change of the dev-streams
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat
|-
| Distribute files to download servers
| Curt
|-
! Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Changelog 2.8.0]]
| All developers
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

=== Open items, questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons learned ===
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

[[Category:Core developer documentation]]
[[Category:FlightGear]]

FlightGear Newsletter May 2012

2012-05-06T16:13:05Z

ThorstenB: /* Development news */

Howto:Translate FlightGear

2012-05-06T16:02:17Z

ThorstenB:

How to '''translate [[FlightGear]]''''s menus and messages to your language.

# Check whether your language already has a subdirectory below <tt> [[$FG_ROOT]]/translations/</tt>. Also check the master repository [https://www.gitorious.org/fg/fgdata/trees/master/Translations fgdata/Translations] - maybe someone has just recently created the language resources.
#* The two letter language code can be obtained from the [http://www.loc.gov/standards/iso639-2/php/code_list.php ISO 639 list]. If it does exist, skip to step 2, else do the following:
## Create an empty directory with your language's code.
## Download the latest English language resources from [https://www.gitorious.org/fg/fgdata/trees/master/Translations/en fgdata/Translations/en].
## Copy all the downloaded files to the directory of your language (e.g. "menu.xml" and "options.xml").
# Translate the English strings in your language's xml files.
#* '''Do not''' translate the filenames!
#* Please do not change the order, structure or indentation of the XML files - only translate the English text content itself. This helps with future maintenance when the language resource need to be updated for another FG version, since the files can more easily be compared with the default English resource.
# Edit the file <tt>[[$FG_ROOT]]/Translations/locale.xml</tt> and add the section for your language.
# Start FlightGear
#* FlightGear selects the language resource based on your computer's main language setting (operations system's locale).
#* When FlightGear does not select your preferred language automatically (i.e. you have configured your machine to another language), you can explicitly select a language using the command-line switch <code>--language=<language code></code>, or, when starting via [[FGRun]], select the language at <tt>Advanced > General</tt>.

=== Supported Versions ===
Menu translations are only supported as of FG 2.7.0 and later.

=== Supported Character Sets ===
Currently, FlightGear has very limited character set support. Only plain [http://en.wikipedia.org/w/index.php?title=American_Standard_Code_for_Information_Interchange&section=5#ASCII_printable_characters ASCII] characters and its [http://en.wikipedia.org/wiki/Latin1 Latin1/ISO-8859-1] extension are supported - which covers Western European languages only (Portuguese to German, Italian to Norwegian).

However, FlightGear's GUI is currently being reworked (PLIB is ported to OSG). Once the work is complete, it should be possible to support arbitrary fonts and languages - so even Russian, Japanese, Chinese, ... fonts will be supported.

== Related content ==
* [[Howto: Translate FlightGear Launch Control‎‎]]

[[Category:Howto|Translate FlightGear]]

Howto:Translate FlightGear

2012-05-06T15:37:12Z

ThorstenB: Some updates and corrections

How to '''translate [[FlightGear]]''''s menus and messages to your language.

# Check whether your language already has a subdirectory below <tt> [[$FG_ROOT]]/translations/</tt>. The two letter language code can be obtained from the [http://www.loc.gov/standards/iso639-2/php/code_list.php ISO 639 list]. If it does exist, skip to step 2, else do the following:
## Create an empty directory with your language's code.
## Copy all files from <tt>[[$FG_ROOT]]/translations/en/</tt> to the directory of your language (e.g. "menu.xml" and "options.xml").
# Translate the English strings in your language's xml files.
#* '''Do not''' translate the filenames!
#* Please do not change the order, structure or indentation of the XML files - only translate the English text content itself. This helps with future maintenance when the language resource need to be updated for another FG version, since the files can more easily be compared with the default English resource.
# Edit the file <tt>[[$FG_ROOT]]/Translations/locale.xml</tt> and add the section for your language.
# Start FlightGear
#* FlightGear selects the language resource based on your computer's main language setting (operations system's locale).
#* When FlightGear does not select your preferred language automatically (i.e. you have configured your machine to another language), you can explicitly select a language using the command-line switch <code>--language=<language code></code>, or, when starting via [[FGRun]], select the language at <tt>Advanced > General</tt>.

=== Supported Versions ===
Menu translations are only supported as of FG 2.7.0 and later.

=== Supported Character Sets ===
Currently, FlightGear has very limited character set support. Only plain [http://en.wikipedia.org/w/index.php?title=American_Standard_Code_for_Information_Interchange&section=5#ASCII_printable_characters ASCII] characters and its [http://en.wikipedia.org/wiki/Latin1 Latin1/ISO-8859-1] extension are supported - which covers Western European languages only (Portuguese to German, Italian to Norwegian).

However, FlightGear's GUI is currently being reworked (PLIB is ported to OSG). Once the work is complete, it should be possible to support arbitrary fonts and languages - so even Russian, Japanese, Chinese, ... fonts will be supported.

== Related content ==
* [[Howto: Translate FlightGear Launch Control‎‎]]

[[Category:Howto|Translate FlightGear]]

Current events

2012-03-08T20:25:40Z

ThorstenB: Well, let's hope - at least...

This page lists events directly, or indirectly, related to [[FlightGear]]. Please note that FlightGear is not being advertised at all of these events, but feel free to spread the word when you visit an event ;)

Upcoming and past [[multiplayer]] events can be found in the [http://www.flightgear.org/calendar.html FlightGear MP Event calendar].

'''Feel free to add events that are linked to FlightGear.'''

== Upcoming events ==
* 2012
** '''May 23-26:''' [http://www.linuxtag.org/ LinuxTag Berlin] at the ''Messegelände unter dem Funkturm'', Berlin, Germany.
** '''November 3+4 2012:''' [[FSweekend 2012]] at [[Aviodrome]] ([[Lelystad Airport]], the Netherlands)
*** As of yet it is uncertain whether this event will continue, due to the museum being bankrupt.

== Past events ==
* '''2011'''
** '''November 5+6 2011:''' [[FSweekend 2011]] at [[Aviodrome]] ([[Lelystad Airport]], the Netherlands)
*** [[FlightGear Newsletter November 2011#FSweekend 2011|Event report]]
** '''May 11-14:''' [http://www.linuxtag.org/ LinuxTag Berlin] at the ''Messegelände unter dem Funkturm'', Berlin, Germany.
*** [[FlightGear Newsletter May 2011#LinuxTag 2011|Event report]]
* '''2010'''
** '''November 6+7:''' [[FSweekend 2010]] at [[Aviodrome]] ([[Lelystad Airport]], the Netherlands)
*** [[FlightGear Newsletter November 2010#FSweekend|Event report]]
*** [http://www.dropbox.com/gallery/7455889/1/FSWeekend2010?h=0e9825 Pictures]
** '''August 28+29:''' [http://www.astrasimexpo.co.uk/ Summer Sim 2010] at the Royal Air Force Museum, Cosford, United Kingdom
** '''July 6-11:''' [http://2010.rmll.info/?lang=en Libre Software Meeting] in Bordeaux, France
** '''June 9-12:''' [http://www.linuxtag.org/ LinuxTag Berlin] at the ''Messegelände unter dem Funkturm'', Berlin, Germany
** '''May 15+16:''' [http://www.fscweston.co.uk/ Flight Simulator Convention 2010] at the Helicopter Museum in Weston Super Mare, North Somerset, United Kingdom
* '''2009'''
** '''November 7+8:''' [[FSweekend 2009]] at [[Aviodrome]] ([[Lelystad Airport]], the Netherlands)
*** [[FlightGear Newsletter November 2009#FSweekend|Event report]]
*** [http://www.xs4all.nl/~dtalsma/FSWeekend/web/ Pictures]
** '''June 24-27:''' [http://www.linuxtag.org/ LinuxTag Berlin] at the Messegelände unter dem Funkturm, Berlin, Germany
* '''2008'''
** '''November 1+2:''' [[FSweekend]] at [[Aviodrome]] ([[Lelystad Airport]], the Netherlands)
*** [http://www.t3r.de/flightpics/fsweekend2008/ Pictures]
** '''May 28-31:''' [http://www.linuxtag.org/2008 LinuxTag] at Berlin's Messezentrum unter dem Funkturm. The world's No. 1 Linux Expo and Conference since 1996
*** [http://www.t3r.de/linuxtag/ Pictures]
*** [http://durktalsma.xs4all.nl/LinuxTag2008/web/index.html Pictures]
** '''February 8-10:''' [http://www.socallinuxexpo.org Southern California Linux Expo] in The Westin Hotel (Los Angeles, CA, United States)
* '''2007'''
** '''November 3+4:''' [[FSweekend]] at Aviodrome (Lelystad Airport, the Netherlands)
*** [http://durktalsma.xs4all.nl/FSWeekend2007/web/index.html Pictures]
** '''May 30-June 2:''' [http://www.linuxtag.org/2007 LinuxTag] at Berlin's Messezentrum unter dem Funkturm. The world's No. 1 Linux Expo and Conference since 1996
* '''2006'''
** '''November 4+5:''' [[FSweekend]] at Aviodrome (Lelystad Airport, the Netherlands)

[[Category:List]]
[[Category:Community]]
[[Category:Events]]

Release plan

2012-02-16T20:23:23Z

ThorstenB: /* Detailed Time Schedule and Checklist */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This release plan was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General Release Concept ===
New FlightGear releases will be scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch will be created for SimGear, FlightGear and FGDATA.

After branching, we will allow one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA will take place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA will be set into a frozen state one month before the branch-day (17th) to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version Numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.4.0 => current development stream is 2.5.0, next official release is 2.6.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed Time Schedule and Checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
#:Send a mail to the flightgear-devel mailing-list to announce the state
#:Create a "release preperations" topic at the forum and make it a "Global Announcement"
#:Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:frozen}}</nowiki></tt>
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"
##Post an update to the forum topic
##Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:closed}}</nowiki></tt>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.5.0 -> 2.6.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
##Tag (annotated) flightgear, simgear and fgdata with "version/2.6.0"
##:''git tag -a version/2.6.0'' (Enter a wise comment)
##Create the release branches on simgear, flightgear and fgdata named release/2.6.0
##:''git branch release/2.6.0''
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.6.0 -> 2.7.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.7.0"
##:''git tag -a version/2.7.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.6.0 '''and''' the tags upstream
##:for flightgear, simgear and fgdata: ''git push origin release/2.6.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.6.0''
##:for flightgear, simgear and fgdata: ''git push origin version/2.7.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##: Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:open}}</nowiki></tt>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''get_started.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''.
##Tag the release/2.6.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.6.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0-final''
##Merge the branch release/2.6.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.6.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file
** <s>edit ''CMakeLists.txt''</s>
**: <s>change the line '''find_package(SimGear 2.5.0 REQUIRED)'''</s>
** <s>edit ''src/Main/options.cxx''</s>
**: <s>change the line '''static char required_version[] = "2.5.0";'''</s>
** <s>edit configure.ac</s> (Obsolete, automake is gone)
**: <s>change the line '''AC_MSG_CHECKING([for SimGear 2.5.0 or newer])'''</s>

=== Definition of Repository States ===
* Open/Green
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.6.0.
A fix goes into release/2.6.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.6.0 branch.

'''DO NOT''' merge next into release/2.6.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug Tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.6.0 the list of fixed bugs].

=== Legacy ===
The branch for version 2.2.0 will be left untouched. No release has ever been created from this branch.

The last official release was made from branch ''release/2.4.0'', tag ''version/2.4.0-final''.

If everything goes well, version 2.6.0 will be available around Feb, 18th 2012.

=== Tasks and Owners ===
(taskowners not yet assigned)
* Announce the state-change of the dev-streams
* Create/maintain the git branches
* Track the bugs on the tracker, trigger developers, adjust bug-priorities
* Beta testing
* Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
* Pack RC and final version of FGDATA
* Create the RC and final version (source-tarball)
* Create the RC and final version for Linux
* Create the RC and final version for Windows
* Create the RC and final version for MacOS
* Distribute files to download servers
* Make adjustments on the web-site
** Collect/make screenshots for the gallery
* Announce the new version to the public
** Write a changelog: [[Changelog 2.6.0]]
** Contact flightsim websites and send them/link them to the "press announcement"

=== Open Items, Questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons Learned ===
This is a list of lessons learned from the previous release, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* Good: feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* Not so good: feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* Not so good: switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* Not so good: manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.

Howto:Use the system monitor

2012-02-12T15:19:31Z

ThorstenB: /* The system monitor */

== The system monitor ==

[[File:System-performance-monitor-fg260.png|400px|thumb|Screen shot showing the system performance monitor available in FG 2.6.0+]]

In FlightGear >= 2.6.0, use the menu option '''Debug''' => '''Monitor System Performance''' to analyze stutters.

In a perfect world, min/max/mean values should be almost identical for every subsystem - and standard deviation should be almost 0. Larger differences / high standard deviations result in a sloppy simulation and stuttering movements, though they'll hardly influence the frames-per-second value at all.

Also, imagine a system producing 100 frames in 0.5 seconds, then blocking completely for another 0.5 seconds. The fps display would still show "100fps", which seems great. But the 0.5 second stutter cause the visual performance to be terrible. That's why I prefer to display "(worst-case) frame spacing" instead of fps (View => Display Options => Show frame spacing). The frame spacing for the previous example would show "500ms", while a system producing 100 frames with perfectly even spacing would show "10ms".

So, frame spacing is a much better property to judge visual quality than just watching fps.

The new GUI dialog is available in the menu: "'''Debug'''" => "'''Monitor system performance'''".

* Only statistics on our "subsystems" are shown. That's the FG modules running in our single-threaded main loop. Everything outside the main loop isn't shown, i.e. there are no statistics on the GPU or OSG rendering threads (use the OSG statistics screen for these).

* Title bar shows average and worst case frame rate. In a perfect world, all frames should be spaced evenly, so both values should be almost identical. When frames are produced unevenly, then a larger difference between the worst and average frame rate is visible. Needless to say, we should try to get FG to deliver frames evenly, so movements look smooth.

* Main table shows statistics on the individual subsystems. Helps to identify how much tme certain systems currently consume, or which are responsible for jitters resulting in uneven frame rates.

* A bit background on the FG subsystems may be necessary though to really judge what's going on:
** For example, you'll see the "nasal" subsystem consuming almost no time at all, so it looks great. However, almost all the nasal code runs in timers, and timers are driven by the "events" subsystem. So, to judge Nasal performance, you'll mainly need to look at "events" (and yes, you'll see time being consumed and jitters being produced there, which is related due to Nasal's current MARK/SWEEP Garbage Collector implementation, i.e. see: [[Improving Nasal]]).
** The "tile-manager" an "ai-model" subsystems may also contain time consumed by the Nasal engine, since each scenery tile and each AI/MP aircraft may trigger a Nasal script ("load"/"unload" hooks).

* At the moment, it is unfortunately not yet possible to get timing statistics for individual Nasal scripts or sub modules, but this is something that has been requested by a number of users and so we are looking into making this possible eventually.

* Statistics data is only collected while the dialog is open (or you manually set /sim/performance-monitor/enabled).

Anyway, this alone isn't improving anything yet, but having a GUI to conveniently monitor performance will hopefully help us to see where exactly we're having issues - and help us to improve...

= Debugging stuttering =

To put it simple, vertex shader performance is affected by the amount of detail visible in the geometry of scene (number of vertices visible), and of course shader complexity itself, while fragment performance is affected by screen resolution(or widow size if you run it windowed) and shader complexity as well. They both affect framerate in the end, since the frame needs to be finished before being put up for display.
Frame delay might be affected by a lot of other stuff, but it's a better measure of smoothness since it displays the "longest" time it had to wait for a frame in a certain amount of time.
There might be some performance lost in high detail scenes, due to the culling (visibility check, and hiding of faces facing away from the camera, or being behind other faces, or too small to display (openscenegraph is smart about that one and it won't "display" faces/parts of objects that would end up too small)) that needs to be done on the scene before it goes through the shaders.

To test if it's a graphics performance issue, you'd do a couple of tests.:

First load up the ufo, oevr detailed scenery, remain static, don't move the view around. Check framerate and frame delay. If they're consistent with each other it might be a graphics performance issue, if not you can be sure there's some other subsystem that does background processing and needs to finish it's stuff.

Move the view around, do you get stutters? If you do, then there's some pressure on your video card's RAM. As it needs to load the new geometry and textures that come into view, it might not have enough space left, so it might need to offload the "old" ones. Even like this framerate should stabilise once you stop moving the view around, or once the rate of movement is slow enough so that the video card can keep up.

Fly straight and level, at reasonable speeds, keeping the view fixed. Do you get stutters? Is framerate consistent with frame delay? If it is, and you get low fps, again it might be a graphics issue, as new random objects come into view and/or the trees shader creates new ones in the distance. If not I's still suspect another susbsytem being the culprit.

You can repeat these with some aircraft, see if and how things change.

In short: if the framerate '''varies along with the Frame Delay''', then it's a graphics performance issue. If framerate is pretty stable, and Frame Delay '''varies more or less wildly''' I'd suspect some other subsystem being the culprit and causing more or less periodic delays as it needs to do it's stuff.

= Interpreting the OSG on screen stats =

[[Image:OSG-OnScreen-Stats.png|thumb|400px|Screenshot showing the OSG on screen stats]]

You can also try to play with osg's frame statistics, you can switch that on from the debug menu.

Being CPU and draw limited means the yellow bar is long. And the blue one grows when cull happens
to be a problem.

A simple help is to switch on the onscreen stats in the viewer or flightgear and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu.
Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease!

Once your orange bar is longer than the yellow one, you can start to care for
the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very
different on the same shader.

And regarding all that, even if your box already is gpu bound this does not mean that other driver/hardware combinations are gpu bound too. Always: As much as needed and as few as possible.

== References ==
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35202.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35917.html

Howto:Use the system monitor

2012-02-12T15:19:03Z

ThorstenB:

== The system monitor ==

[[File:System-performance-monitor-fg260.png|400px|thumb|Screen shot showing the system performance monitor available in FG 2.6.0+]]

In FlightGear => 2.6.0, use the menu option '''Debug''' => '''Monitor System Performance''' to analyze stutters.

In a perfect world, min/max/mean values should be almost identical for every subsystem - and standard deviation should be almost 0. Larger differences / high standard deviations result in a sloppy simulation and stuttering movements, though they'll hardly influence the frames-per-second value at all.

Also, imagine a system producing 100 frames in 0.5 seconds, then blocking completely for another 0.5 seconds. The fps display would still show "100fps", which seems great. But the 0.5 second stutter cause the visual performance to be terrible. That's why I prefer to display "(worst-case) frame spacing" instead of fps (View => Display Options => Show frame spacing). The frame spacing for the previous example would show "500ms", while a system producing 100 frames with perfectly even spacing would show "10ms".

So, frame spacing is a much better property to judge visual quality than just watching fps.

The new GUI dialog is available in the menu: "'''Debug'''" => "'''Monitor system performance'''".

* Only statistics on our "subsystems" are shown. That's the FG modules running in our single-threaded main loop. Everything outside the main loop isn't shown, i.e. there are no statistics on the GPU or OSG rendering threads (use the OSG statistics screen for these).

* Title bar shows average and worst case frame rate. In a perfect world, all frames should be spaced evenly, so both values should be almost identical. When frames are produced unevenly, then a larger difference between the worst and average frame rate is visible. Needless to say, we should try to get FG to deliver frames evenly, so movements look smooth.

* Main table shows statistics on the individual subsystems. Helps to identify how much tme certain systems currently consume, or which are responsible for jitters resulting in uneven frame rates.

* A bit background on the FG subsystems may be necessary though to really judge what's going on:
** For example, you'll see the "nasal" subsystem consuming almost no time at all, so it looks great. However, almost all the nasal code runs in timers, and timers are driven by the "events" subsystem. So, to judge Nasal performance, you'll mainly need to look at "events" (and yes, you'll see time being consumed and jitters being produced there, which is related due to Nasal's current MARK/SWEEP Garbage Collector implementation, i.e. see: [[Improving Nasal]]).
** The "tile-manager" an "ai-model" subsystems may also contain time consumed by the Nasal engine, since each scenery tile and each AI/MP aircraft may trigger a Nasal script ("load"/"unload" hooks).

* At the moment, it is unfortunately not yet possible to get timing statistics for individual Nasal scripts or sub modules, but this is something that has been requested by a number of users and so we are looking into making this possible eventually.

* Statistics data is only collected while the dialog is open (or you manually set /sim/performance-monitor/enabled).

Anyway, this alone isn't improving anything yet, but having a GUI to conveniently monitor performance will hopefully help us to see where exactly we're having issues - and help us to improve...

= Debugging stuttering =

To put it simple, vertex shader performance is affected by the amount of detail visible in the geometry of scene (number of vertices visible), and of course shader complexity itself, while fragment performance is affected by screen resolution(or widow size if you run it windowed) and shader complexity as well. They both affect framerate in the end, since the frame needs to be finished before being put up for display.
Frame delay might be affected by a lot of other stuff, but it's a better measure of smoothness since it displays the "longest" time it had to wait for a frame in a certain amount of time.
There might be some performance lost in high detail scenes, due to the culling (visibility check, and hiding of faces facing away from the camera, or being behind other faces, or too small to display (openscenegraph is smart about that one and it won't "display" faces/parts of objects that would end up too small)) that needs to be done on the scene before it goes through the shaders.

To test if it's a graphics performance issue, you'd do a couple of tests.:

First load up the ufo, oevr detailed scenery, remain static, don't move the view around. Check framerate and frame delay. If they're consistent with each other it might be a graphics performance issue, if not you can be sure there's some other subsystem that does background processing and needs to finish it's stuff.

Move the view around, do you get stutters? If you do, then there's some pressure on your video card's RAM. As it needs to load the new geometry and textures that come into view, it might not have enough space left, so it might need to offload the "old" ones. Even like this framerate should stabilise once you stop moving the view around, or once the rate of movement is slow enough so that the video card can keep up.

Fly straight and level, at reasonable speeds, keeping the view fixed. Do you get stutters? Is framerate consistent with frame delay? If it is, and you get low fps, again it might be a graphics issue, as new random objects come into view and/or the trees shader creates new ones in the distance. If not I's still suspect another susbsytem being the culprit.

You can repeat these with some aircraft, see if and how things change.

In short: if the framerate '''varies along with the Frame Delay''', then it's a graphics performance issue. If framerate is pretty stable, and Frame Delay '''varies more or less wildly''' I'd suspect some other subsystem being the culprit and causing more or less periodic delays as it needs to do it's stuff.

= Interpreting the OSG on screen stats =

[[Image:OSG-OnScreen-Stats.png|thumb|400px|Screenshot showing the OSG on screen stats]]

You can also try to play with osg's frame statistics, you can switch that on from the debug menu.

Being CPU and draw limited means the yellow bar is long. And the blue one grows when cull happens
to be a problem.

A simple help is to switch on the onscreen stats in the viewer or flightgear and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu.
Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease!

Once your orange bar is longer than the yellow one, you can start to care for
the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very
different on the same shader.

And regarding all that, even if your box already is gpu bound this does not mean that other driver/hardware combinations are gpu bound too. Always: As much as needed and as few as possible.

== References ==
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35202.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35917.html

Howto:Use the system monitor

2012-02-12T15:06:22Z

ThorstenB: /* The system monitor */

== The system monitor ==

[[File:System-performance-monitor-fg260.png|400px|thumb|Screen shot showing the system performance monitor available in FG 2.60+]]

In FlightGear => 2.60, use the menu option '''Debug''' => '''Monitor System Performance''' to analyze stutters.

In a perfect world, min/max/mean values should be almost identical for every subsystem - and standard deviation should be almost 0. Larger differences / high standard deviations result in a sloppy simulation and stuttering movements, though they'll hardly influence the frames-per-second value at all.

Also, imagine a system producing 100 frames in 0.5 seconds, then blocking completely for another 0.5 seconds. The fps display would still show "100fps", which seems great. But the 0.5 second stutter cause the visual performance to be terrible. That's why I prefer to display "(worst-case) frame spacing" instead of fps (View => Display Options => Show frame spacing). The frame spacing for the previous example would show "500ms", while a system producing 100 frames with perfectly even spacing would show "10ms".

So, frame spacing is a much better property to judge visual quality than just watching fps.

The new GUI dialog is available in the menu: "'''Debug'''" => "'''Monitor system performance'''".

* Only statistics on our "subsystems" are shown. That's the FG modules running in our single-threaded main loop. Everything outside the main loop isn't shown, i.e. there are no statistics on the GPU or OSG rendering threads (use the OSG statistics screen for these).

* Title bar shows average and worst case frame rate. In a perfect world, all frames should be spaced evenly, so both values should be almost identical. When frames are produced unevenly, then a larger difference between the worst and average frame rate is visible. Needless to say, we should try to get FG to deliver frames evenly, so movements look smooth.

* Main table shows statistics on the individual subsystems. Helps to identify how much tme certain systems currently consume, or which are responsible for jitters resulting in uneven frame rates.

* A bit background on the FG subsystems may be necessary though to really judge what's going on:
** For example, you'll see the "nasal" subsystem consuming almost no time at all, so it looks great. However, almost all the nasal code runs in timers, and timers are driven by the "events" subsystem. So, to judge Nasal performance, you'll mainly need to look at "events" (and yes, you'll see time being consumed and jitters being produced there, which is related due to Nasal's current MARK/SWEEP Garbage Collector implementation, i.e. see: [[Improving Nasal]]).
** The "tile-manager" an "ai-model" subsystems may also contain time consumed by the Nasal engine, since each scenery tile and each AI/MP aircraft may trigger a Nasal script ("load"/"unload" hooks).

* At the moment, it is unfortunately not yet possible to get timing statistics for individual Nasal scripts or sub modules, but this is something that has been requested by a number of users and so we are looking into making this possible eventually.

* Statistics data is only collected while the dialog is open (or you manually set /sim/performance-monitor/enabled).

Anyway, this alone isn't improving anything yet, but having a GUI to conveniently monitor performance will hopefully help us to see where exactly we're having issues - and help us to improve...

= Debugging stuttering =

To put it simple, vertex shader performance is affected by the amount of detail visible in the geometry of scene (number of vertices visible), and of course shader complexity itself, while fragment performance is affected by screen resolution(or widow size if you run it windowed) and shader complexity as well. They both affect framerate in the end, since the frame needs to be finished before being put up for display.
Frame delay might be affected by a lot of other stuff, but it's a better measure of smoothness since it displays the "longest" time it had to wait for a frame in a certain amount of time.
There might be some performance lost in high detail scenes, due to the culling (visibility check, and hiding of faces facing away from the camera, or being behind other faces, or too small to display (openscenegraph is smart about that one and it won't "display" faces/parts of objects that would end up too small)) that needs to be done on the scene before it goes through the shaders.

To test if it's a graphics performance issue, you'd do a couple of tests.:

First load up the ufo, oevr detailed scenery, remain static, don't move the view around. Check framerate and frame delay. If they're consistent with each other it might be a graphics performance issue, if not you can be sure there's some other subsystem that does background processing and needs to finish it's stuff.

Move the view around, do you get stutters? If you do, then there's some pressure on your video card's RAM. As it needs to load the new geometry and textures that come into view, it might not have enough space left, so it might need to offload the "old" ones. Even like this framerate should stabilise once you stop moving the view around, or once the rate of movement is slow enough so that the video card can keep up.

Fly straight and level, at reasonable speeds, keeping the view fixed. Do you get stutters? Is framerate consistent with frame delay? If it is, and you get low fps, again it might be a graphics issue, as new random objects come into view and/or the trees shader creates new ones in the distance. If not I's still suspect another susbsytem being the culprit.

You can repeat these with some aircraft, see if and how things change.

In short: if the framerate '''varies along with the Frame Delay''', then it's a graphics performance issue. If framerate is pretty stable, and Frame Delay '''varies more or less wildly''' I'd suspect some other subsystem being the culprit and causing more or less periodic delays as it needs to do it's stuff.

= Interpreting the OSG on screen stats =

[[Image:OSG-OnScreen-Stats.png|thumb|400px|Screenshot showing the OSG on screen stats]]

You can also try to play with osg's frame statistics, you can switch that on from the debug menu.

Being CPU and draw limited means the yellow bar is long. And the blue one grows when cull happens
to be a problem.

A simple help is to switch on the onscreen stats in the viewer or flightgear and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu.
Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease!

Once your orange bar is longer than the yellow one, you can start to care for
the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very
different on the same shader.

And regarding all that, even if your box already is gpu bound this does not mean that other driver/hardware combinations are gpu bound too. Always: As much as needed and as few as possible.

== References ==
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35202.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35917.html

Release plan

2012-01-31T20:44:00Z

ThorstenB: /* To bump up the version number */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This release plan was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General Release Concept ===
New FlightGear releases will be scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch will be created for SimGear, FlightGear and FGDATA.

After branching, we will allow one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA will take place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA will be set into a frozen state one month before the branch-day (17th) to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version Numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.4.0 => current development stream is 2.5.0, next official release is 2.6.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed Time Schedule and Checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
#:Send a mail to the flightgear-devel mailing-list to announce the state
#:Create a "release preperations" topic at the forum and make it a "Global Announcement"
#:Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:frozen}}</nowiki></tt>
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"
##Post an update to the forum topic
##Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:closed}}</nowiki></tt>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.5.0 -> 2.6.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
##Tag (annotated) flightgear, simgear and fgdata with "version/2.6.0"
##:''git tag -a version/2.6.0'' (Enter a wise comment)
##Create the release branches on simgear, flightgear and fgdata named release/2.6.0
##:''git branch release/2.6.0''
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.6.0 -> 2.7.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.7.0"
##:''git tag -a version/2.7.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.6.0 '''and''' the tags upstream
##:for flighgear, simgear and fgdata: ''git push origin release/2.6.0''
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0''
##:for flighgear, simgear and fgdata: ''git push origin version/2.7.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##: Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:open}}</nowiki></tt>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch
##Tag the release/2.6.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.6.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0-final''
##Merge the branch release/2.6.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.6.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file
** <s>edit ''CMakeLists.txt''</s>
**: <s>change the line '''find_package(SimGear 2.5.0 REQUIRED)'''</s>
** <s>edit ''src/Main/options.cxx''</s>
**: <s>change the line '''static char required_version[] = "2.5.0";'''</s>
** <s>edit configure.ac</s> (Obsolete, automake is gone)
**: <s>change the line '''AC_MSG_CHECKING([for SimGear 2.5.0 or newer])'''</s>

=== Definition of Repository States ===
* Open/Green
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.6.0.
A fix goes into release/2.6.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.6.0 branch.

'''DO NOT''' merge next into release/2.6.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug Tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.6.0 the list of fixed bugs].

=== Legacy ===
The branch for version 2.2.0 will be left untouched. No release has ever been created from this branch.
The last official release was made from branch ''release/2.4.0'', tag ''version/2.4.0-final''.
If everything goes well, version 2.6.0 will be available around Jan, 18th 2012.

=== Tasks and Owners ===
(taskowners not yet assigned)
* Announce the state-change of the dev-streams
* Create/maintain the git branches
* Track the bugs on the tracker, trigger developers, adjust bug-priorities
* Beta testing
* Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
* Pack RC and final version of FGDATA
* Create the RC and final version (source-tarball)
* Create the RC and final version for Linux
* Create the RC and final version for Windows
* Create the RC and final version for MacOS
* Distribute files to download servers
* Make adjustments on the web-site
** Collect/make screenshots for the gallery
* Announce the new version to the public
** Write a changelog: [[Changelog 2.6.0]]
** Contact flightsim websites and send them/link them to the "press announcement"

=== Open Items, Questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons Learned ===
This is a list of lessons learned from the previous release, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* Good: feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* Not so good: feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* Not so good: switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* Not so good: manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.

Release plan

2012-01-31T20:26:02Z

ThorstenB: /* Version Numbers */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This release plan was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General Release Concept ===
New FlightGear releases will be scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch will be created for SimGear, FlightGear and FGDATA.

After branching, we will allow one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA will take place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA will be set into a frozen state one month before the branch-day (17th) to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version Numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.4.0 => current development stream is 2.5.0, next official release is 2.6.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed Time Schedule and Checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
#:Send a mail to the flightgear-devel mailing-list to announce the state
#:Create a "release preperations" topic at the forum and make it a "Global Announcement"
#:Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:frozen}}</nowiki></tt>
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"
##Post an update to the forum topic
##Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:closed}}</nowiki></tt>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.5.0 -> 2.6.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
##Tag (annotated) flightgear, simgear and fgdata with "version/2.6.0"
##:''git tag -a version/2.6.0'' (Enter a wise comment)
##Create the release branches on simgear, flightgear and fgdata named release/2.6.0
##:''git branch release/2.6.0''
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.6.0 -> 2.7.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.7.0"
##:''git tag -a version/2.7.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.6.0 '''and''' the tags upstream
##:for flighgear, simgear and fgdata: ''git push origin release/2.6.0''
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0''
##:for flighgear, simgear and fgdata: ''git push origin version/2.7.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##: Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:open}}</nowiki></tt>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch
##Tag the release/2.6.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.6.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0-final''
##Merge the branch release/2.6.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.6.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file
** edit ''CMakeLists.txt''
**: change the line '''find_package(SimGear 2.5.0 REQUIRED)'''
** edit ''src/Main/options.cxx''
**: change the line '''static char required_version[] = "2.5.0";'''
** <s>edit configure.ac</s> (Obsolete, automake is gone)
**: <s>change the line '''AC_MSG_CHECKING([for SimGear 2.5.0 or newer])'''</s>

=== Definition of Repository States ===
* Open/Green
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.6.0.
A fix goes into release/2.6.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.6.0 branch.

'''DO NOT''' merge next into release/2.6.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug Tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.6.0 the list of fixed bugs].

=== Legacy ===
The branch for version 2.2.0 will be left untouched. No release has ever been created from this branch.
The last official release was made from branch ''release/2.4.0'', tag ''version/2.4.0-final''.
If everything goes well, version 2.6.0 will be available around Jan, 18th 2012.

=== Tasks and Owners ===
(taskowners not yet assigned)
* Announce the state-change of the dev-streams
* Create/maintain the git branches
* Track the bugs on the tracker, trigger developers, adjust bug-priorities
* Beta testing
* Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
* Pack RC and final version of FGDATA
* Create the RC and final version (source-tarball)
* Create the RC and final version for Linux
* Create the RC and final version for Windows
* Create the RC and final version for MacOS
* Distribute files to download servers
* Make adjustments on the web-site
** Collect/make screenshots for the gallery
* Announce the new version to the public
** Write a changelog: [[Changelog 2.6.0]]
** Contact flightsim websites and send them/link them to the "press announcement"

=== Open Items, Questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons Learned ===
This is a list of lessons learned from the previous release, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* Good: feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* Not so good: feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* Not so good: switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* Not so good: manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.

Release plan

2012-01-31T20:25:09Z

ThorstenB: /* Version Numbers */

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This release plan was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. Please discuss this concept at the mailing-list.

=== General Release Concept ===
New FlightGear releases will be scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch will be created for SimGear, FlightGear and FGDATA.

After branching, we will allow one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA will take place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear and FGDATA will be set into a frozen state one month before the branch-day (17th) to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

=== Version Numbers ===
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.4.0 => current development stream is 2.5.0, next stable/official release is be 2.6.0).
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).

=== Detailed Time Schedule and Checklist ===
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
#:Send a mail to the flightgear-devel mailing-list to announce the state
#:Create a "release preperations" topic at the forum and make it a "Global Announcement"
#:Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:frozen}}</nowiki></tt>
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"
##Post an update to the forum topic
##Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:closed}}</nowiki></tt>
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.5.0 -> 2.6.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear) and master(fgdata)
##Tag (annotated) flightgear, simgear and fgdata with "version/2.6.0"
##:''git tag -a version/2.6.0'' (Enter a wise comment)
##Create the release branches on simgear, flightgear and fgdata named release/2.6.0
##:''git branch release/2.6.0''
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.6.0 -> 2.7.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear and fgdata with "version/2.7.0"
##:''git tag -a version/2.7.0'' (Enter a wise comment)
##Push the branches next/master '''and''' release/2.6.0 '''and''' the tags upstream
##:for flighgear, simgear and fgdata: ''git push origin release/2.6.0''
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0''
##:for flighgear, simgear and fgdata: ''git push origin version/2.7.0''
##:for flightgear and simgear: ''git push origin next''
##:for fgdata: ''git push origin master''
##: Declare dev-streams "open" or "green"
##: Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:open}}</nowiki></tt>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch
##Tag the release/2.6.0 branches of simgear, flightgear and fgdata and push the tags.
##:for flighgear, simgear and fgdata: ''git tag version/2.6.0-final''
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0-final''
##Merge the branch release/2.6.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear and simgear:
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch
##:''git merge version/2.6.0-final
##:''git push origin master''

=== To bump up the version number ===
* fgdata
** edit the ''version'' file
* SimGear
** edit the ''version'' file
* FlightGear
** edit the ''version'' file
** edit ''CMakeLists.txt''
**: change the line '''find_package(SimGear 2.5.0 REQUIRED)'''
** edit ''src/Main/options.cxx''
**: change the line '''static char required_version[] = "2.5.0";'''
** <s>edit configure.ac</s> (Obsolete, automake is gone)
**: <s>change the line '''AC_MSG_CHECKING([for SimGear 2.5.0 or newer])'''</s>

=== Definition of Repository States ===
* Open/Green
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.
* Frozen/Yellow
*: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.
*:It's a good idea for aircraft developers to adhere to this rule. However, 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. Also, 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.
* Closed/Red
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.

=== Bug fix committing policy ===
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.6.0.
A fix goes into release/2.6.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.6.0 branch.

'''DO NOT''' merge next into release/2.6.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

=== Bug Tracking ===
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.6.0 the list of fixed bugs].

=== Legacy ===
The branch for version 2.2.0 will be left untouched. No release has ever been created from this branch.
The last official release was made from branch ''release/2.4.0'', tag ''version/2.4.0-final''.
If everything goes well, version 2.6.0 will be available around Jan, 18th 2012.

=== Tasks and Owners ===
(taskowners not yet assigned)
* Announce the state-change of the dev-streams
* Create/maintain the git branches
* Track the bugs on the tracker, trigger developers, adjust bug-priorities
* Beta testing
* Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
* Pack RC and final version of FGDATA
* Create the RC and final version (source-tarball)
* Create the RC and final version for Linux
* Create the RC and final version for Windows
* Create the RC and final version for MacOS
* Distribute files to download servers
* Make adjustments on the web-site
** Collect/make screenshots for the gallery
* Announce the new version to the public
** Write a changelog: [[Changelog 2.6.0]]
** Contact flightsim websites and send them/link them to the "press announcement"

=== Open Items, Questions ===
* Automate the creation of Windows and Mac installers
* Automate the creation of FGDATA distribution

=== Lessons Learned ===
This is a list of lessons learned from the previous release, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.
* Good: feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* Not so good: feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* Not so good: switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* Not so good: manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.

Building FlightGear - Linux

2012-01-29T22:39:20Z

ThorstenB: easier link to SUSE repo

{{Main article|Building Flightgear}}

This section describes how to build [[FlightGear]] on Linux system.

Compiling FlightGear is not a task for novice users. Thus, if you're a beginner (we all were once) on a platform which binaries are available for, we recommend postponing this task and just starting with the binary distribution to get you flying.

openSUSE also provides binary packages of the latest development version, which are continuously updated.
Follow [http://software.opensuse.org/download.html?lang=en&project=games:FlightGear:Unstable&package=fgrun this link] to select your openSUSE version and install, or manually add ''games:FlightGear:Unstable'' to your ''YaST Software Repositories''.

Or if you develop on Ubuntu or Debian, consider trying the script described in [[Scripted Compilation on Linux Debian/Ubuntu]].

== Requirements ==
Before you can compile FlightGear, you need to have the following installed on your computer:

'''C++ compiler'''

These are: c++, cpp, gcc, g++ found under the /usr/bin directory. You will also need to have the tools '''autoconf''' and '''automake1.9''' installed.

'''GIT'''

See [[FlightGear and Git]].

'''[[OpenGL]] support'''

More specifically, your system needs the support for hardware accelerated graphics. You can check for this by running the following in a [[command line]]:

glxinfo | grep direct

Note: To run the above command, you need to have the tool '''mesa-utils''' installed.

You should then see:

direct rendering: Yes

This means you are good to go as far as OpenGL support is concerned.

If you see:

direct rendering: No

Don't panic yet. This may just mean some required libraries for hardware accelerated graphic are missing. Go ahead and try installing plib 1.8.5 and its dependencies first. If you still get the above message, then you will need to do some googling and troubleshoot yourself.

== Dependencies ==
FlightGear is dependent on quite a few number of libraries. You do not need to compile all of them yourself, but you will at least need to have their development version installed. For example, the development version for package plib1.8.5 is plib1.8.5'''-dev'''.

The dependency is summarized in the following tree. Please note that each library has its own dependencies, and most of these are not shown here.

* FlightGear
** [http://kcat.strangesoft.net/openal.html OpenAL]
** SimGear
*** [http://plib.sourceforge.net/ PLIB]. Since March 2008, you will need version 1.8.5 - your distro probably supplies 1.8.4 still.
**** For versions pre March 2008: (Free)GLUT or SDL (We recommend the use of SDL over Free/GLUT, [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16153.html however since March 2008, FreeGLUT as well as SDL are both considered depreciated, please only use --enable-osgviewer during configuration instead])
*** [[OpenSceneGraph]] (check link for compatible versions)
*** You also need the development files for several basic libraries to build the software, among them the following (the package names are for Debian and derivatives(?)):
**** libfreetype6-dev
**** libjpeg62-dev
**** libungif4-dev
**** libtiff4-dev
**** libpng12-dev
**** libxmu-dev
**** libxi-dev
**** zlib1g-dev
**** libglut3-dev

If you attack the above dependencies in the order listed below, you should be good:

1. Glut. Most distributions include glut packages, although you may have to hunt for them. Make sure you install both the glut and glut-devel packages, otherwise FlightGear may be able to compile but won't run correctly.

2. Zlib. Most distributions install the basic zlib libraries by default, but not the development portions. If you don't have zlib.h, you probably need to install the zlib-devel package for your distribution.

3. Plib - portability libraries and scene graph.

4. [[OpenSceneGraph]]

5. SimGear - Simulation support libraries. If you are building FlightGear from Git, you need the Git version of SimGear. If you have strange build errors, one of the first things to check is that you have an up-to-date version of SimGear built and installed.

==== APT-GET List ====
This is a list of all the apt-get commands I had to do while compiling FG, SG, and OSG on a mostly clean Ubuntu 64 system. It is a list of all the libraries you and your computer needs to compile FG, SG, OSG, and PLib. All you have to do is copy the full command, paste it in Terminal, enter your password, and it will download all the packages for you, and install them too. The full command is at the bottom, and I hope someone finds it useful :) sub-dependencies (dependencies of the dependencies) are not included as they are installed automatically by apt-get. If anyone sees something missing, please add it.

git - to get SG and FG 
subversion - to get OSG 
build-essential - to build (includes GCC, and other build tools) 
cmake - OSG Uses this 
cmake-curses-gui -- OSG Uses this 
libpng-dev - to enable FG to use PNG textures 
libfreetype6-dev - fonts 
libjpeg-dev 
libungif4-dev 
libtiff-dev 
libxmu-dev 
libxi-dev 
libglut3-dev 
libalut-dev - sound 
libboost-dev - makes coding for some developers easier 
''automake - needed by ./autogen.sh files'' 
''autoconf - needed by ./autogen.sh files'' 
libfltk1.1-dev - You will need this if you will be using FGRun 
-----------
<pre>
sudo apt-get install git subversion build-essential cmake cmake-curses-gui libpng-dev libfreetype6-dev
libjpeg-dev libungif4-dev libtiff-dev libxmu-dev libxi-dev libglut3-dev libalut-dev
libboost-dev automake autoconf libfltk1.1-dev
</pre>
-----------
Total size is about 230 MB, depending on what you already have from other applications.

This list might seem a bit short, but the sub-dependencies all add up :) The dependencies will be listed by apt-get when you use the command.
-----------
NOTE: On a Linux Mint 9 (Ubuntu 10.04) system this is the command I used:
<pre>
sudo apt-get install git-core subversion build-essential cmake cmake-curses-gui libpng-dev libfreetype6-dev libjpeg-dev libungif4-dev
libtiff-dev libxmu-dev libxi-dev libglut3-dev libalut-dev libboost-dev ''automake autoconf'' libfltk1.1-dev libplib-dev libopenscenegraph-dev
</pre>
libopenscenegraph-dev
You just need to copy that long line into a terminal and you should have all the packages you need to compile Flightgear and Simgear.

== Compiling ==
Assuming you are root, do:
cd /usr/local/src

'''Note:''' When tracking a fast changing software like FlightGear/Git it is highly advisable to install it in a separate directory. That way one can also easily build and reinstall without being root, which greatly reduces the risk of messing up one's system.
To install in a directory of your choice add the <tt>--prefix</tt> argument to configure. E.g. <tt>./configure --prefix=$HOME/FlightGear</tt>. I would recommend installing all of OSG, plib, SimGear and FlightGear with the same prefix.

=== Getting and compiling SimGear ===

'''Step 1:'''

Clone the SimGear git repository and set it up to track the 'next' branch.
git clone git://gitorious.org/fg/simgear.git

By default after cloning you should have a local next branch that tracks the master next branch. It can be updated it with git pull.

'''Step 2:'''

The source code will be downloaded into a directory called '''simgear'''.

Next, go into the directory and make preparations for the compilation:
cd simgear
''./autogen.sh''
./configure

'''Note''' that if you don't want to install simgear globally on the system but in a specific directory, you can do so by adding --prefix=/path/to/your/fgInstallation to the ./configure command

'''Step 3:'''

Compile and install SimGear by doing:
make; make install

''Note:'' with gcc 4.2 or later,on some platforms, you can get compiling errors about alc.h like:

'<anonymous>' has incomplete type
take a look at http://bugs.gentoo.org/166723

=== Getting and compiling FlightGear ===

'''Step 1:'''

Clone the FlightGear git repository and set it up to track the 'next' branch.
git clone git://gitorious.org/fg/flightgear.git

By default after cloning you should have a local next branch that tracks the master next branch. It can be updated it with git pull.

'''Step 2:'''

Next, go into the folder and make preparations for the compilation:
cd flightgear
''./autogen.sh''
./configure

Note that if you don't want to install simgear globally on the system but in a specific directory, you can do so by adding --prefix=/path/to/your/fgInstallation to the ./configure command.
If you didn't install OSG globally or in the same prefix as SimGear and FlightGear, you have to pass the OSG directory to the configure-command like this:
./configure --prefix=/path/to/fgInstallation --with-osg=/path/to/osg/installation --enable-osgviewer
In this case you have to tell your system where to find the OSG libraries before you can run flightgear:
export LD_LIBRARY_PATH=/path/to/osgInstallation/lib:$LD_LIBRARY_PATH

'''Step 3:'''

Now you can compile and install Flightgear by:
make; make install

'''Step 4:'''

Clone the data directory:
git clone git://gitorious.org/fg/fgdata.git

The data directory is large (almost 2.5GB) so it will take considerable time to download.
There mirror of fgdata that might be faster to download from:
git clone git://mapserver.flightgear.org/fgdata

The mirror is synchronized with the master so either will do.

And install it in (or as) /usr/local/share/FlightGear
mv fgdata /usr/local/share/flightgear

== Distro-specific instructions ==
=== Debian/Ubuntu ===
* You can use the [[Scripted Compilation on Linux Debian/Ubuntu]] script to have Flightgear compiled in one shot under both Ubuntu and Debian systems.
* Debian users who prefer to build it without script may look at [[Building Flightgear - Debian]].
=== Gentoo ===
* Gentoo users can also use overlays to build FlightGear without much hassle: [[Building Flightgear - Gentoo]].

== External links ==
=== Instructions ===
* [[MSYS]]
* [[MinGW/cross-compiler]]
* [[CodeBlocks IDE]]
* [[OpenSUSE 10.1 10.2]]
* [http://www.geoffmclane.com/fg/fgmsvc7.htm MSVC7 *.Net]
* [http://www.oflebbe.de/oflebbe/FlightGear/index.html MSVC8 aka Visual 2005]
* [http://macflightgear.sourceforge.net/home/documents/ Mac OS X]
== Important note for GIT users ==
As of latest development in GIT, only cmake is now required for building both SimGear and FlightGear. So if you build GIT (for what any reason) please don't try to use autogen.sh as it is removed from repository.

For detailed instructions, see page [[Building_using_CMake|Building using cmake]].

{{Building}}

FlightGear Newsletter January 2012

2012-01-29T22:14:26Z

ThorstenB: /* New openSUSE FlightGear repository */

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

=== 2.6.0 release preparations ===
On January 17, the release branches were created from our [[Git]] repositories. From then on, no new features (and aircraft) shall be pushed. Only bug fixes are accepted.

FlightGear 2.6.0 will be released on February 17!

==== Release candidates ====
In order to fix bugs we first need to identify them. That's where we create release candidates for. These are basically complete releases, meant for testing by a large group of people. As the actual release is still some time away, bugs found during these tests have a fair chance getting fixed. Do note that the earlier bugs are reported, the more time we'll have to fix them.

The release candidates are available [http://www.flightgear.org/news/flightgear-v2-6-release-candidates at our website]. Please help us create a release with a minimum amount of bugs!

=== Experiment: A new bounty system ===
If somebody would like a specific feature implemented, it will be posted in the wiki. 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 at [[Bounty (Overview)]].

== Lightfield shaders ==
As part of the ongoing efforts to make the skydome scattering [[shader]] blend seamlessly into the terrain under all conditions, substantial work on getting sunrise and sunset conditions right has been done.

The eventual solution to the problems are lightfield shaders - the shader doesn not assume a single light source for the whole scene, but computes the incident light intensity and hue for each point of the scene dependent on position and altitude. This turns out particularly tricky for the fog, as the visible fog color is really a line integral along points with very different lighting - which is too slow to do real-time, so a good approximation scheme has to be used. The development effort for the lightfield shaders is easily five times the effort for the original terrain haze shader which handles everything during daytime - which illustrates a bit how complex problems sunrises are.

The shaders handle a variety of conditions and generate spectacular scenes, from the first glow of the predawn sky, via high altitude clouds lighting up before the terrain to full daylight.

{|
|[[File:Lightfield_shader12.jpg|200px|thumb|Predawn sky light]]
|[[File:Lightfield_shader02.jpg|200px|thumb|Takeoff in predawn light]]
|[[File:Lightfield_shader05.jpg|200px|thumb|High altitude cloud glow]]
|}

Among other things, the lightfield allows mountain summits and high altitude clouds to be illuminated by morning light before the lower terrain lights up. The scene is rendered faithfully from ground level up to low Earth orbit where the terminator line becomes visible, distorted by the terrain elevation pattern. As an example, here's the Alaska range from 24.000 ft and from 240.000 ft:

{|
|[[File:Lightfield_shader01.jpg|200px|thumb|Alaska range from 24.000 ft]]
|[[File:Lightfield_shader04.jpg|200px|thumb|Alaska range from 240.000 ft]]
|}

The action of the shaders interfaces with the environment conditions. For instance, high altitude haze makes the indirect ground light more red than blue since it causes substantial backscatter to the ground.

{|
|[[File:Lightfield_shader06.jpg|200px|thumb|Sunrise without high altitude haze]]
|[[File:Lightfield_shader03.jpg|200px|thumb|Sunrise with high altitude haze]]

|}

Cloud cover blocks the incident direct light on the haze layer and cause a change in hue of the haze illumination. The Local Weather system provides the necessary interface information - for instance at the egde of a cloud layer, direct light can reach underneath the layer and illuminate the haze, causing a change in the shader response. Also, the self-shading of the haze layer leads to a different haze hue on the ground and at higher altitude.

{|
|[[File:Lightfield_shader07.jpg|200px|thumb|Sunrise in moderate cloud cover]]
|[[File:Lightfield_shader10.jpg|200px|thumb|Sunrise in thick Stratus cloud cover]]
|[[File:Lightfield_shader11.jpg|200px|thumb|Sunrise in strong cloud cover at layer edge]]
|}

For low sun, additional shading of the terrain occurs - this is not shading of the terrain itself (which would be reasonably easy to approximate) but shading of the haze by the terrain. This effect goes away when the light attenuation in the fog is too strong:

{|
|[[File:Lightfield_shader08.jpg|200px|thumb|Haze shading for high visibility]]
|[[File:Lightfield_shader09.jpg|200px|thumb|Haze shading for low visibility]]
|}

All these effects do not currently mesh with other shaders. While eventually an integration with other projects is discussed, the lightfield shader code will hopefully make its appearance on Git soon as an optional feature.

As a preview, here's what may come next - a mode detailed light attenuation model in which the darker hue of the fog beneath clouds is really prominent.

{|
|[[File:Lightfield_shader_next.jpg|200px|thumb|More detailed attenuation model]]
|}

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

== New openSUSE FlightGear repository ==
openSUSE now provides a dedicated ''FlightGear repository'' continuously delivering ready-to-use binaries of the latest development version ("Git" version) of the FlightGear Flight Simulator and many related utilities. The binaries are regularly updated (''not'' daily, but about weekly for FlightGear and a bit less often for the utilities).

The repository currently provides:
* '''FlightGear''', '''SimGear''', '''fgdata'''
* '''Atlas'''
* '''FGcom'''
* '''FGComGui'''
* '''fgms''' (multiplayer server, for local setups)
* '''TaxiDraw'''
* '''TerraGearGUI'''
* '''fgrun'''
* '''FGx'''
More utilities may be added, if someone is able to provide the necessary build script to pack the RPM.

After installation, all tools should be pretty much pre-configured, and can directly be launched from the menu.

For installation, use [http://software.opensuse.org/download.html?lang=en&project=games:FlightGear:Unstable&package=fgrun this link] to select your openSUSE version and install fgrun + flightgear. Alternatively, you can add openSUSE's ''games:FlightGear:Unstable'' repository manually. After installation, you can select and install more FG-related utilities directly from ''YaST''.

Remember, the ''Unstable'' repository always provides the latest ''development'' version, which may not be suitable for inexperienced users.

Until FlightGear 2.6.0 is released, this repository provides '''FlightGear 2.6.0 release candidates''', so you can help with testing the new release.
After the official release, FlightGear 2.6.0 and a stable version of all utilities will be available in the openSUSE ''games'' repository, while this ''Unstable'' repository keeps tracking the development versions (you could switch back to ''games'' after the 2.6.0 release).

Maybe we can find volunteers to set up a similar service for other Linux distros, or at least try to add stable versions of FlightGear and all its friend-utilities to the distros, so Linux users no longer need to compile all utilities from scratch and solve installation issues.

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we adopted 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 ===

The '''Curtiss JN-4 "Jenny"''' has been added by helijah.

* [http://helijah.free.fr/flightgear/les-appareils/jenny/appareil.htm Download page]

=== Updated aircraft ===
==== Douglas DC-3 C47 ====
The [[Douglas DC-3-C47|Douglas DC-3 C47]] has been updated by the PAF team. The improvements have mainly been made in the cockpit because that is where the pilots spend most of their time (hopefully!), but many other details have been given around.

* [http://equipe-flightgear.forumactif.com/t835-hangar-de-la-paf Download]
* [http://www.flightgear.org/forums/viewtopic.php?f=4&t=13629 Forum topic]

=== Liveries ===
All liveries that were not available as downloads have been removed from the [[livery database]]. Most of those got lost when the former server suddenly quit (all the way back in December 2009). As we were able to save the list of liveries, they ended up in the database eventough the files got lost.

To save liveries from future server failures, backups are nowadays made on a regularly basis.

== Scenery corner ==
=== Topologically clean datasets ===
[[File:IJburg_clc2000_vs_clc2006.png|thumb|270px|A Dutch artificial island currently under construction, as visualized with CLC2000 (top) and CLC2006 (lower) and [[OSM]] data.]]
Martin now has what should be topologically clean CLC2000v15 and VMap0 edition 5.0 datasets. These have been loaded into the [http://mapserver.flightgear.org/ Landcover-DB] as replacements for the old VMap0 and CLC layers.

Thanks to the great folks at GRASS GIS, most notably Markus M., the procedure of cleaning large vector datasets like [[CORINE]] is now a matter
of just a few days and runs on a machine with far less than 32 GByte of main memory! One year ago, cleaning CORINE took about one and a half
months to complete just one single (!) of multiple iterations and you never knew if somebody would reboot the server while the job was still running (which actually happened several times).

Having topologically clean datasets is a very important step for at least two reasons:
# TerraGear's overall stability is expected to increase with topologically clean vector data.
# Merging custom land cover data (like John Holden's great work) into the "Custom Scenery" layer (at MapServer) had been failing in some cases due to topological inconsistencies. These failures are expected to disappear with topologically clean vector data.
# As soon as the various tools are working in a predictable manner, the driving motivation behind all the effort can be revived, which is to build an infrastructure for re-compiling the respective terrain tiles on a regular, maybe daily schedule after the land cover has been updated in a certain region.

A clean CLC2006 is provided as well, but because that one's still incomplete (and work in progress, actually) CLC2000 is considered more important. CLC2006 focused mainly on the identification and mapping of land cover changes between 2000 and 2006.<ref>[http://sia.eionet.europa.eu/CLC2006 Corine Land Cover 2006, Eionet]</ref> All land cover changes bigger than 5 ha have been mapped. CLC2006 is significantly more up to date in some areas, as can be seen in the image on the right.

=== Shared object deletion script ===

Olivier has a new script for you: it's here: http://scenemodels.flightgear.org/submission/shared/index_delete.php

Just give the position of the shared object you want to delete, give a small comment on why you are deleting. After human validation, it will be deleted from the database and you should no more see it in Terrasync a few days later.

=== TerraGear GUI updates ===
After a couple of months of little (to none) development, Gijs released a new Windows binary of the [[TerraGear GUI]]. Other OS are supported, but require it to be build from source.

The GUI runs pretty stable now, provides helpfull error messages and can guide you through the entire process of scenery generation. Updates include:
* OpenStreetMap and CORINE2006 added to the download feature. Material suggestions are given as well for those.
* Up to date with today's TerraGear builds.
* Most tools have a progress bar to give you a live overview of the progress.
* Removed unnecessary texts and error messages.
* Resizable dialog with proper layouting.
Besides all that, several (small) bugs have been fixed.

=== Dutch windturbines ===
[[File:Prinses_Amaliawindpark_overview.png|thumb|270px|Overviewing the 60 wind turbines of Prinsess Amaliawindpark, 20km west of the Netherlands.]]
The Netherlands have slightly less than 1900 windturbines at the moment. Since this month, 757 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. Some countries even have a site similar to [http://www.w-i-n-d.nl this website] from the Dutch government, that 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.

For the offshore Prinses Amaliawindpark, a custom windturbine model has been made. Resembling the Vestas V80-2.0 MW edition. [http://scenemodels.flightgear.org/modeledit.php?id=2418 The model] can be easily re-used on other offshore windparks, via the method described above.

=== Airports ===
==== Congonhas - Brazil ====
[[File:Grupofgbrsmall.png|right]]
The Airport of Congonhas is currently being modeled, completely from scratch, by the [http://www.grupofgbr.com.br Grupo FG BR]. Download our logo and link us, please.
{{#ev:youtube|tUQCMTmQ-5Y}}

== FlightGear users ==
=== 360 degrees motion simulator ===
''Contributed by Samuel DeRose''

Several years ago during a trip to Washington DC, my family got tickets to a flight simulator ride at the [http://www.nasm.si.edu/ Air and Space Museum]. All of us were amazed at the innovation of the Smithsonian's interactive simulator ride, having grown accustom to the common, mediocre, hydraulic-platform simulators often seen at carnivals and amusement parks. These simulators could roll 360 degrees, continuously, and could tilt about 30 degrees along the pitch axis.

Inspired by that experience, our group ("Team Viper") is attempting to create an even better version. Like the one at the Air and Space Musuem, ours will roll 360 degrees. In addition we also intend to allow 360 degrees of motion along the pitch axis. Since our family are huge Battlestar Glactica fans we thought it would be fun to theme the interior of the simulator as a Viper fighter from the show.

One big challenge for us is the physical construction of the simulator, but an even greater feat lies in the software to control the motion platform. In order for the game to feel real (and also to avoid motion sickness), the visuals that will be displayed across three 22" monitors need to be fully synced to what the rider feels in his inner ear and his stomach. Thankfully we found FlightGear, which allows us to easily read the plane's flight dynamics from the sim so we can calculate the angles to orient the motion platform.

More info, videos and updates at the website: [http://www.the-viper.org the-viper.org]

{{#ev:youtube|brSW-y0dEOo}}

=== Worldwide unique paragliding simulator ===
ActiveFly is a simulator just for paragliding. It let's you practice paragliding on the ground.

{{cquote|In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated. The brakes are extended and retracted via servos, simulating steering forces as they occur in a particular situation. The pilot will try to keep these forces constant by pulling or releasing the brakes. His actions can be viewed on a monitor and subsequently evaluated, allowing him to check the results and monitor progress as he develops his piloting skills.|[http://www.activefly.com/simulator_en.htm ActiveFly.com]}}
As visualizing system they use FlightGear.

Some bigger images which shows the sim in action can be found [http://aufwindfreunde.de/fotoalbum/simulator_training_27022011/simulator_training_27022011.htm in this gallery].

{{#ev:youtube|YFcHebPaiEs}}

Maybe they should use some of our new generated sceneries.
But great to see how FlightGear can be used in many ways!

== Aircraft of the month ==

== Airport of the month ==
==EDDI Tempelhof Berlin==
[[File:EDDI Tempelhof Belin.jpg|804px]]

One of the few airports that has written history, that has changed it. The [[Berlin Tempelhof Airport]] is in the city of Berlin. The scenery on the airport includes historic buildings, rotating antenna's, a fire-drill location and many historic aircraft. Around the airport you will discover an amazing scenery. If you have ever been to Berlin, you can navigate using the landmarks and easy find your way around (towards the bierstubes at the Kudamm). Visit this place soon since the airport has been closed and will one day disappear from the map, once they figure out what to do with the terrain.
*More reading: [http://en.wikipedia.org/wiki/Berlin_Tempelhof_Airport Tempelhof]

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

Cessna c172p near San Francisco flying over the ocean.

== Suggested flights ==
===Khorog, Tajikistan===

[[File:Fw190HinduKush.jpeg|right|thumb|Approaching a bank of snow-covered mountains in the south of the Hindu Kush]]
Surrounded by spectacular mountains and nestled in the end of a valley, Khorog Airfield (UT1C) makes an interesting place to land. It can only be approached by flying down the curved valley that snakes in from the North. Flying from here to OPCH (Chitral, Pakistan) at around 500ft AGL all the way is a wonderful way to explore the Hindu Kush mountains.

If you bring a piston engined aircraft, be prepared to adjust the mixture as you climb - at the highest point in the flight, you will be at around 22000ft. Also, don't forget to carry plenty of fuel - there are very few airfields in the Hindu Kush that exist in FlightGear. This is a scenery bug that will hopefully be fixed in the future.

More amazing places to visit can be found at [[Suggested Flights]].

== Aircraft reviews ==

== Wiki updates ==
As of January, [[User:Hooray|Hooray]] is part of the wiki team. He'll remove spam, lock newsletters after publicitation and you can contact him in case of problems. The team now exists of the following people:
* [[User:Hellosimon|Hellosimon]] (admin)
* [[User:Gijs|Gijs]]
* [[User:Hooray|Hooray]]
* [[User:Lolalilo|Lolalilo]]

===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 ===
* [http://www.youtube.com/user/FlyTristarairlines?feature=watch Trez] started a new video series Final Approach:
** [http://www.youtube.com/watch?v=Au6eS6Y6sYY&list=PL60A11F004175486E&index=1&feature=plcp episode 1]
* Dave shared a [http://www.youtube.com/watch?v=VInCXCTi6OA nice approach] to El Dorado International Airport (SKBO)
* [http://www.youtube.com/watch?v=nkoQCr47ddY Highway to Hell] by Kamus Tupolev 214 ILS Dusk APP KSFO /--28R--\ />
* [http://www.youtube.com/watch?v=jdBXlKmLXtQ Manual Approach] MD-BFC landing in TNCM
==== 12 Days of Flight Tips ====
From December 26th to January 6th, [http://www.youtube.com/user/osjcag Oscar] uploaded a daily series in which he gave quick tips in flying and the use of FlightGear.
{| 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]
*[http://www.youtube.com/watch?v=HdVCVH0XMXM Day 10 - Manual Flight Tips]
*[http://www.youtube.com/watch?v=NeDMwBMg6Gs Day 11 - Multiplayer ATC]
*[http://www.youtube.com/watch?v=9FSdbw_c9qA Day 12 - Crosswind Landing Tips]
|}
Or watch all the episodes in [http://www.youtube.com/watch?v=RbB5Sn_ag-A&list=PL569D227E5E767F3D a playlist].

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

=== Then and now ===

My first contact with Flightgear was 0.91 which came with my Linux distribution. I've always enjoyed flying carrier ops - we've just come a long way in visual quality. The left picture is from my old album documenting my 0.91 adventures, the right is using the shader technology of 2.5.

[[File:Carrier-ops-0.91.jpg|400px]] [[File:Carrier-ops-2.5.jpg|400px]]

=== Did you know ===

{{Appendix}}

[[Category:FlightGear Newsletter|2012 01]]

FlightGear Newsletter January 2012

2012-01-27T21:05:02Z

ThorstenB: /* New openSUSE FlightGear repository */

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

=== 2.6.0 release preparations ===
On January 17, the release branches were created from our [[Git]] repositories. From then on, no new features (and aircraft) shall be pushed. Only bug fixes are accepted.

FlightGear 2.6.0 will be released on February 17!

=== Experiment: A new bounty system ===
If somebody would like a specific feature implemented, it will be posted in the wiki. 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 at [[Bounty (Overview)]].

== Lightfield shaders ==
As part of the ongoing efforts to make the skydome scattering [[shader]] blend seamlessly into the terrain under all conditions, substantial work on getting sunrise and sunset conditions right has been done.

The eventual solution to the problems are lightfield shaders - the shader doesn not assume a single light source for the whole scene, but computes the incident light intensity and hue for each point of the scene dependent on position and altitude. This turns out particularly tricky for the fog, as the visible fog color is really a line integral along points with very different lighting - which is too slow to do real-time, so a good approximation scheme has to be used. The development effort for the lightfield shaders is easily five times the effort for the original terrain haze shader which handles everything during daytime - which illustrates a bit how complex problems sunrises are.

The shaders handle a variety of conditions and generate spectacular scenes, from the first glow of the predawn sky, via high altitude clouds lighting up before the terrain to full daylight.

{|
|[[File:Lightfield_shader12.jpg|200px|thumb|Predawn sky light]]
|[[File:Lightfield_shader02.jpg|200px|thumb|Takeoff in predawn light]]
|[[File:Lightfield_shader05.jpg|200px|thumb|High altitude cloud glow]]
|}

Among other things, the lightfield allows mountain summits and high altitude clouds to be illuminated by morning light before the lower terrain lights up. The scene is rendered faithfully from ground level up to low Earth orbit where the terminator line becomes visible, distorted by the terrain elevation pattern. As an example, here's the Alaska range from 24.000 ft and from 240.000 ft:

{|
|[[File:Lightfield_shader01.jpg|200px|thumb|Alaska range from 24.000 ft]]
|[[File:Lightfield_shader04.jpg|200px|thumb|Alaska range from 240.000 ft]]
|}

The action of the shaders interfaces with the environment conditions. For instance, high altitude haze makes the indirect ground light more red than blue since it causes substantial backscatter to the ground.

{|
|[[File:Lightfield_shader06.jpg|200px|thumb|Sunrise without high altitude haze]]
|[[File:Lightfield_shader03.jpg|200px|thumb|Sunrise with high altitude haze]]

|}

Cloud cover blocks the incident direct light on the haze layer and cause a change in hue of the haze illumination. The Local Weather system provides the necessary interface information - for instance at the egde of a cloud layer, direct light can reach underneath the layer and illuminate the haze, causing a change in the shader response. Also, the self-shading of the haze layer leads to a different haze hue on the ground and at higher altitude.

{|
|[[File:Lightfield_shader07.jpg|200px|thumb|Sunrise in moderate cloud cover]]
|[[File:Lightfield_shader10.jpg|200px|thumb|Sunrise in thick Stratus cloud cover]]
|[[File:Lightfield_shader11.jpg|200px|thumb|Sunrise in strong cloud cover at layer edge]]
|}

For low sun, additional shading of the terrain occurs - this is not shading of the terrain itself (which would be reasonably easy to approximate) but shading of the haze by the terrain. This effect goes away when the light attenuation in the fog is too strong:

{|
|[[File:Lightfield_shader08.jpg|200px|thumb|Haze shading for high visibility]]
|[[File:Lightfield_shader09.jpg|200px|thumb|Haze shading for low visibility]]
|}

All these effects do not currently mesh with other shaders. While eventually an integration with other projects is discussed, the lightfield shader code will hopefully make its appearance on Git soon as an optional feature.

As a preview, here's what may come next - a mode detailed light attenuation model in which the darker hue of the fog beneath clouds is really prominent.

{|
|[[File:Lightfield_shader_next.jpg|200px|thumb|More detailed attenuation model]]
|}

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

== New openSUSE FlightGear repository ==
openSUSE now provides a dedicated ''FlightGear repository'' continuously delivering ready-to-use binaries of the latest development version ("Git" version) of the FlightGear Flight Simulator and many related utilities. The binaries are regularly updated (''not'' daily, but about weekly for FlightGear and a bit less often for the utilities).

The repository currently provides:
* '''FlightGear''', '''SimGear''', '''fgdata'''
* '''Atlas'''
* '''FGcom'''
* '''FGComGui'''
* '''fgms''' (multiplayer server, for local setups)
* '''TaxiDraw'''
* '''fgrun'''
* '''FGx'''
More utilities may be added, if someone is able to provide the necessary build script to pack the RPM.

After installation, all tools should be pretty much pre-configured, and can directly be launched from the menu.

For installation, use [http://software.opensuse.org/download.html?lang=en&project=games:FlightGear:Unstable&package=fgrun this link] to select your openSUSE version and install fgrun + flightgear. Alternatively, you can add openSUSE's ''games:FlightGear:Unstable'' repository manually. After installation, you can select and install more FG-related utilities directly from ''YaST''.

Remember, the ''Unstable'' repository always provides the latest ''development'' version, which may not be suitable for inexperienced users.

Until FlightGear 2.6.0 is released, this repository provides '''FlightGear 2.6.0 release candidates''', so you can help with testing the new release.
After the official release, FlightGear 2.6.0 and a stable version of all utilities will be available in the openSUSE ''games'' repository, while this ''Unstable'' repository keeps tracking the development versions (you could switch back to ''games'' after the 2.6.0 release).

Maybe we can find volunteers to set up a similar service for other Linux distros, or at least try to add stable versions of FlightGear and all its friend-utilities to the distros, so Linux users no longer need to compile all utilities from scratch and solve installation issues.

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we adopted 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 ===

The '''Curtiss JN-4 "Jenny"''' has been added by helijah.

* [http://helijah.free.fr/flightgear/les-appareils/jenny/appareil.htm Download page]

=== Updated aircraft ===
==== Douglas DC-3 C47 ====
The [[Douglas DC-3-C47|Douglas DC-3 C47]] has been updated by the PAF team. The improvements have mainly been made in the cockpit because that is where the pilots spend most of their time (hopefully!), but many other details have been given around.

* [http://equipe-flightgear.forumactif.com/t835-hangar-de-la-paf Download]
* [http://www.flightgear.org/forums/viewtopic.php?f=4&t=13629 Forum topic]

=== Liveries ===
All liveries that were not available as downloads have been removed from the [[livery database]]. Most of those got lost when the former server suddenly quit (all the way back in December 2009). As we were able to save the list of liveries, they ended up in the database eventough the files got lost.

To save liveries from future server failures, backups are nowadays made on a regularly basis.

== Scenery corner ==
=== Topologically clean datasets ===
[[File:IJburg_clc2000_vs_clc2006.png|thumb|270px|A Dutch artificial island currently under construction, as visualized with CLC2000 (top) and CLC2006 (lower) and [[OSM]] data.]]
Martin now has what should be topologically clean CLC2000v15 and VMap0 edition 5.0 datasets. These have been loaded into the [http://mapserver.flightgear.org/ Landcover-DB] as replacements for the old VMap0 and CLC layers.

Thanks to the great folks at GRASS GIS, most notably Markus M., the procedure of cleaning large vector datasets like [[CORINE]] is now a matter
of just a few days and runs on a machine with far less than 32 GByte of main memory! One year ago, cleaning CORINE took about one and a half
months to complete just one single (!) of multiple iterations and you never knew if somebody would reboot the server while the job was still running (which actually happened several times).

Having topologically clean datasets is a very important step for at least two reasons:
# TerraGear's overall stability is expected to increase with topologically clean vector data.
# Merging custom land cover data (like John Holden's great work) into the "Custom Scenery" layer (at MapServer) had been failing in some cases due to topological inconsistencies. These failures are expected to disappear with topologically clean vector data.
# As soon as the various tools are working in a predictable manner, the driving motivation behind all the effort can be revived, which is to build an infrastructure for re-compiling the respective terrain tiles on a regular, maybe daily schedule after the land cover has been updated in a certain region.

A clean CLC2006 is provided as well, but because that one's still incomplete (and work in progress, actually) CLC2000 is considered more important. CLC2006 focused mainly on the identification and mapping of land cover changes between 2000 and 2006.<ref>[http://sia.eionet.europa.eu/CLC2006 Corine Land Cover 2006, Eionet]</ref> All land cover changes bigger than 5 ha have been mapped. CLC2006 is significantly more up to date in some areas, as can be seen in the image on the right.

=== TerraGear GUI updates ===
After a couple of months of little (to none) development, Gijs released a new Windows binary of the [[TerraGear GUI]]. Other OS are supported, but require it to be build from source.

The GUI runs pretty stable now, provides helpfull error messages and can guide you through the entire process of scenery generation. Updates include:
* OpenStreetMap and CORINE2006 added to the download feature. Material suggestions are given as well for those.
* Up to date with today's TerraGear builds.
* Most tools have a progress bar to give you a live overview of the progress.
* Removed unnecessary texts and error messages.
* Resizable dialog with proper layouting.
Besides all that, several (small) bugs have been fixed.

=== Dutch windturbines ===
[[File:Prinses_Amaliawindpark_overview.png|thumb|270px|Overviewing the 60 wind turbines of Prinsess Amaliawindpark, 20km west of the Netherlands.]]
The Netherlands have slightly less than 1900 windturbines at the moment. Since this month, 757 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. Some countries even have a site similar to [http://www.w-i-n-d.nl this website] from the Dutch government, that 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.

For the offshore Prinses Amaliawindpark, a custom windturbine model has been made. Resembling the Vestas V80-2.0 MW edition. [http://scenemodels.flightgear.org/modeledit.php?id=2418 The model] can be easily re-used on other offshore windparks, via the method described above.

=== Airports ===
==== Congonhas - Brazil ====
[[File:Grupofgbrsmall.png|right]]
The Airport of Congonhas is currently being modeled, completely from scratch, by the [http://www.grupofgbr.com.br Grupo FG BR]. Download our logo and link us, please.
{{#ev:youtube|tUQCMTmQ-5Y}}

== FlightGear users ==
=== 360 degrees motion simulator ===
''Contributed by Samuel DeRose''

Several years ago during a trip to Washington DC, my family got tickets to a flight simulator ride at the [http://www.nasm.si.edu/ Air and Space Museum]. All of us were amazed at the innovation of the Smithsonian's interactive simulator ride, having grown accustom to the common, mediocre, hydraulic-platform simulators often seen at carnivals and amusement parks. These simulators could roll 360 degrees, continuously, and could tilt about 30 degrees along the pitch axis.

Inspired by that experience, our group ("Team Viper") is attempting to create an even better version. Like the one at the Air and Space Musuem, ours will roll 360 degrees. In addition we also intend to allow 360 degrees of motion along the pitch axis. Since our family are huge Battlestar Glactica fans we thought it would be fun to theme the interior of the simulator as a Viper fighter from the show.

One big challenge for us is the physical construction of the simulator, but an even greater feat lies in the software to control the motion platform. In order for the game to feel real (and also to avoid motion sickness), the visuals that will be displayed across three 22" monitors need to be fully synced to what the rider feels in his inner ear and his stomach. Thankfully we found FlightGear, which allows us to easily read the plane's flight dynamics from the sim so we can calculate the angles to orient the motion platform.

More info, videos and updates at the website: [http://www.the-viper.org the-viper.org]

{{#ev:youtube|brSW-y0dEOo}}

=== Worldwide unique paragliding simulator ===
ActiveFly is a simulator just for paragliding. It let's you practice paragliding on the ground.

{{cquote|In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated. The brakes are extended and retracted via servos, simulating steering forces as they occur in a particular situation. The pilot will try to keep these forces constant by pulling or releasing the brakes. His actions can be viewed on a monitor and subsequently evaluated, allowing him to check the results and monitor progress as he develops his piloting skills.|[http://www.activefly.com/simulator_en.htm ActiveFly.com]}}
As visualizing system they use FlightGear.

Some bigger images which shows the sim in action can be found [http://aufwindfreunde.de/fotoalbum/simulator_training_27022011/simulator_training_27022011.htm in this gallery].

{{#ev:youtube|YFcHebPaiEs}}

Maybe they should use some of our new generated sceneries.
But great to see how FlightGear can be used in many ways!

== 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 ==
===Khorog, Tajikistan===

[[File:Fw190HinduKush.jpeg|right|thumb|Approaching a bank of snow-covered mountains in the south of the Hindu Kush]]
Surrounded by spectacular mountains and nestled in the end of a valley, Khorog Airfield (UT1C) makes an interesting place to land. It can only be approached by flying down the curved valley that snakes in from the North. Flying from here to OPCH (Chitral, Pakistan) at around 500ft AGL all the way is a wonderful way to explore the Hindu Kush mountains.

If you bring a piston engined aircraft, be prepared to adjust the mixture as you climb - at the highest point in the flight, you will be at around 22000ft. Also, don't forget to carry plenty of fuel - there are very few airfields in the Hindu Kush that exist in FlightGear. This is a scenery bug that will hopefully be fixed in the future.

More amazing places to visit can be found at [[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 ===
* [http://www.youtube.com/user/FlyTristarairlines?feature=watch Trez] started a new video series Final Approach:
** [http://www.youtube.com/watch?v=Au6eS6Y6sYY&list=PL60A11F004175486E&index=1&feature=plcp episode 1]
* Dave shared a [http://www.youtube.com/watch?v=VInCXCTi6OA nice approach] to El Dorado International Airport (SKBO)
* [http://www.youtube.com/watch?v=nkoQCr47ddY Highway to Hell] by Kamus Tupolev 214 ILS Dusk APP KSFO /--28R--\ />
* [http://www.youtube.com/watch?v=jdBXlKmLXtQ Manual Approach] MD-BFC landing in TNCM
==== 12 Days of Flight Tips ====
From December 26th to January 6th, [http://www.youtube.com/user/osjcag Oscar] uploaded a daily series in which he gave quick tips in flying and the use of FlightGear.
{| 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]
*[http://www.youtube.com/watch?v=HdVCVH0XMXM Day 10 - Manual Flight Tips]
*[http://www.youtube.com/watch?v=NeDMwBMg6Gs Day 11 - Multiplayer ATC]
*[http://www.youtube.com/watch?v=9FSdbw_c9qA Day 12 - Crosswind Landing Tips]
|}
Or watch all the episodes in [http://www.youtube.com/watch?v=RbB5Sn_ag-A&list=PL569D227E5E767F3D a playlist].

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

=== Then and now ===

My first contact with Flightgear was 0.91 which came with my Linux distribution. I've always enjoyed flying carrier ops - we've just come a long way in visual quality. The left picture is from my old album documenting my 0.91 adventures, the right is using the shader technology of 2.5.

[[File:Carrier-ops-0.91.jpg|400px]] [[File:Carrier-ops-2.5.jpg|400px]]

=== Did you know ===

{{Appendix}}

[[Category:FlightGear Newsletter|2012 01]]

FlightGear Newsletter January 2012

2012-01-27T21:03:19Z

ThorstenB: easier install link for openSUSE FlightGear repository

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

=== 2.6.0 release preparations ===
On January 17, the release branches were created from our [[Git]] repositories. From then on, no new features (and aircraft) shall be pushed. Only bug fixes are accepted.

FlightGear 2.6.0 will be released on February 17!

=== Experiment: A new bounty system ===
If somebody would like a specific feature implemented, it will be posted in the wiki. 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 at [[Bounty (Overview)]].

== Lightfield shaders ==
As part of the ongoing efforts to make the skydome scattering [[shader]] blend seamlessly into the terrain under all conditions, substantial work on getting sunrise and sunset conditions right has been done.

The eventual solution to the problems are lightfield shaders - the shader doesn not assume a single light source for the whole scene, but computes the incident light intensity and hue for each point of the scene dependent on position and altitude. This turns out particularly tricky for the fog, as the visible fog color is really a line integral along points with very different lighting - which is too slow to do real-time, so a good approximation scheme has to be used. The development effort for the lightfield shaders is easily five times the effort for the original terrain haze shader which handles everything during daytime - which illustrates a bit how complex problems sunrises are.

The shaders handle a variety of conditions and generate spectacular scenes, from the first glow of the predawn sky, via high altitude clouds lighting up before the terrain to full daylight.

{|
|[[File:Lightfield_shader12.jpg|200px|thumb|Predawn sky light]]
|[[File:Lightfield_shader02.jpg|200px|thumb|Takeoff in predawn light]]
|[[File:Lightfield_shader05.jpg|200px|thumb|High altitude cloud glow]]
|}

Among other things, the lightfield allows mountain summits and high altitude clouds to be illuminated by morning light before the lower terrain lights up. The scene is rendered faithfully from ground level up to low Earth orbit where the terminator line becomes visible, distorted by the terrain elevation pattern. As an example, here's the Alaska range from 24.000 ft and from 240.000 ft:

{|
|[[File:Lightfield_shader01.jpg|200px|thumb|Alaska range from 24.000 ft]]
|[[File:Lightfield_shader04.jpg|200px|thumb|Alaska range from 240.000 ft]]
|}

The action of the shaders interfaces with the environment conditions. For instance, high altitude haze makes the indirect ground light more red than blue since it causes substantial backscatter to the ground.

{|
|[[File:Lightfield_shader06.jpg|200px|thumb|Sunrise without high altitude haze]]
|[[File:Lightfield_shader03.jpg|200px|thumb|Sunrise with high altitude haze]]

|}

Cloud cover blocks the incident direct light on the haze layer and cause a change in hue of the haze illumination. The Local Weather system provides the necessary interface information - for instance at the egde of a cloud layer, direct light can reach underneath the layer and illuminate the haze, causing a change in the shader response. Also, the self-shading of the haze layer leads to a different haze hue on the ground and at higher altitude.

{|
|[[File:Lightfield_shader07.jpg|200px|thumb|Sunrise in moderate cloud cover]]
|[[File:Lightfield_shader10.jpg|200px|thumb|Sunrise in thick Stratus cloud cover]]
|[[File:Lightfield_shader11.jpg|200px|thumb|Sunrise in strong cloud cover at layer edge]]
|}

For low sun, additional shading of the terrain occurs - this is not shading of the terrain itself (which would be reasonably easy to approximate) but shading of the haze by the terrain. This effect goes away when the light attenuation in the fog is too strong:

{|
|[[File:Lightfield_shader08.jpg|200px|thumb|Haze shading for high visibility]]
|[[File:Lightfield_shader09.jpg|200px|thumb|Haze shading for low visibility]]
|}

All these effects do not currently mesh with other shaders. While eventually an integration with other projects is discussed, the lightfield shader code will hopefully make its appearance on Git soon as an optional feature.

As a preview, here's what may come next - a mode detailed light attenuation model in which the darker hue of the fog beneath clouds is really prominent.

{|
|[[File:Lightfield_shader_next.jpg|200px|thumb|More detailed attenuation model]]
|}

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

== New openSUSE FlightGear repository ==
openSUSE now provides a dedicated ''FlightGear repository'' continuously delivering ready-to-use binaries of the latest development version ("Git" version) of the FlightGear Flight Simulator and many related utilities. The binaries are regularly updated (''not'' daily, but about weekly for FlightGear and a bit less often for the utilities).

The repository currently provides:
* '''FlightGear''', '''SimGear''', '''fgdata'''
* '''Atlas'''
* '''FGcom'''
* '''FGComGui'''
* '''fgms''' (multiplayer server, for local setups)
* '''TaxiDraw'''
* '''fgrun'''
* '''FGx'''
More utilities may be added, if someone is able to provide the necessary build script to pack the RPM.

After installation, all tools should be pretty much pre-configured, and can directly be launched from the menu.

For installation, use [http://software.opensuse.org/download.html?lang=en&project=games:FlightGear:Unstable&package=fgrun this link] to select your openSUSE version and install fgrun + flightgear. Alternatively, you can add openSUSE's ''games:FlightGear:Unstable'' repository manually. After installation, you can select and install more FG-related utilities directly from ''YaST''.

Remember, the ''Unstable'' repository always provides the latest ''development'' version, which may not be suitable for inexperienced users.

Until FlightGear 2.6.0 is released, this repository provides '''FlightGear 2.6.0 release candidates''', so you can help with testing the new release.
After the official release, FlightGear 2.6.0 and a stable version of all utilities will be available in the openSUSE ''games repository'', while this ''Unstable'' repository keeps tracking the development versions (you could switch back to ''games'' after the 2.6.0 release).

Maybe we can find volunteers to set up a similar service for other Linux distros, or at least try to add stable versions of FlightGear and all its friend-utilities to the distros, so Linux users no longer need to compile all utilities from scratch and solve installation issues.

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we adopted 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 ===

The '''Curtiss JN-4 "Jenny"''' has been added by helijah.

* [http://helijah.free.fr/flightgear/les-appareils/jenny/appareil.htm Download page]

=== Updated aircraft ===
==== Douglas DC-3 C47 ====
The [[Douglas DC-3-C47|Douglas DC-3 C47]] has been updated by the PAF team. The improvements have mainly been made in the cockpit because that is where the pilots spend most of their time (hopefully!), but many other details have been given around.

* [http://equipe-flightgear.forumactif.com/t835-hangar-de-la-paf Download]
* [http://www.flightgear.org/forums/viewtopic.php?f=4&t=13629 Forum topic]

=== Liveries ===
All liveries that were not available as downloads have been removed from the [[livery database]]. Most of those got lost when the former server suddenly quit (all the way back in December 2009). As we were able to save the list of liveries, they ended up in the database eventough the files got lost.

To save liveries from future server failures, backups are nowadays made on a regularly basis.

== Scenery corner ==
=== Topologically clean datasets ===
[[File:IJburg_clc2000_vs_clc2006.png|thumb|270px|A Dutch artificial island currently under construction, as visualized with CLC2000 (top) and CLC2006 (lower) and [[OSM]] data.]]
Martin now has what should be topologically clean CLC2000v15 and VMap0 edition 5.0 datasets. These have been loaded into the [http://mapserver.flightgear.org/ Landcover-DB] as replacements for the old VMap0 and CLC layers.

Thanks to the great folks at GRASS GIS, most notably Markus M., the procedure of cleaning large vector datasets like [[CORINE]] is now a matter
of just a few days and runs on a machine with far less than 32 GByte of main memory! One year ago, cleaning CORINE took about one and a half
months to complete just one single (!) of multiple iterations and you never knew if somebody would reboot the server while the job was still running (which actually happened several times).

Having topologically clean datasets is a very important step for at least two reasons:
# TerraGear's overall stability is expected to increase with topologically clean vector data.
# Merging custom land cover data (like John Holden's great work) into the "Custom Scenery" layer (at MapServer) had been failing in some cases due to topological inconsistencies. These failures are expected to disappear with topologically clean vector data.
# As soon as the various tools are working in a predictable manner, the driving motivation behind all the effort can be revived, which is to build an infrastructure for re-compiling the respective terrain tiles on a regular, maybe daily schedule after the land cover has been updated in a certain region.

A clean CLC2006 is provided as well, but because that one's still incomplete (and work in progress, actually) CLC2000 is considered more important. CLC2006 focused mainly on the identification and mapping of land cover changes between 2000 and 2006.<ref>[http://sia.eionet.europa.eu/CLC2006 Corine Land Cover 2006, Eionet]</ref> All land cover changes bigger than 5 ha have been mapped. CLC2006 is significantly more up to date in some areas, as can be seen in the image on the right.

=== TerraGear GUI updates ===
After a couple of months of little (to none) development, Gijs released a new Windows binary of the [[TerraGear GUI]]. Other OS are supported, but require it to be build from source.

The GUI runs pretty stable now, provides helpfull error messages and can guide you through the entire process of scenery generation. Updates include:
* OpenStreetMap and CORINE2006 added to the download feature. Material suggestions are given as well for those.
* Up to date with today's TerraGear builds.
* Most tools have a progress bar to give you a live overview of the progress.
* Removed unnecessary texts and error messages.
* Resizable dialog with proper layouting.
Besides all that, several (small) bugs have been fixed.

=== Dutch windturbines ===
[[File:Prinses_Amaliawindpark_overview.png|thumb|270px|Overviewing the 60 wind turbines of Prinsess Amaliawindpark, 20km west of the Netherlands.]]
The Netherlands have slightly less than 1900 windturbines at the moment. Since this month, 757 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. Some countries even have a site similar to [http://www.w-i-n-d.nl this website] from the Dutch government, that 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.

For the offshore Prinses Amaliawindpark, a custom windturbine model has been made. Resembling the Vestas V80-2.0 MW edition. [http://scenemodels.flightgear.org/modeledit.php?id=2418 The model] can be easily re-used on other offshore windparks, via the method described above.

=== Airports ===
==== Congonhas - Brazil ====
[[File:Grupofgbrsmall.png|right]]
The Airport of Congonhas is currently being modeled, completely from scratch, by the [http://www.grupofgbr.com.br Grupo FG BR]. Download our logo and link us, please.
{{#ev:youtube|tUQCMTmQ-5Y}}

== FlightGear users ==
=== 360 degrees motion simulator ===
''Contributed by Samuel DeRose''

Several years ago during a trip to Washington DC, my family got tickets to a flight simulator ride at the [http://www.nasm.si.edu/ Air and Space Museum]. All of us were amazed at the innovation of the Smithsonian's interactive simulator ride, having grown accustom to the common, mediocre, hydraulic-platform simulators often seen at carnivals and amusement parks. These simulators could roll 360 degrees, continuously, and could tilt about 30 degrees along the pitch axis.

Inspired by that experience, our group ("Team Viper") is attempting to create an even better version. Like the one at the Air and Space Musuem, ours will roll 360 degrees. In addition we also intend to allow 360 degrees of motion along the pitch axis. Since our family are huge Battlestar Glactica fans we thought it would be fun to theme the interior of the simulator as a Viper fighter from the show.

One big challenge for us is the physical construction of the simulator, but an even greater feat lies in the software to control the motion platform. In order for the game to feel real (and also to avoid motion sickness), the visuals that will be displayed across three 22" monitors need to be fully synced to what the rider feels in his inner ear and his stomach. Thankfully we found FlightGear, which allows us to easily read the plane's flight dynamics from the sim so we can calculate the angles to orient the motion platform.

More info, videos and updates at the website: [http://www.the-viper.org the-viper.org]

{{#ev:youtube|brSW-y0dEOo}}

=== Worldwide unique paragliding simulator ===
ActiveFly is a simulator just for paragliding. It let's you practice paragliding on the ground.

{{cquote|In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated. The brakes are extended and retracted via servos, simulating steering forces as they occur in a particular situation. The pilot will try to keep these forces constant by pulling or releasing the brakes. His actions can be viewed on a monitor and subsequently evaluated, allowing him to check the results and monitor progress as he develops his piloting skills.|[http://www.activefly.com/simulator_en.htm ActiveFly.com]}}
As visualizing system they use FlightGear.

Some bigger images which shows the sim in action can be found [http://aufwindfreunde.de/fotoalbum/simulator_training_27022011/simulator_training_27022011.htm in this gallery].

{{#ev:youtube|YFcHebPaiEs}}

Maybe they should use some of our new generated sceneries.
But great to see how FlightGear can be used in many ways!

== 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 ==
===Khorog, Tajikistan===

[[File:Fw190HinduKush.jpeg|right|thumb|Approaching a bank of snow-covered mountains in the south of the Hindu Kush]]
Surrounded by spectacular mountains and nestled in the end of a valley, Khorog Airfield (UT1C) makes an interesting place to land. It can only be approached by flying down the curved valley that snakes in from the North. Flying from here to OPCH (Chitral, Pakistan) at around 500ft AGL all the way is a wonderful way to explore the Hindu Kush mountains.

If you bring a piston engined aircraft, be prepared to adjust the mixture as you climb - at the highest point in the flight, you will be at around 22000ft. Also, don't forget to carry plenty of fuel - there are very few airfields in the Hindu Kush that exist in FlightGear. This is a scenery bug that will hopefully be fixed in the future.

More amazing places to visit can be found at [[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 ===
* [http://www.youtube.com/user/FlyTristarairlines?feature=watch Trez] started a new video series Final Approach:
** [http://www.youtube.com/watch?v=Au6eS6Y6sYY&list=PL60A11F004175486E&index=1&feature=plcp episode 1]
* Dave shared a [http://www.youtube.com/watch?v=VInCXCTi6OA nice approach] to El Dorado International Airport (SKBO)
* [http://www.youtube.com/watch?v=nkoQCr47ddY Highway to Hell] by Kamus Tupolev 214 ILS Dusk APP KSFO /--28R--\ />
* [http://www.youtube.com/watch?v=jdBXlKmLXtQ Manual Approach] MD-BFC landing in TNCM
==== 12 Days of Flight Tips ====
From December 26th to January 6th, [http://www.youtube.com/user/osjcag Oscar] uploaded a daily series in which he gave quick tips in flying and the use of FlightGear.
{| 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]
*[http://www.youtube.com/watch?v=HdVCVH0XMXM Day 10 - Manual Flight Tips]
*[http://www.youtube.com/watch?v=NeDMwBMg6Gs Day 11 - Multiplayer ATC]
*[http://www.youtube.com/watch?v=9FSdbw_c9qA Day 12 - Crosswind Landing Tips]
|}
Or watch all the episodes in [http://www.youtube.com/watch?v=RbB5Sn_ag-A&list=PL569D227E5E767F3D a playlist].

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

=== Then and now ===

My first contact with Flightgear was 0.91 which came with my Linux distribution. I've always enjoyed flying carrier ops - we've just come a long way in visual quality. The left picture is from my old album documenting my 0.91 adventures, the right is using the shader technology of 2.5.

[[File:Carrier-ops-0.91.jpg|400px]] [[File:Carrier-ops-2.5.jpg|400px]]

=== Did you know ===

{{Appendix}}

[[Category:FlightGear Newsletter|2012 01]]

Building FlightGear - Linux

2012-01-26T18:49:35Z

ThorstenB: openSUSE repository

{{Main article|Building Flightgear}}

This section describes how to build [[FlightGear]] on Linux system.

Compiling FlightGear is not a task for novice users. Thus, if you're a beginner (we all were once) on a platform which binaries are available for, we recommend postponing this task and just starting with the binary distribution to get you flying.

openSUSE also provides binary packages of the latest development version, which are continuously updated. You can simply add the following URL to your ''YaST Software Repositories'': http://download.opensuse.org/repositories/games:/FlightGear:/Unstable/openSUSE_12.1/ (for other openSUSE versions, replace the "12.1" appropriately).

Or if you develop on Ubuntu or Debian, consider trying the script described in [[Scripted Compilation on Linux Debian/Ubuntu]].

== Requirements ==
Before you can compile FlightGear, you need to have the following installed on your computer:

'''C++ compiler'''

These are: c++, cpp, gcc, g++ found under the /usr/bin directory. You will also need to have the tools '''autoconf''' and '''automake1.9''' installed.

'''GIT'''

See [[FlightGear and Git]].

'''[[OpenGL]] support'''

More specifically, your system needs the support for hardware accelerated graphics. You can check for this by running the following in a [[command line]]:

glxinfo | grep direct

Note: To run the above command, you need to have the tool '''mesa-utils''' installed.

You should then see:

direct rendering: Yes

This means you are good to go as far as OpenGL support is concerned.

If you see:

direct rendering: No

Don't panic yet. This may just mean some required libraries for hardware accelerated graphic are missing. Go ahead and try installing plib 1.8.5 and its dependencies first. If you still get the above message, then you will need to do some googling and troubleshoot yourself.

== Dependencies ==
FlightGear is dependent on quite a few number of libraries. You do not need to compile all of them yourself, but you will at least need to have their development version installed. For example, the development version for package plib1.8.5 is plib1.8.5'''-dev'''.

The dependency is summarized in the following tree. Please note that each library has its own dependencies, and most of these are not shown here.

* FlightGear
** [http://kcat.strangesoft.net/openal.html OpenAL]
** SimGear
*** [http://plib.sourceforge.net/ PLIB]. Since March 2008, you will need version 1.8.5 - your distro probably supplies 1.8.4 still.
**** For versions pre March 2008: (Free)GLUT or SDL (We recommend the use of SDL over Free/GLUT, [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16153.html however since March 2008, FreeGLUT as well as SDL are both considered depreciated, please only use --enable-osgviewer during configuration instead])
*** [[OpenSceneGraph]] (check link for compatible versions)
*** You also need the development files for several basic libraries to build the software, among them the following (the package names are for Debian and derivatives(?)):
**** libfreetype6-dev
**** libjpeg62-dev
**** libungif4-dev
**** libtiff4-dev
**** libpng12-dev
**** libxmu-dev
**** libxi-dev
**** zlib1g-dev
**** libglut3-dev

If you attack the above dependencies in the order listed below, you should be good:

1. Glut. Most distributions include glut packages, although you may have to hunt for them. Make sure you install both the glut and glut-devel packages, otherwise FlightGear may be able to compile but won't run correctly.

2. Zlib. Most distributions install the basic zlib libraries by default, but not the development portions. If you don't have zlib.h, you probably need to install the zlib-devel package for your distribution.

3. Plib - portability libraries and scene graph.

4. [[OpenSceneGraph]]

5. SimGear - Simulation support libraries. If you are building FlightGear from Git, you need the Git version of SimGear. If you have strange build errors, one of the first things to check is that you have an up-to-date version of SimGear built and installed.

==== APT-GET List ====
This is a list of all the apt-get commands I had to do while compiling FG, SG, and OSG on a mostly clean Ubuntu 64 system. It is a list of all the libraries you and your computer needs to compile FG, SG, OSG, and PLib. All you have to do is copy the full command, paste it in Terminal, enter your password, and it will download all the packages for you, and install them too. The full command is at the bottom, and I hope someone finds it useful :) sub-dependencies (dependencies of the dependencies) are not included as they are installed automatically by apt-get. If anyone sees something missing, please add it.

git - to get SG and FG 
subversion - to get OSG 
build-essential - to build (includes GCC, and other build tools) 
cmake - OSG Uses this 
cmake-curses-gui -- OSG Uses this 
libpng-dev - to enable FG to use PNG textures 
libfreetype6-dev - fonts 
libjpeg-dev 
libungif4-dev 
libtiff-dev 
libxmu-dev 
libxi-dev 
libglut3-dev 
libalut-dev - sound 
libboost-dev - makes coding for some developers easier 
''automake - needed by ./autogen.sh files'' 
''autoconf - needed by ./autogen.sh files'' 
libfltk1.1-dev - You will need this if you will be using FGRun 
-----------
<pre>
sudo apt-get install git subversion build-essential cmake cmake-curses-gui libpng-dev libfreetype6-dev
libjpeg-dev libungif4-dev libtiff-dev libxmu-dev libxi-dev libglut3-dev libalut-dev
libboost-dev automake autoconf libfltk1.1-dev
</pre>
-----------
Total size is about 230 MB, depending on what you already have from other applications.

This list might seem a bit short, but the sub-dependencies all add up :) The dependencies will be listed by apt-get when you use the command.
-----------
NOTE: On a Linux Mint 9 (Ubuntu 10.04) system this is the command I used:
<pre>
sudo apt-get install git-core subversion build-essential cmake cmake-curses-gui libpng-dev libfreetype6-dev libjpeg-dev libungif4-dev
libtiff-dev libxmu-dev libxi-dev libglut3-dev libalut-dev libboost-dev ''automake autoconf'' libfltk1.1-dev libplib-dev libopenscenegraph-dev
</pre>
libopenscenegraph-dev
You just need to copy that long line into a terminal and you should have all the packages you need to compile Flightgear and Simgear.

== Compiling ==
Assuming you are root, do:
cd /usr/local/src

'''Note:''' When tracking a fast changing software like FlightGear/Git it is highly advisable to install it in a separate directory. That way one can also easily build and reinstall without being root, which greatly reduces the risk of messing up one's system.
To install in a directory of your choice add the <tt>--prefix</tt> argument to configure. E.g. <tt>./configure --prefix=$HOME/FlightGear</tt>. I would recommend installing all of OSG, plib, SimGear and FlightGear with the same prefix.

=== Getting and compiling SimGear ===

'''Step 1:'''

Clone the SimGear git repository and set it up to track the 'next' branch.
git clone git://gitorious.org/fg/simgear.git

By default after cloning you should have a local next branch that tracks the master next branch. It can be updated it with git pull.

'''Step 2:'''

The source code will be downloaded into a directory called '''simgear'''.

Next, go into the directory and make preparations for the compilation:
cd simgear
''./autogen.sh''
./configure

'''Note''' that if you don't want to install simgear globally on the system but in a specific directory, you can do so by adding --prefix=/path/to/your/fgInstallation to the ./configure command

'''Step 3:'''

Compile and install SimGear by doing:
make; make install

''Note:'' with gcc 4.2 or later,on some platforms, you can get compiling errors about alc.h like:

'<anonymous>' has incomplete type
take a look at http://bugs.gentoo.org/166723

=== Getting and compiling FlightGear ===

'''Step 1:'''

Clone the FlightGear git repository and set it up to track the 'next' branch.
git clone git://gitorious.org/fg/flightgear.git

By default after cloning you should have a local next branch that tracks the master next branch. It can be updated it with git pull.

'''Step 2:'''

Next, go into the folder and make preparations for the compilation:
cd flightgear
''./autogen.sh''
./configure

Note that if you don't want to install simgear globally on the system but in a specific directory, you can do so by adding --prefix=/path/to/your/fgInstallation to the ./configure command.
If you didn't install OSG globally or in the same prefix as SimGear and FlightGear, you have to pass the OSG directory to the configure-command like this:
./configure --prefix=/path/to/fgInstallation --with-osg=/path/to/osg/installation --enable-osgviewer
In this case you have to tell your system where to find the OSG libraries before you can run flightgear:
export LD_LIBRARY_PATH=/path/to/osgInstallation/lib:$LD_LIBRARY_PATH

'''Step 3:'''

Now you can compile and install Flightgear by:
make; make install

'''Step 4:'''

Clone the data directory:
git clone git://gitorious.org/fg/fgdata.git

The data directory is large (almost 2.5GB) so it will take considerable time to download.
There mirror of fgdata that might be faster to download from:
git clone git://mapserver.flightgear.org/fgdata

The mirror is synchronized with the master so either will do.

And install it in (or as) /usr/local/share/FlightGear
mv fgdata /usr/local/share/flightgear

== Distro-specific instructions ==
=== Debian/Ubuntu ===
* You can use the [[Scripted Compilation on Linux Debian/Ubuntu]] script to have Flightgear compiled in one shot under both Ubuntu and Debian systems.
* Debian users who prefer to build it without script may look at [[Building Flightgear - Debian]].
=== Gentoo ===
* Gentoo users can also use overlays to build FlightGear without much hassle: [[Building Flightgear - Gentoo]].

== External links ==
=== Instructions ===
* [[MSYS]]
* [[MinGW/cross-compiler]]
* [[CodeBlocks IDE]]
* [[OpenSUSE 10.1 10.2]]
* [http://www.geoffmclane.com/fg/fgmsvc7.htm MSVC7 *.Net]
* [http://www.oflebbe.de/oflebbe/FlightGear/index.html MSVC8 aka Visual 2005]
* [http://macflightgear.sourceforge.net/home/documents/ Mac OS X]
== Important note for GIT users ==
As of latest development in GIT, only cmake is now required for building both SimGear and FlightGear. So if you build GIT (for what any reason) please don't try to use autogen.sh as it is removed from repository.

For detailed instructions, see page [[Building_using_CMake|Building using cmake]].

{{Building}}

FlightGear Newsletter January 2012

2012-01-26T18:42:55Z

ThorstenB: /* New openSUSE FlightGear repository */

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

=== 2.6.0 release preparations ===
On January 17, the release branches were created from our [[Git]] repositories. From then on, no new features (and aircraft) shall be pushed. Only bug fixes are accepted.

FlightGear 2.6.0 will be released on February 17!

=== Experiment: A new bounty system ===
If somebody would like a specific feature implemented, it will be posted in the wiki. 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 at [[Bounty (Overview)]].

== Lightfield shaders ==
As part of the ongoing efforts to make the skydome scattering [[shader]] blend seamlessly into the terrain under all conditions, substantial work on getting sunrise and sunset conditions right has been done.

The eventual solution to the problems are lightfield shaders - the shader doesn not assume a single light source for the whole scene, but computes the incident light intensity and hue for each point of the scene dependent on position and altitude. This turns out particularly tricky for the fog, as the visible fog color is really a line integral along points with very different lighting - which is too slow to do real-time, so a good approximation scheme has to be used. The development effort for the lightfield shaders is easily five times the effort for the original terrain haze shader which handles everything during daytime - which illustrates a bit how complex problems sunrises are.

The shaders handle a variety of conditions and generate spectacular scenes, from the first glow of the predawn sky, via high altitude clouds lighting up before the terrain to full daylight.

{|
|[[File:Lightfield_shader12.jpg|200px|thumb|Predawn sky light]]
|[[File:Lightfield_shader02.jpg|200px|thumb|Takeoff in predawn light]]
|[[File:Lightfield_shader05.jpg|200px|thumb|High altitude cloud glow]]
|}

Among other things, the lightfield allows mountain summits and high altitude clouds to be illuminated by morning light before the lower terrain lights up. The scene is rendered faithfully from ground level up to low Earth orbit where the terminator line becomes visible, distorted by the terrain elevation pattern. As an example, here's the Alaska range from 24.000 ft and from 240.000 ft:

{|
|[[File:Lightfield_shader01.jpg|200px|thumb|Alaska range from 24.000 ft]]
|[[File:Lightfield_shader04.jpg|200px|thumb|Alaska range from 240.000 ft]]
|}

The action of the shaders interfaces with the environment conditions. For instance, high altitude haze makes the indirect ground light more red than blue since it causes substantial backscatter to the ground.

{|
|[[File:Lightfield_shader06.jpg|200px|thumb|Sunrise without high altitude haze]]
|[[File:Lightfield_shader03.jpg|200px|thumb|Sunrise with high altitude haze]]

|}

Cloud cover blocks the incident direct light on the haze layer and cause a change in hue of the haze illumination. The Local Weather system provides the necessary interface information - for instance at the egde of a cloud layer, direct light can reach underneath the layer and illuminate the haze, causing a change in the shader response. Also, the self-shading of the haze layer leads to a different haze hue on the ground and at higher altitude.

{|
|[[File:Lightfield_shader07.jpg|200px|thumb|Sunrise in moderate cloud cover]]
|[[File:Lightfield_shader10.jpg|200px|thumb|Sunrise in thick Stratus cloud cover]]
|[[File:Lightfield_shader11.jpg|200px|thumb|Sunrise in strong cloud cover at layer edge]]
|}

For low sun, additional shading of the terrain occurs - this is not shading of the terrain itself (which would be reasonably easy to approximate) but shading of the haze by the terrain. This effect goes away when the light attenuation in the fog is too strong:

{|
|[[File:Lightfield_shader08.jpg|200px|thumb|Haze shading for high visibility]]
|[[File:Lightfield_shader09.jpg|200px|thumb|Haze shading for low visibility]]
|}

All these effects do not currently mesh with other shaders. While eventually an integration with other projects is discussed, the lightfield shader code will hopefully make its appearance on Git soon as an optional feature.

As a preview, here's what may come next - a mode detailed light attenuation model in which the darker hue of the fog beneath clouds is really prominent.

{|
|[[File:Lightfield_shader_next.jpg|200px|thumb|More detailed attenuation model]]
|}

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

== New openSUSE FlightGear repository ==
openSUSE now provides a dedicated ''FlightGear repository'' continuously delivering ready-to-use binaries of the latest development version ("Git" version) of the FlightGear Flight Simulator and many related utilities. The binaries are regularly updated (''not'' daily, but about weekly for FlightGear and a bit less often for the utilities).

The repository currently provides:
* '''FlightGear''', '''SimGear''', '''fgdata'''
* '''Atlas'''
* '''FGcom'''
* '''FGComGui'''
* '''fgms''' (multiplayer server, for local setups)
* '''TaxiDraw'''
* '''fgrun'''
* '''FGx'''
More utilities may be added, if someone is able to provide the necessary build script to pack the RPM.

After installation, all tools should be pretty much pre-configured, and can directly be launched from the menu.

For installation, simply add the following URL as a source to your ''YaST Software Repositories'':
http://download.opensuse.org/repositories/games:/FlightGear:/Unstable/openSUSE_12.1/
(for other openSUSE versions replace the "12.1" as appropriate, i.e. "11.4" or "Tumbleweed") and select the packages to install from YaST.

For openSUSE 12.1 you can also use this [http://software.opensuse.org/ymp/games:FlightGear:Unstable/openSUSE_12.1/fgrun.ymp?base=openSUSE%3A12.1&query=fgrun 1-Click installer] to add the repository and install flightgear + fgrun. After installation, you can select more FG utilities in YaST.

Remember, the ''Unstable'' repository always provides the latest ''development'' version, so this is not suitable for everyone.

Until FlightGear 2.6.0 is released, this repository provides '''FlightGear 2.6.0 release candidates''', so you can help with testing the new release.
After the official release, FlightGear 2.6.0 and a stable version of all utilities will be available in the openSUSE ''games repository'', while this ''Unstable'' repository keeps tracking the development versions (you could switch back to ''games'' after the 2.6.0 release).

Maybe we can find volunteers to set up a similar service for other Linux distros, or at least try to add stable versions of FlightGear and all its friend-utilities to the distros, so Linux users no longer need to compile all utilities from scratch and solve installation issues.

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we adopted 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 ===

The '''Curtiss JN-4 "Jenny"''' has been added by helijah.

* [http://helijah.free.fr/flightgear/les-appareils/jenny/appareil.htm Download page]

=== Updated aircraft ===
==== Douglas DC-3 C47 ====
The [[Douglas DC-3-C47|Douglas DC-3 C47]] has been updated by the PAF team. The improvements have mainly been made in the cockpit because that is where the pilots spend most of their time (hopefully!), but many other details have been given around.

* [http://equipe-flightgear.forumactif.com/t835-hangar-de-la-paf Download]
* [http://www.flightgear.org/forums/viewtopic.php?f=4&t=13629 Forum topic]

=== Liveries ===
All liveries that were not available as downloads have been removed from the [[livery database]]. Most of those got lost when the former server suddenly quit (all the way back in December 2009). As we were able to save the list of liveries, they ended up in the database eventough the files got lost.

To save liveries from future server failures, backups are nowadays made on a regularly basis.

== Scenery corner ==
=== Topologically clean datasets ===
[[File:IJburg_clc2000_vs_clc2006.png|thumb|270px|A Dutch artificial island currently under construction, as visualized with CLC2000 (top) and CLC2006 (lower) and [[OSM]] data.]]
Martin now has what should be topologically clean CLC2000v15 and VMap0 edition 5.0 datasets. These have been loaded into the [http://mapserver.flightgear.org/ Landcover-DB] as replacements for the old VMap0 and CLC layers.

Thanks to the great folks at GRASS GIS, most notably Markus M., the procedure of cleaning large vector datasets like [[CORINE]] is now a matter
of just a few days and runs on a machine with far less than 32 GByte of main memory! One year ago, cleaning CORINE took about one and a half
months to complete just one single (!) of multiple iterations and you never knew if somebody would reboot the server while the job was still running (which actually happened several times).

Having topologically clean datasets is a very important step for at least two reasons:
# TerraGear's overall stability is expected to increase with topologically clean vector data.
# Merging custom land cover data (like John Holden's great work) into the "Custom Scenery" layer (at MapServer) had been failing in some cases due to topological inconsistencies. These failures are expected to disappear with topologically clean vector data.
# As soon as the various tools are working in a predictable manner, the driving motivation behind all the effort can be revived, which is to build an infrastructure for re-compiling the respective terrain tiles on a regular, maybe daily schedule after the land cover has been updated in a certain region.

A clean CLC2006 is provided as well, but because that one's still incomplete (and work in progress, actually) CLC2000 is considered more important. CLC2006 focused mainly on the identification and mapping of land cover changes between 2000 and 2006.<ref>[http://sia.eionet.europa.eu/CLC2006 Corine Land Cover 2006, Eionet]</ref> All land cover changes bigger than 5 ha have been mapped. CLC2006 is significantly more up to date in some areas, as can be seen in the image on the right.

=== TerraGear GUI updates ===
After a couple of months of little (to none) development, Gijs released a new Windows binary of the [[TerraGear GUI]]. Other OS are supported, but require it to be build from source.

The GUI runs pretty stable now, provides helpfull error messages and can guide you through the entire process of scenery generation. Updates include:
* OpenStreetMap and CORINE2006 added to the download feature. Material suggestions are given as well for those.
* Up to date with today's TerraGear builds.
* Most tools have a progress bar to give you a live overview of the progress.
* Removed unnecessary texts and error messages.
* Resizable dialog with proper layouting.
Besides all that, several (small) bugs have been fixed.

=== Dutch windturbines ===
[[File:Prinses_Amaliawindpark_overview.png|thumb|270px|Overviewing the 60 wind turbines of Prinsess Amaliawindpark, 20km west of the Netherlands.]]
The Netherlands have slightly less than 1900 windturbines at the moment. Since this month, 757 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. Some countries even have a site similar to [http://www.w-i-n-d.nl this website] from the Dutch government, that 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.

For the offshore Prinses Amaliawindpark, a custom windturbine model has been made. Resembling the Vestas V80-2.0 MW edition. [http://scenemodels.flightgear.org/modeledit.php?id=2418 The model] can be easily re-used on other offshore windparks, via the method described above.

=== Airports ===
==== Congonhas - Brazil ====
[[File:Grupofgbrsmall.png|right]]
The Airport of Congonhas is currently being modeled, completely from scratch, by the [http://www.grupofgbr.com.br Grupo FG BR]. Download our logo and link us, please.
{{#ev:youtube|tUQCMTmQ-5Y}}

== FlightGear users ==
=== 360 degrees motion simulator ===
''Contributed by Samuel DeRose''

Several years ago during a trip to Washington DC, my family got tickets to a flight simulator ride at the [http://www.nasm.si.edu/ Air and Space Museum]. All of us were amazed at the innovation of the Smithsonian's interactive simulator ride, having grown accustom to the common, mediocre, hydraulic-platform simulators often seen at carnivals and amusement parks. These simulators could roll 360 degrees, continuously, and could tilt about 30 degrees along the pitch axis.

Inspired by that experience, our group ("Team Viper") is attempting to create an even better version. Like the one at the Air and Space Musuem, ours will roll 360 degrees. In addition we also intend to allow 360 degrees of motion along the pitch axis. Since our family are huge Battlestar Glactica fans we thought it would be fun to theme the interior of the simulator as a Viper fighter from the show.

One big challenge for us is the physical construction of the simulator, but an even greater feat lies in the software to control the motion platform. In order for the game to feel real (and also to avoid motion sickness), the visuals that will be displayed across three 22" monitors need to be fully synced to what the rider feels in his inner ear and his stomach. Thankfully we found FlightGear, which allows us to easily read the plane's flight dynamics from the sim so we can calculate the angles to orient the motion platform.

More info, videos and updates at the website: [http://www.the-viper.org the-viper.org]

{{#ev:youtube|brSW-y0dEOo}}

=== Worldwide unique paragliding simulator ===
ActiveFly is a simulator just for paragliding. It let's you practice paragliding on the ground.

{{cquote|In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated. The brakes are extended and retracted via servos, simulating steering forces as they occur in a particular situation. The pilot will try to keep these forces constant by pulling or releasing the brakes. His actions can be viewed on a monitor and subsequently evaluated, allowing him to check the results and monitor progress as he develops his piloting skills.|[http://www.activefly.com/simulator_en.htm ActiveFly.com]}}
As visualizing system they use FlightGear.

Some bigger images which shows the sim in action can be found [http://aufwindfreunde.de/fotoalbum/simulator_training_27022011/simulator_training_27022011.htm in this gallery].

{{#ev:youtube|YFcHebPaiEs}}

Maybe they should use some of our new generated sceneries.
But great to see how FlightGear can be used in many ways!

== 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 ==
===Khorog, Tajikistan===

[[File:Fw190HinduKush.jpeg|right|thumb|Approaching a bank of snow-covered mountains in the south of the Hindu Kush]]
Surrounded by spectacular mountains and nestled in the end of a valley, Khorog Airfield (UT1C) makes an interesting place to land. It can only be approached by flying down the curved valley that snakes in from the North. Flying from here to OPCH (Chitral, Pakistan) at around 500ft AGL all the way is a wonderful way to explore the Hindu Kush mountains.

If you bring a piston engined aircraft, be prepared to adjust the mixture as you climb - at the highest point in the flight, you will be at around 22000ft. Also, don't forget to carry plenty of fuel - there are very few airfields in the Hindu Kush that exist in FlightGear. This is a scenery bug that will hopefully be fixed in the future.

More amazing places to visit can be found at [[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 ===
* [http://www.youtube.com/user/FlyTristarairlines?feature=watch Trez] started a new video series Final Approach:
** [http://www.youtube.com/watch?v=Au6eS6Y6sYY&list=PL60A11F004175486E&index=1&feature=plcp episode 1]
* Dave shared a [http://www.youtube.com/watch?v=VInCXCTi6OA nice approach] to El Dorado International Airport (SKBO)
* [http://www.youtube.com/watch?v=nkoQCr47ddY Highway to Hell] by Kamus Tupolev 214 ILS Dusk APP KSFO /--28R--\ />
* [http://www.youtube.com/watch?v=jdBXlKmLXtQ Manual Approach] MD-BFC landing in TNCM
==== 12 Days of Flight Tips ====
From December 26th to January 6th, [http://www.youtube.com/user/osjcag Oscar] uploaded a daily series in which he gave quick tips in flying and the use of FlightGear.
{| 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]
*[http://www.youtube.com/watch?v=HdVCVH0XMXM Day 10 - Manual Flight Tips]
*[http://www.youtube.com/watch?v=NeDMwBMg6Gs Day 11 - Multiplayer ATC]
*[http://www.youtube.com/watch?v=9FSdbw_c9qA Day 12 - Crosswind Landing Tips]
|}
Or watch all the episodes in [http://www.youtube.com/watch?v=RbB5Sn_ag-A&list=PL569D227E5E767F3D a playlist].

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

=== Then and now ===

My first contact with Flightgear was 0.91 which came with my Linux distribution. I've always enjoyed flying carrier ops - we've just come a long way in visual quality. The left picture is from my old album documenting my 0.91 adventures, the right is using the shader technology of 2.5.

[[File:Carrier-ops-0.91.jpg|400px]] [[File:Carrier-ops-2.5.jpg|400px]]

=== Did you know ===

{{Appendix}}

[[Category:FlightGear Newsletter|2012 01]]

FlightGear Newsletter January 2012

2012-01-26T18:40:38Z

ThorstenB: openSUSE repository

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

=== 2.6.0 release preparations ===
On January 17, the release branches were created from our [[Git]] repositories. From then on, no new features (and aircraft) shall be pushed. Only bug fixes are accepted.

FlightGear 2.6.0 will be released on February 17!

=== Experiment: A new bounty system ===
If somebody would like a specific feature implemented, it will be posted in the wiki. 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 at [[Bounty (Overview)]].

== Lightfield shaders ==
As part of the ongoing efforts to make the skydome scattering [[shader]] blend seamlessly into the terrain under all conditions, substantial work on getting sunrise and sunset conditions right has been done.

The eventual solution to the problems are lightfield shaders - the shader doesn not assume a single light source for the whole scene, but computes the incident light intensity and hue for each point of the scene dependent on position and altitude. This turns out particularly tricky for the fog, as the visible fog color is really a line integral along points with very different lighting - which is too slow to do real-time, so a good approximation scheme has to be used. The development effort for the lightfield shaders is easily five times the effort for the original terrain haze shader which handles everything during daytime - which illustrates a bit how complex problems sunrises are.

The shaders handle a variety of conditions and generate spectacular scenes, from the first glow of the predawn sky, via high altitude clouds lighting up before the terrain to full daylight.

{|
|[[File:Lightfield_shader12.jpg|200px|thumb|Predawn sky light]]
|[[File:Lightfield_shader02.jpg|200px|thumb|Takeoff in predawn light]]
|[[File:Lightfield_shader05.jpg|200px|thumb|High altitude cloud glow]]
|}

Among other things, the lightfield allows mountain summits and high altitude clouds to be illuminated by morning light before the lower terrain lights up. The scene is rendered faithfully from ground level up to low Earth orbit where the terminator line becomes visible, distorted by the terrain elevation pattern. As an example, here's the Alaska range from 24.000 ft and from 240.000 ft:

{|
|[[File:Lightfield_shader01.jpg|200px|thumb|Alaska range from 24.000 ft]]
|[[File:Lightfield_shader04.jpg|200px|thumb|Alaska range from 240.000 ft]]
|}

The action of the shaders interfaces with the environment conditions. For instance, high altitude haze makes the indirect ground light more red than blue since it causes substantial backscatter to the ground.

{|
|[[File:Lightfield_shader06.jpg|200px|thumb|Sunrise without high altitude haze]]
|[[File:Lightfield_shader03.jpg|200px|thumb|Sunrise with high altitude haze]]

|}

Cloud cover blocks the incident direct light on the haze layer and cause a change in hue of the haze illumination. The Local Weather system provides the necessary interface information - for instance at the egde of a cloud layer, direct light can reach underneath the layer and illuminate the haze, causing a change in the shader response. Also, the self-shading of the haze layer leads to a different haze hue on the ground and at higher altitude.

{|
|[[File:Lightfield_shader07.jpg|200px|thumb|Sunrise in moderate cloud cover]]
|[[File:Lightfield_shader10.jpg|200px|thumb|Sunrise in thick Stratus cloud cover]]
|[[File:Lightfield_shader11.jpg|200px|thumb|Sunrise in strong cloud cover at layer edge]]
|}

For low sun, additional shading of the terrain occurs - this is not shading of the terrain itself (which would be reasonably easy to approximate) but shading of the haze by the terrain. This effect goes away when the light attenuation in the fog is too strong:

{|
|[[File:Lightfield_shader08.jpg|200px|thumb|Haze shading for high visibility]]
|[[File:Lightfield_shader09.jpg|200px|thumb|Haze shading for low visibility]]
|}

All these effects do not currently mesh with other shaders. While eventually an integration with other projects is discussed, the lightfield shader code will hopefully make its appearance on Git soon as an optional feature.

As a preview, here's what may come next - a mode detailed light attenuation model in which the darker hue of the fog beneath clouds is really prominent.

{|
|[[File:Lightfield_shader_next.jpg|200px|thumb|More detailed attenuation model]]
|}

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

== New openSUSE FlightGear repository ==
openSUSE now provides a dedicated ''FlightGear repository'' continuously delivering ready-to-use binaries of the latest development version ("Git" version) of the FlightGear Flight Simulator and many related utilities. The binaries are regularly updated (''not'' daily, but about weekly for FlightGear and a bit less often for the utilities).

The repository currently provides:
* '''FlightGear''', '''SimGear''', '''fgdata'''
* '''Atlas'''
* '''FGcom'''
* '''FGComGui'''
* '''fgms''' (multiplayer server, for local setups)
* '''TaxiDraw'''
* '''fgrun'''
* '''FGx'''
More utilities may be added, if someone is able to provide the necessary build script to pack the RPM.

After installation, all tools should be pretty much pre-configured, and can directly be launched from the menu.

For installation, simply add the following URL as a source to your ''YaST Software Repositories'':
http://download.opensuse.org/repositories/games:/FlightGear:/Unstable/openSUSE_12.1/
(for other openSUSE versions replace the "12.1" as appropriate, i.e. "11.4" or "Tumbleweed") and select the packages to install from YaST.

For openSUSE 12.1 you can also use this [http://software.opensuse.org/ymp/games:FlightGear:Unstable/openSUSE_12.1/fgrun.ymp?base=openSUSE%3A12.1&query=fgrun 1-Click installer] to add the repository and install flightgear + fgrun. After installation, you can select more FG utilities in YaST.

Remember, the ''Unstable'' repository always provides the latest ''development'' version, so this is not suitable for everyone.

Until FlightGear 2.6.0 is released, this repository provides '''FlightGear 2.6.0 release candidates''', so you can help with testing the new release.
After the official release, FlightGear 2.6.0 and a stable version of all utilities will be available in the openSUSE "games repository", while this "Unstable" repository keeps tracking the development versions (you could switch back to "games" after the 2.6.0 release).

Maybe we can find volunteers to set up a similar service for other Linux distros, or at least try to add stable versions of FlightGear and all its friend-utilities to the distros, so Linux users no longer need to compile all utilities from scratch and solve installation issues.

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we adopted 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 ===

The '''Curtiss JN-4 "Jenny"''' has been added by helijah.

* [http://helijah.free.fr/flightgear/les-appareils/jenny/appareil.htm Download page]

=== Updated aircraft ===
==== Douglas DC-3 C47 ====
The [[Douglas DC-3-C47|Douglas DC-3 C47]] has been updated by the PAF team. The improvements have mainly been made in the cockpit because that is where the pilots spend most of their time (hopefully!), but many other details have been given around.

* [http://equipe-flightgear.forumactif.com/t835-hangar-de-la-paf Download]
* [http://www.flightgear.org/forums/viewtopic.php?f=4&t=13629 Forum topic]

=== Liveries ===
All liveries that were not available as downloads have been removed from the [[livery database]]. Most of those got lost when the former server suddenly quit (all the way back in December 2009). As we were able to save the list of liveries, they ended up in the database eventough the files got lost.

To save liveries from future server failures, backups are nowadays made on a regularly basis.

== Scenery corner ==
=== Topologically clean datasets ===
[[File:IJburg_clc2000_vs_clc2006.png|thumb|270px|A Dutch artificial island currently under construction, as visualized with CLC2000 (top) and CLC2006 (lower) and [[OSM]] data.]]
Martin now has what should be topologically clean CLC2000v15 and VMap0 edition 5.0 datasets. These have been loaded into the [http://mapserver.flightgear.org/ Landcover-DB] as replacements for the old VMap0 and CLC layers.

Thanks to the great folks at GRASS GIS, most notably Markus M., the procedure of cleaning large vector datasets like [[CORINE]] is now a matter
of just a few days and runs on a machine with far less than 32 GByte of main memory! One year ago, cleaning CORINE took about one and a half
months to complete just one single (!) of multiple iterations and you never knew if somebody would reboot the server while the job was still running (which actually happened several times).

Having topologically clean datasets is a very important step for at least two reasons:
# TerraGear's overall stability is expected to increase with topologically clean vector data.
# Merging custom land cover data (like John Holden's great work) into the "Custom Scenery" layer (at MapServer) had been failing in some cases due to topological inconsistencies. These failures are expected to disappear with topologically clean vector data.
# As soon as the various tools are working in a predictable manner, the driving motivation behind all the effort can be revived, which is to build an infrastructure for re-compiling the respective terrain tiles on a regular, maybe daily schedule after the land cover has been updated in a certain region.

A clean CLC2006 is provided as well, but because that one's still incomplete (and work in progress, actually) CLC2000 is considered more important. CLC2006 focused mainly on the identification and mapping of land cover changes between 2000 and 2006.<ref>[http://sia.eionet.europa.eu/CLC2006 Corine Land Cover 2006, Eionet]</ref> All land cover changes bigger than 5 ha have been mapped. CLC2006 is significantly more up to date in some areas, as can be seen in the image on the right.

=== TerraGear GUI updates ===
After a couple of months of little (to none) development, Gijs released a new Windows binary of the [[TerraGear GUI]]. Other OS are supported, but require it to be build from source.

The GUI runs pretty stable now, provides helpfull error messages and can guide you through the entire process of scenery generation. Updates include:
* OpenStreetMap and CORINE2006 added to the download feature. Material suggestions are given as well for those.
* Up to date with today's TerraGear builds.
* Most tools have a progress bar to give you a live overview of the progress.
* Removed unnecessary texts and error messages.
* Resizable dialog with proper layouting.
Besides all that, several (small) bugs have been fixed.

=== Dutch windturbines ===
[[File:Prinses_Amaliawindpark_overview.png|thumb|270px|Overviewing the 60 wind turbines of Prinsess Amaliawindpark, 20km west of the Netherlands.]]
The Netherlands have slightly less than 1900 windturbines at the moment. Since this month, 757 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. Some countries even have a site similar to [http://www.w-i-n-d.nl this website] from the Dutch government, that 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.

For the offshore Prinses Amaliawindpark, a custom windturbine model has been made. Resembling the Vestas V80-2.0 MW edition. [http://scenemodels.flightgear.org/modeledit.php?id=2418 The model] can be easily re-used on other offshore windparks, via the method described above.

=== Airports ===
==== Congonhas - Brazil ====
[[File:Grupofgbrsmall.png|right]]
The Airport of Congonhas is currently being modeled, completely from scratch, by the [http://www.grupofgbr.com.br Grupo FG BR]. Download our logo and link us, please.
{{#ev:youtube|tUQCMTmQ-5Y}}

== FlightGear users ==
=== 360 degrees motion simulator ===
''Contributed by Samuel DeRose''

Several years ago during a trip to Washington DC, my family got tickets to a flight simulator ride at the [http://www.nasm.si.edu/ Air and Space Museum]. All of us were amazed at the innovation of the Smithsonian's interactive simulator ride, having grown accustom to the common, mediocre, hydraulic-platform simulators often seen at carnivals and amusement parks. These simulators could roll 360 degrees, continuously, and could tilt about 30 degrees along the pitch axis.

Inspired by that experience, our group ("Team Viper") is attempting to create an even better version. Like the one at the Air and Space Musuem, ours will roll 360 degrees. In addition we also intend to allow 360 degrees of motion along the pitch axis. Since our family are huge Battlestar Glactica fans we thought it would be fun to theme the interior of the simulator as a Viper fighter from the show.

One big challenge for us is the physical construction of the simulator, but an even greater feat lies in the software to control the motion platform. In order for the game to feel real (and also to avoid motion sickness), the visuals that will be displayed across three 22" monitors need to be fully synced to what the rider feels in his inner ear and his stomach. Thankfully we found FlightGear, which allows us to easily read the plane's flight dynamics from the sim so we can calculate the angles to orient the motion platform.

More info, videos and updates at the website: [http://www.the-viper.org the-viper.org]

{{#ev:youtube|brSW-y0dEOo}}

=== Worldwide unique paragliding simulator ===
ActiveFly is a simulator just for paragliding. It let's you practice paragliding on the ground.

{{cquote|In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated. The brakes are extended and retracted via servos, simulating steering forces as they occur in a particular situation. The pilot will try to keep these forces constant by pulling or releasing the brakes. His actions can be viewed on a monitor and subsequently evaluated, allowing him to check the results and monitor progress as he develops his piloting skills.|[http://www.activefly.com/simulator_en.htm ActiveFly.com]}}
As visualizing system they use FlightGear.

Some bigger images which shows the sim in action can be found [http://aufwindfreunde.de/fotoalbum/simulator_training_27022011/simulator_training_27022011.htm in this gallery].

{{#ev:youtube|YFcHebPaiEs}}

Maybe they should use some of our new generated sceneries.
But great to see how FlightGear can be used in many ways!

== 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 ==
===Khorog, Tajikistan===

[[File:Fw190HinduKush.jpeg|right|thumb|Approaching a bank of snow-covered mountains in the south of the Hindu Kush]]
Surrounded by spectacular mountains and nestled in the end of a valley, Khorog Airfield (UT1C) makes an interesting place to land. It can only be approached by flying down the curved valley that snakes in from the North. Flying from here to OPCH (Chitral, Pakistan) at around 500ft AGL all the way is a wonderful way to explore the Hindu Kush mountains.

If you bring a piston engined aircraft, be prepared to adjust the mixture as you climb - at the highest point in the flight, you will be at around 22000ft. Also, don't forget to carry plenty of fuel - there are very few airfields in the Hindu Kush that exist in FlightGear. This is a scenery bug that will hopefully be fixed in the future.

More amazing places to visit can be found at [[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 ===
* [http://www.youtube.com/user/FlyTristarairlines?feature=watch Trez] started a new video series Final Approach:
** [http://www.youtube.com/watch?v=Au6eS6Y6sYY&list=PL60A11F004175486E&index=1&feature=plcp episode 1]
* Dave shared a [http://www.youtube.com/watch?v=VInCXCTi6OA nice approach] to El Dorado International Airport (SKBO)
* [http://www.youtube.com/watch?v=nkoQCr47ddY Highway to Hell] by Kamus Tupolev 214 ILS Dusk APP KSFO /--28R--\ />
* [http://www.youtube.com/watch?v=jdBXlKmLXtQ Manual Approach] MD-BFC landing in TNCM
==== 12 Days of Flight Tips ====
From December 26th to January 6th, [http://www.youtube.com/user/osjcag Oscar] uploaded a daily series in which he gave quick tips in flying and the use of FlightGear.
{| 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]
*[http://www.youtube.com/watch?v=HdVCVH0XMXM Day 10 - Manual Flight Tips]
*[http://www.youtube.com/watch?v=NeDMwBMg6Gs Day 11 - Multiplayer ATC]
*[http://www.youtube.com/watch?v=9FSdbw_c9qA Day 12 - Crosswind Landing Tips]
|}
Or watch all the episodes in [http://www.youtube.com/watch?v=RbB5Sn_ag-A&list=PL569D227E5E767F3D a playlist].

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

=== Then and now ===

My first contact with Flightgear was 0.91 which came with my Linux distribution. I've always enjoyed flying carrier ops - we've just come a long way in visual quality. The left picture is from my old album documenting my 0.91 adventures, the right is using the shader technology of 2.5.

[[File:Carrier-ops-0.91.jpg|400px]] [[File:Carrier-ops-2.5.jpg|400px]]

=== Did you know ===

{{Appendix}}

[[Category:FlightGear Newsletter|2012 01]]

Frequently asked questions

2012-01-22T18:24:34Z

ThorstenB: /* Unable to execute file: bin/Win32/fgrun.exe during installation */

Thank you for downloading [[FlightGear]]! This '''FAQ''' lists some of the most commonly asked questions. Please create a topic at [http://flightgear.org/forums our forum] if you cannot find the answer on your problem(s).

== The FAQ ==
=== Where can I get the latest version of this FAQ? ===
http://wiki.flightgear.org/index.php/FAQ

=== Who do I contact if I have comments about this FAQ? ===
Add your comment to this FAQ's [[Talk:Frequently asked questions|discussion page]].

=== How old is this document? ===
Check its [{{fullurl:{{PAGENAME}}|action=history}} history].

=== What other important documentation should I read? ===
* [http://flightgear.org/Docs/getstart/getstart.html Getting Started Guide]
* [[New to FlightGear]]
* Also see the FlightGear/docs-mini/ directory in the source distribution for various other helpful documents.
* Also see the other [http://www.flightgear.org/Docs/FAQ.shtml FAQ]

== Distribution ==
=== Where can I get FlightGear? ===
The official download page is http://www.flightgear.org/download/. Source code is our primary form of distribution, but precompiled binaries are available for Windows and SGI IRIX.

Alternatively, FlightGear is packaged for Linux by SuSE, Debian and Mandrake, and can be directly installed through those distributions via any package manager.

=== How do I install FlightGear on Ubuntu? ===
FlightGear 2.0.0 can be installed directly from the Synaptic Package Manager for Ubuntu 11.04 onwards. Open Synaptic Package Manager, search for FlightGear and follow instructions.
FlightGear 2.4.0 is available as a [http://www.getdeb.net/welcome/ GetDeb] package for Ubuntu 11.04 onwards. Install GetDeb on your Ubuntu machine and install FlightGear from [http://www.playdeb.net/updates/ubuntu/11.04/?q=flightgear PlayDeb]'s website.

=== What is the password for the FTP server? ===
The FTP server uses standard anonymous login procedures. Login with the username "anonymous" and use your email address as the password. Most FTP clients and web browsers will do this automatically for you.

=== Why won't the FTP server let me in with the right login info? ===
This generally means that the server is at its capacity. You should receive a message saying such, but your FTP client may be hiding it from you. Your options are to keep trying until a slot opens up or try connecting to one of our FTP mirrors listed at http://www.flightgear.org/mirrors.html.

=== Where can I find the latest development source code? ===
{{Main article|Flightgear and Git}}
The latest development code is available for everyone through our Git [http://gitorious.org/fg repository].

=== Why are the aircraft at FlightGear.org out of date? ===
The [http://www.flightgear.org/download/aircraft-v2-4/ official aircraft downloads] are only updated at the time of a new release of FlightGear. This is done because aircraft that are currently in development are usually developed on development/unreleased versions of FlightGear. Those development versions have lots of features that are not supported by the (older) stable release. Would we update the aircraft downloads more often; most aircraft won't work on the stable release of FlightGear.

=== What is SimGear, and why do I need it? ===
[[SimGear]] is a library of supporting code. SimGear is only needed if you plan on compiling FlightGear — it is not needed to run precompiled binaries. For more information see http://www.simgear.org/. Note: When compiling FlightGear it is very important to have the matching version of SimGear.

=== Where can I fly and where do I get the scenery? ===
While the base package only comes with scenery for the San Francisco Bay area, you can currently fly just about anywhere in the world. See the "Additional Scenery" section of http://www.flightgear.org/download/ for more information or go directly to our graphical downloader at http://www.flightgear.org/Downloads/scenery-1.0.1.html

[[Terrasync]] is an option too. It downloads the latest scenery while flying. In 2.4.0 a GUI for enabling/disabing Terrasync can be found at Environment->Scenery Download.

Also visit our "Places to Fly" section of the website (http://www.flightgear.org/places.html) for some help navigating to some awesome locations. (see also [[Installing Scenery]])

=== Where can I get different 3D models for my plane? ===
Official FlightGear aircraft can be found at http://www.flightgear.org/download/aircraft-v2-4/ . Other aircraft in development can be found on [[Git]], and some other aircraft can be found on 3rd party [[FlightGear hangars]].

=== How current is the data in FlightGear compared to the real world? ===
We use the same navaid and airport dataset that X-Plane uses. The current dataset can be found in the <tt>[[$FG ROOT]]/Navaids/</tt> and <tt>[[$FG ROOT]]/Airports/</tt> directories. If you have updates or corrections to the dataset, see http://www.flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html for instructions on contacting the database maintainer.

=== Where is the moving map? ===
A popular moving map display is available under a separate project called [[Atlas]]. Also, [[MPmap]] is an online map for multiplayer.

If you like an alternative to Atlas with updated graphics and mapping provided by the OpenStreetMap project, then check out Flightgear Mapping [http://rubyforge.org/projects/fgmap fgmapping] or [[JMapView]].

=== Why don't you charge money for this? ===
FlightGear can be downloaded for free from many locations including the FlightGear website, but can also be bought on a CD. Although we offer that service (see the website), we encourage other groups to redistribute it for their users, especially within an operating system distribution which makes installation even faster and easier for new users.

Occasionally you may see FlightGear for sale on auction sites or commercial websites under some other name. This can be done quite legitimately as long as the terms of the license are upheld and might be worth the cost if some value-added features such as additional scenery, aircraft or after-sale support are included. Unfortunately, most cases seen to date appear to be just someone trying to make money selling something that is free and providing no real added value.

=== How can I get started with FlightGear ===
The latest release of FlightGear can be downloaded at the [http://www.flightgear.org/download/ download central], but most [[aircraft]] need to be separately downloaded [http://www.flightgear.org/download/aircraft-v2-4/ here] and installed manually. Be aware of system requirements! Also, check out [[New to FlightGear]].

== Compiling ==
{{main article|Building Flightgear}}

=== Why won't FlightGear compile? ===
Well, that depends. First make sure you are using the appropriate versions of FlightGear, [[SimGear]], plib, zlib. If any of the packages are out of sync with the others, compilation may fail. See also [[Building FlightGear]]

The [http://www.flightgear.org/download/ FlightGear Downloads page] should tell you what versions you need if you are trying to compile the latest stable release. If you are using a development snapshot, make sure all three packages are up-to-date.

Also ensure that you have some implementation of OpenGL with glut support with the appropriate header files. Linux users with nVidia cards should make sure you have the latest drivers from nVidia. Other Linux users make sure you have Mesa3D (http://mesa3d.org/) and your X server installed correctly.

If your problems persist, ask in the [http://www.flightgear.org/forums FlightGear Forums], on the [[IRC]] or subscribe to our FlightGear-Users [[mailing list]] and let us know what problem you're having.

== Configuring ==
=== How do I install new scenery? ===
{{Main article|Howto: Install scenery}}
The scenery archive files (ie. w100n30.tar.gz) should be untarred into the Scenery/Terrain directory in your $FG_ROOT.

=== How do I setup my joystick(s)? ===
{{Main article|Joystick}}
FlightGear should come with a helpful program called `fgjs` that can help configure your joystick. Run `fgjs` and then copy the dot file it created into your home directory or add its contents to your existing rc file.

Also, see the <tt>[[$FG_ROOT]]/Docs/README.Joystick</tt> file located in the FlightGear base package and the [[Joystick|joystick page]] on the wiki.

=== What format should my personal .fgfsrc file be in? ===
Your .fgfsrc file should simply be a list of [[Command Line Parameters|command line options]] with one option per line. The file is not an XML file.

If you would rather use an [[XML]] configuration file, you can add something like the following in your .fgfsrc

--config=/path/to/my/config.xml

Almost every option corresponds to a property, so you can choose to use whichever method best suits your needs.

== Running ==
If you get errors in the console (black window), please check [[Howto: Understand console output]] and see if your error is listed (with a solution).

=== Unable to execute file: bin/Win32/fgrun.exe during installation ===
Your system is missing the MSVC runtime libraries required by FlightGear.
Download and install the following vcredist_x86.exe:
* MSVC9 for FG2.4.0 (and earlier): http://www.microsoft.com/download/en/details.aspx?id=26368
* MSVC10 for FG2.6.0 (and later): http://www.microsoft.com/download/en/details.aspx?id=5555

=== Why do I get an error loading libopenal.so.0? ===
With the default installation, libopenal.so.0 is installed into /usr/local/lib. You need to ensure that that path is listed in /etc/ld.so.conf, then run `ldconfig`as root.

=== Why do I get "ssgInit called without a valid OpenGL context"? ===
In short, your GL libraries are broken. So far only Red Hat 7.x users have experienced this (see http://www.redhat.com/bugzilla/show_bug.cgi?id=18867). The only solutions are possibly complicated ones: you can either change distributions (most of us prefer Debian) or upgrade/downgrade your Mesa libs.

Why do some other GL applications work though? Well, Steve Baker (Mr. PLIB) has explained this on the plib-users list (http://www.geocrawler.com/lists/3/SourceForge/1867/0/6470648/).

=== What happened to the panel, keyboard, etc? ===
The problem is almost certainly that your base package is out of sync with FlightGear. Many configurable parts of FlightGear are defined in [[XML]] files contained in the base package.

=== Why doesn't audio work properly under Irix? ===
FlightGear (as of June 2001) uses the Portable Libraries ([[PLIB]]) for playing audio. The audio queue implementation of PLIB is far from optimal (in fact it's just wrong). This seems to work on other platforms quite well, but Irix expects things to be programmed properly.

There has been discussion about using OpenAL (http://www.openal.org/) for the next release of both PLIB and FlightGear. Tests show that the OpenAL audio implementation does the job right, meaning that these audio problems should be gone by then. In the mean time it is best to disable audio on Irix completely (by adding --disable-sound either on the command line or to your $HOME/.fgfsrc file).

=== Why is FlightGear so slow? ===
{{Main article|Howto: Improve Framerates}}
FlightGear supports hardware acceleration, but it seems not to be activated. Make sure you have OpenGL libraries installed and configured properly and make sure you have the latest drivers for your video card.

Linux users: If you are an nVidia user, follow their directions on getting your card working. For most other users, make sure Mesa is installed property and ensure that you have the appropriate kernel device drivers for your card. Most people (and distributions) use modules for their video card device drivers; run `lsmod` as root to see what modules are loaded. You should also make sure that you are loading the appropriate modules in your XF86Config and that your video device section is correct. Now try running an OpenGL application (other than FlightGear) to see how it performs. You can try the gears demo from Mesa or something like Quake3.

=== Why is my SGI machine so slow? ===
First of all, one of the most common mistakes on SGI hardware is to forget to specify --fog-fastest. On most SGI machines the EXP2 shading model isn't hardware supported resulting in frame rates below 1 frame per second (fps).

FlightGear makes extensive use of the OpenGL z-buffer feature,which on most older SGI hardware is only supported in software. This means that the CPU has to do all the z-buffer calculations in addition to the other tasks FlightGear involves (flight dynamics, scenery tracking, pushing commands into the graphics queue, etc). The following features are software rendered on low-end SGI machines (like Indy and Indigo):

* stencil and accumulation buffer
* depth queuing and depth buffering
* fogging, lighting, clipping and transforms
* texturing

This means that running FlightGear with the following options may not even get the desired result:

./runfgfs --fog-disable --shading-flat --disable-skyblend --disable-textures --disable-clouds --disable-sound --disable-panel --enable-hud --disable-anti-alias-hud

I could even imagine that adding --enable-wireframe doesn't work on these machines (I would be happy to be proven wrong though).

On a machine like O2 the following options give an acceptable result:
./runfgfs --fog-fastest --disable-sound

Since I don't have access to other SGI hardware I can't tell which options would be appropriate for your situation.

=== How do I see the Frame Rate? ===
On the in-sim [[menu]] select View > Display Options, then check the box that says "Show frame rate".

=== How do I toggle panel settings? ===
There are two ways. One way is to hide the panel without the HUD showing. To hide the panel, use Shift+P; To make the HUD disappear, use H. The second way is to use the alternative HUD by Shift+I (Use I to switch back).

=== Stuck upside down after "crash"? ===
In his infinite wisdom the FlightGear Grand Master decided that planes were too valuable to allow them to be destroyed by novice pilots who seemed to crash a lot. The fact that nobody has bothered to model crashes may have something to do with it too. :-)

The result of this as you have noticed is that with a little practice an ingenuity you can trim the ship to fly inverted along the ground. The quick answer is to reset the sim, via the <tt>File > Reset</tt> menu. This will place your aircraft back at its starting location.

For the stubborn people out there: The trick to learn is to roll back to normal (non inverted) do this by nursing the elevator to get to about 500 feet or so and use the ailerons to snap roll 180*. This is all good avionics except for the plane not destroying itself. Remember the controls work in reverse when you are inverted and keep that airspeed up!!!

=== Why does FlightGear die on startup saying "time zone reading failed"? ===
This is probably caused by a line-ending problem in the timezone files. Win32 users can resolve the problem by downloading a DOS to UNIX conversion utility available at http://www.nottingham.ac.uk/~eazdluf/d2u.zip. Run as `d2u *.tab` from within the timezone directory to fix your timezone files.

=== Why won't the latest versions of some aircraft work in my (older) version of FlightGear? ===
Often new aircraft development keeps pace with the latest FlightGear code development. New or newly modified aircraft may rely on files (such as new instrument files) or features, only available with newer versions of FlightGear. If you are stuck with an older version of FlightGear, you can try downloading an earlier version of the aircraft at one of the archives:
* [http://www.flightgear.org/Downloads/aircraft-1.9.1/index.shtml Aircraft for 1.9.1]
* [http://flightgear.org/Downloads/aircraft-2.0.0/ Aircraft for 2.0.0]
* [http://ftp.riken.go.jp/pub/FreeBSD/distfiles/flightgear-aircrafts/ Aircraft from various dates]

=== Why are my screenshots black? ===
Make sure you have multithreading disabled in <tt>[[$FG_ROOT]]/preferences.xml</tt>. Enabling it currently breaks the screenshot function.

== Flying ==
=== Why won't my engine(s) start? ===
Aircraft vary in their starting procedure. Some may have an auto-start sequence menu entry or instructions in the aircraft help menu (Press "?") and/or at [[Aircraft|the aircraft's wiki]].

==== Starting engine in single-engine aircraft ====
In general to start the engine on a piston-engine type aircraft, you need:

# Fuel - You can run out of fuel, of course, but for certain aircraft, FlightGear may load it with no fuel, making it impossible to start the engines. Check this in the menu <tt>Equipment > Fuel and Payload</tt>.
# Correct mixture (generally "rich", ie red knob all the way in)
# Magnetos on (R, L, or both--generally select "both")
# Throttle (some engines start better with a little gas)
# Hold starter for sufficient time.

You may be able to do all these functions with the standard 2-D panel or your aircraft's built-in panel. However using the standard key bindings is more reliable:

# Press/hold "m" to set mixture to rich (m=rich, M=lean--if you are at a very high elevation you may need to set it somewhere besides full rich)
# Press "}}}" (three times) to set magneto to R, L, and finally "Both".
# Open throttle a little.
# Press "s" to run the starter. For some aircraft you may have to hold "s" as long as 10 seconds before the engine starts.

These instructions may not work for jet aircraft, helicopters, or other types of aircraft with complex start procedures. Check the instructions in the aircraft help menu (Press "?") and/or at [[Aircraft|the aircraft's wiki]].

==== Starting engine in multi-engine aircraft ====
Starting all engines in a multi-engine aircraft is similar to the single engine--except you must follow the same start sequence for each and every engine. Flightgear provides a convenient way to do this for all engines at once.

Note that the default 2-D panel is connected to ''only one engine''. So if you try to start the engines using the 2-D panel controls you will most likely start only one engine.

Instead, use the keyboard to start all engines at once:

# Press "~" (select all engines)
# Press/hold "m" to set mixture to rich (m=rich, M=lean--if you are at a very high elevation you may need to set the mixture somewhere besides full rich)
# Press "}}}" (three times) to set magnetos to R, L, and finally "Both".
# Open throttle a little (it now controls all engines).
# Press "s" to run the starter (it now runs the starter on all engines). For some aircraft you may have to hold "s" as long as 10 seconds before the engine starts.
# Rev the engines a little with your throttle and check your tachometers and/or visually to be sure all engines are running.

If the engines won't start, make sure you have fuel. Some aircraft have switches to control which fuel tanks feed which engines, so check these. Make sure each engine you want to start is connected to a tank that has fuel. Check fuel tanks in the menu <tt>Equipment > Fuel and Payload</tt>.

These instructions may not work for jet aircraft, helicopters, or other types of aircraft with complex start procedures. Check the instructions in the aircraft help menu (Press "?") and/or at [[Aircraft|the aircraft's wiki]].

=== Where can I learn about instrument flying and navigation? ===
{{Main article|Understanding Navigation}}
* http://www.navfltsm.addr.com/ is a very good site for learning techniques for navigation.
* [http://www.av8n.com/how/ See How It Flies] a very nice book by John S. Denker, freely accessible online

=== What is the difference between Aileron and Rudder? ===
There is a bit of info on aileron vs. rudder in the very same book...

=== Is there support for multi-player flying? ===
{{Main article|Howto: Multiplayer}}
Yes. Both the Windows and *nix versions of FlightGear are capable of multi-player flying on FlightGear servers.

A map showing players aircraft online in real time is available as [[MPmap]].

=== Where are the best places to fly in FlightGear? ===
FlightGear scenery covers the whole world, but thanks to the FlightGear user community, certain airports and areas are more detailed than others. For a full list of airports with buildings available in the default scenery, visit the forum's [http://flightgear.org/forums/viewtopic.php?f=5&t=4700&st=0&sk=t&sd=a|list of improved airports].

* There are a lot of high-quality scenery models around Paris, France.
* EHAM Amsterdam Schiphol, EGKK London Gatwick and LFPG Paris Charles de Gaulle are some of the highest quality airports in FlightGear.
* TNCM St. Maarten is a popular destination, and the surrounding islands (Anguilla, St. Eustatius, Saba, St. Barthélemy, St. Kitts, and Nevis) are all well-modeled.

Furthermore, there is a special wiki page with a list and preview of good [[Places to fly]].

=== Where can I find airport info and aeronautical charts online? ===
{{Main article|Getting IFR Charts}}
A world-wide database of airports and [[navaids]] can be found at [http://worldaerodata.com World Aero Data].

Two very good US-only sources are
* Airports:
** [http://www.airnav.com/airports/ AirNav.com]
* Charts:
** [http://skyvector.com/ SkyVector.com]

=== Is there support for any military scenarios like dog fighting or bomb dropping? ===
Most of our developers are primarily interested and focused on civilian aviation. We aren't explicitly excluding these features — we just haven't had anyone who has done much development in these areas until recently. Now there are third-party bombing scenarios for the [[A-10]] and other aircraft with armament, like the [[North American OV-10A Bronco]], [[General Dynamics F-16]] and [[F-117 Nighthawk]].

[http://flightgear.org/forums/viewtopic.php?f=2&t=5742 A new add-on (9/2009)] adds support for dogfighting (including multiplayer dogfighting) and bombing scenarios.

=== Why are my controls returning to a particular position? ===
There are several possibilities that can lead to this:
* If your aircraft's [[autopilot]] is enabled, it will take over (some of) your controls. Switch the autopilot off to regain control.
* Some laptops have an onboard gravity sensor, that might be detected by FlightGear as a [[joystick]]. You can set FlightGear to ignore this fake-joystick:
*# Get your accelerometer's name via the in-sim <tt>Help > Joystick Information</tt> dialog.
*# Add this name to your <tt>[[$FG_ROOT]]/Input/Joysticks/Accelerometers/accelerometers.xml</tt> file, enclosed by <tt><name></tt> and <tt></name></tt> tags..
*# Report your device name to #flightgear at [[IRC|irc.flightgear.org]], so it can be included in the "official" accelerometer.xml file.

=== Why does my panel disappear when looking around? ===
2D panels are often only visible while looking in a fixed direction. At FlightGear, we prefer 3D cockpits, so most aircraft have those. The Cessna C172P is an example of an aircraft that has various variants, including a 2D and 3D one. Make sure you pick the 3D one (<tt>--aircraft=c172p</tt>).

== Hacking ==
=== What language is FlightGear written in? ===
Mostly C++ with some supporting C code that's primarily contained within SimGear.

See the [https://www.ohloh.net/p/flightgear/analyses/latest code analyses at Ohloh] for more details on the used languages:
* [https://www.ohloh.net/p/flightgear/analyses/latest FlightGear programm]
* [https://www.ohloh.net/p/flightgeardata/analyses/latest FlightGear data] (aircraft, sounds etc.)

=== How do I design a flight dynamics model for a new aircraft? ===
FlightGear supports various [[flight dynamics model]]s (FDMs), but just two of them are commonly used:
* [[JSBSim]]: see http://jsbsim.sf.net/.
* [[YASim]]: if you want a simpler FDM to work with, try your hand at YASim. For a guide on creating YASim aircraft, look in the FlightGear base package for <tt>[[$FG_ROOT]]/Docs/README.yasim</tt>.

[[UIUC]] is also available, but the main and most used ones are [[JSBSim]] and [[YASim]].

=== How do I import planes from Microsoft Flight Simulator? ===
You can import planes by using the 3D Convert utility which will convert the MSFS 3d model to a format used by FlightGear. You have to add the animations and parts.

Also, although you can import the 3D model and textures, the flight dynamics (the .AIR file) must be completely redone for FlightGear.

If you wish to import a model made with gmax, you will need to convert it to .MDL format using Microsoft's MakeMDL SDK which is available at http://zone.msn.com/flightsim/FS02DevDeskSDK08.asp.

=== How do I design or modify a panel? ===
See the README.xmlpanel file located in the FlightGear/docs-mini/ directory of the source distribution.

=== How do I place objects, like buildings, into FlightGear? ===
{{Main article|Portal:Developer/Scenery}}
First, ensure that you have v0.7.7 or later, the scenery files where you plan to place the object, the actual model, and the longitude and latitude where you plan to place the object.

Now get the altitude for your point. If you don't want to calculate this yourself, start FlightGear at your location and take note of the altitude. Here's an example command:

fgfs --lat=45.50 --lon=-75.73 2>&1 | tee fgfs.log

The altitude is probably in feet, so divide the starting altitude by 3.28.

Search the output log file for the first occurrence of the string "Loading tile" and take note of the filename. In the above example, the output line looks like:

Loading tile /usr/local/Scenery/w080n40/w076n45/1712601

Copy a 3D model in a format that Plib understands to the same directory as the tile file. Edit the text file in that directory consisting of the tile name with the extension ".stg". The file will already exist if there is an airport on the tile; otherwise, you can create it from scratch. In our example, the filename is:

/usr/local/Scenery/w080n40/w076n45/1712601.stg

At the end of the file, add a new entry for your object, consisting of the word "OBJECT_STATIC" followed by the model name, the longitude in degrees, the latitude in degrees, the altitude in meters, and the heading in degrees. In our example the line looks like:

OBJECT_STATIC Towerax.ac -75.73 45.40 60 0

Save the changes to the .stg file, restart FlightGear, and enjoy.

NOTE: The above information was taken from the following mailing list post: http://www.geocrawler.com/archives/3/11854/2001/6/0/5991409/. See that page if this one doesn't make sense.

An alternative approach using PPE is described at http://mail.flightgear.org/pipermail/flightgear-devel/2001-December/002239.html by Norman Vine.

Since Flightgear 0.9.10 there is an easy way for [[Placing 3D Objects with the UFO]].

=== Where can I learn 3D programming and how do I get involved? ===
Contributing to the 2D panel doesn't require any coding at all, just a minimal knowledge of [[XML]] syntax (i.e. five minutes' worth) and good skills with drawing and/or paint programs. Every instrument on the current panel, with the partial exception of the magnetic compass, is defined entirely in XML with no custom C++ code. If you want to get started, take a look at John Check's excellent intro at <tt>[[$FG_ROOT]]/Docs/README.xmlpanel.html</tt>.

Likewise, if you want to create a 3D cockpit for FlightGear, or to create buildings, external aircraft models, etc., your help is *desperately* needed. The only rule is to go easy on the triangles -- a model with 50,000 triangles probably won't be usable in FlightGear, and one with 5,000 triangles, only marginally. If you can design a nice 3D cockpit interior for in a 3D design program such as [[AC3D]], [[Blender]] or [[PPE]] and you can write some XML code, it will be much appreciatted.

If, on the other hand, you really want to get your hands dirty with C++ coding, you'll have to buy a good [[OpenGL]] book eventually. However, FlightGear uses [[OSG]], a high performance 3D graphics toolkit. To get started with 3D C++ coding, you can take a look at the OSG documentation and learn only as much OpenGL as you need, when you need it.

=== How do I add an airport? ===
You can add your airport to the <tt>[[$FG ROOT]]/Airports/default.apt.gz</tt> file, but to get the airport to show up visually, you will have to [[Frequently asked questions#Can I generate my own scenery?|rebuild the scenery]] around the airport. The format of the default.apt file is documented at http://www.flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html.

=== Can I generate my own scenery? ===
{{Main article|TerraGear}}
Yes, though it can be a difficult task. FlightGear's scenery generation is handled by a sister project, [[TerraGear]].

[[de:FAQ]]
[[es:Preguntas frecuentes]]
[[fr:Foire aux questions]]
[[pl:FAQ]]

FlightGear related projects

2012-01-19T21:05:57Z

ThorstenB: /* FlightGear GUI */

Various [[FlightGear]] related projects and software from the FlightGear website [http://www.flightgear.org/links.html here] and [http://www.flightgear.org/Projects/ here] See also [[Links]] and [[FlightGear hangars]]

== FlightGear ==

=== FlightGear related software and projects ===

* [[JSBSim]] Flight Dynamics Modeling.
** [[JSBSim Commander]]
* [[UIUC]]
* [[YASim]]

* [[Atlas]]
* [[Kelpie Flight Planner]] (uses [[Java]])
* [[FlightGear Package Manager‎]] (uses Java) (Alpha development stage)
* [http://rubyforge.org/projects/fgmap Flightgear Mapping] (realtime flight tracking using openstreetmap maps)

* [[FlightGear Multiplayer Server]] (FGMS)
* [[FlightGear Admin Wizard]] (FGAdmin)
* [[FGCOM]]
* [[MPmap]]

* [[Glass Cockpit Projects]]

* [[SimGear]]
* [[PLIB]]
* [[OSG]]

* [[Comete for FlightGear]] (control FlightGear with an Android device)
** [http://code.google.com/p/comete/ Project Link]
** [https://market.android.com/details?id=alni.comete.android.fgfs Android Market Link]

==== Scenery related ====
* [[TerraSync]]
* [[TerraGear]]
* [[TaxiDraw]]
* [[FlightGear Airport Editor]] ([http://www.greghawkes.com/flightgear/tools/airporteditor.html AirportEditor]) a [[Java]]-based airport editor for FlightGear [http://www.mail-archive.com/flightgear-users@lists.sourceforge.net/msg06118.html]
* [[FlightGear Scenery Designer]]
* [[FGSignMaker]]
* [[Signs]]

* [[FlightGear Scenery Object Database]] (database of models)
* [[World Custom Scenery Project]]
* [[FlightGear NL]]

=== FlightGear GUI ===
* [[FlightGear Launch Control]] ([http://sourceforge.net/projects/fgrun Website]) (Fgrun)
* [[JFlightWizard]] (uses [[Java]]) ([http://sourceforge.net/projects/jflightwizard/ Website])

* [[KFreeFlight]] (for KDE) ([http://kfreeflight.sourceforge.net/ Website])
* [[FGKicker]] (GTK+) ([http://freshmeat.net/projects/fgkicker/ Website])
* [[FGTools]]
* [[FGo!]] ([http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo Website])
* [[FG Flier]] ([http://sourceforge.net/projects/fgflier/ Website])
* [[FGStartup]] ([http://fgstartup.sourceforge.net/ Website])
* [[fgx]] ([http://code.google.com/p/fgx Website])
* [[FGWalk]] ([http://sourceforge.net/projects/fgwalk/ Website])

=== Other ===
* [[FlightGear Live]] ([http://pigeond.net/flightgear/fglive.html Website])
* [[Virtual Air]]
* [[FlightGear Mac OS X]]

== 3D modeling: ==
* [[Blender]] ([[GNU GPL]] licensed)
* [[Wings 3D]] (BSD license)

* [[AC3D]] (free trial version/restricted version)
* [[Sketchup]] (free version of Sketchup Pro)

* [[PPE]]
* [[K-3D]]
* [[ADC Contests]]

== Applied use of FlightGear in projects ==
{{Main article|Professional and educational FlightGear users}}

* [[OV-10 Bronco Museum|OV-10 Bronco Association Museum Simulator Project]]
* RWTH Aachen research simulator [http://www.dynamik.rwth-aachen.de/English/Simulators][http://www.flightgear.org/Projects/]
* Phil Cobbin's Synthetic Vision Project [http://www.flightgear.org/Projects/SynthVision/]
* Genesis 3000 flight simulator
* John Wojnaroski's 747 Cockpit Project [http://www.flightgear.org/Projects/747-JW/]
* Gene Buckle's F-15C Eagle Flight Simulator [http://www.f15sim.com/]
* Smart Icing Systems Project at University of Illinois at Urbana Champaign
* Enhancing of a flight simulator used in a French aeronautics school (ISAE) [http://www.garrouste.net/rapport%20de%20stage%20sup.pdf]

== References ==
* http://www.flightgear.org/Projects/
* http://www.flightgear.org/links.html

== External Links ==
* [http://sourceforge.net/projects/atlas atlas-FlightGear Moving Map] ([[Atlas]])
* [http://sourceforge.net/projects/taxidraw TaxiDraw-Taxiway Layouting] ([[TaxiDraw]])
* [http://sourceforge.net/projects/fgsd fgsd-FlightGear Scenery Designer] ([[FlightGear Scenery Designer]])
* [http://sourceforge.net/projects/fgms FlightGear Multiplayer Server] ([[FlightGear Multiplayer Server]])
* [http://pigeond.net/flightgear/fgmap.html FlightGear Multiplayer Map]
* [http://www.terragear.org TerraGear-FlightGear Scenery Compiler Suite] ([[TerraGear]])
* [http://sourceforge.net/projects/fgrun fgrun-FlightGear GUI Launch Wizard] ([[Fgrun]])
* [http://www.custom-scenery.org/ FlightGear World Custom Scenery Project] ([[World Custom Scenery Project]])
* [http://mapserver.flightgear.org/ FlightGear GIS/Map Server])([[MPmap]])
* [http://www.simgear.org SimGear-FlightGear simulation kernel libs]([[SimGear]])
* [http://squonk.abacab.org/dokuwiki/fgcom FGCOM - FlightGear Radio Comms] ([[FGCOM]])

== Related ==
* [[Suggested Software]]

[[Category:List]]
[[Category:Contribution requests]]

FlightGear related projects

2012-01-19T21:03:21Z

ThorstenB: /* FlightGear GUI */

Various [[FlightGear]] related projects and software from the FlightGear website [http://www.flightgear.org/links.html here] and [http://www.flightgear.org/Projects/ here] See also [[Links]] and [[FlightGear hangars]]

== FlightGear ==

=== FlightGear related software and projects ===

* [[JSBSim]] Flight Dynamics Modeling.
** [[JSBSim Commander]]
* [[UIUC]]
* [[YASim]]

* [[Atlas]]
* [[Kelpie Flight Planner]] (uses [[Java]])
* [[FlightGear Package Manager‎]] (uses Java) (Alpha development stage)
* [http://rubyforge.org/projects/fgmap Flightgear Mapping] (realtime flight tracking using openstreetmap maps)

* [[FlightGear Multiplayer Server]] (FGMS)
* [[FlightGear Admin Wizard]] (FGAdmin)
* [[FGCOM]]
* [[MPmap]]

* [[Glass Cockpit Projects]]

* [[SimGear]]
* [[PLIB]]
* [[OSG]]

* [[Comete for FlightGear]] (control FlightGear with an Android device)
** [http://code.google.com/p/comete/ Project Link]
** [https://market.android.com/details?id=alni.comete.android.fgfs Android Market Link]

==== Scenery related ====
* [[TerraSync]]
* [[TerraGear]]
* [[TaxiDraw]]
* [[FlightGear Airport Editor]] ([http://www.greghawkes.com/flightgear/tools/airporteditor.html AirportEditor]) a [[Java]]-based airport editor for FlightGear [http://www.mail-archive.com/flightgear-users@lists.sourceforge.net/msg06118.html]
* [[FlightGear Scenery Designer]]
* [[FGSignMaker]]
* [[Signs]]

* [[FlightGear Scenery Object Database]] (database of models)
* [[World Custom Scenery Project]]
* [[FlightGear NL]]

=== FlightGear GUI ===
* [[FlightGear Launch Control]] ([http://sourceforge.net/projects/fgrun Website]) (Fgrun)
* [[JFlightWizard]] (uses [[Java]]) ([http://sourceforge.net/projects/jflightwizard/ Website])

* [[KFreeFlight]] (for KDE) ([http://kfreeflight.sourceforge.net/ Website])
* [[FGKicker]] (GTK+) ([http://freshmeat.net/projects/fgkicker/ Website])
* [[FGTools]]
* [[FGo!]] ([http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo Website])
* [[FG Flier]] ([http://sourceforge.net/projects/fgflier/ Website])
* [[FGStartup]] ([http://fgstartup.sourceforge.net/ Website])
* [[FGx]] ([http://code.google.com/p/fgx Website])
* [[FGWalk]] ([http://sourceforge.net/projects/fgwalk/ Website])

=== Other ===
* [[FlightGear Live]] ([http://pigeond.net/flightgear/fglive.html Website])
* [[Virtual Air]]
* [[FlightGear Mac OS X]]

== 3D modeling: ==
* [[Blender]] ([[GNU GPL]] licensed)
* [[Wings 3D]] (BSD license)

* [[AC3D]] (free trial version/restricted version)
* [[Sketchup]] (free version of Sketchup Pro)

* [[PPE]]
* [[K-3D]]
* [[ADC Contests]]

== Applied use of FlightGear in projects ==
{{Main article|Professional and educational FlightGear users}}

* [[OV-10 Bronco Museum|OV-10 Bronco Association Museum Simulator Project]]
* RWTH Aachen research simulator [http://www.dynamik.rwth-aachen.de/English/Simulators][http://www.flightgear.org/Projects/]
* Phil Cobbin's Synthetic Vision Project [http://www.flightgear.org/Projects/SynthVision/]
* Genesis 3000 flight simulator
* John Wojnaroski's 747 Cockpit Project [http://www.flightgear.org/Projects/747-JW/]
* Gene Buckle's F-15C Eagle Flight Simulator [http://www.f15sim.com/]
* Smart Icing Systems Project at University of Illinois at Urbana Champaign
* Enhancing of a flight simulator used in a French aeronautics school (ISAE) [http://www.garrouste.net/rapport%20de%20stage%20sup.pdf]

== References ==
* http://www.flightgear.org/Projects/
* http://www.flightgear.org/links.html

== External Links ==
* [http://sourceforge.net/projects/atlas atlas-FlightGear Moving Map] ([[Atlas]])
* [http://sourceforge.net/projects/taxidraw TaxiDraw-Taxiway Layouting] ([[TaxiDraw]])
* [http://sourceforge.net/projects/fgsd fgsd-FlightGear Scenery Designer] ([[FlightGear Scenery Designer]])
* [http://sourceforge.net/projects/fgms FlightGear Multiplayer Server] ([[FlightGear Multiplayer Server]])
* [http://pigeond.net/flightgear/fgmap.html FlightGear Multiplayer Map]
* [http://www.terragear.org TerraGear-FlightGear Scenery Compiler Suite] ([[TerraGear]])
* [http://sourceforge.net/projects/fgrun fgrun-FlightGear GUI Launch Wizard] ([[Fgrun]])
* [http://www.custom-scenery.org/ FlightGear World Custom Scenery Project] ([[World Custom Scenery Project]])
* [http://mapserver.flightgear.org/ FlightGear GIS/Map Server])([[MPmap]])
* [http://www.simgear.org SimGear-FlightGear simulation kernel libs]([[SimGear]])
* [http://squonk.abacab.org/dokuwiki/fgcom FGCOM - FlightGear Radio Comms] ([[FGCOM]])

== Related ==
* [[Suggested Software]]

[[Category:List]]
[[Category:Contribution requests]]

FlightGear related projects

2012-01-19T21:01:33Z

ThorstenB: /* FlightGear GUI */

Various [[FlightGear]] related projects and software from the FlightGear website [http://www.flightgear.org/links.html here] and [http://www.flightgear.org/Projects/ here] See also [[Links]] and [[FlightGear hangars]]

== FlightGear ==

=== FlightGear related software and projects ===

* [[JSBSim]] Flight Dynamics Modeling.
** [[JSBSim Commander]]
* [[UIUC]]
* [[YASim]]

* [[Atlas]]
* [[Kelpie Flight Planner]] (uses [[Java]])
* [[FlightGear Package Manager‎]] (uses Java) (Alpha development stage)
* [http://rubyforge.org/projects/fgmap Flightgear Mapping] (realtime flight tracking using openstreetmap maps)

* [[FlightGear Multiplayer Server]] (FGMS)
* [[FlightGear Admin Wizard]] (FGAdmin)
* [[FGCOM]]
* [[MPmap]]

* [[Glass Cockpit Projects]]

* [[SimGear]]
* [[PLIB]]
* [[OSG]]

* [[Comete for FlightGear]] (control FlightGear with an Android device)
** [http://code.google.com/p/comete/ Project Link]
** [https://market.android.com/details?id=alni.comete.android.fgfs Android Market Link]

==== Scenery related ====
* [[TerraSync]]
* [[TerraGear]]
* [[TaxiDraw]]
* [[FlightGear Airport Editor]] ([http://www.greghawkes.com/flightgear/tools/airporteditor.html AirportEditor]) a [[Java]]-based airport editor for FlightGear [http://www.mail-archive.com/flightgear-users@lists.sourceforge.net/msg06118.html]
* [[FlightGear Scenery Designer]]
* [[FGSignMaker]]
* [[Signs]]

* [[FlightGear Scenery Object Database]] (database of models)
* [[World Custom Scenery Project]]
* [[FlightGear NL]]

=== FlightGear GUI ===
* [[FlightGear Launch Control]] ([http://sourceforge.net/projects/fgrun Website]) (Fgrun)
* [[JFlightWizard]] (uses [[Java]])

* [[KFreeFlight]] (for KDE) ([http://kfreeflight.sourceforge.net/ Website])
* [[FGKicker]] (GTK+) ([http://freshmeat.net/projects/fgkicker/ Website])
* [[FGTools]]
* [[FGo!]] ([http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo Website])
* [[FG Flier]] ([http://sourceforge.net/projects/fgflier/ Website])
* [[FGStartup]] ([http://fgstartup.sourceforge.net/ Website])
* [[FGx]] ([http://code.google.com/p/fgx Website])
* [[FGWalk]] ([http://sourceforge.net/projects/fgwalk/ Website])

=== Other ===
* [[FlightGear Live]] ([http://pigeond.net/flightgear/fglive.html Website])
* [[Virtual Air]]
* [[FlightGear Mac OS X]]

== 3D modeling: ==
* [[Blender]] ([[GNU GPL]] licensed)
* [[Wings 3D]] (BSD license)

* [[AC3D]] (free trial version/restricted version)
* [[Sketchup]] (free version of Sketchup Pro)

* [[PPE]]
* [[K-3D]]
* [[ADC Contests]]

== Applied use of FlightGear in projects ==
{{Main article|Professional and educational FlightGear users}}

* [[OV-10 Bronco Museum|OV-10 Bronco Association Museum Simulator Project]]
* RWTH Aachen research simulator [http://www.dynamik.rwth-aachen.de/English/Simulators][http://www.flightgear.org/Projects/]
* Phil Cobbin's Synthetic Vision Project [http://www.flightgear.org/Projects/SynthVision/]
* Genesis 3000 flight simulator
* John Wojnaroski's 747 Cockpit Project [http://www.flightgear.org/Projects/747-JW/]
* Gene Buckle's F-15C Eagle Flight Simulator [http://www.f15sim.com/]
* Smart Icing Systems Project at University of Illinois at Urbana Champaign
* Enhancing of a flight simulator used in a French aeronautics school (ISAE) [http://www.garrouste.net/rapport%20de%20stage%20sup.pdf]

== References ==
* http://www.flightgear.org/Projects/
* http://www.flightgear.org/links.html

== External Links ==
* [http://sourceforge.net/projects/atlas atlas-FlightGear Moving Map] ([[Atlas]])
* [http://sourceforge.net/projects/taxidraw TaxiDraw-Taxiway Layouting] ([[TaxiDraw]])
* [http://sourceforge.net/projects/fgsd fgsd-FlightGear Scenery Designer] ([[FlightGear Scenery Designer]])
* [http://sourceforge.net/projects/fgms FlightGear Multiplayer Server] ([[FlightGear Multiplayer Server]])
* [http://pigeond.net/flightgear/fgmap.html FlightGear Multiplayer Map]
* [http://www.terragear.org TerraGear-FlightGear Scenery Compiler Suite] ([[TerraGear]])
* [http://sourceforge.net/projects/fgrun fgrun-FlightGear GUI Launch Wizard] ([[Fgrun]])
* [http://www.custom-scenery.org/ FlightGear World Custom Scenery Project] ([[World Custom Scenery Project]])
* [http://mapserver.flightgear.org/ FlightGear GIS/Map Server])([[MPmap]])
* [http://www.simgear.org SimGear-FlightGear simulation kernel libs]([[SimGear]])
* [http://squonk.abacab.org/dokuwiki/fgcom FGCOM - FlightGear Radio Comms] ([[FGCOM]])

== Related ==
* [[Suggested Software]]

[[Category:List]]
[[Category:Contribution requests]]

FlightGear related projects

2012-01-19T20:59:12Z

ThorstenB: /* FlightGear GUI */ more flightgear launchers...

Various [[FlightGear]] related projects and software from the FlightGear website [http://www.flightgear.org/links.html here] and [http://www.flightgear.org/Projects/ here] See also [[Links]] and [[FlightGear hangars]]

== FlightGear ==

=== FlightGear related software and projects ===

* [[JSBSim]] Flight Dynamics Modeling.
** [[JSBSim Commander]]
* [[UIUC]]
* [[YASim]]

* [[Atlas]]
* [[Kelpie Flight Planner]] (uses [[Java]])
* [[FlightGear Package Manager‎]] (uses Java) (Alpha development stage)
* [http://rubyforge.org/projects/fgmap Flightgear Mapping] (realtime flight tracking using openstreetmap maps)

* [[FlightGear Multiplayer Server]] (FGMS)
* [[FlightGear Admin Wizard]] (FGAdmin)
* [[FGCOM]]
* [[MPmap]]

* [[Glass Cockpit Projects]]

* [[SimGear]]
* [[PLIB]]
* [[OSG]]

* [[Comete for FlightGear]] (control FlightGear with an Android device)
** [http://code.google.com/p/comete/ Project Link]
** [https://market.android.com/details?id=alni.comete.android.fgfs Android Market Link]

==== Scenery related ====
* [[TerraSync]]
* [[TerraGear]]
* [[TaxiDraw]]
* [[FlightGear Airport Editor]] ([http://www.greghawkes.com/flightgear/tools/airporteditor.html AirportEditor]) a [[Java]]-based airport editor for FlightGear [http://www.mail-archive.com/flightgear-users@lists.sourceforge.net/msg06118.html]
* [[FlightGear Scenery Designer]]
* [[FGSignMaker]]
* [[Signs]]

* [[FlightGear Scenery Object Database]] (database of models)
* [[World Custom Scenery Project]]
* [[FlightGear NL]]

=== FlightGear GUI ===
* [[FlightGear Launch Control]] ([http://sourceforge.net/projects/fgrun Website]) (Fgrun)
* [[JFlightWizard]] (uses [[Java]])

* [[KFreeFlight]] (for KDE) ([http://kfreeflight.sourceforge.net/ Website])
* [[FGKicker]] (GTK+) ([http://freshmeat.net/projects/fgkicker/ Website])
* [[FGTools]]
* [[FGo!]] ([http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo Website])
* [[FG Flier]]
* [[FGStartup]] ([http://fgstartup.sourceforge.net/ Website])
* [[FGx]] ([http://code.google.com/p/fgx Website])
* [[FGWalk]] ([http://sourceforge.net/projects/fgwalk/ Website])

=== Other ===
* [[FlightGear Live]] ([http://pigeond.net/flightgear/fglive.html Website])
* [[Virtual Air]]
* [[FlightGear Mac OS X]]

== 3D modeling: ==
* [[Blender]] ([[GNU GPL]] licensed)
* [[Wings 3D]] (BSD license)

* [[AC3D]] (free trial version/restricted version)
* [[Sketchup]] (free version of Sketchup Pro)

* [[PPE]]
* [[K-3D]]
* [[ADC Contests]]

== Applied use of FlightGear in projects ==
{{Main article|Professional and educational FlightGear users}}

* [[OV-10 Bronco Museum|OV-10 Bronco Association Museum Simulator Project]]
* RWTH Aachen research simulator [http://www.dynamik.rwth-aachen.de/English/Simulators][http://www.flightgear.org/Projects/]
* Phil Cobbin's Synthetic Vision Project [http://www.flightgear.org/Projects/SynthVision/]
* Genesis 3000 flight simulator
* John Wojnaroski's 747 Cockpit Project [http://www.flightgear.org/Projects/747-JW/]
* Gene Buckle's F-15C Eagle Flight Simulator [http://www.f15sim.com/]
* Smart Icing Systems Project at University of Illinois at Urbana Champaign
* Enhancing of a flight simulator used in a French aeronautics school (ISAE) [http://www.garrouste.net/rapport%20de%20stage%20sup.pdf]

== References ==
* http://www.flightgear.org/Projects/
* http://www.flightgear.org/links.html

== External Links ==
* [http://sourceforge.net/projects/atlas atlas-FlightGear Moving Map] ([[Atlas]])
* [http://sourceforge.net/projects/taxidraw TaxiDraw-Taxiway Layouting] ([[TaxiDraw]])
* [http://sourceforge.net/projects/fgsd fgsd-FlightGear Scenery Designer] ([[FlightGear Scenery Designer]])
* [http://sourceforge.net/projects/fgms FlightGear Multiplayer Server] ([[FlightGear Multiplayer Server]])
* [http://pigeond.net/flightgear/fgmap.html FlightGear Multiplayer Map]
* [http://www.terragear.org TerraGear-FlightGear Scenery Compiler Suite] ([[TerraGear]])
* [http://sourceforge.net/projects/fgrun fgrun-FlightGear GUI Launch Wizard] ([[Fgrun]])
* [http://www.custom-scenery.org/ FlightGear World Custom Scenery Project] ([[World Custom Scenery Project]])
* [http://mapserver.flightgear.org/ FlightGear GIS/Map Server])([[MPmap]])
* [http://www.simgear.org SimGear-FlightGear simulation kernel libs]([[SimGear]])
* [http://squonk.abacab.org/dokuwiki/fgcom FGCOM - FlightGear Radio Comms] ([[FGCOM]])

== Related ==
* [[Suggested Software]]

[[Category:List]]
[[Category:Contribution requests]]

FGViewer

2011-12-18T22:12:36Z

ThorstenB:

'''FGViewer''' is a utility to load a lightweight [[OSG]] viewer instead of loading the entire simulator. Useful for checking aircraft models, scenery tiles and airport layouts.

To launch FGViewer, you run the following command:
fgfs --fgviewer [path]
where [path] is the path to the thing that you want to view. An example of a possible path is <tt>Scenery/Terrain/w130n30/w123n37/KSFO.btg.gz</tt>. The full command, will show the layout of [[San Francisco International Airport]]:
fgfs --fgviewer Scenery/Terrain/w130n30/w123n37/KSFO.btg.gz

== Controls ==
{| class="prettytable"
!Key
!Function
|-
|Esc
|Quit FGViewer
|-
|LMB
|Rotate view
|-
|MMB
|Pan view
|-
|RMB
|Zoom view
|}

[[Category:Software]]

FGPanel

2011-12-18T22:07:27Z

ThorstenB: orthography

[[File:FGPanel_SenecaII.png|thumb|300px|The 2D panel of a [[SenecaII]].]]
'''FGPanel''' is designed as a standalone lightweight panel rendering engine to draw 2D panels on a low-cost computer/graphic card without 3D acceleration at reasonable frame rates.

FGPanel was not part of the FlightGear 2.4.0 release for Windows. Windows users can get the executable from [http://flightgear.simpits.org:8080/job/FlightGear-Win-Cmake/lastSuccessfulBuild/artifact/install/msvc100/FlightGear/bin/fgpanel.exe Jenkins].

== FGPanel Live System ==
[[File:C172MiniCockpit1.jpg|thumb|200px|right|A complete display setup for the [[Cessna C172P]] using FGPanel.]]
FGPanel is now available as a ''Live System'', 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) 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.

== Related content ==
* [[ Howto: Build your own procedure trainer]], describes how you can create a "cheap" procedure trainer, making use of FGPanel to draw the instruments.

== External link ==
* [https://gitorious.org/fg/flightgear/trees/next/utils/fgpanel Source], part of fg/flightgear.
* [https://gitorious.org/fg/flightgear/blobs/next/utils/fgpanel/README README]

[[Category: Software]]

FlightGear Git: splitting FGData

2011-12-11T22:57:47Z

ThorstenB: /* 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.

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.

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

{{Appendix}}

Aircraft maintenance

2011-12-10T15:37:04Z

ThorstenB:

Some bugfixes and improvements require aircraft to be adapted/fixed to remain airworthy, to be working correctly, or to be taking full advantage of latest FlightGear version. The following ''Airworthiness Directives'' and ''Aviation Maintenance Alerts'' issued by the ''FlightGear Aviation Administration'' (FAA) should be considered for aircraft maintenance (A/B/C/D checks).

== JSBSim ==
=== Deprecated engine properties "egt_degc" and "egt_degf" ===
Properties will be removed with a future JSBSim/FlightGear version. Replace "_" with "-", i.e. use:
/engines/engine[..]/egt-degc
/engines/engine[..]/egt-degf

== Tanks ==
With >= FG2.4.0 the "level-gal_us" and "level-lbs" properties of tanks
/consumables/fuel/tank[..]/level-gal_us
/consumables/fuel/tank[..]/level-lbs
are connected and computed automatically. Aircraft should only set one of these properties manually (i.e. on start-up), and NOT try to configure both.

''Not sure, there is something about it that results in an issue for some aircraft who try to mess with several properties. Torsten knows more...''

== Instruments ==
=== Realistic NAV radio ===
With >= FG2.6.0 the NAV and DME radios are more realistic. Signals are "flickering" when at the edge of a station's range. The properties
/instrumentation/dme/in-range
/instrumentation/nav/in-range
may flicker on-off-on-... frequently. Some autopilots (mainly airliners) try to capture a localizer as soon as a NAV station is "in-range", which results in an issue when signal isn't stable yet. As a work-around, only use the properties above to enable/disable the NAV/DME cockpit display (to get the realistic display flickering effect), but use the property
/instrumentation/nav/signal-quality-norm
to detect a valid signal for the autopilot's capture logic, e.g. add a condition that requires a high signal strength, say above 0.9, to avoid capturing too early while the signal is still unstable.

=== DME vs NAV radio ===
Aircraft with DME displays must include a DME instrument. With <=FG2.4.0 is was enough to add a "nav" instrument in order to also get some DME properties - this is deprecated.
Add the DME instrument:
<dme>
<name>dme</name>
<number>0</number>
</dme>
The use of the NAV radio's DME properties is also deprecated. Instead of
/instrumentation/nav/dme-in-range
use
/instrumentation/dme/in-range
The deprecated DME properties are still supported with FG2.6.0, but will be removed with a later version.

=== Incorrect DME range displayed ===
Many aircraft (mainly airliners) do not display the correct DME distance.
To obtain the correct DME distance, use DME instrument properties - not the nav instrument's properties. For DMEs, do '''not''' use:
/instrumentation/nav/nav-distance
which does not reflect the correct DME distance. Instead use
/instrumentation/dme/indicated-distance-nm

=== DME/NAV display beyond station range ===
Many aircraft (mainly airliners) display DME and/or NAV information, even though the DME/VOR/ILS is out of range - or even when the selected station doesn't even provide DME/NAV information - which is not realistic. NAV/DME displays should have a condition respecting
/instrumentation/dme/in-range
for DME displays and a condition on
/instrumentation/nav/in-range
for NAV/ILS displays, and otherwise blank/disable the distance/direction/display.

=== Attitude indicator ===
The FG attitude indicator supports [http://en.wikipedia.org/wiki/Attitude_indicator caging], usually triggered by a push/pull switch next to the attitude indicator. The correct property name of FG's attitude indicator instrument is named
/instrumentation/attitude-indicator/caged-flag
Apparently a copy & paste issue has resulted in a large number of FlightGear aircraft incorrectly using the property
/instrumentation/attitude-indicator/caged
which has no effect. "caged" should be replaced by "caged-flag".

== Sound ==
=== Stereo sound files unsupported ===
Stereo sound files can not (/no longer) be used for sound effects and must be converted to mono. Proper sound effects always required single channel wave sources. A 3D sound engine uses information on position, direction, speed of every source to ''render'' realistic 3D sound. This does '''not''' work with stereo files, since both channels would be rendered at the same position (no stereo effect anyway). Stereo files were usable with <=FG2.4.0, but resulted in many effects being broken (Doppler etc). To avoid such issues, >= FG2.6.0 produces a warning and rejects loading stereo files.

=== Avoiding sound file duplication ===
We have a large number of sound file duplicates in the FG repositories, which blow up the repository and download size. Generic sound files should be placed in the central /fgdata/Sound folder - and not be copied by individual aircraft. Check if a sound sample is available in the central "Sounds" folder, before copying it into an aircraft. New generic sounds may also be submitted to the central folder (use "git merge request" or mailing list) - which is better than producing loads of duplicates.

== FlightRecorder ==
The default FlightGear flight recorder matches propeller/piston aircraft only. For >= FG2.6.0 the correct flight recorder configuration file matching the aircraft type should be selected. It is also possible to add custom properties.

== Rating System ==
A new rating system was introduced. Aircraft ratings should be encoded in the aircraft -set.xml file from where they are be picked up by launchers like FGRun, web pages etc. See [[Formalizing Aircraft Status]].