FlightGear Newsletter July 2014: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
m (→‎Support for Nasal in Notepad++: Switch to {{gitorious source}} to fix the broken Gitorious links)
 
(29 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{Newsletter being written}}
{{Newsletter-header|July 2014}}
 
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|5 years of newsletters}}<br/><br/>
{{Newsletter-cover-header|Development news}}<br/>
{{Newsletter-cover-item|FlightGear 3.2 on approach}}<br/>
{{Newsletter-cover-item|A Canvas based GNS 530 GPS}}<br/>
{{Newsletter-cover-item|Nasal: Making safer base-class calls}}<br/>
{{Newsletter-cover-item|FGCamera}}<br/>
{{Newsletter-cover-item|Osm2city}}
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery corner}}<br/>
{{Newsletter-cover-item|Paro Int. Airport - VQPR}}<br/><br/>
{{Newsletter-cover-header|Other}}<br/>
{{Newsletter-cover-item|Support for Nasal in Notepad++}}<br/>
{{Newsletter-cover-item|Primary Flight Displays for Android Devices}}<br/>
{{Newsletter-cover-item|Parachute for YASim (Thrusters & Nasal)}}<br/><br/>
| valign="top" width="33%" |
{{Newsletter-cover-header|In the hangar}}<br/>
{{Newsletter-cover-item|Mainair Flash 2 Alpha}}<br/>
{{Newsletter-cover-item|Aero L-159 ALCA}}<br/><br/>
{{Newsletter-cover-header|Multiplayer events}}<br/>
{{Newsletter-cover-item|FGUK Mach Loop Challenge}}
|}
</div>
== 5 years of newsletters ==
== 5 years of newsletters ==
[[File:Fgmagfiveyears.png]]
[[File:Fgmagfiveyears.png]]


The newsletter started in July 2009. (more to write here, just so we don't forget about it)
The [[FlightGear Newsletter July 2009|first edition]] of the FlightGear newsletter in its current form was published in July 2009. At the time, there was no place where news from the various "sections" of FlightGear was collected. After several discussions and earlier fruitless attempts, the first edition was hosted on the wiki. This allowed (and still allows) anyone to contribute by writing articles, collecting news, checking grammar and providing images. Over the years we have together written 60 editions (take a look at [[FlightGear Newsletter|the archive]]).
 
{{FGCquote
  |Would it be an idea to provide some sort of weekly or monthly newsletter? I often find out that there are new things I didn't new about or other users that don't follow all topics won't know if there's an awsome plane released. That's why I think we need a newsletter.<br/>
<br/>
'''Possible things to write about could be:'''<br/>
- New planes that are released.<br/>
- New scenery projects (like a new/redrawed airport, things like the corse scenery etc.).<br/>
- New FG releases (this is not very often, but it should be in the letter if so).<br/>
- New forum features/subforums and other news from the forum.<br/>
- News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse)<br/>
- Events that will be held within a short periode or (links to) screenshots of the latest event(s).<br/>
- The first 3 or 5 pictures of a screenshot contest.<br/>
<br/>
If you got other idea's, post in this topic so we could extend the list.<br/>
I don't really know what's best way to provide the letter. But we have some options:<br/>
- a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me).<br/>
- emails send to all forum-users (I don't really like this myself).<br/>
- a .pdf file with a link on the main page of [http://www.flightgear.org http://www.flightgear.org]<br/>
- or even something else<br/>
<br/>
I would like to write the letter, but if there are other people to we might split stuff (someone for scenery news, someone else for aircrafts etc.). Please respond and vote in the poll. Tips/ideas are very much appreciated.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11211#p11211
    |title=<nowiki>Newsletter</nowiki>
    |author=<nowiki>Gijs</nowiki>
    |date=<nowiki>Mon May 26</nowiki>
  }}
}}
 
{{FGCquote
  |The devel-list is great, I'm subscribed to, but not simple to read. It's more like the forum. Usually I don't want to or have time to read through all emails. So I delete most of it without reading anything more than the subject. We don't want to read a lot of topics if we only want to know what function is new and what it does. The the users (so not the developers) want something more ease to read/check. With some screenies of what they will get with a new function etc. So my idea was to make it especially for users.<br/>
<br/>
Events aren't listed on the pages you gave nor some other stuff we could place in the newsletter. In the letter all important news to know will be listed together. If we get this of the ground it could be a great way to reach users to (for events etc.). So I think the newsletter still will be a addition to the lists.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11216#p11216
    |title=<nowiki>Re: Newsletter</nowiki>
    |author=<nowiki>Gijs</nowiki>
    |date=<nowiki>Mon May 26</nowiki>
  }}
}}
 
