FlightGear Newsletter October 2016
| This newsletter is a draft.
Please feel free to add content that you think will be of interest to the FlightGear community.
Next default airport
Git multimail script updated
For all Git repositories on SourceForge, Edward d'Auvergne has updated the git-multimail repository hook script to 1.5-dev (the current master branch) from 1.2-dev, with a few customisations/simplifications for our commitlogs ML. If you see any error messages when committing, please report these. A failure of the git-multimail Python script will only result in a failure of the sending of an email to the ML, as this is a post-receive hook - the commit will have been successfully pushed/etc.
Local apt.dat versions support
| Work in progress|
This article or section will be worked on in the upcoming hours or days.
See for the latest developments.
Thanks to work by Florent Rougon, multiple apt.dat files can now be loaded. apt.dat now supports local versions:
Local NavData directory support was added very recently, it wasn't included in 2016.3.1. But even when you do have a more recent version, you still need to use TerraGear to actually generate the visible terrain. NavData is only used for maps, startup locations etc., while the physical layout including runways and taxiways has to be generated in advance with TerraGear.
the NavData/apt/*.dat[.gz] files will allow you to see airports on the map, but to see actual 3D terrain different from what is already in TerraSync, running TerraGear and using its output(*) will be necessary.
It is now possible to have one or more local apt.dat files each containing data for one or more airfields. The airfields in the local apt.dat files take precedence over the contents of the apt.dat.g file that is distributed as part of fgdata. - in much the same way as local custom scenery takes preference over terragear scenery. If you are using WED, the apt.dat output by that program is suitable. To use it add a folder NavData/apt in your fg-scenery and place your private files in that folder.  Of course, your apt.dat changes should continue to be submitted to the Xplane gateway so that they will eventually be included in the main distribution.
No need for any command-line option. As I wrote in <https://sourceforge.net/p/flightgear/mailman/message/35424973/>;, you have to put your apt.dat files (any name ending with .dat or .dat.g is OK) in a structure like the following:
Scenery path ├── NavData │ ├── apt | | ├── vrmg.dat | | ├── vrmh.dat | | ├── vrmk.dat ├── vrmm.dat ├── vrmo.dat.gz └── vrmt.dat
where "Scenery path" can be any of you scenery paths (e.g., any component of --fg-scenery/$FG_SCENERY; the path given to --terrasync-dir is also one). The files read are all NavData/apt/*.dat[.gz] files inside each scenery path, followed by the default $FG_ROOT/Airports/apt.dat.gz (last in precedence order, thus allowing your custom sceneries to override airports already present in $FG_ROOT/Airports/apt.dat.gz). In the typical case, just put your apt.dat files(*) in the NavData/apt subdirectory of your custom scenery and they will be picked up automatically. In each of these files, you may include as many airport definitions as you want. (*) Actually, any name ending with .dat or .dat.gz---but the syntax inside, of course, must be valid "apt.dat syntax". And if the file name ends in .gz, of course the contents must be gzipped-compressed. 
The rule is that your file(s) must end in .dat (or .dat.g if gzip-compressed), there is no requirement to use the airport code in the file name, although of course it is clearer this way if you have one apt.dat file per airport. But it is also possible to have many airports in one big apt.dat or apt.dat.gz file like the $FG_ROOT/Airports/apt.dat.gz that comes with FG. you shouldn't add things yourself to the TerraSync folder or even, in this case, to K:\Program Files (x86)\FlightGear 2016.3.1\data created by the FG installation. You should just create a new folder for your custom scenery (k:\myflightgear\myscenery was an example, choose whatever you want) and declare it as a scenery path to FG. The Airports, Objects and Terrain subfolders are standard folders inside custom sceneries, so in the end if your custom scenery is non-empty, you'll have at least Objects or Terrain. As for the startup locations, it is definitely good for the future to include them in these files, but current FG only takes them from groundnet.xml files AFAIK, not apt.dat files (however, I've seen people post links about conversion tools from apt.dat format to groundnet.xml format, so probably the best way currently is to use apt.dat/WED as your primary data source even for startup locations/parkings and generate the groundnet.xml files from that). FFGo does read startup locations from $FG_ROOT/Airports/apt.dat.g, not yet from NavData/apt/*.dat[.gz] files inside scenery paths, but this is coming...
In the last couple of days, we have created a new dialog that can be used to easily prototype new NavDisplay styles, showing multiple ND instances for each pilot, which can be controlled/tested independently (using different settings for range, modes, traffic etc). Once the dialog is closed/reopened, the underlying navdisplay.mfd/styles files are also automatically reloaded from disk, so that you don't need to exit/restart fgfs to test your changes.
Under the hood, this is a conventoinal PUI/XML dialog with multiple embedded CanvasWidget areas that instantiate independent ND instances using a subset of the code commonly found in the aircraft specific ND.nas file, adapted to use the embedded Canvas region for rendering multiple NDs and GUI buttons/widgets added to control the whole thing without necessarily requiring a fully developed cockpit.
Thus, this is also a great tool for people flying aircraft that may not even have access to n ND.
Obviously, this is particularly useful for rapid prototyping ("RAD"), i.e. quickly testing additions and changes without having to exit/restart fgfs and without having a full aircraft developed yet.
This is currently pending review by Gijs and Hyde before it can be committed to the base package.
Continue reading at Howto:Prototyping a new NavDisplay Style...
Benchmarking Canvas Path Performance
The bottleneck is rendering the ADI-created property IO when this is at high quality if the GPU is fast enough.
The actual bottleneck is the ADI ball canvas code, because all needs to be done in the same frame, and the ADI should be updating reasonably fast. Also, getting the properties to display is not the issue, setting the points for canvas is.
For the MFDs... let's go through the numbers. We have 40 pages by now, each displays on average something like 50 properties. That's 2000 getprop calls for the data provider to manage. At 3 Hz, and 30 fps, that's 200 requests per frame.
Now, if these 40, no more than 9 different ones can actually be on at any given time - so that's 450 getprop calls if you do it without data provider.
Assembling a property path by string manipulation may be in theory less appealing, but it is in practice 3 to 10 times faster than using the props module (implemented in scripting space)- Thorsten has made several benchmark tests, all leading to the same result. Large-scale property manipulation from Nasal is performance hungry and should be avoided if possible by using Nasal-internal variables instead, and if it needs to be done, getprop() /setprop() offer significantly superior performance. If you dig a bit in the mailing list archive, there should be a post with the actual benchmark test results.
In the second case the property tree is being walked trough by the C++ code while in the first case it's done in Nasal. 
Continue reading at Howto:Canvas Path Benchmarking ...
Live-Streaming a Canvas via HTTP
There are situations, e.g., for home cockpit builders , where it is useful to display instruments like a PFD, ND, EICAS or any MFD externally from the FlightGear 3D main window in a separate window or on a separate monitor, computer or a mobile device   .
Many of these avionics/graphics are created by FlightGear's 2D drawing Canvas system internally.
In addition there, are a number of other use-cases where being able to obtain a Canvas from fgfs using a network protocol like http may be desirable (e.g. imagine getting a tilemap based on actual scenery from FlightGear ) .
ThomasS has created a patch for FlightGear for downloading any canvas image from a running FlightGear process by HTTP by serializing it to a raster image and serving that via the built-in mongoose based httpd server created by Torsten  .
This could be considered the groundwork needed for more sophisticated use-cases such as e.g. actually streaming a live video of a certain MFD to a browser.
Continue reading at Read canvas image by HTTP
In the hangar
When you have some spare time left, interested in heliopters and always wished to improve things, you might want to apply to this job. More informations on: MBB Bk 117 wiki-page
2016 Camaro SS and more
Auskunst is currently seeking help to improve the handling of his 2016 Camaro SS and another future automobile project. If you have experience of tweaking YASIM FDM, you can apply the job by clicking here
psadro_gm has the normal calculations, now. Everything is being generated on the fly. psadro_gm sees very little CPU usage. Still lot's to do - e.g. need to sample 1 extra pixel in the DEM so edges of tiles get correct normals ( you can see the edges )
Also, psadro_gm hasn't created skirts, yet, so there are gaps between levels.
psadro_gm will add to Mathias' tunables to select grid spacing at each LOD level, to see if we can minimie the popping. Note: the texture is just 1 4096x4096 sheet for the whole planet. It'll be nice to see what we can do with procedural texturing.
As far as creating ws3.0, let's see how the experimental engine works out. It basically does away with terragear, and uses standard gis tools for all elevation, landclass editing.
Terragear was never meant as a 'users' tool. It was designed to generate world scenery ( the whole planet at once ), not individual custom scenery locations.
That said, there have been some ( mostly unsuccessful ) attempts to make it more user friendly. We will see how far the new scenery experiments get us. If it shows enough promise, perhaps it will become the way forward, and terragear will mostly disappear. QGIS or GRASS, along with a few scripts will all that you would need to generate custom scenery, then.
To learn more, see Experimental terrain engine
|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.|
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 October 2016 is C182 takeoff at dawn by xcvb
If you want to participate in the screenshot contest of November 2016, 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 November 2016.