FlightGear Newsletter January 2018: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (Protected "FlightGear Newsletter January 2018": Publishing newsletter ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
 
(11 intermediate revisions by 6 users not shown)
Line 1: Line 1:
<!--
NOTES TO EDITORS
* Headings
  * DO NOT DELETE HEADINGS prior to final cleanup
  * Current headings and their order is merely a suggestion based on what have been used earlier
* Discussion, issues and suggestions
  * Regarding this newsletter issue, please use the discussion page
  * Regarding the newsletter in general, primarily use the FlightGear Newsletter discussion page (Talk:FlightGear Newsletter)
  * Regarding this template, please use FIXME
* Final cleanup before write protecting
  * Remove unused headings
  * Search for INSERT and insert current month etc.
  * Finally remove this comment
-->
{{Newsletter-header|January 2018}}
{{Newsletter-header|January 2018}}
{{TOC_right|limit=2}}
{{TOC_right|limit=2}}
Line 40: Line 9:


=== Docker-based scenery toolchain ===
=== Docker-based scenery toolchain ===
 
[[File:Docker-sourceforge.png|thumb|screenshot showing sourceforge header with new docker entry]]
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.  
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.  


Line 62: Line 31:
   }}</ref>
   }}</ref>


The Docker image is now capable of performing almost all tasks required for building scenery:
* Fetch SRTM elevation data
* Run hgtchop
* Run terrafit
* Fetch airports and stay in sync with the x-plane gateway
* Run ogr-decode against local shapefiles or perform direct queries to a postgres database
Torsten  has sucessfully created the elevation data from SRTM1/3 for the entire globe and created a few random airports with this image. Currently, he is playing with integrating ogr-decode. The docker image gets automatically built, including building latest simgear & terragear from GIT. This build process runs directly at the docker hub: https://hub.docker.com/r/flightgear/terragear/builds/ (Yes: docker hub compiles simgear and terragear for us, amazing, isn't it?) Torsten hopes to be able to compile the a first chunk of scenery within the next couple of weeks.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36209739/
  |title  =  <nowiki> Re: [Flightgear-devel] Making containers fly: FlightGear scenery
goes docker </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Jan 30th, 2018
  |added  =  Jan 30th, 2018
  |script_version = 0.36
  }}</ref>
That means, if someone wants to generate scenery in the future they will simply be able to download the latest docker image, start it up on Docker CE and run the commands. No compilation required. Which is quite amazing, and could massively reduce the effort required to work on scenery.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36209758/
  |title  =  <nowiki> Re: [Flightgear-devel] Making containers fly: FlightGear scenery
goes docker </nowiki>
  |author =  <nowiki> Stuart Buchanan </nowiki>
  |date  =  Jan 30th, 2018
  |added  =  Jan 30th, 2018
  |script_version = 0.36
  }}</ref>


In other words, Build once, run anywhere - thats what docker is made for. (caveat: anywhere means "any Linux flavor or MacOS on x86-64 architecture and eventually Windows64, too.)<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/36209773/
  |title  =  <nowiki> Re: [Flightgear-devel] Making containers fly: FlightGear scenery
goes docker </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Jan 30th, 2018
  |added  =  Jan 30th, 2018
  |script_version = 0.36
  }}</ref>


=== Oscilloscope Addon ===
=== 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>]]
[[File:Rleibner-canvas-vsd-12-2017.png|thumb|left|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>]]
rleibner is developing a graph class that works using local (customized) coordinates and calls the plot2D helpers (see below).
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>
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>]]


This '''oscilloscope''' was created as an example of the use of 3 helpers included in the addon:
*  '''skinnable.nas''' to create Canvas GUI dialogs including multiple clickable layers.
*  '''graph.nas''' to create various types of Canvas instruments.
*  '''plot2D.nas''' the very basic Canvas helpers.
But apart from that, the '''oscilloscope''' itself may be an useful tool for developers and coders. Although I do not know any aircraft that has this instrument in its panel, the on-board engineer will eventually appreciate having it on hand at some point.


See [[Oscilloscope addon]]
{{-}}
=== Aircraft Dialogs ===
=== Aircraft Dialogs ===
[[File:Extra500-Failuredialog-deice.png|right|thumb|Extra 500 - failure dialog - de-ice]]
[[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.]]
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).
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!
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.
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 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.
Line 96: Line 103:
If anyone wants to follow the development or use the code, it's here:
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
https://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tree/Nasal/canvas/canvas_dialogs.nas


=== FG1000 Updates ===
=== FG1000 Updates ===
Line 129: Line 135:


Learn more at [[FG1000]] ...
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 ==
== New software tools and projects ==
Sidi has updated the iOS version of FGYoke and make it available on AppStore recently.
Sidi has updated the iOS version of FGYoke and make it available on AppStore recently.
For details, check  [[Yoke_for_FlightGear]]
For details, check  [[Yoke for FlightGear]]
[[File:Screenshot of FGYoke in AppStore.png|thumbnail|center|Screenshot of FGYoke in AppStore]]
[[File:Screenshot of FGYoke in AppStore.png|thumbnail|center|Screenshot of FGYoke in AppStore]]


Line 143: Line 162:


