FlightGear Newsletter April 2014

Welcome to the FlightGear Newsletter! Please help us write the next edition! Enjoy reading the latest edition!

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. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release. At the end of each month, it's generally a good idea to get in touch with other contributors to ask them to add news about their contributions to the newsletter.

Development news

Text-to-Speech: ATIS via FLITE

Torsten and James started adding FLITE support to FlightGear. Thanks to James' finding of flite+hts_engine, those running the development version of FlightGear are now again able to listen to spoken atis and probably any other kind of spoken messages soon. This is a complete text-to-speech system (currently only English language) that generates wav files from plain text on the fly with surprisingly good quality speech and small memory footprint.

Torsten pushed some code that uses the flite+hts_engine to synthesize the generated atis text for comm radios into a SGSoundSample and feed this into our sound manager. To make use of this feature you have to rebuild FlightGear from source and call cmake with -DENABLE_FLITE=On. When ready, tune your comm radio to the ATIS frequency of your airport. After a few seconds, you should hear a lady talking about FlightGear weather.

The code contains some ugly hacks and not everything is working perfectly yet. But please give it a try and test on performance, sound quality and cross platform compatibility.

Proof-of-Concept: A TerraGear Web Service (by F-JJTH)

As part of prototyping a TerraGear scenery build server, F-JJTH has started working on a proof-of-concept for a web-based TerraGear GUI/build service. This can use the precompiled-TerraGear packages created and provided by saiarcot895. We are currently looking for people interested in picking up this prototype to continue developing it over time. All the difficult bits are now in place (namely the TerraGear setup), as well as a compelling web-based interface. People interested in helping with this, should ideally have some web programming experience, for TerraGear specifics you can probably just get in touch with psadro_gm and papillon81 (or refer to the docs for starters). Also, we're hoping to also create Linux packages for the web interface, so that installation/updates can be just as easily handled using the deb/apt/ppa package manager.

Primarily, we are now looking for hosting, not just for the TerraGear setup itself (which should be fairly powerful), but also for those deb/apt packages. If you'd like to help with this, please get in touch via the forum.

• 

  Schematic of a possible setup for TG GUI or a web interface to access TerraGear services provided by a build server

• 

  TerraGear BuildServer Experiments

• 

  TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages

• 

  Web-based TerraGear GUI prototype developed by F-JJTH in 03/2014

Continue reading at TerraGear scenery build server...

Missions & Adventures via Tutorials

Marius_A is working on extending Stuart's Tutorials system to also support missions and adventures. That way, missions and adventures can be easily created and maintained by editing XML files, so people don't necessarily need to be coders (familiar with Nasal scripting) to add/extend missons.

Learn more at FlightGear Missions and Adventures...

DFaber's Walker used for adding NPC support to Stuart's tutorial system

YASim Bug Fixes

As of April 4th, several bug fixes by Colin Howell have been merged into the "next" branch of FlightGear's source. As per issues #1400, #1423, and #1427, these are only small fixes in portions of code, but they still may have noticeable affects on YASim aircraft, including making the solver fail with some aircraft and making other aircraft perform better. Currently these fixes are loaded unconditionally, so there's no opt-in or opt-out system in place, meaning that we need you to help test as many YASim aircraft as possible. (Please note that these patches are only available with a latest binary, i.e. a nightly from Jenkins or a compilation from source, and a corresponding FGData clone.) Detlef posts, "I have tested the slat patch and the twist patch and found very little problems, in fact most cases I've seen saw an improvement. Of the 15 Aircraft I've tested the twist patch on, only two wouldn't start up at all" [1]. Having a large number of non-working aircraft in the next release would be undesirable, and would suggest that we need an opt-in system for such fixes, but if most aircraft work well it will be simpler to let the patches load unconditionally.

Please report aircraft that fail to work with latest FlightGear (but that still work in 3.0, i.e. without the fixes) on the devel list or on the forums.

