FlightGear Newsletter April 2014: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
(Switch to {{fgdata source}} to fix the Gitorious link created by the broken and depreciated {{git link}} template.)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{newsletter}}
{{newsletter}}
{{TOC_right|limit=2}}
{{TOC_right|limit=2}}
''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 [[Next Changelog|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.''


{{Newsletter being written}}
== Development news ==
== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].


=== Splitting fgdata ===
{{Conversational}}
http://sourceforge.net/p/flightgear/mailman/message/32238780/
<pre>
</pre>
=== Text-to-Speech: ATIS via FLITE ===
=== Text-to-Speech: ATIS via FLITE ===
Torsten and James started adding FLITE support to FlightGear/next:
Torsten and James started adding FLITE support to FlightGear. Thanks to James' finding of [http://flite-hts-engine.sp.nitech.ac.jp/ 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.
{{Conversational}}
<pre>thanks to James' finding of flite+hts_engine
(http://flite-hts-engine.sp.nitech.ac.jp/)
we 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.
 
I have just 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 I'd like to get some feedback regarding performance,
sound quality and cross platform compatibility. So please give it a try.
 
Torsten
</pre>
 
=== YaSim versioning ===
{{Conversational}}
 
<pre>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
Torsten pushed some code that uses the flite+hts_engine to synthesize the generated atis text for comm radios into a SGSoundSample
The original version of YASim as implemented up to FlightGear 3.0.0
and feed this into our sound manager. To make use of this feature you have to rebuild FlightGear from source and call cmake with
(this is the default)
-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.


YASIM_VERSION_32
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.
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
</pre>


=== Proof-of-Concept: A TerraGear Web Service (by F-JJTH) ===
=== Proof-of-Concept: A TerraGear Web Service (by F-JJTH) ===
Line 91: Line 26:
F-jjth-tggui-prototype.jpg|Web-based TerraGear GUI prototype developed by F-JJTH in 03/2014
F-jjth-tggui-prototype.jpg|Web-based TerraGear GUI prototype developed by F-JJTH in 03/2014
</gallery>
</gallery>


Continue reading at [[TerraGear scenery build server]]...
Continue reading at [[TerraGear scenery build server]]...
Line 98: Line 31:
=== Missions & Adventures via Tutorials ===
=== Missions & Adventures via Tutorials ===
{{forum|79|Tutorials, Missions & Adventures}}
{{forum|79|Tutorials, Missions & Adventures}}
[[File:Missionb.png|425px]]


[[File:Missionb.png]]
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]]...