{{FGCquote
  |At one time a few years ago we attempted to launch a newsletter.  We had two volunteers, but we never got even the first issue out.  It's a lot of work so we need a pretty dedicated volunteer.  I've heard of other folks using scribus, but even open-office writer would probably be just fine.  Let's not get too caught up in the details of a print/publishing quality layout if we have to sacrifice time for content and just getting the newsletter out on a regular time frame.  There are a bazillion ideas for articles.  I could dust off my unpublished "yasim howto" for instance.  That ended up being about 10 pages (so not newsletter material really) but I could trim it down to a teaser article and we could post the full version on the wiki or something?<br/>
<br/>
But if you are willing to get a newsletter rolling, that would be awsome.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11277#p11277
    |title=<nowiki>Re: Newsletter</nowiki>
    |author=<nowiki>curt</nowiki>
    |date=<nowiki>Tue May 27</nowiki>
  }}
}}
 
{{FGCquote
  |Gijs is right when it comes to being a Developer or a User of FG is Vastly different. I know when i first started here i had no clue about lots of developmental things, now i talk of writing .xml files, modelling nasal scripting. That is due to people describing things is basic easy to understand" Laymans" terms and not the kind of language that the DEvs use (understandably of course)<br/>
 
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11368#p11368
    |title=<nowiki>Re: Newsletter</nowiki>
    |author=<nowiki>MaverickAlex</nowiki>
    |date=<nowiki>Thu May 29</nowiki>
  }}
}}
 
{{FGCquote
  |Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15619#p15619
    |title=<nowiki>Re: Newsletter</nowiki>
    |author=<nowiki>Gijs</nowiki>
    |date=<nowiki>Thu Aug 21</nowiki>
  }}
}}
 
{{FGCquote
  |Why not simply start a new page on the wiki where anybody can provide contents, so that whenever it's time to send out a newsletter, the draft from the wiki could be taken?<br/>
That way, it wouldn't be too much work for a single person - more like a "community-driven" newsletter, while this may appear to sort of defeat the purpose, not all newsletter recipients are necessarily also wiki users.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=18015#p18015
    |title=<nowiki>Re: Newsletter</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Fri Oct 03</nowiki>
  }}
}}
 
== Adding backdrop styling to Canvas (by Gijs) ==
Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides.
 
For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now [http://forum.flightgear.org/viewtopic.php?f=71&t=23500&p=214278#p214275].
{{FGCquote
  |And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes).<br/>
<br/>
(see the [http://i.imgur.com/dqMzBS4.png linked image])
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214268#p214268
    |title=<nowiki>Re: osgText backdrop</nowiki>
    |author=<nowiki>Gijs</nowiki>
    |date=<nowiki>Mon Jul 07</nowiki>
  }}
}}
 
<syntaxhighlight lang="diff">
commit 5cc0adc778bda1773189b0119d24fbaf5ecd4500
Author: Gijs de Rooy
Date:  Mon Jul 7 18:26:16 2014 +0200
 
    Canvas: add backdrop option to text
 
diff --git a/simgear/canvas/elements/CanvasText.cxx b/simgear/canvas/elements/CanvasText.cxx
index d99760a..3a986e1 100644
--- a/simgear/canvas/elements/CanvasText.cxx
+++ b/simgear/canvas/elements/CanvasText.cxx
@@ -39,6 +39,7 @@ namespace canvas
      void setLineHeight(float factor);
      void setFill(const std::string& fill);
      void setBackgroundColor(const std::string& fill);
+      void setOutlineColor(const std::string& backdrop);
      SGVec2i sizeForWidth(int w) const;
      osg::Vec2 handleHit(const osg::Vec2f& pos);
@@ -97,6 +98,15 @@ namespace canvas
  }
  //----------------------------------------------------------------------------
+  void Text::TextOSG::setOutlineColor(const std::string& backdrop)
+  {
+    osg::Vec4 color;
+    setBackdropType(osgText::Text::OUTLINE);
+    if( parseColor(backdrop, color) )
+      setBackdropColor( color );
+  }
+
+  //----------------------------------------------------------------------------
  // simplified version of osgText::Text::computeGlyphRepresentation() to
  // just calculate the size for a given weight. Glpyh calculations/creating
  // is not necessary for this...
