FlightGear Newsletter November 2015

Enjoy reading the latest edition!
Please help us write the coming edition!
November 2015

Development news

FlightGear v3.6 canceled

Unfortunately, due to various circumstances and problems, it has been decided that the FlightGear v3.6 release will be skipped.[1] The development focus will now be channeled into the FlightGear v3.8 release. In addition, through debates raised by the delays leading up to this cancellation, it has been decided to pursue the automation of the release cycle through the use of scripts in the FlightGear build server.

If users want to download the 3.6 release candidate (which may be unstable), they can do so here. Or, if they want to risk running an even more unstable version of FlightGear, they can download latest FlightGear nightly build here.

See also What’s the Flightgear news? (FlightGear website)
  1. Torsten Dreyer (Nov 30th, 2015). Re: [Flightgear-devel] Fate of 3.6 and features for 3.8.

AeromatiC++ 3.0 released

Many JSBSim aircraft developers know about Aeromatic, a web-based configuration file generator for JSBSim. In the past month, AeromatiC++ was created using the PHP code from Aeromatic2. AeromatiC++ is a flexible command line utility which, like Aeromatic2, can create JSBSim configuration files based on a minimal set of input variables. However, AeromatiC++ is much more flexible by design, which allows it to create appropriate subdirectories, engines and thruster files, and also systems files.

The fuel consumption of engines is now calculated to a reasonable degree of accuracy based on a minimal number of inputs. The turboprop engine is now transformed from a turbine-simulated turboprop configuration to a true JSBSim turboprop engine with propeller. Support has also been added for the electric engine.

The number of systems has been extended considerably. Every system adds its own lift, drag and/or side forces, and pitch, roll and/or yaw moments if selected. New and updated systems include:

  • Conventional controls (with or without yaw damper)
  • Flaps
  • Landing gear
  • Arrestor hook
  • Spoilers and speedbrakes
  • Thrust reverse
  • Drag chute and rescue chute
  • Catapult system

Version 3.1.0 adds code that estimates CLde, CMa, CMadot, CMq, CMde, CYbeta, Cnbeta, Cnr, Cndr, Clbeta, Clr and Clp based on wing geometry. There is now also support for the calculation of CLq, CLadot, CYp, CYr, CYdr and Cnp based on wing geometry which previous versions did not specify. After a request from Necolatis, the turbine engine tables are now adjusted for bypass ratio.

For this to work properly, you have to provide factual data. Do not try to estimate it yourself. If some data is unknown, leave it blank and AeromatiC++ will make it's own estimation or reverts to the table lookup method.

Early HLA Experiments

Stuart Buchanan has started looking at the High-Level Architecture (HLA) integration for FlightGear, after some very useful discussions with Mathias Froehlich. This is a summary of what he's looking at and how he's thinking of developing it. Comments and advice are welcome.

Currently, there is a partial HLA implementation in SimGear, which has a dependency on OpenRTI. As the name suggests, OpenRTI is an open-source run-time infrastructure This is a link to a Wikipedia article (RTI), and is in fact developed by Mathias himself.

This is all very well, but the HLA has evolved since this code was written, and the code doesn't support some of the modern technologies.

Mathias has been working on a toolkit that provides a lot of the "plumbing" required for a HLA client, in a much nicer package. This toolkit, called SimKit, would allow us to ditch most or all of the SimGear HLA code. Note that, like the current HLA dependency, this is completely optional and only required if one is compiling with the ENABLE_RTI CMake option.

As a first use-case, Stuart expects to start looking at a very basic AI integration, so other aircraft in the federation are displayed within FlightGear (see also Decoupling the AI Traffic System). That doesn't really leverage the power of HLA, but should at least allow developers to get to grips with the problems and architecture before moving onto more ambitious plans, including the "Holy Grail" of separating the viewer from the Flight Dynamics Model.

A lot of the challenge is likely to be in designing the data to be shared across the RTI, which will require a lot more thought than one might naively assume.[1].

