FlightGear Newsletter January 2018
- 1 Development news
- 2 New software tools and projects
- 3 In the hangar
- 4 Community news
- 5 Multiplayer events
- 6 Contributing
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.
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. 
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.
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.
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.)
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): 
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.
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  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
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!
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.
Learn more at FG1000 ...
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
In the hangar
Aérospatiale 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
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.
|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.|
|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.|
|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.|
|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.|
|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.|
|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.|
|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.|
|FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 Help:Translate.|
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.
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
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!