@@ -546,6 +556,7 @@ namespace canvas
    addStyle("fill", "color", &TextOSG::setFill, text);
    addStyle("background", "color", &TextOSG::setBackgroundColor, text);
+    addStyle("backdrop", "color", &TextOSG::setOutlineColor, text);
    addStyle("character-size",
              "numeric",
              static_cast<
</syntaxhighlight>


<big>We would like to thank all readers and contributors for their support!</big>


<syntaxhighlight lang="diff">commit 838cabd2a551834cbcac2b3edd21500409ff2e98
PS: Please take a look at [[FlightGear Newsletter#You are invited to contribute!|FlightGear Newsletter]] if you're interested in helping!
Author: Gijs de Rooy
Date:  Mon Jul 7 18:27:50 2014 +0200


    Canvas: add backdrop option to text
== Development news ==
=== FlightGear 3.2 on approach ===
With the release branch creation on July 17, FlightGear version 3.2 is approaching fast. No new features shall be added over the coming weeks, now that the focus is on finding and fixing bugs. Those of you building from source are encouraged to build from release/3.2.0 and report bugs at [http://flightgear-bugs.googlecode.com our bug tracker].


diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
The stable release is due around August 17. See our [[release plan]] for details on the release procedure.
index 8bc12d8..3047dbf 100644
--- a/Nasal/canvas/api.nas
+++ b/Nasal/canvas/api.nas
@@ -634,6 +634,8 @@ var Text = {
  setColorFill: func me.set('background', _getColor(arg)),
  getColorFill: func me.get('background'),
+  setBackdropColor: func me.set('backdrop', _getColor(arg)),
};
# Path
</syntaxhighlight>


== FGCanvas Updates ==
=== FGCanvas Updates ===
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as  each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]]
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as  each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]]
{{FGCquote
{{FGCquote
Line 179: Line 53:
     |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
     |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Sun Jul 06</nowiki>
     |date=<nowiki>Sun Jul 06 2013</nowiki>
   }}
   }}
}}
}}
Line 190: Line 64:
     |title=<nowiki>Re: FSWeekend 2010</nowiki>
     |title=<nowiki>Re: FSWeekend 2010</nowiki>
     |author=<nowiki>zakalawe</nowiki>
     |author=<nowiki>zakalawe</nowiki>
     |date=<nowiki>Tue Nov 02</nowiki>
     |date=<nowiki>Tue Nov 02 2010</nowiki>
   }}
   }}
}}
}}


{{FGCquote
{{FGCquote
   |Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running:<br/>
   |Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running:
<br/>
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
     |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
     |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Sun Jul 06</nowiki>
     |date=<nowiki>Sun Jul 06 2013</nowiki>
   }}
   }}
}}
}}


