FlightGear Newsletter June 2014

< Previous editionNext edition >

Enjoy reading the latest edition!

Please help us write the coming edition!

June 2014

Development news FlightGear 3.2 - Feature Freeze Canvas GUI: Layouting, Widgets and MessageBoxes Preview: Aircraft Center - get it on the fly Canvas/MapStructure Updates Boeing 777 EFB prototype Towards an Aircraft-agnostic MFD Framework Mapping polar and date line crossing routes Logo proposal

Addons and mods Damage and disintegration Scenesetter In the hangar Beechcraft Bonanza Saab JA-37 Viggen Updated P-51D now in git Balancing the Boeing 747-400 Extra500 is updated to production status

Scenery corner USA state capital buildings LIPY, a scenery conversion from MSFS Reshaping Leipzig/Halle Airport Wiki updates An updated Weather article

Development news

FlightGear 3.2 - Feature Freeze

By TorstenD

On June 17, we entered our scheduled feature freeze state for the next release. Please use the remaining weeks to improve the existing features, harden and cleanup the code, edit the ChangeLog, improve the Manual, document the undocumented etc. etc. The release branches will be created on July 17th to have the release ready by Aug. 17th. See our release plan for detals about the release process.

Canvas GUI: Layouting, Widgets and MessageBoxes

By TheTom

Widgets and Layouting

Screen shot showing a simple Canvas GUI dialog with a handful of Button Widgets.

Thanks to the recent work of Tom, the Canvas system now supports basic widgets and layouting, similar to the Qt Layouting System. Using vertical and horizontal box layouts widgets can be placed and sized automatically within the available space. Together with standard widgets like buttons, checkboxes, labels and scroll areas, this is a large step forward in creating a modern, new GUI for FlightGear.

For an example on how to use the new system see Howto:Creating a Canvas GUI dialog file.

MessageBoxes

Based on the new widgets and layouts, Message Boxes provide a simple way to report information to the user or ask him simple questions with a standardized appearance. Selecting from a predefined set of icons and buttons showing a message can be as simple as:

canvas.MessageBox.information("Success", "The operation has successfully completed.");

Get more information on how to create Message Boxes on your own...

• 

  Reporting information

• 

  Showing a warning (allowing the user to not get it reported the next time)

Preview: Aircraft Center - get it on the fly

By TheTom and Zakalawe

Canvas dialog showing the prototype for an Aircraft Center for directly installing/managing aircraft from within FlightGear, an upcoming feature scheduled for FlightGear 3.2, currently being developed by TheTom and Zakalawe

The "built-in" GUI/launcher is one of the longest-standing feature requests - but it's not just about the GUI (which is rather straightforward in comparison), but about the simulator never having been developed with this requirement, i.e. run-time reinitialization, in mind - thus, things like "fgrun" (and a plethora of other external launchers) were developed, which acted as a front-end on top of FG, so that FG itself wouldn't need to be changed - i.e. kind of a "remote control" using command line arguments. So it's there for a reason - fgrun uses the FLTK GUI library, which while relatively simple, is much more powerful than our legacy GUI engine, PUI.

Still, people have been asking for this for years, and it's thanks to pretty much a single person, Zakalawe, that switching aircraft is going to become possible pretty soon - he handled all the ugly work of cleaning up the simulator internals to make this happen - it's not exactly glamorous work, you gotta touch a ton of places, and you inevitably introduce a ton of regressions along the way.

And yes, even the legacy FG GUI is entirely based on XML and configurable through just editiing XML files - but the collection of "widgets" (GUI controls like buttons, checkboxes, labels etc) is extremely small and very inflexible.

This is something that is currently being addressed by TheTom and Zakalawe, who've both been working on a new Canvas GUI, and a new Canvas GUI dialog called "Aircraft Center", which -while still experimental- is intended to eventually allow end-users to easily download/install aircraft right within the simulator, and also switch between aircraft at run-time without having to exit/restart the simulator.

Thus, adopting Canvas is going to address a number of long-standing issues, but it's obviously a process that only just got started, and it will not happen overnight - 2-3 release cycles are not far-fetched, that's how long the whole migration could very well take, unless there are more people interested in helping.