<!-- === New aircraft === -->
<!-- === New aircraft === -->
=== Aérospatiale SA 315B Lama ===
[[File:Lama Sunset.png|thumb|Screenshot of Lama 315B at sunset]]
[[File:Lama Overhead.png|thumb|Overhead panel for SA 315B Lama]]
The FGUK Development team are very pleased to announce the '''Aérospatiale SA 315B Lama''' for FlightGear. An incredibly accurate model with a selection of liveries, equipment loadouts and a totally custom FDM for flying by the book
More photos on the [https://www.facebook.com/FlightGearUK/ FGUK Facebook Page]
[http://www.http://fguk.eu/index.php/hangar/download/13-rotary-wing/558-aerospatiale-sa-315b-lama Download here]


<!-- === Updated aircraft === -->
<!-- === Updated aircraft === -->
Line 150: Line 178:
<!-- === Aircraft reviews === -->
<!-- === Aircraft reviews === -->


== AI ==
<!-- == AI == -->


== Scenery corner ==
<!-- == Scenery corner == -->
<!-- Scenery development news -->
<!-- Scenery development news -->


Line 224: Line 252:


==== Screenshot of the Month ====
==== Screenshot of the Month ====
<!--FlightGear's Screenshot of the Month INSERT MONTH HERE is INSERT TITLE HERE by {{usr|INSERT USERNAME HERE (IF ON THE WIKI)}}
FlightGear's Screenshot of the Month January 2017 is '''Flying high with the Lama''' by StuartC
ADD IMAGE
[[File:SOTM-Jan18.jpg|900px|center|Flying high with the Lama - StuartC]]


If you want to participate in the screenshot contest of INSERT MONTH HERE, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=FIXME this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=31149#p300344 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of INSERT MONTH HERE.-->
If you want to participate in the screenshot contest of February 2018, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=33703 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=33703#p327123 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of February 2018.


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


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


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

Latest revision as of 14:18, 3 February 2018

Magagazine.png
Enjoy reading the latest edition!
Please help us write the coming edition!
January 2018

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

screenshot showing sourceforge header with new docker entry

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:

Anybody interested in driving this forward, willing to learn or contribute is more than welcome to do so. [1]

The Docker image is now capable of performing almost all tasks required for building scenery:

  • Fetch SRTM elevation data
  • Run hgtchop
  • Run terrafit
  • Fetch airports and stay in sync with the x-plane gateway
  • Run ogr-decode against local shapefiles or perform direct queries to a postgres database

Torsten has sucessfully created the elevation data from SRTM1/3 for the entire globe and created a few random airports with this image. Currently, he is playing with integrating ogr-decode. The docker image gets automatically built, including building latest simgear & terragear from GIT. This build process runs directly at the docker hub: https://hub.docker.com/r/flightgear/terragear/builds/ (Yes: docker hub compiles simgear and terragear for us, amazing, isn't it?) Torsten hopes to be able to compile the a first chunk of scenery within the next couple of weeks.[2]

That means, if someone wants to generate scenery in the future they will simply be able to download the latest docker image, start it up on Docker CE and run the commands. No compilation required. Which is quite amazing, and could massively reduce the effort required to work on scenery.[3]

In other words, Build once, run anywhere - thats what docker is made for. (caveat: anywhere means "any Linux flavor or MacOS on x86-64 architecture and eventually Windows64, too.)[4]

Oscilloscope Addon

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): [5]
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.[6]

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): [7]

This oscilloscope was created as an example of the use of 3 helpers included in the addon:

  • skinnable.nas to create Canvas GUI dialogs including multiple clickable layers.
  • graph.nas to create various types of Canvas instruments.
  • plot2D.nas the very basic Canvas helpers.

But apart from that, the oscilloscope itself may be an useful tool for developers and coders. Although I do not know any aircraft that has this instrument in its panel, the on-board engineer will eventually appreciate having it on hand at some point.

See Oscilloscope addon

Aircraft Dialogs

Extra 500 - failure dialog - de-ice
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.

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-500 team is - look at the failure dialog of that plane where you can click the components you want to fail and you see what he means!

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.

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 [8] 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

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:

  1. 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.
  2. 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![9]

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.

[10]


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

Screenshot of FGYoke in AppStore


In the hangar

Aérospatiale SA 315B Lama

Screenshot of Lama 315B at sunset
Overhead panel for SA 315B Lama

The FGUK Development team are very pleased to announce the Aérospatiale SA 315B Lama for FlightGear. An incredibly accurate model with a selection of liveries, equipment loadouts and a totally custom FDM for flying by the book

More photos on the FGUK Facebook Page

Download here






Community news

FlightGear on Facebook

Since early December 2010, FlightGear has an 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 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

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.
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 Help:Traduire.
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 Help:Übersetzen an.
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 Help:Vertalen.
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 Help:Traducir.
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 Help:Traduir.
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 Help:Traduzir.
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

FlightGear's Screenshot of the Month January 2017 is Flying high with the Lama by StuartC

Flying high with the Lama - StuartC

If you want to participate in the screenshot contest of February 2018, you can submit your candidate to this forum topic. Be sure to see the first post for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of February 2018.

Thanks for reading FlightGear Newsletter January 2018!

References