Links to ongoing discussion at the development list: [2] [3] [4] [5] [6] [7] [8]

YASim versioning

In order to cope with the YASim changes discussed above, a versioning scheme has been introduced to YASim configuration files. The <airplane> element of the YASim config file now understands the "version" attribute that can be currently one of these values:

• YASIM_VERSION_ORIGINAL

  The original version of YASim as implemented up to FlightGear 3.0.0 (this is the default)

• YASIM_VERSION_32

  The version of YASim currently implemented in FlightGear 3.1 (current git HEAD)

• YASIM_VERSION_CURRENT

  The current and latest version of YASim (which is currently the same as YASIM_VERSION_32)

For example:

<airplane mass="1344" version="YASIM_VERSION_32">

A missing "version" attribute will cause YASim to use the original (buggy) implementation without the latest patches. This should restore the original behaviour to all YASim aircraft. Aircraft that were adapted to the new version of YASim (with the latest patches from Colin Douglas Howell) should set version=" YASIM_VERSION_32" to re-enable those changes.

The idea is to add a new YASIM_VERSION_xx with every release cycle where xx is the next to-be-released version number (32 for 3.2 for the current cycle and 34 for the next cycle etc).

How to troubleshoot FlightGear crashes

The recent two release cycles have made one thing pretty obvious: more and more end-users are faced with obscure crashes, so called "segfaults" - unfortunately, developers cannot easily reproduce those in most cases. Thus, we need our contributors to provide better diagnostics. However, the process isn't exactly straightforward for non-developers, but at least Linux-based users can typically provide all the required information even without having to be programmers themselves.

A segfault is another word for "application crash", it's a so called "segmentation fault", where the FlightGear program is doing things that it wasn't designed to do, such as accessing invalid memory for example, so that the operating system will terminate the process because its behavior is no longer valid/correct.

These segfaults will typically happen due to coding errors, either in FlightGear or one of its dependencies (libraries like SimGear, plib, OpenSceneGraph or OpenAL), and at times due to a combination of issues in several dependencies.

In order to see what was going on when the crash occurred, you'll need to build a binary with debugging symbols enabled/included, usually this includes FlightGear and SimGear - and possibly even OSG (OpenSceneGraph, normally only if your crash happens inside rendering related code).

A so called backtrace is basically pretty much like a flight data recorder tape/log that is used to conduct a post-crash analysis.

A binary with debugging symbols included will contain additional information that helps developers track down what was causing a certain crash, such as for example the file name, function, line number, variable that was accessed before the crash happened. This is analogous to how a FDR/CVR on an airplane records certain parameters like position, orientation, altitude, velocities, configuration, cockpit conversations etc. This can also be used by developers to see who is responsible for a certain segfault/bug, i.e. which commit introduced the bug.

Debugging FlightGear crashes is significantly simplified by having access to such runtime data, because we can basically go back in time and see what the FlightGear program was doing shortly before the crash.

Learn more at Debugging Segfaults & Obtaining Backtraces...

Orbital Rendering:Earthview

Earthview is an orbital rendering engine for FlightGear designed to get credible visuals when using spacecraft such as Vostok-1. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. Since there is only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

Textures are taken from the NASA Visible Earth project - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed via GIT, a mode to make the GB-sized hires textures has yet to be determined.

Combined with the atmospheric light scattering (ALS) shader to render the atmosphere, visuals are generally rather compelling.

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

A long standing problem in FlightGear's atmosphere definition has now been addressed and JSBSim spacecraft should now be able to reach any orbital altitude within their capabilities (previously flight was restricted to be below 150 km altitude).

FlightGear/Oculus Rift Experiments

The number of users that will currently be able to use this is small, and Gouranga's implementation not perfect. Actually, the stereoscopy is perfect but there are a few bugs which are down to unfamiliarity with FlightGear's render pipeline (currently the distortion shader replaces the skybox). These are bugs which could quickly be remedied by a core developer. Currently it is hardcoded towards the 1st dev kit but this could be changed later on for the release of the new dev kit and finally the commercial.