{{#ev:youtube|yWEyRVGJks0}} {{#ev:youtube|LC2bk3UH8jg}} {{#ev:youtube|dU7ikBZOjgk}}
{| border=0
 
|valign="top"|[[File:Non-player-characters 1 20140421 1863384647.png|425px|DFaber's Walker used for adding NPC support to Stuart's tutorial system]]
[[File:Non-player-characters 1 20140421 1863384647.png|thumb|DFaber's Walker used for adding NPC support to Stuart's tutorial system]]
DFaber's Walker used for adding NPC support to Stuart's tutorial system
 
|{{#ev:youtube|yWEyRVGJks0}}
Learn more at [[FlightGear Missions and Adventures]]...
|-
|{{#ev:youtube|LC2bk3UH8jg}}
|{{#ev:youtube|dU7ikBZOjgk}}
|}


=== YASim Bug Fixes ===
=== 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 {{issue|1400|}}, {{issue|1423|}}, and {{issue|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" [http://forum.flightgear.org/viewtopic.php?f=49&t=22522#p204370]. 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.
As of April 4th, several bug fixes by Colin Howell have been merged into the "next" branch of FlightGear's source. As per issues {{issue|1400|}}, {{issue|1423|}}, and {{issue|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" [http://forum.flightgear.org/viewtopic.php?f=49&t=22522#p204370]. 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.
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:
Links to ongoing discussion at the development list:
[http://sourceforge.net/p/flightgear/mailman/message/32183541/] [http://sourceforge.net/p/flightgear/mailman/message/32185064/] [http://sourceforge.net/p/flightgear/mailman/message/32185188/] [http://sourceforge.net/p/flightgear/mailman/message/32185412/] [http://sourceforge.net/p/flightgear/mailman/message/32185690/] [http://sourceforge.net/p/flightgear/mailman/message/32185691/] [http://sourceforge.net/p/flightgear/mailman/message/32185923/]
[http://sourceforge.net/p/flightgear/mailman/message/32183541/] [http://sourceforge.net/p/flightgear/mailman/message/32185064/] [http://sourceforge.net/p/flightgear/mailman/message/32185188/] [http://sourceforge.net/p/flightgear/mailman/message/32185412/] [http://sourceforge.net/p/flightgear/mailman/message/32185690/] [http://sourceforge.net/p/flightgear/mailman/message/32185691/] [http://sourceforge.net/p/flightgear/mailman/message/32185923/]
=== 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 ===
=== How to troubleshoot FlightGear crashes ===
The recent 2 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.
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.  
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.  
Line 131: Line 86:
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.
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 [[Howto:Debugging FlightGear Crashes#Debugging_Segfaults_.26_Obtaining_Backtraces|Debugging Segfaults & Obtaining Backtraces]]...
Learn more at [[Howto:Debugging FlightGear Crashes#Debugging Segfaults & Obtaining_Backtraces|Debugging Segfaults & Obtaining Backtraces]]...
=== 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:
 
# 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.
# 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.
# 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 ===
=== 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.
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's only a single object in the field of view, performance is generally very good provided that there's 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.
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 ALS shader to render the atmosphere, visuals are generally rather compelling.
Combined with the [[atmospheric light scattering]] (ALS) shader to render the atmosphere, visuals are generally rather compelling.


[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]
[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]


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 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:


[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]
[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]


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


{{#ev:youtube|v-31tCHpKC0}}
{{#ev:youtube|v-31tCHpKC0}}


 
Learn more at [http://forum.flightgear.org/viewtopic.php?f=6&t=22640&p=205438 this forum topic]
Learn more at http://forum.flightgear.org/viewtopic.php?f=6&t=22640&p=205438
 
=== Random Buildings ===
 
=== 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 ===
=== 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 [http://forum.flightgear.org/viewtopic.php?f=71&t=16984&p=204730#p204730].
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 [http://forum.flightgear.org/viewtopic.php?f=71&t=16984&p=204730#p204730].
 
=== High Level Architecture ===
 
=== Usability Improvements ===


=== Creating your own keybindings ===
=== 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.
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 {{Git link|gitorious|fg/fgdata|master|keyboard.xml|pre=$FG_ROOT/}}, but each aircraft can add/change its own bindings through its -set.xml file, and additional [[config file]]s can do the same.
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 {{fgdata source|path=keyboard.xml|pre=$FG_ROOT}}, 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]]...
Continue reading [[Howto:Reassign keyboard keys]]...
Line 219: Line 129:
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.
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 ==
== Nasal for newbies ==
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.
=== 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.


== Interview with a contributor (NAME) ==
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:
''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?
# 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.
* What are your major interests in FlightGear?
# 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.
* What project are you working on right now?
# 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...).
* 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]].
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


Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX
* 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)


== Nasal for newbies ==
Continue reading at [[Object oriented programming in Nasal]]...


== New software tools and projects ==
== New software tools and projects ==


=== Free SVG VFR & IFR Symbol Sets===
=== Free SVG VFR & IFR Symbol Sets===
 
[[File:Canvastest.png|thumb|Tests with IFR Icons Set for FGCanvas]]
[[File:Helichartsbroadcaststationsexampleflagandunderscore.png]]
[[File:Helichartsbroadcaststationsexampleflagandunderscore.png]]


Line 261: Line 182:
[[File:Collocatedwithvfrcheckpoint.png]]
[[File:Collocatedwithvfrcheckpoint.png]]
[[File:Helichartsrco.png]]
[[File:Helichartsrco.png]]
[[File:Canvastest.png|thumb|Tests with IFR Icons Set for FGCanvas]]
[[File:Highintensityobstructionlights4big.png]]
[[File:Highintensityobstructionlights4big.png]]
[[File:Groupobstruction3big.png]]
[[File:Groupobstruction3big.png]]
Line 280: Line 198:


=== osm2city.py update ===
=== osm2city.py update ===
[[File:LOWI with OSM buildings from FL300.jpg|thumb|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.
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.


== FlightGear addons and mods ==
The screenshot below shows an aerial view of LOWI with 60k OSM buildings.
 
[[File:LOWI with OSM buildings from FL300.jpg|400px]]


== In the hangar ==
== In the hangar ==
Line 294: Line 213:
![http://img.ourl.ca/20.png]
![http://img.ourl.ca/20.png]


'''Embraer ERJ 145'''
==== Embraer ERJ 145 ====
 
'''Emmanuel Baranger, (helijah)'''
'''Emmanuel Baranger, (helijah)'''


Line 303: Line 221:
[[File:Erj145.png|thumb|ERJ 145 in flight]]
[[File:Erj145.png|thumb|ERJ 145 in flight]]


'''Focke Wulf Ta 154 "Moskito"'''
==== Focke Wulf Ta 154 "Moskito" ====


'''Emmanuel Baranger, (helijah)'''
'''Emmanuel Baranger, (helijah)'''
Line 313: Line 231:


=== Updated aircraft ===
=== Updated aircraft ===
{{Conversational}}
Updated: http://sourceforge.net/p/flightgear/mailman/message/32241203/


==== PA24-250 ====
==== PA24-250 ====
Line 327: Line 241:


FAC (FlightGear Aviation Commission)
FAC (FlightGear Aviation Commission)
Download here: [https://drive.google.com/file/d/0B1neCIlnSm2hYVlWdmtVSjgtS1k/edit?usp=sharing] under Creative Commons Attribution-Share Alike 3.0 Unported license from original FG Logos [http://wiki.flightgear.org/FlightGear_logos]
Download here: [https://drive.google.com/file/d/0B1neCIlnSm2hYVlWdmtVSjgtS1k/edit?usp=sharing] under Creative Commons Attribution-Share Alike 3.0 Unported license from original [[FlightGear logos]].


== Scenery corner ==
== Scenery corner ==
=== The Making of a new World Scenery ===
=== 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.
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. [[File:terrain-generation-memory-consumption.png|right|thumb|Memory consumption during scenery creation]]
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. [[File:terrain-generation-memory-consumption.png|right|thumb|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.


=== Airports ===
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.


== Aircraft of the month ==
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.
== Airport of the month ==
All this only works because of just a few people working hard and usually undiscovered in the background.
== Screenshot of the month ==
 
== Suggested flights ==
== Aircraft reviews ==


== Wiki updates ==
== Wiki updates ==
Line 366: Line 274:
{{#ev:youtube|PW36zkuHyBA}}
{{#ev:youtube|PW36zkuHyBA}}


Retrospective flight in B707 via Rembrant
Retrospective flight in B707 in Rembrandt


=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Multiplayer ===
==== The Northern-Italy ATC Controlled Area (NIATCA) ====
==== The Northern-Italy ATC Controlled Area (NIATCA) ====
Line 396: Line 302:
* be able to man their position(s) at least one/two hours a week.
* be able to man their position(s) at least one/two hours a week.


=== Virtual airlines ===
=== FlightGear events ===
== Useful links ==
== And finally ... ==
== And finally ... ==
=== Contributing ===
=== Contributing ===


{{Volunteer Intro|mode=showlogo}}
{{Volunteer Intro|mode=showlogo}}
<!--
TODO: this needs to be added to  Template:Volunteer Intro
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].
To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].
-->
=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}
<references/>


=== Call for volunteers ===
=== 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 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
 
=== Did you know ===


[[Category:FlightGear Newsletter]]
<!-- this needs to be changed after each release, so that newsletters show up in the proper category -->


[[Category:Changes after 3.00]]
[[Category:FlightGear Newsletter|2014 04]]
[[Category:Changes after 3.0]]

Latest revision as of 11:11, 14 March 2016

Magagazine.png
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.

Continue reading at TerraGear scenery build server...

Missions & Adventures via Tutorials

Missionb.png

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

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.

Low orbit High orbit

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:

Cloud shadows in Earthview Specular water reflections and cloud shadows in Earthview

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

Helichartsbroadcaststationsexampleflagandunderscore.png

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.

Vfrwaypointsstandalone.png Rotatinglightwithcourselightsandsitenumberarrowsstarbig.png Helichartsultralightflightpark.png Helichartsgliderarea.png Civilairportwithnocontroltower.png Rotatinglightwithcourselightsandsitenumberairportsmall.png Airmarkedidentification.png Wrecksexposed.png Helicopterchartsseaplane.png Collocatedwithvfrcheckpoint.png Helichartsrco.png Highintensityobstructionlights4big.png Groupobstruction3big.png Highintensityobstructionlights3big.png Highintensityobstructionlights5small.png

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.

Helichartsvor.png Helichartsvortac.png Helichartsvordme.png

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.

LOWI with OSM buildings from FL300.jpg

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

En.gif 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.
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 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

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 This is a link to the FlightGear 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.