Stuart has successfully replaced the HLA implemented in SimGear with SimKit. This has allowed Stuart to replace about 17,000 lines of SimGear/FlightGear code with just 500 in FlightGear alone. He has also successfully joined an OpenRTI HLA federation, and received updates from an external source, which are displayed as an MP aircraft in the property tree.[2] More recently, he has got an external HLA federate to be displayed in FlightGear. The implementation right now is very basic: a KC-135 circling above LOWI at 10 kt and 500 ft. But it's enough to build on.

The work that Stuart is doing on HLA will hopefully allow Nasal to be run in a separate thread from the FDM and display so that Nasal Garbage Collector no longer can impact framerates. It would also allow for writing a weather simulation completely external to FlightGear, which would be quite neat.

The next steps Stuart is planning are as follows:

  • Flesh out the viewer federate implementation, possibly to include mapping of HLA data to properties.
  • Publish the FlightGear aircraft instance position to the RTI so it can be picked up by other viewers.
  • Create a multiplayer proxy as a federate that proxies between the MP network and the RTI. This will run in a separate thread or as a separate executable.
  • Split out the Traffic Manager in a similar way. This is obviously focused on the viewer aspect, but it does not address splitting out the FDM or control elements.[3]
  1. Stuart Buchanan (Nov 6th, 2015). [Flightgear-devel] HLA developments.
  2. Stuart Buchanan (Nov 16th, 2015). Re: [Flightgear-devel] HLA developments.
  3. Stuart Buchanan (Nov 17th, 2015). Re: [Flightgear-devel] HLA developments.

Troubleshooting reset/re-init

Reset/Re-init control panel, implemented using Nasal & Canvas, for regression testing purposes.

FlightGear does not currently support saving/loading flights or reliably switching between aircraft at runtime (this is extensively discussed at FlightGear Sessions). Reset & re-init is an effort to refactor the FlightGear initialization process so that resetting and repositioning is supported, without having to exit or restart FlightGear. Currently, this is exposed via the Canvas-based Aircraft Center, but that is considered broken or fragile at best by most core developers, and is known to be be a source of resource leaks.

The core developers are aiming to find out the dependencies of different subsystems and re-factor them so that more and more subsystems can be made optional (similar to FlightGear Run Levels), enabling them to be dynamically removed and re-added at runtime. This will be particularly important to untangle implicit or hard-coded dependencies among the different subsystems, and will be one of the key tasks to move certain subsystems into dedicated High-Level Architecture (HLA) federates.

One of the long-term goals is to provide a so called "headless" mode so that certain features/subsystems (unrelated to graphics) can be better tested in isolation. An example would be running FlightGear in an automated fashion on the FlightGear Build Server, which could help increasingly automate the release process and related regression testing, which is another long-standing wish.

The other goal is to increasingly modularize FlightGear by using HLA and split off the simulation loops (see also FGViewer), as well as supporting different renderers (such as Rembrandt and ALS), scenery engines (e.g., standard and osgEarth) and weather engines, in a fashion similar to how FlightGear already supports different Flight Dynamics Models (JSBSim and YASim). HLA will make it possible for certain subsystems to be moved to dedicated cores by using separate threads or even processes, meaning that certain subsystems may even be able to be run on a different computer in a distributed setup.

The underlying requirement that these efforts share is the need for a much better re-initialization process, with no hard-coded assumptions about running subsystems or initialization order, because subsystems may be running elsewhere, and may need to be dynamically added/removed at runtime.

For the time being, however, many of these efforts are not yet completely functional, so more feedback and data are needed.

You can help this effort by running the relevant APIs and providing GNU Debugger backtraces and bug reports (or crash reports if you have Windows) of any segmentation faults that occur.

Find out more at Howto:Reset/re-init Troubleshooting.

Help needed for Windows compiler updates

James Turner is trying to extend the Windows 3rd party repository to enable builds with Visual Studio 2013 and 2015. He has assembled some pieces using the equivalent OpenSceneGraph packages, but is having some difficulties with the correct Boost version and OpenSceneGraph version. He also needs to recompile PLIB (which has an ancient Visual Studio project) for the new compiler.