Learn more at this forum topic

Canvas System

Tom has removed a lot of unneeded OpenGL state changes in the development version of FlightGear. Depending on the GPU/driver this can lead to quite a noticeable performance improvement. For example, he was able to get from ~120ms down to ~45ms [9].

Creating your own keybindings

A common request is how to change keys to do different commands. FlightGear makes this as easy as editing an XML file, and possibly adding a parameter to point FG to the new XML file.

In general, the list of keyboard commands is stored in the property tree and is loaded at startup or when the menu option "Debug -> Reload input" is selected. The main list of commands is available in $FG_ROOT/keyboard.xml, but each aircraft can add/change its own bindings through its -set.xml file, and additional config files can do the same.

Continue reading Howto:Reassign keyboard keys...

Getting involved as a programmer

Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.

If you are interested in contributing as a core developer, please see Howto:Start core development.

If you interested in other developing, i.e. not C++ but Nasal scripting and/or XML, there are some articles listed at Category:Popular Community Requests that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from you -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at Nasal, so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

Nasal for newbies

Under the Hood of: Nasal OOP (by Philosopher & galvedro)

Nasal does not have the concept of "classes", understanding by a class an object definition that cannot exist as an instance on its own. What we always have in Nasal is hashes that perhaps reference other hashes via the parents vector.

The parents vector is just a symbol lookup trick. The only thing it does is to add other hashes as targets where Nasal can search for symbols that are not defined in the current hash. This servers for implementing object inheritance in a traditional way as long as:

1. The symbols that you expect to be gathering from the parented hashes are functions. This is because when you are executing a function in a parent hash, the me symbol will allow you you to resolve the context back to the instance hash down the hierarchy.
2. Non function members that are expected to be kept per instance, are defined in the instance hash. Otherwise those members might end up being shared across derived hashes due to the parents lookup mechanism.
3. Members that are expected to be shared across different instances are defined in the template hash and not in the instances themselves. Which means that you have to be careful on how you write values to them or you will end up creating a new member in the instance hash that will shadow the shared member. (Mmm, this one is a dangerous pitfall, but I remember seeing this explained in the wiki, and is not that often that you need this...).

The me reference is a syntactic trick, and it can be dangerous to use depending on the usage pattern, so some good practices are in order, in particular

• When writing a constructor in a template object, do not use me in the parents vector, because me will resolve to a hash reference only when the new() method is called, and which hash will it be depends on how the method is called.
• When calling a "super" class method from an overriding method, use the Nasal call() library function, specifying the instance hash as the me parameter. If you use the parents vector directly, me will likely end up referring to a template hash instead and you will loose the instance context.

Basically you have an expression on the left side of a dot, and then a lvalue and parenthesis on the right side -- no exceptions! The expression is evaluated once, with the value being DUP'ed (duplicated/copied) and used both for the member get (i.e. what is the function contained in the hash) and as a special argument to the function (now a method) call. That "me" is then set as a symbol like an argument, originating from the left-hand expression, and is otherwise unset.

In other cases, using the call() builtin, it is possible to specify the me reference manually, but what "me" is, is otherwise a consequence of how it is called. If the syntax differs, there is no me local variable. (One common example is passing a MEMBER of an object to a function as a parameter or saving it to a variable - i.e. then it doesn't matter if it is a function or not.) (I use MEMBER here to distinguish from METHODS, where a METHOD uses "me" and a MEMBER doesn't.)

The thing with a func {} expression is that it delays evaluation, so it can keep the proper syntax for the method call and therefore pass the correct me reference, which is preserved in its closure.

Parents inheritance is really simple: to find a member you search for it in the current hash or try finding it in each parent (indexes 0..n), throwing an error if there is too much recursion. Basically, inheritance is implemented such that there's a mutable parents vector that maintains a list of hashes that are used for recursive symbol lookups, me will be defined per instance and point to the outer hash. Which is why shadowing can occur.

