FlightGear Newsletter June 2014
- 1 Development news
- 1.1 Logo Proposal
- 1.2 MapStructure stress-testing
- 1.3 777 EFB Prototype by I-NEMO
- 1.4 Canvas Garmin GPSMap196 Updates
- 1.5 Avidyne Entegra R9
- 1.6 Towards an Aircraft-agnostic MFD Framework
- 1.7 Canvas System
- 1.8 Missions & Adventures
- 1.9 High Level Architecture
- 1.10 Usability Improvements
- 1.11 Getting your own ideas and features in FlightGear without having to be a coder
- 1.12 Getting involved as a programmer
- 2 Done
- 3 Work in Progress
- 4 Autopilot/Property Rules
- 5 props.nas
- 6 Candidates
- 7 Release ChangeLog
- 8 Interview with a contributor (NAME)
- 9 Nasal for newbies
- 10 New software tools and projects
- 11 FlightGear addons and mods
- 12 In the hangar
- 13 Scenery corner
- 14 Aircraft of the month
- 15 Airport of the month
- 16 Screenshot of the month
- 17 Suggested flights
- 18 Aircraft reviews
- 19 Wiki updates
- 20 Community news
- 21 Useful links
- 22 And finally ...
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: Next Changelog.
This is the new logo badge concept proposal for FlightGear designed by Michat.
|Now that Hyde has committed Philosopher's latest changes, I'd be interested in getting some more feedback on performance.
Here, I am using the ufo @ksfo circling in a shuttle climb at >= 2000 kts GS and getting roughly 30 fps and 40-60 ms.
— Hooray (Tue Jun 03). Re: NavDisplay & MapStructure discussion (previously via PM).
777 EFB Prototype by I-NEMO
I-NEMO has started porting his 777/EFB prototype to Canvas
|I do not pretend that current 777's EFB.nas is a piece of nice software; but - to my initial purpose - it works. Not completely, not nicely, not properly...but it's a starting point. At least, it works...
Learn more at Canvas EFB Framework ...
Canvas Garmin GPSMap196 Updates
Avidyne Entegra R9
Towards an Aircraft-agnostic MFD Framework
Missions & Adventures
| The FlightGear forum has a
subforum related to: Tutorials, Missions & Adventures
High Level Architecture
Getting your own ideas and features in FlightGear without having to be a coder
We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback. Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless. We've had some extremely heated discussions over the years, some debating interesting ideas - and many ending up being dozens of pages in size, containing hundreds of postings. Often, these contain lots of good ideas and suggestions, but sooner or later these suggestions become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form. We are now trying to document how "bootstrapping" a feature or project works conceptually, i.e. implementing new features for Flightgear - to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own. Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which we didn't come up with, but which is just a convention that happens to "just work", which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens".
Continue reading at Implementing new features for FlightGear...
Getting involved as a programmer
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.
If you are interested in contributing as a core developer, please see Howto:Start core development.
If you interested in other developing, i.e. not C++ but Nasal scripting and/or XML, there are some articles listed at Category:Popular Community Requests that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from you -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at Nasal, so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.
FlightGear's built-in Nasal scripting language comes with a set of standard libraries, and can be extended using FlightGear specific APIs.
Exposing simulator internals to scripting space is a fairly common and useful thing, because it enables base package developers to access these internals without having to build FlightGear from source, so the barrier to entry is significantly lower and we've seen an increasing number of novel features purely implemented in scripting space, due to powerful APIs being available to aircraft developers and other base package developers.
Until FlightGear 2.8, the Nasal scripting engine only provided a C API to expose such hooks/bindings to scripting space or to expose scripting space data structures back to C/C++.
Unlike the core Nasal engine itself (which is C), FlightGear however is mostly written and being developed in C++. For quite a while, that meant that the Nasal APIs were a bit low-level, and sometimes also awkward to use when making functions, data structures or objects accessible between C++ and Nasal.
Thanks to development on Tom's Canvas system, there's now a new bindings framework to be found in $SG_SRC/simgear/nasal/cppbind. This is fully object oriented and supports modern C++ features by operating through classes and methods with full STL support, abstracting most common operations away.
After working through the Nasal/CppBind article, some of the more useful things to play with in the beginning, would be exposing additional SG/FG classes to Nasal space, such as for example:
- SGPath Done (by TheTom)
- SGCondition Done (by TheTom) flightgear/flightgear/1b55ab5f4032c6f3f1a4d07c0b9babd3744f1c37 commit view
Work in Progress
|This and using maketimer instead of settimer should reduce the number of leaked resources a lot, because you would not be able to accidentally leak listeners/timers anymore.
— Thomas Geymayer (2014-11-22). [Flightgear-devel] RFC: Nasal ghosts and garbage collection.
(powered by Instant-Cquotes)
|Note This is a summary of all discussions about exposing the autopilot/property-rule system (there are certain Nasal GC issues, so that we ask people not to implement FDM-coupled Nasal code like autopilots): this would be the best way to decrease the amount of Canvas-related Nasal code, i.e. by using property-rules for animation purposes, as per Torsten's RBAR EFIS and TheTom's system-modeling plans.|
|I would prefer to do this in an XML filter in the generic autopilot helpers - definitely not in Nasal. It can be done in C++ if strictly required but then we need way to disable it for people who want different filtering.
— James Turner (2015-04-03). Re: [Flightgear-devel] Route manager: waypoint smoothing.
(powered by Instant-Cquotes)
|I vote for #3: avoid *any* Nasal in the fast simulation [FDM] loop. Nasal execution is slow and non-deterministic. Running it in the fast simulation loop is the last thing we want.
|Concerning your original issue on implementing an autopilot: a much better way to do it is to avoid Nasal for the actual autopilot controller elements (numeric computation). Instead, use XML "autopilot" rules for the filter, gain, damper, integrator elements: http://wiki.flightgear.org/Autopilot_Configuration_Reference
You can then use Nasal for the high level stuff, and enable/disable/switch the individual controller elements (e.g. in order to automatically switch the autopilot mode when capturing the ILS).
|I agree with your main point that xml-configured hard-coded filters are the right way to implement and autopilot, and I also agree that in general low-level multi-purpose workhorse code should be C++ whereas Nasal is more suitable for the numerically cheap high-level specific functions.
— Renk Thorsten (2012-08-30). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes)
|I'd strongly agree with Thorsten here. It's nothing against Nasal from me - I've not even used it - but creating an autopilot (or any GNC or system model, for that matter) can be done very effectively with discrete objects such as summers, gains, controllers, filters, switches, etc., much as JSBSim has done with the system components. This is a standard approach in industry as Thorsten mentions as exemplified by Mathwork's $imulink product.
Scilab/Scicos is similar in concept. Control system topologies are often diagrammed in a way that can lead to a one-to-one correspondence between a block and a control system object that can be referenced in an XML file, if the control system component library has been defined properly. This, again, is the way that JSBSim has approached the solution. Some benefits to such an approach include (IMHO) better testability, more predictability, and easier interface (someday) with a GUI tool, should one materialize. The downside is that XML can be verbose, but it's a price I've come to accept.
— Jon S. Berndt (2012-08-30). Re: [Flightgear-devel] Running Nasal at simulation rate.
(powered by Instant-Cquotes)
|I have recently committed some code to allow runtime loading of property rules and have a Nasal binding for that in mind.
|The more I think about it, the more I am leaning towards unifying the different system modeling blocks in the C++ core under a generic interface that is exposed (or linked in some way) to Nasal. Think the PID controller, the different filters, flip-flops, etc. They are not substantially different to the basic bricks I am writing...The basic idea would be to detach those blocks from their specific application (autopilot, for example) and refactor them into an independent library with bindings in Nasal and a similar interface to what I have been showing so far. The end result would be quite simulinkish in flavour. It is already starting to smell a bit to that actually... :D
An architecture like that would eventually enable three possible approaches to system modeling: low level C++, static xml driving C++ underneath and fully scripted Nasal.
— galvedro (Tue Nov 05). Re: A general approach to systems modeling in Nasal.
(powered by Instant-Cquotes)
|Regarding things like the PID controller code, its developer/maintainer (Torsten) was actually planning on making this stuff accessible from Nasal, just to prevent scripters from implementing APs in Nasal (due to garbage collection issues) - so that should be a no-brainer actually, and such work should be appreciated
— Hooray (Tue Nov 05). Re: A general approach to systems modeling in Nasal.
(powered by Instant-Cquotes)
|there's an extremely powerful and flexible autopilot system in FG that is entirely XML configurable: Autopilot
There's also a very powerful route manager. Please note however, that there's currently no support for AI traffic to directly make use of the autopilot system or the route manager, so you need to come up with your own infrastructure in scripting space.
|Note however that scripted AI traffic cannot currently make use of any hard-coded FDMs/AP/RM functionality (JSBSim/YaSim), instead you need to come up with your own "pseudo systems" in scripting space unfortunately.
|The AI traffic system has its own "route manager" system which is currently not yet compatible with the rest of FG unfortunately. But there are plans in place to fix this eventually:
|At the moment, Durk has already implemented his own "custom" AI FDM logic, exactly like David predicted a decade ago
|You can probably find 50+ postings by long term contributors suggesting that AI traffic with FDM support would be a good idea: An_Integrated_AI_Traffic_System#FDM_driven_AI_Traffic
| if you wanted to equip your AI traffic with a working route manager, autopilot or even FDM, you would also need to instantiate these subsystems dynamically
|ne thing I thing I want to achieve with this changes is to make the Nasal props API more similar to its C++ counterpart as this makes it easier to use if you are using both the C++ and the Nasal API. Also someday I want to refactor nasal-props.cpp to use cppbind, where I want to export as much methods as possible with exactly the same signature than in C++. Especially if using properties seldom (eg. only for initialiation) the relative versions are probably even faster, as the Nasal overhead is lower. Eg. consider the following Nasal code used to initialize some module: var cfg = props.globals.getNode("/my/config/root", 1); var x = cfg.getDoubleValue("x"); var do_it = cfg.getBoolValue("do_it"); Using getprop on the one hand does not allow getting a property converted to a given type and on the other hand is tedious to use for more than one property, as one has to assemble the according property paths (which is definitely less efficient than using a relative method).
— Thomas Geymayer (Apr 14th, 2013). Re: [Flightgear-devel] Nasal props API relative path support.
(powered by Instant-Cquotes)
- environmental sounds
- simgear::PropertyBasedElement (background/motivation)
- for better diagnostics, and better end-user bug reports, we could consider exposing a cross-platform process and system utilities module via Nasal/CppBind, such as e.g. SIGAR (Windows, MacOS & BSD/Unix) Not done
- Airways/Airspace boundaries don't seem to be exposed via NasalPositioned currently? 
- FGProtocol, to implement I/O protocols via Nasal (and help solve ticket #396 and support AJAX, REST, JSON or WebSockets) (stubs available at gitorious/fg/hoorays-flightgear/topics/cppbind-fgprotocol).
- the loglist/SG_LOG() logging buffer machinery
- expose VoiceSynthesizer/FLITE TTS to Nasal to get rid of ATC chatter  Not done
- the SGSubsystem interface to register scripted SGSubsystems
- flight path history Done (by TheTom)
- the flight recorder system (replay buffers) Not done
- State machines e.g. to help clean up the ND code 
- exposing the sound manager, so that scripts can directly play audio files 
- exposing the random buildings system Pending  
- There's also a pending feature request (ticket #619) to implement USB-HID support .
- ESRI shapelib?
|When we have vector road data at runtime, we can do the following:
— James Turner (2014-11-21). Re: [Flightgear-devel] Future city terrain strategy.
(powered by Instant-Cquotes)
- effects framework ?
- Howto:Using OpenCL in FlightGear
- Nasal/HLA bindings, so that we can run certain scripts as HLA federates outside the fgfs process space (such as bombable or local weather)
|Specifically, there are some C++ data structures that still need to be exposed to Nasal via cppbind so that we can implement features available in the Map dialog and the hard-coded ND
| Note Before working on anything related, please do get in touch with other contributors to ensure that this list is still up-to-date.
For more technical Nasal questions (C API, internals etc), you'll probably want to refer to Philosopher, TheTom, Zakalawe or Hooray on the forum - TheTom and Zakalawe can also provide help on using cppbind, having both used it extensively during the last months.
Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.
Interview with a contributor (NAME)
In each edition we have an interview with a contributor. Suggestions for possible questions are available on interview questions, you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the list of interview volunteers! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.
- How long have you been involved in FlightGear?
- What are your major interests in FlightGear?
- What project are you working on right now?
- What do you plan on doing in the future?
- Are you happy with the way the FlightGear project is going?
- What do you enjoy most about developing for FlightGear?
- Are there any "hidden features" you have worked on in FlightGear that new users may miss?
- What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?
More questions are being collected here: Interview questions.
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX
Nasal for newbies
New software tools and projects
FlightGear addons and mods
Damage and disintegration
The development team at FGUK have been experimenting with modelling aircraft damage in a number of different ways. First of all, Tomaskom has used the particle system carefully to produce visually impressive fireballs and smoke columns with very little FPS impact. First seen in his V-1, we hope to adapt this to simulate realistic fireballs for ground impacts (where appropriate). For the moment, it explodes with the full force of a V-1's explosive payload. On the right is a video excerpt from the #FlightNight which Tom organised to debut the V-1, where we all had way too much fun bombing London. As you can see, the smoke is visible from quite a long way away from the impact, and despite two fires burning with huge smoke columns, and over ten multiplayer aircraft within model range, the frame rates are still more than acceptable. StuartC has already integrated the explosion and fireball into several development aircraft, and we expect eventually to combine it with the disintegration code and make the size of the explosion dependent on fuel load etc.
In a separate development, Algernon's work on the Victor V2.0(YASim) now includes modelled damage, a collection of Nasal scripts, some modified from existing FlightGear staples, which detects irregularities such as component failures, birdstrikes and combat weapon damage and adversely affects system performance and reliability accordingly. Unserviceability often follows, using the existing FlightGear failures system, and compatibility will be maintained as the failures system is improved. The damage script also calculates probabilites for chain reaction damage - for instance, an explosion or serious fire in one Victor engine will usually have an effect on the other. In extreme circumstances, an explosion will trigger further explosions and destroy the aircraft. The second video on the right shows a serious induced explosion on the Victor's number one engine at night. Some fine-tuning of the Rembrandt light has been carried out since this video was shot, so apologies for the visible cut-off.
Finally, and most spectacularly, Tomaskom has demonstrated the disintegration capabilities of his L-159, which is under development. Hopefully, he will explain all here before publication date.
Scenesetter is a piece of code by Algernon, very early in development but already quite effective, which can effect changes to the time and weather from an AI scenario synchronously with other MP players. A crude proof of concept was used in the recent FGUK #FlightNight "British Weather", where pilots visited different airfields with various unpleasant flying conditions. Scenesetter pushes METAR strings to the FlightGear weather system based on the location of an associated Navaid, establishing a circular zone of a specified radius around it in which METAR will be changed. Start time can be specified too, either by providing a local start time or a local time offset (useful for Multiplayer use where players will not all start the AI scenario at precisely the same time).
In the hangar
The Swedish fighter jet Saab JA-37 Viggen has been updated, since it was included in FG 3.0.0; More instruments, additional liveries, aerodynamic response to payload and tooltips on instruments. Option for automatic reverse thrust at touchdown, selection of HUD brightness, disabling of structural damage. The aircraft now also has multiplayer sounds and better cockpit view helps seeing the landing strip. Support for FG 2.8 by deleting a small section in an xml file. Also worth mentioning is countless bug-fixes and improvements, e.g. better handling at high altitudes and a bug fix in the lift force formula.
Aircraft of the month
Airport of the month
Screenshot of the month
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at Help:Translate.|
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit Help:Übersetzen an.|
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij Help:Vertalen.|
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en Help:Traducir.|
FlightGear on YouTube
New tutorials and screencasts
And finally ...
Many people think that contributing to the FlightGear project requires writing C++ code or doing 3D modeling and that it takes lots of time, and therefore feel that they cannot contribute directly. Not so. There's a whole variety of ways to make a valuable and satisfying contribution to FlightGear without being a developer.
The Volunteer page is intended to provide a starting point for those wanting to contribute, but who don't know how. Of course, these are just suggestions. So if you have already a specific idea in mind, please do get in touch with the community to ask for feedback, using the mailing lists, or the IRC channel (chat).
Remember that work in non-development areas will be appreciated as much as developer contributions (or more!), because generally more visible to the end user.
If you'd like to learn more about getting your own ideas and features into FlightGear, check out Implementing new features for FlightGear.
If you are contributing to the core simulator, or an aircraft in the master repository, you should be part of the FlightGear-devel mailing list, which is the primary point of contact for all discussions regarding the development of the simulator. You may want to check out also Howto: Understand the FlightGear development process and Howto: Starting core development.
Call for volunteers
- The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at World Scenery 3.0 roadmap.