Canvas/MapStructure Updates

By Hooray and Philosopher

The upcoming FlightGear version (3.2) will contain a canvas-based map dialog, including a modular "plugin" system for creating custom map layers and charts with roughly ~50 lines of code, most of it boilerplate. This is entirely XML/Nasal based (scripted) - symbols can be pretty much anything, raster or vector images (png or svg), but even animated. Styling can be customized, too.

For more info, I suggest to check out: MapStructure#Porting the map dialog

• 

  You can basically create arbitrary layers, even for custom objects/positions

• 

  The same method can be used for creating a "live" radar display

• 
• 

  But maps and layers can be fairly sophisticated, too - all 100% scripted

As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments

Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure article.

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.

The recent GUI work committed by TheTom means that we can phase out the PUI map-canvas.xml dialog and create the whole dialog procedurally using a native canvas window, because we really only need two types of widgets: buttons and checkboxes, which are both supported now, thanks to the new Aircraft Center.

We're also in the process of turning our map-canvas.xml dialog into a generic, and reusable, widget for $FG_ROOT/Nasal/canvas/gui/widgets - the widget is using the new Layout engine to align other widgets (checkboxes & buttons for now). And one of our goals is to also modernize airports.xml (the airport selection dialog) such that it can use MapStructure. The simplest way would be to simply turn the PUI CanvasWidget into a Canvas.Window() so that layouting etc works as expected, and so that we can simply show the new scripted MapWidget there.

• 

  stress-testing MapStructure using the ufo @ KSFO circling at 2000 kts in a climb, see [1]

