FlightGear Newsletter July 2014
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)
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.
|
Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
|
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].
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).
|
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
The whole discussion dates back to the early FGPanel days:
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!
|
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:
|
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:
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) |
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".
|
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.
|
A Canvas based GNS 530 GPS
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:
|
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
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/
YASim Nasal & Thruster based 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
In the hangar: Aero L-159 ALCA
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 sometines 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