Difference between revisions of "FlightGear Newsletter June 2014"

From FlightGear wiki
Jump to: navigation, search
(FlightGear addons and mods)
(Switch to {{gitorious clone}} to fix the broken Gitorious instructions.)
 
(40 intermediate revisions by 11 users not shown)
Line 1: Line 1:
 +
{{Newsletter-header|June 2014}}
 +
<div style="border-bottom:3px double #BBB;">
 +
{| width="100%" |
 +
| valign="top" width="33%" |
 +
{{Newsletter-cover-header|Development news}}<br/>
 +
{{Newsletter-cover-item|FlightGear 3.2 - Feature Freeze}}<br/>
 +
{{Newsletter-cover-item|Canvas GUI: Layouting, Widgets and MessageBoxes}}<br/>
 +
{{Newsletter-cover-item|Preview: Aircraft Center - get it on the fly}}<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/>
  
{{newsletter}}
+
| valign="top" width="33%" |
{{TOC_right|limit=2}}
+
{{Newsletter-cover-header|Addons and mods}}<br/>
{{Newsletter being written}}
+
{{Newsletter-cover-item|Damage and disintegration}}<br/>
 +
{{Newsletter-cover-item|Scenesetter}}<br/><br/>
 +
{{Newsletter-cover-header|In the hangar}}<br/>
 +
{{Newsletter-cover-item|Beechcraft Bonanza}}<br/>
 +
{{Newsletter-cover-item|Saab JA-37 Viggen}}<br/>
 +
{{Newsletter-cover-item|Updated P-51D now in git}}<br/>
 +
{{Newsletter-cover-item|Balancing the Boeing 747-400}}<br/>
 +
{{Newsletter-cover-item|Extra500 is updated to production status}}
 +
| valign="top" width="33%" |
 +
{{Newsletter-cover-header|Scenery corner}}<br/>
 +
{{Newsletter-cover-item|USA state capital buildings}}<br/>
 +
{{Newsletter-cover-item|LIPY, a scenery conversion from MSFS}}<br/>
 +
{{Newsletter-cover-item|Reshaping Leipzig/Halle Airport}}<br/><br/>
 +
{{Newsletter-cover-header|Wiki updates}}<br/>
 +
{{Newsletter-cover-item|An updated Weather article}}
 +
|}
 +
</div>
  
== Development news ==
+
== {{Newsletter-article-start|FlightGear 3.2 - Feature Freeze|By [[User:t3r|TorstenD]]|Development news}} ==
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].
+
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.
  
=== Logo Proposal ===
+
== {{Newsletter-article-start|Canvas GUI: Layouting, Widgets and MessageBoxes|By [[User:TheTom|TheTom]]}} ==
This is the new logo badge concept proposal for FlightGear designed by Michat.
+
  
[[File:Fglogo1.png]]
+
=== Widgets and Layouting ===
[[File:Fglogowiki.png]]
+
[[File:Fglogoforum.png]]
+
  
===MapStructure stress-testing ===
+
[[File:Canvas GUI Demo Dialog.png|300px|thumb|Screen shot showing a simple [[Canvas GUI]] dialog with a handful of [[Canvas Widgets|Button Widgets]].]]
  
[[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] ]]
+
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.
  
{{cquote
+
For an example on how to use the new system see [[Howto:Creating a Canvas GUI dialog file]].
  |<nowiki>Now that Hyde has committed Philosopher's latest changes, I'd be interested in getting some more feedback on performance.</nowiki><br/><nowiki>
+
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>
+
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211611#p211611
+
    |title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki>
+
    |author=<nowiki>Hooray</nowiki>
+
    |date=<nowiki>Tue Jun 03</nowiki>
+
  }}
+
}}
+
  
=== 777 EFB Prototype by I-NEMO ===
+
=== MessageBoxes ===
[[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]]]
+
  
I-NEMO has started porting his 777/EFB prototype to [[Canvas]]
+
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:
  