{{FGCquote
{{FGCquote
   |Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&amp;re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below:<br/>
   |Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&amp;re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: [[FGCanvas]]
<br/>
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]]
[[FGCanvas]]<br/>
 
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]]<br/>
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are:
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are:<br/>
* flight (FDM)
<ul>
* scenery (tile manager, ephemeris)
<li> flight (FDM)</li>
* view manager
<li> scenery (tile manager, ephemeris)</li>
* lighting
<li>view manager</li>
* terrasync
<li>lighting</li>
<li>terrasync</li>
</ul>
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
   |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
     |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
     |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Sun Jul 06</nowiki>
     |date=<nowiki>Sun Jul 06 2014</nowiki>
   }}
   }}
}}
}}
Line 233: Line 103:
     |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
     |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Sun Jul 06</nowiki>
     |date=<nowiki>Sun Jul 06 2014</nowiki>
   }}
   }}
}}
}}
Line 242: Line 112:
     |title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
     |title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
     |author=<nowiki>Philosopher</nowiki>
     |author=<nowiki>Philosopher</nowiki>
     |date=<nowiki>Sun Jul 06</nowiki>
     |date=<nowiki>Sun Jul 06 2014</nowiki>
   }}
   }}
}}
}}
=== A Canvas based GNS 530 GPS ===
After a long hiatus (3 years!) forum user cbendele felt like doing some FlightGear aircraft modeling again. Three years ago, when he started the panel for his Bo, he could not find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So he decided to start with this:
[[File:Gns530-prototype-07-2014.png|300px]]
The GNS530 is already kind of outdated as well, but together with its smaller sibling the GNS430, it is still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces.
Right now this is very much work in progress. It is also the first time cbendele wrote more than five lines of nasal, so he was basically learning the language while he wrote this. Still, it's far enough to present it here and let people try it and send critique and suggestions. Learn more at [[Garmin GNS530]] or the [http://forum.flightgear.org/viewtopic.php?p=215254#p215254 forum topic]
=== Nasal: Making safer base-class calls ===
There is a lot of Nasal code floating around doing the equivalent of this when using multiple inheritance to make base class calls:
<syntaxhighlight lang="nasal">
object.parents[x].method();
</syntaxhighlight>
Internally, this works such that Nasal's inheritance mechanism relies on a so called '''parents''' vector that contains a list of classes that are used for field/method look-ups. This vector can be accessed using numeric indexes - thus, the correct value for '''x''' is directly affected by the way the parents vector is set up, i.e. its internal class ordering:
<syntaxhighlight lang="nasal">
var myClass = {parents:[FirstBaseClass, SecondBaseClass, ThirdBaseClass] };
</syntaxhighlight>
However, this practice of using indexed parents access to look up a base class should be considered a "hack" and discouraged, because it's not a particularly robust or even safe way to call a superclass, simply because it doesn't tell Nasal anything about the name of the class you're trying to call, but merely its index in the inheritance/lookup vector, which may be subject to change (e.g. due to refactoring). Thus, we encourage people to actually use Nasal's built-in '''call()''' API to accomplish the same thing in a more robust fashion:
<syntaxhighlight lang="nasal">
call(Class.method, [], me);
</syntaxhighlight>
This will tell Nasal that you want it to call a certain method in a particular class - and if that fails, you'll get better diagnostics (error messages), too. The main problem here is that the other approach is pretty vulnerable when restructuring your code, as it is heavily reliant on inheritance '''ordering''' - which is something that isn't exactly straightforward: code shouldn't "break" just because the inheritance ordering is modified. Thus, please try to use the latter idiom. If in doubt, just get in touch via the Nasal sub forum.
To pass argument to the method, just add them to the 2nd argument, i.e. the empty vector:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me);
</syntaxhighlight>
To pass a custom namespace environment, you can use this:
<syntaxhighlight lang="nasal">
var namespace = {};
call(Class.method, [nil,nil,nil], me, namespace);
</syntaxhighlight>
Which would be equivalent to this example using an anonymous namespace:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, {} );
</syntaxhighlight>
(If you want to preserve/modify the namespace, it makes sense not use an anonymous namespace though).
To do exception handling, you can pass an empty vector and check its size (>=1):
<syntaxhighlight lang="nasal">
var err = [];
call(Class.method, [nil,nil,nil], me, {}, err );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
</syntaxhighlight>
You can also declare the variable expression inline:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, var ns={}, var err=[] );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
else {
print("Success, namespace is:");
debug.dump(ns);
}
</syntaxhighlight>


== FGCamera ==
== FGCamera ==
Development of FGCamera continues. The script is being redesigned to be compatible with default view system.
Development of FGCamera continues. The script is being redesigned to be compatible with default view system. The upcoming version (FGCamera v1) will have new camera mode: "world-view".
Upcoming version (FGCamera v1) will have new camera mode: "world-view".


{{#ev:youtube|hebx8WdXHa0}}
{{#ev:youtube|hebx8WdXHa0}}
== Osm2city ==
Development of Osm2city continues. The video shows Innsbruck, Austria (LOWI) with Flightgear at 1440p (Rendered for youtube at 1080p).
For more information see: [[Osm2city.py]]
{{#ev:youtube|V_Bkpx8tANE}}


== Scenery corner ==
== Scenery corner ==
=== Paro Int. Airport - VQPR ===
=== Paro Int. Airport - VQPR ===
[[File:VQPR PARO AIRPORT.jpg|320px|right]]
[[File:VQPR PARO AIRPORT.jpg|320px|right]]
{{#ev:youtube|itNY9YUmY3M||right|domestic flight from Bumthang to Paro}}
Works have been added to [[Paro Airport|Paro International Airport]] (VQPR) with terminal, tower, hangars and other buildings. Now users you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. [[TerraSync]] has it all! It is not necessary to download any custom scenery. More information can be found on the wiki page: [[Paro Airport]]. This is the first airport of the Bhutanese Series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Work also continues on navaids for the Kingdom of Bhutan - of course only in the FlightGear-World. Everybody is invited to follow the stage of development at the designers wiki user page ([[User:Fgjosh|Fgjosh]]).
Works have been added to Paro International Airport (VQPR) with terminal, tower, hangars and other buildings. Also you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. TerraSync has it all! You don't need to download a custom scenery. More information can be found on the wiki page: [[Paro Airport]]. This is the first airport of the bhutanese series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Also we have to work on navaids for the Kingdom of Bhutan - of course only in the FG-World ;-) You can follow the stage of development on my wiki user page [[User:Fgjosh|Fgjosh]].
 
{{#ev:youtube|itNY9YUmY3M}}
 
== Support for Nasal in Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of {{gitorious source|nasal-support|nasal-npp|text=Nasal support for Notepad++}}]]
Programming in Nasal on Windows can now be a lot friendlier with {{gitorious source|nasal-support|nasal-npp|text=Nasal support for Notepad++}}. It provides comprehensive syntax highlighting and class/function listing in a hierarchical fashion.
 
Syntax highlighting is available for other editors as well, for more information see [[Howto:Syntax highlighting for Nasal]]
 
== Primary Flight Displays for Android Devices ==
Android devices are light, thin, and offer a very decent computing power and graphics processing. They are battery operated and can connect to other devices through WiFi (there is no need of cables). They are, in fact, perfect for integration in home-made cockpits. This new project offers the opportunity of extending their usage in the form of Primary Flight Displays and Navigation displays for airliners in FlightGear. There are currently four Primary Flight Display (PFD) Apps in "early production" state: Basic, Boeing 777, Boeing 787-8, and Airbus 330. The Basic App is at this moment available in the Android Play Store. The other Apps will be uploaded during the next days provided that no serious problems are found in the Basic App. You are more than welcome to test it and give feedback! Visit the project website for more information: https://sites.google.com/site/flightgearandroid/
 
{{#ev:youtube|jd61x-_QNpM}}
{{#ev:youtube|Y6M9SyMZSCk}}
{{#ev:youtube|N1D--DZjvtE}}
 
== Parachute for YASim (Thrusters & Nasal) ==
[[File:V-1 Parachute.png|350px|thumb|V-1falling slowly with a parachute]]
Tomaskom developed a realistically behaving parachute for YASim aircraft. It is capable of a slow and stable fall and can recover the aircraft even from very severe rotations. It all began as a question about a parachute which ended by brainstorming of the best approach. See [http://fguk.eu/index.php/forum/development-hangar/4546-external-reactions-forces-in-yasim this forum topic] for the discussion.
 
Re-implementing the code elsewhere is very easy. Most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). See [http://forum.flightgear.org/viewtopic.php?f=49&p=215650 this forum topic] for instructions.
 
Currently there is a reference implementation in a special version of the V-1 flying bomb, available at [http://fguk.eu/index.php/hangar/viewdownload/11-other-objects-and-vehicles/400-v-1-flying-bomb FGUK]. You can also get an idea of it's stabilization properties from [https://www.dropbox.com/s/81ns5ib5tf3y74t/V-1_Parachute.avi this video]
 
The drone (Firebee) for which the parachute was requested is not yet publicly available.
 
== In the hangar ==
=== Mainair Flash 2 Alpha ===
[[File:Flash2a_in_Air2.png|350px|thumb]]
The microlight [[Mainair Flash 2 Alpha]] is now weightshift controlled and has a new wing model.
* redesigned FDM with weightshift-control
* new wing model
* customizable controls
* weight and balance gui
* animated cockpit view
* animated pilot and an optional passenger
* emergency parachute
* multiplayer ready
* aerotow hitch
 
=== Aero L-159 ALCA ===
{{#ev:youtube|uLojBI7ezdM|350|right|L-159 Disintegration}}
A first public version of the L-159 ALCA (Advanced Light Combat Aircraft) has been released. The aircraft is still in alpha stage and fairly incomplete (there are some changes to the model planned, so no texturing yet, no cockpit instruments), but it already has many advanced and sometimes unique features, most notably the disintegration animations.<br/>
Some of the most important features include:
* Unique model disintegration animation (video on the right, see details here: http://forum.flightgear.org/viewtopic.php?f=4&t=23681)
* Cannons with realistic fire rate and tracers once every few rounds, visible/audible over MP (hit transmission is a work in progress)
* Fully automated fuel system with automatic source switching and fuel level balancing
* Carefully tuned lights including Rembrandt support, light intensity and flares fading in daylight. You may need to increase the Lights shader setting in order to see all effects with Rembrandt on.
* Most payload options modeled, including optional experimental fixed fuel probe
* I consider the FDM (YASim) almost complete and generally well tuned, handling changes a lot with heavy payload
Download available from the FGUK hangar: <br/>
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]
{{-}}
 
== Multiplayer Events ==
=== FGUK Mach Loop Challenge ===
'' Saturday 9th August 2014 - Llanbedr Airfield (EGOD) - 1900 G/U/Z''
{{-}}
{{#ev:youtube|XK0Y1sfijLY||right|A trip around the loop with the Vulcan B2}}
[http://www.fguk.eu FGUK] will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. The world-famous low flying route in North Wales, on the doorstep of FGUK's Llanbedr headquarters, is a 26 mile course threading the valleys and hills around Machynlleth. Can you consistently lower your time and beat the other pilots around the course without breaking the sound barrier and startling the sheep?
 
A custom AI scenario displays the route with fly-through pointers, checks for adherence to the rules, and announces and records your time - just hand in your score file, and you will be included in the results when published in the following week. More information and updates in the weeks either side of the 9th on FGUK's [https://www.facebook.com/FlightGearUK Facebook page] and [https://twitter.com/FlightGearUK Twitter account]. As always at the Mach Loop, there will be photography and video and the event will be streamed live on our [https://www.youtube.com/channel/UCBb-2WXJuAOVh8QvsdVNrrQ YouTube channel].
 
Recommended choices to fly the loop competitively are Supersonic single and twin seaters, but you can bring anything within reason that doesn't make you a danger to others. Assemble at FGUK Llanbedr (EGOD) at 1900 G/U/Z (8pm BST). If you're planning to bring something unusual, we ask you to notify us in the forum to make sure all the models are visible to the camera.
 
A full briefing for pilots will be published on Sunday, along with the definitive AI scenario for the competition. Check the [http://fguk.eu/index.php/12-flight-articles/saturday-flight-articles/21-saturday-9th-august-mach-loop-challenge ongoing event article] and the [http://fguk.eu/index.php/forum/saturday-night-flying/4659-flightnight-9-8-14-mach-loop-challenge?start=40#16865 forum thread] to keep up to date.
 
[[Category:FlightGear Newsletter|2014 07]]

Latest revision as of 15:02, 12 March 2016

Magagazine.png
Enjoy reading the latest edition!
Please help us write the coming edition!
July 2014

5 years of newsletters

Development news
FlightGear 3.2 on approach
A Canvas based GNS 530 GPS
Nasal: Making safer base-class calls
FGCamera
Osm2city

Scenery corner
Paro Int. Airport - VQPR

Other
Support for Nasal in Notepad++
Primary Flight Displays for Android Devices
Parachute for YASim (Thrusters & Nasal)

In the hangar
Mainair Flash 2 Alpha
Aero L-159 ALCA

Multiplayer events
FGUK Mach Loop Challenge

5 years of newsletters

Fgmagfiveyears.png

The first edition of the FlightGear newsletter in its current form was published in July 2009. At the time, there was no place where news from the various "sections" of FlightGear was collected. After several discussions and earlier fruitless attempts, the first edition was hosted on the wiki. This allowed (and still allows) anyone to contribute by writing articles, collecting news, checking grammar and providing images. Over the years we have together written 60 editions (take a look at the archive).

We would like to thank all readers and contributors for their support!

PS: Please take a look at FlightGear Newsletter if you're interested in helping!

Development news

FlightGear 3.2 on approach

With the release branch creation on July 17, FlightGear version 3.2 is approaching fast. No new features shall be added over the coming weeks, now that the focus is on finding and fixing bugs. Those of you building from source are encouraged to build from release/3.2.0 and report bugs at our bug tracker.

The stable release is due around August 17. See our release plan for details on the release procedure.

FGCanvas Updates

checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [1]
Cquote1.png Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system:


Cquote1.png Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend.


If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself -
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than
sending per-frame pixel surfaces over shared memory or sockets / pipes.

Cquote2.png

— Hooray (Sun Jul 06 2013). FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
Cquote2.png

The whole discussion dates back to the early FGPanel days:

Cquote1.png I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people). It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic!
— zakalawe (Tue Nov 02 2010). Re: FSWeekend 2010.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running:
Cquote1.png Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...
Cquote2.png

— Hooray (Sun Jul 06 2013). FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: FGCanvas

Patching-fg-3.2-to-make-more-subsystems-optional.png

Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are:

  • flight (FDM)
  • scenery (tile manager, ephemeris)
  • view manager
  • lighting
  • terrasync

Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)


— Hooray (Sun Jul 06 2014). FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png This means that there's basically just a handful of subsystems that now need to be made optional, and that FGCanvas will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically".


In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.


— Hooray (Sun Jul 06 2014). FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea.
— Philosopher (Sun Jul 06 2014). Re: FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
Cquote2.png

A Canvas based GNS 530 GPS

After a long hiatus (3 years!) forum user cbendele felt like doing some FlightGear aircraft modeling again. Three years ago, when he started the panel for his Bo, he could not find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So he decided to start with this:

Gns530-prototype-07-2014.png

The GNS530 is already kind of outdated as well, but together with its smaller sibling the GNS430, it is still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces.

Right now this is very much work in progress. It is also the first time cbendele wrote more than five lines of nasal, so he was basically learning the language while he wrote this. Still, it's far enough to present it here and let people try it and send critique and suggestions. Learn more at Garmin GNS530 or the forum topic

Nasal: Making safer base-class calls

There is a lot of Nasal code floating around doing the equivalent of this when using multiple inheritance to make base class calls:

object.parents[x].method();

Internally, this works such that Nasal's inheritance mechanism relies on a so called parents vector that contains a list of classes that are used for field/method look-ups. This vector can be accessed using numeric indexes - thus, the correct value for x is directly affected by the way the parents vector is set up, i.e. its internal class ordering:

var myClass = {parents:[FirstBaseClass, SecondBaseClass, ThirdBaseClass] };

However, this practice of using indexed parents access to look up a base class should be considered a "hack" and discouraged, because it's not a particularly robust or even safe way to call a superclass, simply because it doesn't tell Nasal anything about the name of the class you're trying to call, but merely its index in the inheritance/lookup vector, which may be subject to change (e.g. due to refactoring). Thus, we encourage people to actually use Nasal's built-in call() API to accomplish the same thing in a more robust fashion:

call(Class.method, [], me);

This will tell Nasal that you want it to call a certain method in a particular class - and if that fails, you'll get better diagnostics (error messages), too. The main problem here is that the other approach is pretty vulnerable when restructuring your code, as it is heavily reliant on inheritance ordering - which is something that isn't exactly straightforward: code shouldn't "break" just because the inheritance ordering is modified. Thus, please try to use the latter idiom. If in doubt, just get in touch via the Nasal sub forum.

To pass argument to the method, just add them to the 2nd argument, i.e. the empty vector:

call(Class.method, [nil,nil,nil], me);

To pass a custom namespace environment, you can use this:

var namespace = {};
call(Class.method, [nil,nil,nil], me, namespace);

Which would be equivalent to this example using an anonymous namespace:

call(Class.method, [nil,nil,nil], me, {} );

(If you want to preserve/modify the namespace, it makes sense not use an anonymous namespace though).

To do exception handling, you can pass an empty vector and check its size (>=1):

var err = [];
call(Class.method, [nil,nil,nil], me, {}, err );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");

You can also declare the variable expression inline:

call(Class.method, [nil,nil,nil], me, var ns={}, var err=[] );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
else {
print("Success, namespace is:");
debug.dump(ns);
}

FGCamera

Development of FGCamera continues. The script is being redesigned to be compatible with default view system. The upcoming version (FGCamera v1) will have new camera mode: "world-view".

Osm2city

Development of Osm2city continues. The video shows Innsbruck, Austria (LOWI) with Flightgear at 1440p (Rendered for youtube at 1080p). For more information see: Osm2city.py

Scenery corner

Paro Int. Airport - VQPR

VQPR PARO AIRPORT.jpg

Works have been added to Paro International Airport (VQPR) with terminal, tower, hangars and other buildings. Now users you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. TerraSync has it all! It is not necessary to download any custom scenery. More information can be found on the wiki page: Paro Airport. This is the first airport of the Bhutanese Series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Work also continues on navaids for the Kingdom of Bhutan - of course only in the FlightGear-World. Everybody is invited to follow the stage of development at the designers wiki user page (Fgjosh).

Support for Nasal in Notepad++

Programming in Nasal on Windows can now be a lot friendlier with Nasal support for Notepad++. It provides comprehensive syntax highlighting and class/function listing in a hierarchical fashion.

Syntax highlighting is available for other editors as well, for more information see Howto:Syntax highlighting for Nasal

Primary Flight Displays for Android Devices

Android devices are light, thin, and offer a very decent computing power and graphics processing. They are battery operated and can connect to other devices through WiFi (there is no need of cables). They are, in fact, perfect for integration in home-made cockpits. This new project offers the opportunity of extending their usage in the form of Primary Flight Displays and Navigation displays for airliners in FlightGear. There are currently four Primary Flight Display (PFD) Apps in "early production" state: Basic, Boeing 777, Boeing 787-8, and Airbus 330. The Basic App is at this moment available in the Android Play Store. The other Apps will be uploaded during the next days provided that no serious problems are found in the Basic App. You are more than welcome to test it and give feedback! Visit the project website for more information: https://sites.google.com/site/flightgearandroid/

Parachute for YASim (Thrusters & Nasal)

V-1falling slowly with a parachute

Tomaskom developed a realistically behaving parachute for YASim aircraft. It is capable of a slow and stable fall and can recover the aircraft even from very severe rotations. It all began as a question about a parachute which ended by brainstorming of the best approach. See this forum topic for the discussion.

Re-implementing the code elsewhere is very easy. Most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). See this forum topic for instructions.

Currently there is a reference implementation in a special version of the V-1 flying bomb, available at FGUK. You can also get an idea of it's stabilization properties from this video

The drone (Firebee) for which the parachute was requested is not yet publicly available.

In the hangar

Mainair Flash 2 Alpha

Flash2a in Air2.png

The microlight Mainair Flash 2 Alpha is now weightshift controlled and has a new wing model.

  • redesigned FDM with weightshift-control
  • new wing model
  • customizable controls
  • weight and balance gui
  • animated cockpit view
  • animated pilot and an optional passenger
  • emergency parachute
  • multiplayer ready
  • aerotow hitch

Aero L-159 ALCA

L-159 Disintegration

A first public version of the L-159 ALCA (Advanced Light Combat Aircraft) has been released. The aircraft is still in alpha stage and fairly incomplete (there are some changes to the model planned, so no texturing yet, no cockpit instruments), but it already has many advanced and sometimes unique features, most notably the disintegration animations.
Some of the most important features include:

  • Unique model disintegration animation (video on the right, see details here: http://forum.flightgear.org/viewtopic.php?f=4&t=23681)
  • Cannons with realistic fire rate and tracers once every few rounds, visible/audible over MP (hit transmission is a work in progress)
  • Fully automated fuel system with automatic source switching and fuel level balancing
  • Carefully tuned lights including Rembrandt support, light intensity and flares fading in daylight. You may need to increase the Lights shader setting in order to see all effects with Rembrandt on.
  • Most payload options modeled, including optional experimental fixed fuel probe
  • I consider the FDM (YASim) almost complete and generally well tuned, handling changes a lot with heavy payload

Download available from the FGUK hangar:
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca

L-159 ALCA


Multiplayer Events

FGUK Mach Loop Challenge

Saturday 9th August 2014 - Llanbedr Airfield (EGOD) - 1900 G/U/Z

A trip around the loop with the Vulcan B2

FGUK will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. The world-famous low flying route in North Wales, on the doorstep of FGUK's Llanbedr headquarters, is a 26 mile course threading the valleys and hills around Machynlleth. Can you consistently lower your time and beat the other pilots around the course without breaking the sound barrier and startling the sheep?

A custom AI scenario displays the route with fly-through pointers, checks for adherence to the rules, and announces and records your time - just hand in your score file, and you will be included in the results when published in the following week. More information and updates in the weeks either side of the 9th on FGUK's Facebook page and Twitter account. As always at the Mach Loop, there will be photography and video and the event will be streamed live on our YouTube channel.

Recommended choices to fly the loop competitively are Supersonic single and twin seaters, but you can bring anything within reason that doesn't make you a danger to others. Assemble at FGUK Llanbedr (EGOD) at 1900 G/U/Z (8pm BST). If you're planning to bring something unusual, we ask you to notify us in the forum to make sure all the models are visible to the camera.

A full briefing for pilots will be published on Sunday, along with the definitive AI scenario for the competition. Check the ongoing event article and the forum thread to keep up to date.