FlightGear Newsletter April 2014

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

Development news

Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: Next Changelog.

Splitting fgdata

This article or section requires updating due to being mostly based on a forum/mailing list conversation, its style is usually not suitable for the wiki/newsletter. For example, due to using first person speech or lacking proper cquotes. Please help improve the article by updating it. There may be additional information on the talk page..

http://sourceforge.net/p/flightgear/mailman/message/32238780/

YaSim versioning

This article or section requires updating due to being mostly based on a forum/mailing list conversation, its style is usually not suitable for the wiki/newsletter. For example, due to using first person speech or lacking proper cquotes. Please help improve the article by updating it. There may be additional information on the talk page..

Hi all,

as promised, I have just added a versioning scheme 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)

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 behavior 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).

I hope this is somewhat useful and works as described.
Please test some yasim aircraft and provide feedback.

Greetings,
Torsten

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

Error creating thumbnail: File missing

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

Learn more at FlightGear Missions and Adventures...

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 improvment. 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 FG (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]

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

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

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

Orbital Rendering:Earthview

This article or section requires updating due to being mostly based on a forum/mailing list conversation, its style is usually not suitable for the wiki/newsletter. For example, due to using first person speech or lacking proper cquotes. Please help improve the article by updating it. There may be additional information on the talk page..

I have just pushed a first version of the Earthview orbital rendering engine. The textures for the planet are based on the NASA Visible Earth collection

http://visibleearth.nasa.gov

As far as I understand the terms of use which allow re-use, re-distribution and commercial use, this should be fine with GPL.
 
To see the blue planet from high up, start FG using the ufo at a high altitude (around 10 million ft is quite good with the texture resolution provided), open the (currently minimalistic) GUI from the View menu, push start, wait for the textures to load and admire the view.

Space is grey up there because this is outside of the skydome, and the overall background color is defined fog-grey. As far as I understand, this is legacy code coming from a time when FG unloaded the skydome in poor visibility to get a few percent more performance out. We don't actually have to do this these days and if you want space black, there is a way. To quote Lauri who figured this out:

 If you want to try to change the clear color to black, you must edit
flightgear/src/Main/renderer.cxx around line  700. There are two
instances of following:
camera->setClearColor(toOsg(clearColor));
which should be changed to
camera->setClearColor(osg::Vec4(0.0, 0.0, 0.0, 0.0));

Without this, only a rim around Earth is rendered in proper colors. 

Earthview responds to the weather visibility setting and typically 80-140 km visibility work best (won't affect any scenery loading because we're too far from the planet). Also, rendering in ALS manually tweaking Rayleigh and Mie constants gives a nice atmosphere effect.

NASA provides textures in /much/ higher resolution - in my highest resolution texture set I have the planet covered in 32768x16384 and the cloud layer in half of that. For such large textures, loading time is an issue (Earthview isn't excatly *cough* elegant) and pre-mipmapped compressed DDS is pretty much the only sane option - then that's 8 texture chunks a 176 MB each. It'd be nice to make higher resolution versions available for download, but I realize that's quite a bandwidth hog - if there's sufficient interest and someone knows a server... the textures are there.

Provided you have the texture memory, performance should actually be pretty high - there's just two textured spheres in the scene, and even on my old computer I get a solid 60 fps.

Enjoy!

* Thorsten

FlightGear/Oculus Rift Experiments

Learn more at http://forum.flightgear.org/viewtopic.php?f=6&t=22640&p=205438

Project Rembrandt

A number of Mac users have been reporting issues related to running Project Rembrandt (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: Project Rembrandt#Mac Issues.

Canvas System

Tom has updated FlightGear 3.1 to remove a lot of unneeded OpenGL state changes. 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 [10], 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.

Release ChangeLog

This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

Interview with a contributor (NAME)

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.

• How long have you been involved in FlightGear?
• What are your major interests in FlightGear?
• What project are you working on right now?
• What do you plan on doing in the future?
• Are you happy with the way the FlightGear project is going?
• What do you enjoy most about developing for FlightGear?
• Are there any "hidden features" you have worked on in FlightGear that new users may miss?
• What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: Interview questions.

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

New software tools and projects

Free SVG VFR & IFR Symbol Sets

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.

Tests with IFR Icons Set for FGCanvas

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

Aerial view of LOWI, with 60k OSM buildings

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.

In the hangar

New aircraft

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

This article or section requires updating due to being mostly based on a forum/mailing list conversation, its style is usually not suitable for the wiki/newsletter. For example, due to using first person speech or lacking proper cquotes. Please help improve the article by updating it. There may be additional information on the talk page..

Updated: http://sourceforge.net/p/flightgear/mailman/message/32241203/

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: [11] under Creative Commons Attribution-Share Alike 3.0 Unported license from original FG Logos [12]

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 toolchain. 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 extremly 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 Harddisk. 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 via Rembrant

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)

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), Innsbruck-Kranebitten (LOWI), 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.

YASim looking for a new maintainer

There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions. Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :) So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. Suggestions for that means in practice, are most welcome! Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working. — James Turner

I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my latencies here are measured in weeks. Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former. — Andy Ross

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.
• The Target4Today team is looking for volunteers to help improving FlightGear's combat support