FlightGear Newsletter July 2014: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (Added: In the hangar section, aircraft are subsections + typo fix)
No edit summary
Line 390: Line 390:
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]
== Multiplayer Events ==
[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. An AI scenario displays the route, checks for adherence to the rules, and announces and records your time - the results will be 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 Twitter account.

Revision as of 19:32, 1 August 2014

Template:Newsletter being written

5 years of newsletters

Fgmagfiveyears.png

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

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


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.

Cquote2.png

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

A Canvas based GNS 530 GPS

Cquote1.png After a long hiatus (3 years!) I felt like doing some flightgear aircraft modeling again. 3 Years ago when I started the panel for my Bo, I couldn't 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 I decided to start with this:


Gns530-prototype-07-2014.png
I know the GNS530 is already kind of outdated as well, but together with its smaller sibling, the GNS430 it's still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces, which I'm not really a fan of.

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


— cbendele (Wed Jul 23). Garmin gns530.
(powered by Instant-Cquotes)
Cquote2.png

Nasal: Making safer base-class calls

There's 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. Upcoming version (FGCamera v1) will have new camera mode: "world-view".

Scenery corner

Paro Int. Airport - VQPR

VQPR PARO AIRPORT.jpg
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/


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, you can read the related thread here:
http://fguk.eu/index.php/forum/development-hangar/4546-external-reactions-forces-in-yasim

Re-implementing the code elsewhere is very easy, most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). There is a thread on the main forum with HOWTO for implementation, see Parachute for YASim (Thrusters & Nasal).
Currently there is a reference implementation in a special version of the V-1 flying bomb:
http://fguk.eu/index.php/hangar/viewdownload/11-other-objects-and-vehicles/400-v-1-flying-bomb
The drone (Firebee) for which the parachute was requested is not yet publicly available.
You can also get an idea of it's stabilization properties from this video:
https://www.dropbox.com/s/81ns5ib5tf3y74t/V-1_Parachute.avi

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

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 will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. An AI scenario displays the route, checks for adherence to the rules, and announces and records your time - the results will be 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.