FlightGear Newsletter July 2014
|
5 years of newsletters |
Scenery corner |
In the hangar |
5 years of newsletters
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
|
Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system:
|
|
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: FGCanvas
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:
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!) 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:
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
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)
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
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
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
Multiplayer Events
FGUK Mach Loop Challenge
Saturday 9th August 2014 - Llanbedr Airfield (EGOD) - 1900 G/U/Z
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.