He would love to hear from anyone who has done this in the past.

From James Turner (Nov 24th, 2015). [Flightgear-devel] Windows compiler updates - help needed.

In the hangar

The FlightGear Dragon

There is an interesting new addition to FGAddon and the FlightGear Project: a dragon. Made by Erik Hofman, and inspired by a personal project, it demonstrates the diverse capabilities of FlightGear in terms of aircraft (or flying things). As well as a JSBSim FDM, it also sports ALS flames to simulate the breathing of fire. You can find out more at the forum thread. Currently, it can only be obtained via FGAddon (see FGAddon § Obtaining aircraft). Below is a video of the dragon in flight:

The FlightGear Dragon in flight.

Scenery corner


Project3000 is a project to automatically improve scenery at many airports using position data from the X-Plane Scenery Gateway and shared models from FlightGear.

The project started in October 2015, and is so named because the Scenery Gateway website contains roughly 3,000 scenery packs with 3D objects. Some airports have more than one pack to choose from, so at the moment 2,260 airports can be populated.

Red Bull Air Race

Some people may not be aware that the Red Bull Air Race is using FlightGear for various tasks during planing and preparation of their races. The Zivko Edge 540 is often used to virtually test-fly a track and to create introduction videos for the racing teams.

We have already received some valuable feedback from the Air Race team. For example the EFIS and the g-load LED strip indicator included in the Edge has been modeled after the real thing after being able to visit the team in Gdynia, Poland last summer.

Over the last few years, we have developed a very friendly relationship to the team. This year at FSWeekend, we had one of their members at our booth (see video at 2:44).

For the next season, they are evaluating several new locations, one of which is the Indianapolis Motor Speedway. To make their evaluation as realistic as possible, they need good scenery. Unfortunately, we don't have anything there and they are looking at FSX instead.

Here comes my challenge for our 3d and texture artists: Would some of you like to create a virtual motor speedway with all its buildings, signs, etc. and check them in into our scenemodels database? There are many photos available on the Internet, and the racetracks itself are in OpenStreetMap. The terrain generation tool is already working, but we need objects.

Be assured some of the best pilots of world will see and like your work!

Feel free to respond on the forum topic.

From Torsten (Nov 16th, 2015). Red Bull Air Race: Request for help with 3d models.

Community news

New scenemodels and TerraSync hosting needed

By the end of this year (2015), the FlightGear Project's hosting for the scenemodels database and website and the TerraSync repository will no longer be available. As a result, the FlightGear Project is searching for a replacement, even just a temporary one. The technical requirements are roughly these:

  • A PostgreSQL database (with the PostGIS extension) of approximately 40 GB, with capacity to expand (this is for the scenemodels database).
  • An Apache webserver, PHP, access to the database and the usual toolkit for hosting the scenemodels website
  • An SVN server with 140+ GB for the TerraSync repository.
  • Enough bandwith to serve the data.
  • One or more reverse proxies serving TerraSync requests (not much storage required, just bandwidth).

If you can provide the above, are able to provide help, or have any serious ideas for a replacement, please get in touch via the forum topic or the mailing list topic

From Torsten (Nov 9th, 2015). Scenemodels and terrasync are going down.

New contest: FlightGear photography and art contest

For those of you out there who love post-editing photos and screenshots, this is for you! This new contest is focused on creating the most artistic and compelling pictures made with FlightGear. Post-editing is allowed and encouraged. Find out more at the forum topic


Online Flight Planner now supports FlightGear

OnlineFlightPlanner.org can now output routes to a format compatible with Flightgear's Route Manager. The planner produces a PDF containing the flight plan (RouteFinder) with estimated fuel quantity calculation (Fuelplanner.com). The flight plan can be loaded to the Route Manager for immediate use in FlightGear.


Translators required

En.gif The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, start 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 doch mit 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.

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.


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

The winner of Screenshot of the Month November 2015 is This is OH-CTL over LOWI on an autumn setting on late afternoon by geed:

OH-CTL over LOWI.jpg