me is also mutable, i.e. if it isn't defined, it can be explicitly defined, or passed via call() - a mehod which we tend to use in MapStructure whenever we want to ensure that the proper instance is passed, i.e. no variable shadowing taking place.

• FUNC() -> no me
• OBJ.METHOD() -> me = OBJ
• (OBJ.MEMBER_FUNC)() -> no me
• (EXPR).METHOD() -> me = (EXPR)

Continue reading at Object oriented programming in Nasal...

New software tools and projects

Free SVG VFR & IFR Symbol Sets

Tests with IFR Icons Set for FGCanvas

This is a free set created by Michat that will be available soon in order to support whatever any project related with FlightGear in need to use navigation symbols. I.e FGMap, manuals , route explanation charts, virtual schools, virtual airliners, Android app, ATC or whatever project related with FG that need it.

The project consists of a very high detailed VFR Symbols Advanced Set, and a IFR Basic Set that you can use freely for your FlightGear project.

Here are shown some examples of Obstruction Symbols based on the AOPA's VFR Charts. As you can see It was 'another night space invaders' design session.

Also IFR Symbols will be available soon to support your project.

osm2city.py update

Following Mathias' suggestion at FS Weekend 2013, Radi changed the code such that it merges all buildings per (osm2city) tile into one object, reducing the number of drawables from O(10k) to O(10) and thereby improving performance. On an i7/Intel HD 5000/2560x1440, a scene looking down at LOWI from FL300 with 60k buildings would render previously at 6 fps. That has more than doubled to 14 fps. Plain Scenery 2.0 (no buildings) gives 19 fps. For the moment, LOD and textures are broken but will be fixed soon.

The screenshot below shows an aerial view of LOWI with 60k OSM buildings.

In the hangar

New aircraft

Beech V35 Bonanza

Flyingfisch is working on the Beech 35 Bonanza. ![10] ![11]

Embraer ERJ 145

Emmanuel Baranger, (helijah)

The Embraer ERJ 145 family is a series of regional jets produced by Embraer, a Brazilian aerospace company. Family members include the ERJ 135 (37 passengers), ERJ 140 (44 passengers), and ERJ 145 (50 passengers), as well as the Legacy business jet and the R-99 family of military aircraft. The ERJ 145 is the largest of the group. Each jet in the series is powered by two turbofan engines. The family's primary competition comes from the Bombardier CRJ regional jets.(Source wikipedia)

ERJ 145 : SplashScreen

ERJ 145 in flight

Focke Wulf Ta 154 "Moskito"

Emmanuel Baranger, (helijah)

The Focke-Wulf Ta 154 Moskito was a fast twin-engined German night fighter aircraft designed by Kurt Tank and produced by Focke-Wulf during late World War II. Only a few were produced and proved to have less impressive performance than the prototypes.

Ta 154 : SplashScreen

Ta 154 in flight

Updated aircraft

PA24-250

Interior of the updated pa24-250

Livery support now available

flyingfisch has added livery support and more to an updated version of the PA24 available at https://github.com/flyingfisch/pa24-250.

Liveries

Screenshot of EC-137D FAC livery - FlightGear Aviation Commission

FAC (FlightGear Aviation Commission) Download here: [12] under Creative Commons Attribution-Share Alike 3.0 Unported license from original FlightGear logos.

Scenery corner

The Making of a new World Scenery

A frequently asked question about scenery is: "Why isn't the terrain updated more often?". Most of us are probably unaware about what is required to build a new World Scenery and what is required to ship a complete set of data for rendering the world in FlightGear. As there is actually a new build in progress, we are able to present some naked numbers to give a rough impression about the resources involved.

First, there is the raw data. Roughly half a dozen databases containing more than 100GB of elevation, coast lines, water ways, roads, land cover, navigation data and all the things that make up the details of our planets surface.