{{cquote
+
<syntaxhighlight lang="nasal">
  |<nowiki>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:</nowiki><br/><nowiki>
+
canvas.MessageBox.information("Success", "The operation has successfully completed.");
</nowiki><br/><nowiki>
+
</syntaxhighlight>
1) to do something to compensate for the lacking of an EFB inside the Seattle.</nowiki><br/><nowiki>
+
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.</nowiki><br/><nowiki>
+
</nowiki>
+
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
+
    |title=<nowiki>Re: 777 EFB status & plans  ?</nowiki>
+
    |author=<nowiki>I-NEMO</nowiki>
+
    |date=<nowiki>Mon Jun 02</nowiki>
+
  }}
+
}}
+
  
{{cquote
+
Get more information on how to [[Canvas MessageBox|create Message Boxes on your own...]]
  |<nowiki> 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. </nowiki><br/><nowiki>
+
My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit.</nowiki><br/><nowiki>
+
</nowiki><br/><nowiki>
+
My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. </nowiki>
+
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
+
    |title=<nowiki>Re: 777 EFB status & plans  ?</nowiki>
+
    |author=<nowiki>I-NEMO</nowiki>
+
    |date=<nowiki>Mon Jun 02</nowiki>
+
  }}
+
}}
+
  
{{cquote
+
<gallery mode=packed>
  |<nowiki>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...</nowiki>
+
Canvas-MessageBox-demo information.png|Reporting information
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
+
Canvas-MessageBox-demo warning dont-show-again.png|Showing a warning (allowing the user to not get it reported the next time)
    |title=<nowiki>Re: 777 EFB status & plans  ?</nowiki>
+
</gallery>
    |author=<nowiki>I-NEMO</nowiki>
+
    |date=<nowiki>Mon Jun 02</nowiki>
+
  }}
+
}}
+
  
Learn more at [[Canvas EFB Framework]] ...
+
== {{Newsletter-article-start|Preview: Aircraft Center - get it on the fly|By [[User:TheTom|TheTom]] and [[User:Zakalawe|Zakalawe]]}} ==
  
=== Canvas Garmin GPSMap196 Updates ===
+
[[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]]
 +
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.
  
[[File:Gpsmap196-canvas-panel-page.png|thumb|F-JJTH has updated the SVG file implementing the panel page for the [[Garmin GPSMap 196]]]]
+
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.
  
=== Avidyne Entegra R9 ===
+
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.
  
[[File:Extra500canvas.png|thumb|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]]]]
+
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.
  
=== Towards an Aircraft-agnostic MFD Framework ===
+
== {{Newsletter-article-start|Canvas/MapStructure Updates|By [[User:Hooray|Hooray]] and [[User:Philosopher|Philosopher]]}}==
  
[[File:Canvas-mfd-framework-prototyping.png|thumb|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]].]]
+
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]]
  
 +
<gallery mode=packed>
 +
MapStructureDialog.png|You can basically create arbitrary layers, even for custom objects/positions
 +
Map-canvas-chain-home-editor.png|The same method can be used for creating a "live" radar display
 +
MapStructure-TFC-Troubleshooting.png|
 +
Map-canvas-dialog-storms-overlay.png|But maps and layers can be fairly sophisticated, too - all 100% scripted
 +
</gallery>
  
[[File:Canvas-mfd-framework-prototyping-with-mapstructure.png|400px|thumb|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]].]]
+
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.
  
[[File:Canvas-mfd-framework-prototyping-with-mapstructure-with-kln89-skin.png|400px|thumb|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.]]
+
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.
  
=== Canvas System ===
+
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]].
  
=== Missions & Adventures ===
+
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.
[[File:Missionb.png|thumb]]
+
  
{{forum|79|Tutorials, Missions & Adventures}}
+
<gallery mode=packed widths="400px">
 +
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]
 +
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]
 +
Native Canvas MapWidget Dialog Prototyping.png|More Canvas/MapWidget prototyping. See [http://forum.flightgear.org/viewtopic.php?f=71&t=23391&p=213435#p213435]
 +
</gallery>
 +
<gallery mode=packed heights="200px" widths="400px">
 +
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]]}} ==
 +
[[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]]]
  
=== High Level Architecture ===
+
I-NEMO has started porting his 777/EFB prototype to [[Canvas]]
  
=== Usability Improvements ===
+
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:
 +
# do something to compensate for the lacking of an EFB inside the Boeing 777 Seattle.
 +
