FlightGear Newsletter June 2014: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
mNo edit summary
(Switch to {{gitorious clone}} to fix the broken Gitorious instructions.)
 
(7 intermediate revisions by 4 users not shown)
Line 8: Line 8:
{{Newsletter-cover-item|Preview: Aircraft Center - get it on the fly}}<br/>
{{Newsletter-cover-item|Preview: Aircraft Center - get it on the fly}}<br/>
{{Newsletter-cover-item|Canvas/MapStructure Updates}}<br/>
{{Newsletter-cover-item|Canvas/MapStructure Updates}}<br/>
{{Newsletter-cover-item|Boeing 777 EFB prototype}}<br/>
{{Newsletter-cover-item|Towards an Aircraft-agnostic MFD Framework}}<br/>
{{Newsletter-cover-item|Mapping polar and date line crossing routes}}<br/>
{{Newsletter-cover-item|Logo proposal}}<br/>
| valign="top" width="33%" |
{{Newsletter-cover-header|Addons and mods}}<br/>
{{Newsletter-cover-header|Addons and mods}}<br/>
{{Newsletter-cover-item|Damage and disintegration}}<br/>
{{Newsletter-cover-item|Damage and disintegration}}<br/>
{{Newsletter-cover-item|Scenesetter}}
{{Newsletter-cover-item|Scenesetter}}<br/><br/>
| valign="top" width="33%" |
{{Newsletter-cover-header|In the hangar}}<br/>
{{Newsletter-cover-header|In the hangar}}<br/>
{{Newsletter-cover-item|Beechcraft Bonanza}}<br/>
{{Newsletter-cover-item|Beechcraft Bonanza}}<br/>
Line 28: Line 33:
</div>
</div>