• 

  Native Canvas MapWidget dialog using just Canvas Widgets, the Map has been turned into a Canvas Widget itself, so that it can be easily embedded in other dialogs (obviously the whole thing still needs to be cleaned up, layouting isn't currently used yet). See [2]

• 

  More Canvas/MapWidget prototyping. See [3]

• 

  Screen shot showing TheTom's modified demo dialog with a MapStructure based map that has clipping and event handling applied, i.e. can respond to common mouse events in order to either display tooltips or support drag&drop-style GUI dialogs for editing map-like displays, e.g. for creating an Advanced weather GUI[4]. Particular care must be taken to formalize z-index handling (rendering priority) for each MapStructure layer, which is something we still need to work out, especially for possibly overlapping symbols...

• 

  This screen shot shows an experimental MapStructure-based Weather Editor Widget for Canvas using interactive and editable lcontroller files that respond to GUI events so that map symbols can be interactively placed on a map.

• 

  This is a screen shot showing Stuart's PUI/XML based airport selection dialog with an embedded Canvas MapWidget that is driven by Philosopher's MapStructure framework using TheTom's latest GUI/Layouting changes (e.g. checkbox widgets).

Boeing 777 EFB prototype

By I-NEMO

777-200ER EFB [5]

777-200 EFB AIRPORT SEARCH, see [6]

I-NEMO has started porting his 777/EFB prototype to Canvas

As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind:

1. do something to compensate for the lacking of an EFB inside the Boeing 777 Seattle.
2. actually try (I repeat it: 'try') to learn some first essentials of nasal.

This Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be. My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit. 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... Current development ('modernisation' phase) of the Boeing 777 Seattle's EFB is going on nicely; the code is shorter, more readable and cleaner. I have not finished it, yet (I'd say that it's almost 50% done).

At the moment I have a single Canvas group (i.e., EFB_group), with 5 children: the text-matrix (16 left lines, 16 right lines), a Title line , an Helper line and the Display. The Display element is then textured with all the various pages' textures, called by the page-handler (see here below). Currently, I'm using the .jpg textures which I had previously generated through Photoshop; in the future they might be replaced by .svg files, depending from actual interactive use of some graphical objects (a few EFB pages do need interaction with graphical parts). Besides - if i'm not wrong - I've read somewhere on the FGWiki that gradients are not handled by the SVG parser...and I do like to use some gradients effects (antialiasing and such) to achieve a sort of realism on the displays.

that's the current status of the new 777 Seattle's EFB: it's still far from being perfect, but - as a newbie - I'm quite satisfied for the moment: I need to finish the first version fairly soon, because my to-do-list is long (I have to re-model all the aircraft fuselage [original model has wrong measures, sigh!], produce better gears and flight-control surfaces model & animations in Blender, and then to produce a new Paint-Kit in Photoshop; then all 3D models optimizations...and so forth; of course, we also have to take care of CDU, which will interface with the EFB. So, the job is still very, very long...

The current EFB code is heavily focused on rendering raster images, which can be retained obviously, but in FG, we have additional means to render airport information that is 100% in sync with the FG side of things (navdb).

Airport selection dialog

For instance, we are going to "port" the airport selection dialog to move rendering of airports/runways/taxiways/parking spots into dedicated MapStructure layers that can be properly styled and customized: Canvas MapStructure#Porting the airports.xml dialog. As you can probably tell, these kinds of layers would be very useful for any kind of EFB related application.

As long as the underlying design for a "page"-based MFD framework is sufficiently generic, we can easily replace/augment raster images and procedurally created charts - we could even use the built-in support for fetching via HTTP to download images on-line. In fact, we could then even extend Canvas to directly support rendering PDFs (OSG supports this out-of-the-box), this would make many steps unnecessary, because we could directly access http://airnav.com without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison.

Learn more at Canvas EFB Framework or follow the forum discussion...

Towards an Aircraft-agnostic MFD Framework

By Hooray

Given the recent trend of having several MFD-related efforts without any kind of collaboration/code reuse going on here among our contributors (PFD, ND, Avidyne Entegra R9, EFB), I have started prototyping a generic MFD framework that is purely XML-based, inspired by discussions we've had over the last couple of weeks, and lessons learnt from the missions subsystem.

It is intended to:

• support multiple independent instances
• be totally aircraft agnostic
• support a pure dialog-driven mode
• support skinning/theming

This is supposed to support modelling complex avionics like a PFD, ND, EFB, CDU etc - and, eventually, also the Avidyne Entegra R9. It's currently just a prototype, but it gets away with very little code and we really only need a few more "skins" for common avionics. I am willing to extend this over time and help maintain it if people can agree to use something like this. It should be straightforward to allow such "MFDs" to be reloaded from disk at run-time, i.e. for more rapid prototyping.

Note  This is work in progress - the idea is to identify required building blocks to easily specify most MFD functionality in a generic fashion, without requiring a ton of custom Nasal code and without being specific to a single type of MFD. The whole concept is based on FlightGear Missions and Adventures#XML Extension Framework, i.e. providing a Nasal-space mechanism to expose and re-define building blocks to XML space. The Nasal/Canvas data structures will be transparently created and compiled for each MFD. Each MFD consists of an arbitrary number of buttons, modes and pages. Each MFD can be instantiated multiple times, and each MFD is designed to be aircraft/instrument agnostic, i.e. also works just in a conventional Canvas dialog. Buttons can trigger and switch between modes, and modes may have pages (conventionally implemented through a single SVG file). Each page consists of an arbitrary number of page elements, which can in turn be animated/updated via listeners and timers. Should look at existing displays, especially the NavDisplay and the update() method in navdisplay.mfd, but the most complete test-case would probably be the Avidyne Entegra R9

• 

  F-JJTH has updated the SVG file implementing the panel page for the Garmin GPSMap 196.

• 

  This is an adapted version of the Garmin GPSMap 196 that is currently being developed by F-JJTH. Here, the whole instrument is entirely set up in XML space, including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, NavDisplay or EFB. For details, please see Canvas Glass Cockpit Efforts.

• Error creating thumbnail: File missing

  This demonstrates how a purely XML-based MFD framework can instantiate dynamic MapStructure layers - none of this involves any Nasal coding now, it's just an XML file - to learn more, see Canvas Glass Cockpit Efforts.

• 

  This screen shot shows the texture of the hard-coded KLN89 instrument used as a skin/theme for the MFD instrument, with a MapStructure-powered map shown.

Mapping polar and date line crossing routes

By Gijs

The map dialog used to fail plotting routes near the poles, as well as routes crossing the International Date Line. The Sanson–Flamsteed projection that we used simply could not cope with such extreme latitudes and longitudes. By changing the map to an Azimuthal equidistant projection all points on the map are at proportionately correct distances from the center point at the correct azimuth (direction) from the center point. Ideal for navigating to your next way point!

• 

  Route over the north pole

• 

  Route crossing the International Date Line

Logo proposal

By Aepcam

This is a new logo badge concept proposal for FlightGear designed by Michat.

FlightGear addons and mods

Damage and disintegration

By Algernon

Tomaskom's V-1 used in anger over London

Victor V2.0 damage script causing a catastrophic failure and fire

L-159 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, bird strikes 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 probabilities 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

By Algernon

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

Beechcraft Bonanza

By Flyingfisch

Flyingfisch is building the Beechcraft A35 Bonanza for Flightgear. Some pictures:

• 

  Panel lighting

• 

  Remember to do your pre-flight check before startup!

• 

  The Beech Bonanza at Kent State University (1G3) just before sunrise

• 

  The interior of the Bonanza at sunrise.

Saab JA-37 Viggen

By Necolatis

The Swedish fighter jet Saab JA-37 Viggen has been updated, since it was included in FlightGear 3.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. HUD can now switch to imperial units and show MP and AI aircraft and closest airport. 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.

Updated P-51D now in git

By hvengel

The new 3D exterior model for the North American P-51D Mustang is now in git and under active development. It is currently in gray primer waiting for the UV map to be finalized. It is now fully integrated into the existing FDM. Extensive new animation work has been done including animated trim tabs and a fully functional canopy. Here are some screen shots taken in sim for your enjoyment.

• 

  P-51D testing it's guns before a flight.

• 

  P-51D trim tab animation.

Balancing the Boeing 747-400

By Gijs

After he started developing the Boeing 747-400 as a hobby project six years ago, Gijs finally managed to get the weight and balancing right. The center of gravity is now within 0.05% MAC (40 cm) of the published values.

Make sure to use the new Fuel and Payload dialog to fill your fuel tanks. There is a slider and button that will nicely distribute a specified amount of fuel, while making sure the CoG stays within the operational limits. Before takeoff, check the Takeoff Reference page on the CDU to find the required stab trim units (your current setting is displayed to the left of the throttle quadrant). When you set your trim properly, you can almost relax your yoke to the neutral position after rotate. There's still some FDM work left to fine-tune this.

The updated 747-400 is already available through Git and will be on the download page when FlightGear 3.2 is released.

Extra500 is updated to production status

By Evandenberg

The Extra EA-500 is updated and has reached "production status"! Just a short list of changes for release 1.1.0:

• Engine+fuel: realistic flame-out, fuel flow to collector compartment, anti ice influence on TOT, improved oil press and temp model
  
• Aerodynamics: flap performance, elevator-30deg-flaps authority improvement
  
• User interface: interactive checklists
  
• Sounds: corrected sounds for test, CWS and AP disc
  
• Model: added interior, yokes
  
• Avionics: IFD moving map, automatic NAV tuning, automatic NAV switching, magnetic variation fixes
  
• Autopilot: added OBS and fly vectors mode, significant improvement of coupled ILS performance

A more extensive list can be found in the "version" file.

This version does perform a bit better on my computer, but this has to do with improvements to FGFS, not of the aircraft model. So if your computer was struggling with the initial version, we recommend to use current FlightGear git/nightly builds or wait until 3.2 comes out!

Please checkout the Extra500 wiki for download instructions and lots of more info.

• 

  Extra500 flying in clouds

• 

  Work has begun to analyze, refactor and generalize useful parts of the Avidyne Entegra R9 to help reuse some code in similar MFD efforts, like the Garmin GPSMap 196 or Canvas EFB Framework

Scenery corner

USA state capital buildings

By Jonbourg

There is a project to add all the USA state capital buildings into FG. It is discussed in this scenery forum thread. There is also a wiki page: State Capitol Buildings in the United States. So far, Idaho, Louisiana & Nebraska have been completed. Hawaii and New York are currently in progress. Please feel free to join in with any other state that has not been done yet. Just let us know through the forum and we will add it to the in progress list.

LIPY, a scenery conversion from MSFS

By bigstones

This month saw the second "preview" release of the conversion of a scenery for MS Flight Simulator, Falconara Airport (ICAO code: LIPY), a small Italian international airport halfway down the Adriatic coast. The original author granted the permission to the conversion and even allowed for it to be included in the FlightGear official World Scenery, at least the GPL compatible parts. This is not a huge limitation though, because most of the material was created from scratch, included pictures taken on purpose at the real airport, with the authorities' collaboration. Copyrighted aerial imagery only include the (unsuable) photoreal ground and some roofs.

The conversion was made with ModelConverterX, which makes the job partially easier than by the Blender method, yet it's still needing fixes because of some misunderstandings with the coordinates axes. The author of the tool, though, seems not very concerned and anyway, it's so rare to have a freeware scenery author allow conversions, that the usefulness of this tool would be greatly reduced anyhow, especially if you plan to upload the models to the FlightGear Scenery Database.

The conversion itself, moreover, sure is not the matter of a button press. MSFS scenery are often packed and "compiled" in *.BGL files such that independent, far objects with the same materials and same LOD level (Level Of Detail) are bound together. This is clearly against FG's way, in which each new scenery generation could change the relative heights, and however MSFS airports are flat, while in FG they're all sloped. A similar thing happens with the texture maps. This basically means that you'll have to join all these objects and split them again based on the model they belong to (e.g. tower, terminal, hangars...)

Another issue with textures is that in FG it's good practice - recommended if not mandatory - to have 2 separate texture maps for the same object, if some parts are translucent. This means that without rebuilding all the texture maps you'll likely get artifacts. Then, you'd have to add the Rembrandt lights if you want, and also the lightmaps (MSFS uses night textures, but Gimp can easily convert them). This whole experience can be summed up in the following quote:

I really wanted to have this scenery in FG because it's my home base, and seeing it ready and so well done just made me want it. However, even if still easier than making it from scratch (even if reusing the textures), I'd have to think well if I had to do this again. — bigstones, maintainer of the conversion

Reshaping Leipzig/Halle Airport

By August

In FlightGear Germany's second largest cargo airport EDDP is well known as a detailed model accessible for everybody via TerraSync. Until 2013 it was famous for its regular ATC-events. It has been updated several times, at least 2012 by users D-STHO and August. When FlightGear 3.0 was published the airport layout changed from the old 810-standard to the new 850-standard. But the update (based on a taxiway layout modelled for X-Plane) turned out to be very imperfect. Many aprons and taxiways did not exist, dimensions did not appear to be correct and many new facilities which had been added at the real-world airport had not been taken into account. So maintainer August decided to redesign the whole airport from the scratch using WorldEditor. Pilots and developers are now invited to test the new airport model which includes further improvements like predefined STAR-, -SID and Transition procedures and hundreds of replaced Static- and Shared Models. The project will be published on TerraSync as soon as all defects are discovered remedied.

Developer Version:

git clone https://gitorious.org/eddp-custom-scenery/eddp-custom-scenery.git

Feedback is welcome at August's wiki page.

• 

  Taxiway T - new ground textures

• 

  Runway 26L with DHL-area

• 

  Apron 4

Wiki updates

An updated Weather article

By bigstones

The Weather wiki article went through a wide extension. Although Advanced Weather was released quite a while ago, its usage has never been explained in the wiki, and some thorough instructions were available only in a readme in the "docs" folder of the base package which is not commonly explored by users, while the wiki article Advanced weather is more about the project than the usage.

AW's advanced configuration is known to be not easy. So, if you always only used the weather selection menu and want to know more, or want to understand what the options actually do and how you can combine them, the Weather article has now been updated with some hints and basic notions extracted from experience and the original documentation, and quality checked by the author of the AW weather engine.

Translators required

	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.

And finally...

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 TerraGear roadmap.

References