# actually try (I repeat it: 'try') to learn some first essentials of nasal.
  
=== Getting your own ideas and features in FlightGear without having to be a coder ===
+
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).
  
We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback.
+
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.
Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless. We've had some extremely heated discussions over the years, some debating interesting ideas - and many ending up being dozens of pages in size, containing hundreds of postings. Often, these contain lots of good ideas and suggestions, but sooner or later these suggestions become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form.
+
We are now trying to document how "bootstrapping" a feature or project works conceptually, i.e. implementing new features for Flightgear - to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own. Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which we didn't come up with, but which is just a convention that happens to "just work", which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens".
+
  
Continue reading at [[Implementing new features for FlightGear]]...
+
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...
  
=== Getting involved as a programmer ===
+
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).
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done.  Fundamentally we need more core devs.
+
  
If you are interested in contributing as a core developer, please see [[Howto:Start core development]].
+
[[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.
  
If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.  
+
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.
  
{{CppBind Ideas}}
+
Learn more at [[Canvas EFB Framework]] or follow the [http://forum.flightgear.org/viewtopic.php?f=71&t=23204 forum discussion]...
  
Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.
+
== {{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.
  
== Release ChangeLog ==
+
It is intended to:
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.
+
* support multiple independent instances
 +
* be totally aircraft agnostic
 +
* support a pure dialog-driven mode
 +
* support skinning/theming
  
== Interview with a contributor (NAME) ==
+
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.
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''
+
  
* How long have you been involved in FlightGear?
+
{{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.
* What are your major interests in FlightGear?
+
* What project are you working on right now?
+
* What do you plan on doing in the future?
+
* Are you happy with the way the FlightGear project is going?
+
* What do you enjoy most about developing for FlightGear?
+
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
+
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?
+
  
More questions are being collected here: [[Interview questions]].
+
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]] }}
  
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX
+
<gallery mode=packed>
 +
Gpsmap196-canvas-panel-page.png|F-JJTH has updated the SVG file implementing the panel page for the [[Garmin GPSMap 196]].
 +
Canvas-mfd-framework-prototyping.png|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]].
 +
Canvas-mfd-framework-prototyping-with-mapstructure.png|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]].
 +
Canvas-mfd-framework-prototyping-with-mapstructure-with-kln89-skin.png|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.
 +
</gallery>
  