{{Template:Newsletter-article-start|{{{1|FlightGear 3.2 - Feature Freeze}}}|By [[User:t3r|TorstenD]]|Development news}}
== {{Newsletter-article-start|FlightGear 3.2 - Feature Freeze|By [[User:t3r|TorstenD]]|Development news}} ==
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 [[Next Changelog|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.
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 [[Next Changelog|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.
 
== {{Newsletter-article-start|Canvas GUI: Layouting, Widgets and MessageBoxes|By [[User:TheTom|TheTom]]}} ==
 
=== Widgets and Layouting ===
 
[[File:Canvas GUI Demo Dialog.png|300px|thumb|Screen shot showing a simple [[Canvas GUI]] dialog with a handful of [[Canvas Widgets|Button Widgets]].]]
 
Thanks to the recent work of Tom, the [[Canvas]] system now supports basic widgets and layouting, similar to the Qt [http://qt-project.org/doc/qt-5/layout.html 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, [[Canvas MessageBox|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:


{{Template:Newsletter-article-start|{{{1|Canvas GUI: Layouting, Widgets and MessageBoxes}}}|By [[User:TheTom|TheTom]]}}
Thanks to Tom's and James' recent work on the upcoming [[Aircraft Center]] for downloading and switching between aircraft without having to exit FlightGear, beginning with FlightGear 3.2, FlightGear's [[Canvas]]-based GUI will contain support for so called [[Canvas MessageBox|Message Boxes]]:
{|
|- style="vertical-align:top;"
| [[File:Canvas-MessageBox-demo information.png|link=]] ||
<syntaxhighlight lang="nasal">
<syntaxhighlight lang="nasal">
canvas.MessageBox.information("Success", "The operation has successfully completed.");
canvas.MessageBox.information("Success", "The operation has successfully completed.");
</syntaxhighlight>
</syntaxhighlight>
|- style="vertical-align:top;"
| [[File:Canvas-MessageBox-demo question.png|link=]] ||
<syntaxhighlight lang="nasal">
canvas.MessageBox.question(
  "Do you want it?",
  "The question is: Do you want to get a real question?.",
  func(sel)
  {
    if( sel == canvas.MessageBox.Yes )
      print("I only know that the answer is 42.");
    else
      print("Ok, I will not give you a real question.");
  }
);
</syntaxhighlight>
|- style="vertical-align:top;"
| [[File:Canvas-MessageBox-demo warning dont-show-again.png|link=]] ||
<syntaxhighlight lang="nasal">
canvas.MessageBox.warning(
  "Warning...",
  "Have you read this warning? If you want it will not be shown again.",
  func(sel)
  {
    if( sel != canvas.MessageBox.Ok )
      return;


    print("You have been warned. Let the games begin...");
Get more information on how to [[Canvas MessageBox|create Message Boxes on your own...]]
  },
    canvas.MessageBox.Ok
  | canvas.MessageBox.Cancel
  | canvas.MessageBox.DontShowAgain
);
</syntaxhighlight>
|}


[[File:Canvas GUI Demo Dialog.png|300px|thumb|Screen shot showing a simple [[Canvas GUI]] dialog with a handful of [[Canvas Widgets|Button Widgets]].]]
<gallery mode=packed>
 
Canvas-MessageBox-demo information.png|Reporting information
For an example see [[Howto:Creating a Canvas GUI dialog file]].
Canvas-MessageBox-demo warning dont-show-again.png|Showing a warning (allowing the user to not get it reported the next time)
 
</gallery>
<div style="clear:both;"></div>


{{Template:Newsletter-article-start|{{{1|Preview: Aircraft Center - get it on the fly}}}|By [[User:TheTom|TheTom]] and [[User:Zakalawe|Zakalawe]]}}
== {{Newsletter-article-start|Preview: Aircraft Center - get it on the fly|By [[User:TheTom|TheTom]] and [[User:Zakalawe|Zakalawe]]}} ==


[[File:Aircraft-center-prototype.png|270px|thumb|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]]
[[File:Aircraft-center-prototype.png|270px|thumb|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]]
Line 93: Line 74:
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.
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.


{{Newsletter-article-start|Canvas/MapStructure Updates|By [[User:Hooray|Hooray]] and [[User:Philosopher|Philosopher]]}}
== {{Newsletter-article-start|Canvas/MapStructure Updates|By [[User:Hooray|Hooray]] and [[User:Philosopher|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.
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.
Line 108: Line 89:
As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure article.
As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments<br><br>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]].


[[File:Map-canvas-mapstructure-performance.png|thumb|stress-testing [[MapStructure]] using the ufo @ KSFO circling at 2000 kts in a climb, see [http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=211611#p211611] ]]
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 &amp; 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.


{{cquote
<gallery mode=packed widths="400px">
  |<nowiki>Now that Hyde has committed Philosopher's latest changes, I'd be interested in getting some more feedback on performance.</nowiki><br/><nowiki>
Map-canvas-mapstructure-performance.png|stress-testing [[MapStructure]] using the ufo @ KSFO circling at 2000 kts in a climb, see [http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=211611#p211611]
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.</nowiki>
Native Canvas MapWidget Dialog.png|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 [http://forum.flightgear.org/viewtopic.php?f=71&t=23391&p=213435#p213435]
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211611#p211611
Native Canvas MapWidget Dialog Prototyping.png|More Canvas/MapWidget prototyping. See [http://forum.flightgear.org/viewtopic.php?f=71&t=23391&p=213435#p213435]
    |title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki>
</gallery>
    |author=<nowiki>Hooray</nowiki>
<gallery mode=packed heights="200px" widths="400px">
    |date=<nowiki>Tue Jun 03</nowiki>
MapStructure dialog with clipping and event handling applied.png|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[http://forum.flightgear.org/viewtopic.php?f=71&t=17642]. 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...
  }}
MapStructure-based Weather Editor Widget for Canvas using interactive and editable lcontroller files.png|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.
}}
The legacy PUI-airport selection dialog using the new Canvas MapWidget.png|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).
</gallery>


{{Newsletter-article-start|Boeing 777 EFB prototype|By [[User:I-NEMO|I-NEMO]]}}
== {{Newsletter-article-start|Boeing 777 EFB prototype|By [[User:I-NEMO|I-NEMO]]}} ==
[[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]]
[[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]]
[[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]]
[[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]]
Line 135: Line 121:
I have not finished it, yet (I'd say that it's almost 50% done).
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.<br/>
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.
The ''Display'' element is then textured with all the various pages' textures, called by the page-handler (''see'' here below).<br/>
 
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 &amp; 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).


that's the <u>current status</u> 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 &amp; 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...
[[File:Airport-selection-dialog.png|thumb|250px|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.


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). <br/>
<br/>
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]] <br/>
<br/>
[[File:Airport-selection-dialog.png|250px]]<br/>
<br/>
As you can probably tell, these kinds of layers would be very useful for any  kind of EFB related application.<br/>
<br/>
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 http://airnav.com] without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison.
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 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 [http://forum.flightgear.org/viewtopic.php?f=71&t=23204 forum discussion]...
Learn more at [[Canvas EFB Framework]] or follow the [http://forum.flightgear.org/viewtopic.php?f=71&t=23204 forum discussion]...


{{Newsletter-article-start|Towards an Aircraft-agnostic MFD Framework|By [[User:Hooray|Hooray]]}}
== {{Newsletter-article-start|Towards an Aircraft-agnostic MFD Framework|By [[User:Hooray|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.
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.


Line 162: Line 143:
* support skinning/theming
* support skinning/theming


This is supposed to support modeling 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.
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.
{{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]] }}
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]] }}
Line 175: Line 156:
</gallery>
</gallery>


{{Newsletter-article-start|Logo proposal|By [[User:Aepcam|Aepcam]]}}
== {{Newsletter-article-start|Mapping polar and date line crossing routes|By [[User:Gijs|Gijs]]}} ==
The [[Map|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.<ref>{{Cite web |url=http://en.wikipedia.org/wiki/Azimuthal_equidistant_projection |title=Azimuthal equidistant projection |publisher=Wikipedia}}</ref> Ideal for navigating to your next way point!
 
<gallery mode=packed heights=250px>
Map_north_pole_route.jpg|Route over the north pole
Map_west_to_east.jpg|Route crossing the International Date Line
</gallery>
 
== {{Newsletter-article-start|Logo proposal|By [[User:Aepcam|Aepcam]]}} ==
This is a new logo badge concept proposal for FlightGear designed by Michat.
This is a new logo badge concept proposal for FlightGear designed by Michat.


Line 182: Line 171:
[[File:Fglogoforum.png]]
[[File:Fglogoforum.png]]


 
== {{Newsletter-article-start|Damage and disintegration|By [[User:Algernon|Algernon]]|FlightGear addons and mods}} ==
{{Newsletter-article-start|Damage and disintegration|By [[User:Algernon|Algernon]]|FlightGear addons and mods}}
{{#ev:youtube|OpwNaoO3xMQ|200|right|Tomaskom's V-1 used in anger over London}}
{{#ev:youtube|OpwNaoO3xMQ|200|right|Tomaskom's V-1 used in anger over London}}
{{#ev:youtube|H4XDuLo35ks|200|right|Victor V2.0 damage script causing a catastrophic failure and fire}}
{{#ev:youtube|H4XDuLo35ks|200|right|Victor V2.0 damage script causing a catastrophic failure and fire}}
Line 189: Line 177:
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.
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.
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.
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.


{{Newsletter-article-start|Scenesetter|By [[User:Algernon|Algernon]]}}
== {{Newsletter-article-start|Scenesetter|By [[User:Algernon|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).
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).


{{Newsletter-article-start|Beechcraft Bonanza|By [[User:Flyingfisch|Flyingfisch]]|In the hangar}}
== {{Newsletter-article-start|Beechcraft Bonanza|By [[User:Flyingfisch|Flyingfisch]]|In the hangar}} ==
Flyingfisch is building the Beechcraft A35 Bonanza for Flightgear. Some pictures:
Flyingfisch is building the Beechcraft A35 Bonanza for Flightgear. Some pictures:
<gallery mode=packed>
<gallery mode=packed>
Line 205: Line 193:
</gallery>
</gallery>


{{Newsletter-article-start|Saab JA-37 Viggen|By [[User:Necolatis|Necolatis]]}}
== {{Newsletter-article-start|Saab JA-37 Viggen|By [[User:Necolatis|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.
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.


[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]
[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]


{{Newsletter-article-start|Updated P-51D now in git|By [[User:hvengel|hvengel]]}}
== {{Newsletter-article-start|Updated P-51D now in git|By [[User:hvengel|hvengel]]}} ==
The new 3D exterior model for the [[North American P-51 Mustang|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.
The new 3D exterior model for the [[North American P-51 Mustang|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.


Line 218: Line 206:
</gallery>
</gallery>


{{Newsletter-article-start|Balancing the Boeing 747-400|By [[User:Gijs|Gijs]]}}
== {{Newsletter-article-start|Balancing the Boeing 747-400|By [[User:Gijs|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.
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.


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


{{Newsletter-article-start|Extra500 is updated to production status|By [[User:Evandenberg|Evandenberg]]}}
== {{Newsletter-article-start|Extra500 is updated to production status|By [[User:Evandenberg|Evandenberg]]}} ==
The [[Extra EA-500]] is updated and has reached "production status"! Just a short list of changes for release 1.1.0:
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<br/>
* Engine+fuel: realistic flame-out, fuel flow to collector compartment, anti ice influence on TOT, improved oil press and temp model<br/>
Line 245: Line 233:
</gallery>
</gallery>


{{Newsletter-article-start|USA state capital buildings|By [[User:Jonbourg|Jonbourg]]|Scenery corner}}
== {{Newsletter-article-start|USA state capital buildings|By [[User:Jonbourg|Jonbourg]]|Scenery corner}} ==
There is a project to add all the USA state capital buildings into FG.  It is discussed in [http://forum.flightgear.org/viewtopic.php?f=5&t=22715&sid=ea847909bde2e1f8ffe5b94bcc673f4f 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.
There is a project to add all the USA state capital buildings into FG.  It is discussed in [http://forum.flightgear.org/viewtopic.php?f=5&t=22715&sid=ea847909bde2e1f8ffe5b94bcc673f4f 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.


{{Newsletter-article-start|LIPY, a scenery conversion from MSFS|By [[User:bigstones|bigstones]]}}
== {{Newsletter-article-start|LIPY, a scenery conversion from MSFS|By [[User:bigstones|bigstones]]}} ==
This month saw the [http://forum.flightgear.org/viewtopic.php?f=5&t=22623 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.
This month saw the [http://forum.flightgear.org/viewtopic.php?f=5&t=22623 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.


Line 260: Line 248:
{{cquote|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}}
{{cquote|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}}


{{Newsletter-article-start|Reshaping Leipzig/Halle Airport|By [[User:August|August]]}}
== {{Newsletter-article-start|Reshaping Leipzig/Halle Airport|By [[User:August|August]]}} ==
[[File:2014 new-layout-EDDP 05.jpg|650px|right]]
[[File:2014 new-layout-EDDP 05.jpg|650px|right]]
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]].  
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]].  
Line 266: Line 254:


Developer Version:
Developer Version:
  '''git clone''' [https://gitorious.org/eddp-custom-scenery/eddp-custom-scenery/ https://gitorious.org/eddp-custom-scenery/eddp-custom-scenery/]
{{gitorious clone|proj=eddp-custom-scenery|repo=eddp-custom-scenery}}


Feedback is welcome at [[User talk:August|August's wiki page]].
Feedback is welcome at [[User talk:August|August's wiki page]].
Line 275: Line 263:
</gallery>
</gallery>


{{Newsletter-article-start|An updated Weather article|By [[User:bigstones|bigstones]]|Wiki updates}}
== {{Newsletter-article-start|An updated Weather article|By [[User:bigstones|bigstones]]|Wiki updates}} ==
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.
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.
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.


{{Newsletter-article-start|Translators required|}}
== {{Newsletter-article-start|Translators required|}} ==
{|
{|
|[[File:en.gif]]
|[[File:en.gif]]
Line 295: Line 283:
|}
|}


{{Newsletter-article-start|Call for volunteers||And finally...}}
== {{Newsletter-article-start|Call for volunteers||And finally...}} ==
* 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]].
* 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]].
{{Appendix}}


[[Category:FlightGear Newsletter|2014 06]]
[[Category:FlightGear Newsletter|2014 06]]
[[Category:Changes after 3.00]]
[[Category:Changes after 3.0]]

Latest revision as of 10:57, 12 March 2016

Magagazine.png
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

FlightGear 3.2 - Feature Freeze

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

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

Preview: Aircraft Center - get it on the fly

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

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

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.

Boeing 777 EFB prototype

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

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

Mapping polar and date line crossing routes

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.[1] Ideal for navigating to your next way point!

Logo proposal

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

Fglogo1.png Fglogowiki.png Fglogoforum.png

Damage and disintegration

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

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

Beechcraft Bonanza

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

Saab JA-37 Viggen

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.

Blå Petter Livery for JA-37

Updated P-51D now in git

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.

Balancing the Boeing 747-400

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

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.

USA state capital buildings

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

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.

LIPY structures landscape.jpg

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:

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

Reshaping Leipzig/Halle Airport

2014 new-layout-EDDP 05.jpg

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.

An updated Weather article

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

En.gif 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.
De.gif 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.
Nl.gif 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.
Es.gif 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.

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
  1. Azimuthal equidistant projection. Published by Wikipedia.