Memory consumption during scenery creation

All these information have to be converted into files understandable by FlightGear. The earth's surface in FlightGear is cut into tiles, each tile containing a 3d model for that area. While generating a single tile is a not too complicated task, generating the entire world is. Roads, coastlines, run- and taxiways do sometimes cross tile boundaries so the 3d surface has to be sliced at the tile boundary. The vertices on both edges have to be at the exact same position. To guarantee, you can't fall into the abyss while taxiing across an unclosed tile boundary, all tiles have to be created in a single run with the current tool chain.

The machine performing that task has to crunch all the 100GB of raw data, keep the results more or less in memory and write the results to disk. This is an extremely time and resource hungry job. The current vectorization job has been started on Feb. 28th and is still running (Apr. 6th). Probably most impressive is the memory consumption which has grown to nearly 130GB. This is RAM, not hard disk. As the machine is unfortunately only equipped with 100GB of RAM has started to use nearly 30GB of swap space. All this only works because of just a few people working hard and usually undiscovered in the background.

Wiki updates

Translators required

	The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at Help:Translate.
	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.
	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 FlightGear wiki 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.

Community news

FlightGear on YouTube

Retrospective flight in B707 in Rembrandt

Multiplayer

The Northern-Italy ATC Controlled Area (NIATCA)

NIATCA was born between December 2013 and January 2014 to offer Air Traffic Control in Northern Italy and in the neighboring area; the project originally covered only LIPA, LIPX, LSZS and LIMC.

Today, its members' efforts allow you to enjoy professional services at the following airports:

• Milano Linate (LIML)
• Milano Malpensa (LIMC)
• Samedan (LSZS)
• Bergamo Orio al Serio (LIME)
• Verona Villafranca (LIPX)
• Bologna (LIPE)
• Aviano Air Base (LIPA)
• Trieste-Ronchi dei Legionari (LIPQ)
• Venezia Tessera (LIPZ)
• Innsbruck-Kranebitten (LOWI)

ATC sessions take place throughout the week and are planned on Lenny's website. Airport briefings and links to charts are available on the forum.

For more informations, you can visit the project's Google+ page or its YouTube channel. The project is also searching for new members to extend coverage; current open positions are Torino Caselle (LIMF), Genova Sestri (LIMJ), Treviso "San Angelo" (LIPH),Rimini-Miramare (LIPR), Bolzano-Dolomiti (LIPB), Base aerea di Rivolto (LIPI), Base aerea militare di Istrana (LIPS). If you want to contribute, just apply to become a member.

Candidates are required to:

• know ATC phraseology;
• know the English language (knowledge of Italian is a plus);
• be able to read charts and to let pilots follow real SIDs/STARs;
• be able to man their position(s) at least one/two hours a week.

And finally ...

Contributing

File:Wiki I Want You For Wiki.jpg

Many people think that contributing to the FlightGear project requires writing C++ code or doing 3D modeling and that it takes lots of time, and therefore feel that they cannot contribute directly. Not so. There's a whole variety of ways to make a valuable and satisfying contribution to FlightGear without being a developer.

The Volunteer page is intended to provide a starting point for those wanting to contribute, but who don't know how. Of course, these are just suggestions. So if you have already a specific idea in mind, please do get in touch with the community to ask for feedback, using the mailing lists, forum or the IRC channel (chat).

Remember that work in non-development areas will be appreciated as much as developer contributions (or more!), because generally more visible to the end user.

If you'd like to learn more about getting your own ideas and features into FlightGear, check out Implementing new features for FlightGear.

If you are contributing to the core simulator, or an aircraft in the master repository, you should be part of the FlightGear-devel mailing list, which is the primary point of contact for all discussions regarding the development of the simulator. You may want to check out also Howto: Understand the FlightGear development process and Howto: Starting core development.

Call for volunteers

• The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at World Scenery 3.0 roadmap.