== Nasal for newbies ==
+
== {{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!
  
== New software tools and projects ==
+
<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>
  
== FlightGear addons and mods ==
+
== {{Newsletter-article-start|Logo proposal|By [[User:Aepcam|Aepcam]]}} ==
=== Damage and disintegration ===
+
This is a new logo badge concept proposal for FlightGear designed by Michat.
{{#ev:youtube|OpwNaoO3xMQ|240|right|Tomaskom's V-1 used in anger over London}}
+
 
{{#ev:youtube|H4XDuLo35ks|240|right|Victor V2.0 damage script causing a catastrophic failure and fire}}
+
[[File:Fglogo1.png]]
{{#ev:youtube|uLojBI7ezdM|240|right|L-159 disintegration}}
+
[[File:Fglogowiki.png]]
 +
[[File:Fglogoforum.png]]
 +
 
 +
== {{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|H4XDuLo35ks|200|right|Victor V2.0 damage script causing a catastrophic failure and fire}}
 +
{{#ev:youtube|uLojBI7ezdM|200|right|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.
 
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.
  
=== Scenesetter ===
+
== {{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).
  
== 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:
 +
<gallery mode=packed>
 +
Beech_bonanza_with_panel_lights_on.png|Panel lighting
 +
Bonanza rbf.png|Remember to do your pre-flight check before startup!
 +
Bonanza at sunrise.png|The Beech Bonanza at Kent State University (1G3) just before sunrise
 +
Bonanza interior at sunrise.png|The interior of the Bonanza at sunrise.
 +
</gallery>
  
=== New aircraft ===
+
== {{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.
  
=== Updated aircraft ===
+
[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]
  
The Swedish fighter jet Saab JA-37 Viggen has been updated, since it was included in FG 3.0.0; More instruments, additional liveries, aerodynamic response to payload and tooltips on instruments. Option for automatic reverse thrust at touchdown, selection of HUD brightness, disabling of structural damage. The aircraft now also has multiplayer sounds and better cockpit view helps seeing the landing strip. Support for FG 2.8 by deleting a small section in an xml file. Also worth mentioning is countless bug-fixes and improvements, e.g. better handling at high altitudes and a bug fix in the lift force formula.
+
== {{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.
  
[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]
+
<gallery mode=packed heights=250px>
 +
P-51D testing it's guns before a flight..jpg|P-51D testing it's guns before a flight.
 +
P-51D trim tab animation..jpg|P-51D trim tab animation.
 +
</gallery>
  
=== Liveries ===
+
== {{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.
  
== Scenery corner ==
+
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.
=== Airports ===
+
  
== Aircraft of the month ==
+
The updated 747-400 is already available through Git and will be on the download page when FlightGear 3.2 is released.
== Airport of the month ==
+
== Screenshot of the month ==
+
  
== Suggested flights ==
+
== {{Newsletter-article-start|Extra500 is updated to production status|By [[User:Evandenberg|Evandenberg]]}} ==
== Aircraft reviews ==
+
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/>
 +
* Aerodynamics: flap performance, elevator-30deg-flaps authority improvement<br/>
 +
* User interface: interactive checklists<br/>
 +
* Sounds: corrected sounds for test, CWS and AP disc<br/>
 +
* Model: added interior, yokes<br/>
 +
* Avionics: IFD moving map, automatic NAV tuning, automatic NAV switching, magnetic variation fixes<br/>
 +
* Autopilot: added OBS and fly vectors mode, significant improvement of coupled ILS performance
 +
A more extensive list can be found in the "version" file.
  
== Wiki updates ==
+
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!
=== Translators required ===
+
 
 +
Please checkout the [[Extra EA-500|Extra500 wiki]] for download instructions and lots of more info.
 +
 
 +
<gallery mode=packed heights=250px>
 +
File:Extra500 flightgear1.png|Extra500 flying in clouds
 +
Extra500canvas.png|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]]
 +
</gallery>
 +
 
 +
== {{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.
 +
 
 +
== {{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.
 +
 
 +
[[File:LIPY structures landscape.jpg|650px|right]]
 +
The conversion was made with [[ModelConverterX]], which makes the job partially easier than by [[Howto:Convert objects from X-Plane|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 [http://forum.flightgear.org/viewtopic.php?f=5&t=22707 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:
 +
 
 +
{{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]]}} ==
 +
[[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]].
 +
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:
 +
{{gitorious clone|proj=eddp-custom-scenery|repo=eddp-custom-scenery}}
 +
 
 +
Feedback is welcome at [[User talk:August|August's wiki page]].
 +
<gallery mode=packed>
 +
2014 new-layout-EDDP 04.jpg|Taxiway T - new ground textures
 +
2014 new-layout-EDDP 01.jpg|Runway 26L with DHL-area
 +
2014 new-layout-EDDP 02.jpg|Apron 4
 +
</gallery>
 +
 
 +
== {{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.
 +
 
 +
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|}} ==
 
{|
 
{|
 
|[[File:en.gif]]
 
|[[File:en.gif]]
Line 195: Line 283:
 
|}
 
|}
  
== Community news ==
+
== {{Newsletter-article-start|Call for volunteers||And finally...}} ==
=== FlightGear on YouTube ===
+
* 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]].
 
+
=== New tutorials and screencasts ===
+
=== Forum news ===
+
=== Multiplayer ===
+
=== Virtual airlines ===
+
=== FlightGear events ===
+
 
+
== Useful links ==
+
== And finally ... ==
+
=== Contributing ===
+
 
+
{{Volunteer Intro|mode=showlogo}}
+
 
+
=== Call for volunteers ===
+
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project.  If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance.  See the plan at [[World Scenery 3.0 roadmap]].
+
 
+
=== Did you know ===
+
  
[[Category:FlightGear Newsletter]]
+
{{Appendix}}
<!-- this needs to be changed after each release, so that newsletters show up in the proper category -->
+
  
[[Category:Changes after 3.00]]
+
[[Category:FlightGear Newsletter|2014 06]]
 +
[[Category:Changes after 3.0]]

Latest revision as of 05: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.