FlightGear Newsletter July 2014

From FlightGear wiki
Revision as of 14:38, 28 July 2014 by Tomaskom (talk | contribs) (Added link to the Nasal syntax highlighting wiki page under the Notepad++ section)
Jump to navigation Jump to search

Template:Newsletter being written

5 years of newsletters


The newsletter started in July 2009. (more to write here, just so we don't forget about it)

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

Possible things to write about could be:
- New planes that are released.
- New scenery projects (like a new/redrawed airport, things like the corse scenery etc.).
- New FG releases (this is not very often, but it should be in the letter if so).
- New forum features/subforums and other news from the forum.
- News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse)
- Events that will be held within a short periode or (links to) screenshots of the latest event(s).
- The first 3 or 5 pictures of a screenshot contest.

If you got other idea's, post in this topic so we could extend the list.
I don't really know what's best way to provide the letter. But we have some options:
- a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me).
- emails send to all forum-users (I don't really like this myself).
- a .pdf file with a link on the main page of http://www.flightgear.org
- or even something else

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.

— Gijs (Mon May 26). Newsletter.
(powered by Instant-Cquotes)
Cquote1.png 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.

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.

— Gijs (Mon May 26). Re: Newsletter.
(powered by Instant-Cquotes)
Cquote1.png 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?

But if you are willing to get a newsletter rolling, that would be awsome.

— curt (Tue May 27). Re: Newsletter.
(powered by Instant-Cquotes)
Cquote1.png 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)

— MaverickAlex (Thu May 29). Re: Newsletter.
(powered by Instant-Cquotes)
Cquote1.png Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
— Gijs (Thu Aug 21). Re: Newsletter.
(powered by Instant-Cquotes)
Cquote1.png 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?

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.

— Hooray (Fri Oct 03). Re: Newsletter.
(powered by Instant-Cquotes)

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

Cquote1.png 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).

(see the linked image)

— Gijs (Mon Jul 07). Re: osgText backdrop.
(powered by Instant-Cquotes)
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);

commit 838cabd2a551834cbcac2b3edd21500409ff2e98
Author: Gijs de Rooy
Date:   Mon Jul 7 18:27:50 2014 +0200

    Canvas: add backdrop option to text

diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
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

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.


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

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). Re: FSWeekend 2010.
(powered by Instant-Cquotes)
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...

— Hooray (Sun Jul 06). FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
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:

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). FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
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). FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
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). Re: FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)


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

Scenery corner

Paro Int. Airport - VQPR

domestic flight from Bumthang to Paro

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++.
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 Fligthgear. There are currently 4 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/

In the hangar: Mainair Flash 2 Alpha

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

Flash2a in Air2.png