FlightGear wiki - User contributions [en]

Canvas ND framework

2014-04-08T06:21:02Z

Drdavid: /* Adding the navigation display to your aircraft */

{{Template:Non-stable|version=3.2|progress=60}}

[[File:Canvasready.png|right]]
{{infobox subsystem
|image = Navigation display MAP mode.png
|alt = MAP mode with a [[Standard Instrument Departure|SID]] from Eindhoven Airport
|name = NavDisplay
|started = 11/2013
|description = [[Canvas]]/[[Nasal]] driven NDs
|status = Under active development as of 12/2013
|maintainers = Gijs (B747), Hyde(B777), Soitanen(B737NG), (Hooray, Philosopher & D-LEON via [[MapStructure]])
|developers = [[User:Gijs]] (since 11/2013)
}}
The '''navigation display''' ('''ND''') is a display in a glass cockpit, providing information about an aircraft's lateral situation. As of late 2013, a new ND ([[Navigation display]] being the old) is in development for [[FlightGear]] using the new [[MapStructure]] back-end for charting purposes, and SVG symbols animated via Nasal functions for any non-mapping aspects. Thanks to [[Canvas]], much more complex and sophisticated graphics are possible now, without having to know any C++, and without having to rebuild FlightGear from source. Anybody able to run FlightGear and a text editor, can now easily use and extend the ND framework.

It can be found on [[Git]] in fgdata/master (2.99). The main source is located in <tt>{{Git link|gitorious|fg/fgdata|master|Nasal/canvas/map/navdisplay.mfd|pre=[[$FG_ROOT]]/}}</tt>.

== Adding the navigation display to your aircraft ==
The new ND is available in FlightGear 3.0 as of February 2014.

Note that the latest ND code is currently only available in Git and not in the latest stable release.
# Add a surface object to your 3D model and apply a place holder texture to it. You can refer to the 747-400 and 777 for examples.
# Copy the ND.nas file of the Boeing 777 into your own aircraft directory (<tt>{{Git link|gitorious|fg/fgdata|master|Aircraft/777/Models/Instruments/ND/ND.nas|pre=[[$FG_ROOT]]/}}</tt>).
# Add the file to the <nasal> block in your aircraft's [[Aircraft-set.xml|-set.xml]] file.
# In order to customize the ND for your specific aircraft, change a few options in your ND.nas file:
## the node behind <code>addPlacement</code> is the name of the object in your 3D model. For multiple independent NDs, each ND should have its own object (and thus placement node). The 777 for example has a "ndScreenL" and a "ndScreenR".
## Rename the properties in the "myCockpit_switches" hash at the top of the ND.nas file to match your own properties (range selector, mode selector etc.), see {{Git link|gitorious|fg/fgdata|master|Aircraft/747-400/Models/Cockpit/Instruments/ND/ND.nas|3|22|pre=[[$FG_ROOT]]/}} You're advised to use the defaults (and change other systems of your aircraft accordingly). For an overview of switches, see [[#Cockpit switches]].
# Add knobs/buttons to the 3D model of your cockpit to control the various options of the ND. See <tt>{{Git link|gitorious|fg/fgdata|master|Aircraft/777/Models/Instruments/EFIS/efis-ctl1.xml|pre=[[$FG_ROOT]]/}}</tt> for an example.
# Add a binding to your screen(s) to open the ND in a popup dialog. See <tt>{{Git link|gitorious|fg/fgdata|master|Aircraft/777/Models/Instruments/ND/ND_L.xml|pre=[[$FG_ROOT]]/}}</tt> for an example.

That's the only thing you need to do right now. future changes will be in navdisplay.mfd and will be automatically available to you once they're committed/merged, no changes needed in your ND.nas at all, except for additional switches/buttons that may be created, and which would obviously need to be mapped to your cockpit hot spots.

If you are facing problems with the steps outlined above, please get in touch via the article's talk page or the forum, so that the instructions can be improved accordingly. Thank you!

{{Note|The following section is currently work-in-progress, it is being written by 5H1N0B1 and drdavid, please get in touch to help reviewing/improving things.}}
More detailed instruction. See if it could help.
ND integration: How it was done on the Mirage 2000:
The integration is simple:

0) Have an updated version of FlightGear (V. 3.0+).

1) Set up the 3D model in this way:

To create a 3D MFD ->
- a) Select a 3D Border (border of the screen, with screws, etc.)
- b) Need to have a 3D Button/switch, molette, or turnable knob
- c) A 3D Screen object, with:
- correct dimensions
- Single texture, -> with correct dimensions
- Correct dimension of the UVmap

2) Copy and paste the ND.nas file to the appropriate folder (In the Mirage 2000 this was the "Center-mfd" folder).
2.1) Add the ND.nas pathway to your base .xml file in the Nasal block.

3) Edit ND.nas :
-a) Rename the screen to match the object in 1)c) if needed.
-b) If installing a single MFD, you do not need another object, so suppress the line (when it's calling the object itself)
-c) Keep the property's name -> it's ok. You just need to input it with the .xml button in 1)b)

4) Code the xml itself.

Really simple, it's just playing with properties. For example, see this for the airport property:


<animation>
<type>pick</type>
<object-name>bt-h1</object-name>
<visible>true</visible>
<action>
<button>0</button>
<binding>
<command>property-toggle</command>
<property>/instrumentation/efis/inputs/arpt</property>
</binding>
</action>
</animation>

Or here again for the range selection:

<animation>
<type>pick</type>
<object-name>trim1</object-name>
<action>
<button>4</button>

<repeatable>false</repeatable>
<binding>
<command>property-cycle</command>
<property>/instrumentation/efis/inputs/range-nm</property>
<value>10</value>
<value>20</value>
<value>40</value>
<value>80</value>
<value>160</value>
<value>320</value>
</binding>
</action>
</animation>

<animation>
<type>pick</type>
<object-name>trim1</object-name>
<action>
<button>3</button>

<repeatable>false</repeatable>

<binding>
<command>property-cycle</command>
<property>/instrumentation/efis/inputs/range-nm</property>
<value>320</value>
<value>160</value>
<value>80</value>
<value>40</value>
<value>20</value>
<value>10</value>
</binding>
</action>
</animation>

5) Then you can optionally add this:

<animation>
<type>pick</type>
<object-name>blackbkd</object-name>
<action>
<button>0</button>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>mirage2000.showNd();</script>
</binding>
</action>
</animation>

Where 'blackbkd' is the screen 1)c). This last option allows you to open a dialog box with what the actual canvas should display in your 1)c) screen. This is very useful to check all the different steps when something isn't working well.

Normally following these steps, you should have a working MFD.

=== Cockpit switches ===
{{Note|The default property is '''relative''' to the root location of your ND, it is NOT an absolute path. Boolean values (true/false) can also be just 1/0. The list of switches below is correct for FG 3.0 - future versions may support additional switches. In the future, we're also going to make the ND style-able this way, so that colors, fonts, size (LOD) and symbols can be customized easily via ND.nas. FlightGear 3.1 introduces an optional hash argument called '''options''' which is a hash that supports layer-specific options (more details to follow) }}

{| class="wikitable"
! Switch !! Description !! Default property !! Accepted values !! new in 3.1+
|-
| toggle_airports || Display airports on the map || /inputs/arpt || true, false
|-
| toggle_centered || Center ND modes || /inputs/nd-centered || true, false
|-
| toggle_data || Display way point data on the map || /inputs/data || true, false
|-
| toggle_display_mode || Change display mode || /mfd/display-mode || APP, MAP, PLAN, VOR
|-
| toggle_display_type || Change display type || /mfd/display-type || CRT, LCD
|-
| toggle_position || Display position data on the map (currently unused) || /inputs/pos || true, false
|-
| toggle_range || Range of the maps in nautical miles || /inputs/range-nm || Any positive number
|-
| toggle_stations || Show/hide stations (VOR/DME/NDB) || /inputs/sta || true/false || options:{ radios:[0,1] } (WIP)
|-
| toggle_terrain || Terrain radar (currently unused) || /inputs/terr || true, false
|-
| toggle_track_heading || toggle track/heading mode (new in 3.1+)|| ??? || 1/0 ||
|-
| toggle_traffic || Display [[Traffic alert and collision avoidance system|TCAS]] data || /inputs/tfc || true, false
|-
| toggle_true_north || Toggle true or magnetic north || /mfd/true-north || true, false
|-
| toggle_waypoints || Display way points (fixes) on the map || /inputs/wpt || true, false
|-
| toggle_weather || Weather radar || /inputs/wxr || true, false
|}

== Aircraft Support ==
For the framework to become sufficiently generalized and aircraft-agnostic, we need many different aircraft to adopt it and aircraft developers to provide feedback regarding missing features.
We are looking for people interested in integrating the new system, so that it can be better developed with different requirements in mind.

The 747 and 777 are the primary reference examples for now.
The following people/aircraft are currently in the process of adopting the new NavDisplay (please add any related efforts here):

* 01/2014: Gijs (747-400) {{Progressbar|100}}
* 01/2014: Hyde (777-200) {{Progressbar|100}}
* 02/2014: mueko (A320) {{Progressbar|90}} [http://forum.flightgear.org/viewtopic.php?f=71&t=22045&p=200427#p200422]

* 02/2014: Soitanen (737-300) {{Progressbar|80}} [http://forum.flightgear.org/viewtopic.php?f=71&t=21509&start=15#p200304]
* 02/2014: Sascha (A310) {{Progressbar|10}}
* 02/2014: drdavid (DC10) {{Progressbar|30}}
* 02/2014: 5H1N0B1 (m2000-5) {{Progressbar|100}}

If you are finding yourself having problems integrating the framework, please refer to already integrated aircraft as reference/example, or get in touch with their maintainers - ideally, via the forum, so that everybody can contribute and benefit.

Note that this will initially just give you a Boeing-centric ND, because it is currently being developed by the 747/777 maintainers primarily - please use the issue tracker to file feature requests for missing features. Over time, the framework will grow and become more flexible,so that also specifics of non-Boeing aircraft can be properly emulated. But obviously this will take a while. We invite aircraft developers to help extend and refine the framework accordingly.

== Gallery ==
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|MAP mode
Navigation display centered MAP mode.png|Centered MAP mode
Navigation display PLAN mode.png|PLAN mode
NavDisplay-GUIFrontend.png|NavDisplay/MapStructure testbed
</gallery>

== Adding new features ==
{{Note|Please get in touch with [[User:Gijs]] before touching navdisplay.mfd
If you are primarily interested in porting/adding new '''mapping''' layers (such as e.g. waypoints, route, weather etc), please see the [[MapStructure]] article for details.
Otherwise, this section is focused on dealing with non-mapping aspects, i.e. ND-specific SVG symbols and animating them via properties and calculations. Typically, a new symbol will require 10-20 lines of code added to navdisplay.mfd - it will typically take 5-10 minutes to add a new animated symbol to the ND.}}
If you want to add new features to the navdisplay.mfd code, you need to open that file and map an SVG element to a callback routine - that's how everything is working currently.

There's a "configuration hash" called "NDStyles" at the top of the file. Each aircraft can have its own entry in NDStyles, such as NDStyles["B747-400"] or NavDisplay["777"]. Then, all the required canvas callbacks are listed there, i.e. the font mapper etc.

There's also an entry for a custom SVG filename. However, we encourage people to get in touch with Gijs and Hyde to help coordinate all ND development a little - so that a common (and shared) SVG file can be used, this is already the case for the B744 and B777 - we're hoping to get other aircraft developers involved, to help generalize the SVG file, instead of having dozens of different files and symbols. Most features should be identical or at least very similar. Which is why it's a good idea to get in touch with other people working on the ND code.

Lines 52-131 set up existing layers, which are now shared with the GUI code - so that is where new layers are added.
Aircraft specific SVG elements are added at the end, after line 132

For now, we suggest to directly use the 747-400 ND - but the framework is now prepared to easily style & customize it for different aircraft, we will probably add a tutorial to the wiki to explain how things are hanging together there. The constructor and init methods may still need some work to generalize things there, because they are basically still the original code.

So to replace the 747 ND and customize it, these are the steps:

* add a new entry to the NDStyles hash, for example "777-200"
* you can simply copy the configuration stuff from the 747 to get started
* start customizing things there
* open the SVG file in inkscape and change it as required, save it
* change the SVG filename in your NDStyles["777-200"] hash entry to match your own file name
* provide animation callbacks for any 777 specific elements
* open your own copy of ND.nas
* change the constructor call .new() to specify the name of your new NDStyles entry
* by default, this is 747-400 for the time being, for example:
<syntaxhighlight lang="nasal">
var NDCpt = ND.new("instrumentation/efis", myCockpit_switches, "777-200" );
</syntaxhighlight>

the "777-200" part needs to match the identifier used in the NDStyles hash.

To get started, just copy the whole 747-400 section in NDStyles and rename it to match your needs. Once that is working (getting a 747-400 ND via the 777-200 identifier), you can simply replace the SVG file name and add your own update handlers to incrementally come up with your own ND.

== Development ==

=== mapping vs. SVG animation ===

It would be really nice to have two sides to navdisplay.mfd: a map (your/my area) and svg ui (Gijs' and aircraft devs' responsibility) 0.o.

: am all for supporting the two use-cases you mentioned - then again, the old code is fragile enough, so I wouldn't add to it - the main thing the old code was all about was establishing the MVC separation so that draw routines can be reused - and that's basically done, so no need to keep the old cruft around ...

: Regarding the navdisplay stuff itself - well, it's pretty much the original code still, i.e. the design is only just evolving - algorithmically, it's still not very optimized - MapStructure only helps with mapping aspects obviously.

: I was going to suggest the "SVG/element animation" separation too - but I think Gijs etc already need to handle quite a bit of re-thinking, because things are no longer as straightforward. In the long run, it will probably happen over time - especially once other things are generalized, especially for generic PFD/EICAS/CDU/EFB functionality - these would all benefit from a corresponding "symbol animation" abstraction eventually like TheTom mentioned on the forum: PFD: A common framework in the background

: Honestly, it would have been great to have such a framework to implement MapStructure on top of it - but obviously, it's a chicken/egg issue :-)

: Currently, the main danger here is that people are going to start using copy & paste again to adopt things like Gijs' PFD, like mentioned by Zakalawe: if someone provides a 'system' I'll use it but I'm not interested in writing it myself

: So the real question is if people can be convinced to team up and come up with a generic and reusable design, or follow the original PFD/ND approach instead - interestingly, most of TheTom's work in this area (MCDU/EICAS) seems pretty reusable, also outside aircraft, i.e. usable via the GUI.

After having looked at navdisplay.mfd, I think we only need to separate a few things using io.include() to make this happen automatically over time - all the 747/Boeing-specific stuff would be moved into "config" hashes and factored out of navdisplay.mfd - into something like "boeing747.nd" that would leave us with very little code remaining in navdisplay - basically a single class and a few methods with foreach loops.

So we would end up with a layered design like this:

* boeing.nd (config hashes via io.include)
* navdisplay (down-stripped code, aircraft-agnostic)
* MapStructure (needs no changes)
* Symbol/Animation Layer (shared with PFD, ND, CDU, EFB, would be developed/grown over time), some animations currently implemented manually in the PFD/ND code:
** rotate (heading,bearing, azimuth)
** scale
** colorize
** update text labels (font size, font type, font color)
* canvas APIs (as is)
* canvas subsystem (as is)
* OSG / Shiva (as is)

=== Misc ===

* use switches hash to procedurally create a GUI dialog with buttons for each toggle_action (TFC,CTR,WXR etc) {{Not done}}
* make sure that the frameworks with properly with time-warp, sim-rate speed-up and replay {{Not done}}
* remove (old) disabled layers
* make the timer update interval configurable via constructor {{Not done}}
* consider adding hooks to generalize those huge conditionals in update() some more {{Not done}}
* use foreach() to hide()/show() or setVisible() groups of symbols {{Not done}}
* make this more aircraft agnostic by getting rid of 747/Boeing specific assumptions {{Not done}}
* unify switch/case|default handling (again, huge conditionals in there) {{Not done}}
* on_update() helper should probably support global listeners and timers, too - i.e. via a hash spec ? {{Not done}}
* the whole symbol lookup needs to cleaned up (getElementById etc) {{Not done}}
* introduce a common "compute" field in the update/predicate hash and make its results available to is_true/false etc {{Not done}}
* use io.include to include boeing specific stuff{{Not done}}
* NDSoruceDriver should be generalized and combined with MapStructure's aircraftpos.controller {{Not done}}
* the radio/autopilot listeners need to be set up in the lcontroller file, they're just empty stubs for now {{Not done}}
* there are 3 foreach loops in newMFD() setting up symbols currently-we only need ONE: loop 2+3 should be removed and use the loop #1 method {{Not done}}
* clean up the ctor and generalize the newMFD() method {{Not done}}
* move stuff out of the update() method into the aircraft-specific configuration hash {{Not done}}
* generalize/extend on_update() method to support other (global) properties and/or listeners/timers to run predicates {{Not done}}
* identify opportunities for improving the framework {{Not done}}
* support multiple routes (WPT/RTE), as per the [[Nasal Flightplan]] API (Hooray) {{Not done}}
* move the config hash out of the navdisplay.mfd file and use io.include instead {{Not done}}
* document SVG symbols currently assumed to be available in the ctor {{Not done}}
* consider using some of the SGCondition/StateMachine stuff in SG {{Not done}}

== Bugs ==

== Feature Requests ==

[[Category:Aircraft instruments]]
[[Category:Canvas]]

FlightGear Newsletter January 2014

2014-02-02T07:34:42Z

Drdavid: /* DC-10-30 Getting a Flightdeck Refit */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter. Core developers are encouraged to add news about their latest work to the newsletter's development section and [[Next Changelog|the changelog of the upcoming release]]. At the end of each month, it's generally a good idea to get in touch with other contributors to ask them to add news about their contributions to the newsletter.''

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].

=== Soaring instrumentation SDK ===

Galvedro has started documenting the new soaring instrumentation Software Development Kit (SDK). The soaring instrumentation toolkit is a small library of Nasal objects that you can use for adding specialised soaring gauges to your glider. The library is comprised of several building blocks that you can connect together in different ways in order to get the desired functionality.

In order to use the library, you will need to write a Nasal script that will be loaded together with your aircraft. You do so by referencing this script in the <Nasal> section of your aircraft definition XML file. But don´t be scared, the scripts will be very simple. Lets see some examples.

<syntaxhighlight lang="nasal">
io.include("Aircraft/Generic/soaring-instrumentation-sdk.nas");

var probe = TotalEnergyProbe.new();

var vario_needle = Dampener.new(
input: probe,
dampening: 2.7,
on_update: update_prop("instrumentation/vario/te_reading"));

var vario_instrument = Instrument.new(
components: [probe, vario_needle],
enable: 1);
</syntaxhighlight>

This code implements a basic total energy compensated variometer, writing the needle reading to the property "instrumentation/vario/te_reading".

Continue reading at [[Soaring instrumentation sdk]]...
=== Creating a custom ATC/RADAR Layer in 10 minutes ===
Philosopher and Hooray have added a new tutorial that demonstrates how to create new [[MapStructure]]-based Canvas displays. People already having some Nasal experience (property tree, OOP), should be able to complete this in less than 15-20 minutes. So, to learn how to create a simple ATC/RADAR display, continue reading at [[MapStructure#Creating_a_custom_ATC.2FRADAR_Layer_in_10_minutes]]...

=== Behind the Scenes of: Nasal Loops ===
Nasal has several ways to implement an iteration, including repeated events run from listeners or timers.
A polling loop, run via a timer, is akin to somebody permanently running to a room to check if the lights are on - a listener is like somebody being INSIDE the room SLEEPING and only WAKING up once the lights are turned on.
The setlistener API is intended to catch rare events, whereas timers are run often, pretty much regardless of external events. Both are triggered by calling a so-called "callback" - which is just a provided function to be called as the event-handler, i.e. the function specifies what is to be done once the event is triggered.

In general, timers are not bad or expensive, because it really depends on what you're doing inside the callback (function) that is called, but some constructs benefit from listeners.

Any callback will be executed within a single frame normally - so a long-running timer will add up to the frame spacing (latency), as will a listener triggered just as often or even multiple times per frame.

It doesn't matter if the code/callback is run inside a timer or a listener - what matters is the complexity of the code that runs. Ultimately, though, some code has to be executed somewhere to get the desired result, but in most cases that code can be simple rather than complex. Listeners are only really preferable over timers when it comes to checking for some condition, because timer-loop-based polling is called "busy-waiting", i.e. more expensive, see the previous analogy of somebody having to do something regularly in order to perform a check.

A listener on the other hand, is not resource-hungry while it is "waiting", it's not even "busy" - it's just not doing anything until it is "fired" (analogous to Interrupt Service Routines, i.e. a smoke detector firing an alarm once it detects smoke). However, there are often times where loops make a lot of sense, mainly when lots of values of properties need to be used to drive or evaluate a subsystem or equation.

Continue reading at [[Nasal Loops]]...

=== Atmospheric Light Scattering ===

Since the uv-mapping of dirt runways in the World Scenery 2.0 is sound, Atmospheric Light Scattering is receiving a hires procedural texturing effect of dirt runways. This effect allows to render puddles and thin snowcover on the runway, as well as allowing patches of another material intruding (here patches of grass). Ultimately, this will make the appearance of dirt runways also regionally configurable, with different mixtures of sand, rocks and grass.

[[File:dirt_rwy.jpg|500px|A procedurally textured wet dirt runway]]

=== Using OpenStreetMap Data in FlightGear ===
In 2013, we've seen quite a bit of progress on procedural scenery generation using OSM data, including buildings & cities (radi, Soitanen/osm2fg), roads, rivers - even railways (vivian) and procedural bridge generation (radi), but also procedural power lines (vanosten).

In other words, there's now some serious -and unprecedented manpower, including quite a few folks who are able to build from source and able to write C++ code. So this deserves being coordinated among all interested parties. And it would clearly make sense not to just expose things to the Canvas system, but to expose the corresponding APIs so that other subsystems and users can access these and use these for the purposes outlined above.

Which is why we have created a summary of the main OSM related efforts we've seen in the last 18 months, continue reading at [[Using OSM Vector Data in FlightGear]]...
=== Project Rembrandt ===
A number of Mac users have been reporting issues related to running [[Project Rembrandt]] (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: [[Project Rembrandt#Mac Issues]].

=== Canvas System ===

=== High Level Architecture ===

=== Usability Improvements ===

=== Getting involved as a programmer ===
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.

If you are interested in contributing as a core developer, please see [[Howto:Start core development]].

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

===Bombable add-on updated to Version 4.5b===
Flightgear add-on Bombable, which turns Flightgear into a full-featured combat flight simulator, was updated to version 4.5b on January 9th.

Highlights of the new version: [[File:A-10 Warthog in Bombable.png|thumb|A-10 Warthogs in an AI Scenario running with the Bombable add-on.]]

* '''Improvements that help with FG 2.12 compatibility''' (particularly FG 2.12's new/improved way of handling AI scenarios)
* '''Improved version of the historically accurate Sopwith Camel''' (choose the JSBSim version of the Camel that is included in the package)
* '''Respawn scenario aircraft, vehicles, and ships either a single clump OR retaining their relative positions and altitudes'''
* Together with FG's new more flexible scenario system, this means '''you can load Bombable's scenarios instantly and move them to wherever you are in the world instantly'''--making it a lot quicker and more fun to run the Bombable AI scenarios. You're not stuck with doing scenarios in the one place they were originally set up--you can easily move them to anywhere in the world, while retaining the original scenario's general setup (bombers in a formation, fighter flying cover, tanks scattered around hillsides, etc)
* '''Improvements to AI aircraft realism''', bug fixes.

[http://forum.flightgear.org/viewtopic.php?f=6&t=5742 Read more about Bombable or download the add-on here.]

{{#ev:youtube|PirnWJHZtcg|400}}

This very well explained video made by Jetman shows how to do a short flight mission from San Francisco (KSFO) intercepting an [[A-10 Warthog]] air patrol near Sausalito in a [[F-14_Tomcat]] running in FlightGear Bombable.

== In the hangar ==

=== New aircraft ===

=== Updated aircraft ===
==== '''DC-10-30 Getting a Flightdeck Refit''' ====

'''David Waggoner, “DrDavid”'''

[[File:DC-10-30ER_Over_Mt_Everest.jpg]]

'''DC-10-30ER over Mt. Everest'''

'''A New Front Office for a Great Widebody Airliner '''

The DC-10-30 (by Ryan Miller) is getting an updated flightdeck with state of the art glass cockpit avionics. The purpose of the project is to create a theoretical refit of the aircraft as if Boeing/McDonnell-Douglas had continued to produce the airplane. The original instrument panel is historically accurate, but as FlightGear has evolved, the advances in avionics technologies have opened up a whole new universe for giving the pilot real-time situational awareness. It proved too good of a prospect to pass by.

The DC-10-30 makes a great platform for this kind of revision because of its sophisticated flight dynamics, autopilot and it is Rembrandt enabled. Rembrandt provides superior lighting capabilities both outside and inside the aircraft, but not all FG instruments are Rembrandt-compatible. Therefore, a new avionics package had to be functional in that environment.

[[File:DC-10-30_Flightdeck_Day_Screenshot.jpg]]

'''State of the Project'''

Fortunately, the CRJ-700 Family Series (also by Ryan Miller) has a glass cockpit set up for Rembrandt. The PFD, MFD, EICAS, CDU, Radio Stack, Upper Light Switch Panel, and Side Panels were transferred from the CRJ700 to the DC-10-30. After much tweaking and trial and error, many, but not all of the CRJ’s screens are functional. In addition, a set of standby instruments have been added to support the three glass screens. Note there is cleanup work to be done on the panel—this is a work in development. The choice of instruments and layout are designed to meet my preferences, but that is expected to continue to progress.
The two screenshots illustrate the great effectiveness of having Rembrandt.

[[File:DC-10-30_Flightdeck_Night_Screenshot.jpg]]

'''Rembrandt and Now the Canvas-Ready NavDisplay'''

A brilliant opportunity has popped up, in the mean time. The release of the new Canvas-ready NavDisplay screens, which will be developed by FlightGear over time to match specific aircraft, is now available. I am in the process of installing the ND in the DC-10’s MFD. Once a stable MFD is achieved, the aircraft will be uploaded into Git for the FlightGear Community to take a look at. I have a long TODO list for other improvements to the model, and will welcome other collaborators—I suspect you might have some ideas I haven’t even thought of that would be great to include. There is also the opportunity to create more liveries for the airplane.

==== McDonnell Douglas MD 902 Explorer ====
The [[McDonnell Douglas MD 902 Explorer]] had an significant improvement. Heiko Schulz made a brand new FDM for the MD 902. The helicopter has also a new cockpit with working instruments (most instruments are taken from the [[EC135]]). This helicopter has a role as light twin helicopter and makes use of a NOTAR system. So this is a helicopter without a tailrotor.

<gallery mode=packed widths=350px heights=350px>
MD 902 flying near EDMA.png|Screen shot showing the MD 902 in Polizei livery near EDMA.
Cockpit from the MD 902.png|The cockpit of the MD 902.
</gallery>

====Updated JSBSim FDM for Sopwith Camel with historical features====

A new JSBSim Flight Dynamics Model for the Sopwith Camel was [https://www.youtube.com/playlist?list=PLttk_Y2c7I-c4_SH4zvqJXx1WMt9U1CUF Aircraft of the Month] in May 2013. The FDM attempts to incorporate all known performance characteristics of the Camel documented in various historical accounts by pilots as well as published technical documents. Many of these documents and interesting historical accounts of the Camel can by found in the Docs directory of the release.

Now version 1.8 of the JSBSim FDM for the Camel has been released, taking into consideration feedback from users and making various improvements.

[http://forum.flightgear.org/viewtopic.php?f=4&t=19584 Find out more or download the Sopwith Camel here]

<gallery mode=packed widths=350px heights=350px>
Sopwith Camels battle in Bombable 02.png|Sopwith Camels in an AI Scenario running with the Bombable add-on.
Sopwith Camels battle in Bombable 01.png|Sopwith Camels in an AI Scenario running with the Bombable add-on.
</gallery>

=== Liveries ===

== Scenery corner ==
=== Airports ===

Works have been added to '''Václav Havel Airport Prague - LKPR''' with a lot of hangars, terminals and other buildings. More informations you can find on this FG wiki page: [[Václav_Havel_Airport_Prague|Václav Havel Airport Prague]]

''TerraSync has it all! You don't need to download a custom scenery.''
<gallery mode=Packed-overlay widths=300px heights=300px>
LKPR North Apron.jpg|The north apron of LKPR
LKPR East Apron.jpg|The east apron of LKPR
</gallery>

=== Regional textures ===

Regional texture definitions for Iceland have been updated on GIT to match the newly available CORINE based version of Iceland in our World Scenery 2.0. Check it out - the place looks gorgeous now!

[[File:Iceland new01.jpg|260px|Öskjuvatn, Iceland in World Scenery 2.0]]
[[File:Iceland_new02.jpg|260px|Vatnajökull, Iceland in World Scenery 2.0]]
[[File:Iceland_new03.jpg|260px|Hills near Akureyri, Iceland, in World Scenery 2.0]]

In addition, new regional texture definitions are also available for South Africa - view the famous table mountain near Cape Town and explore grasslands and lush vinyards between rugged hills!

[[File:SouthAfrica01.jpg|260px|Stellenbosch, ZA in World Scenery 2.0]]
[[File:SouthAfrica02.jpg|260px|Assegaiboschkloof, ZA in World Scenery 2.0]]
[[File:SouthAfrica03.jpg|260px|Near Franshoek, ZA in World Scenery 2.0]]

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

Flightgear goes back to space!

Arc top of a ballistic trajectory with the X-15 - 330.000 ft above Iceland, 600 km visibility range!

[[File:X-15-iceland03.jpg|600px|The X-15 on the falling leg of a high-altitude ballistic trajectory above Iceland]]

And falling down to Earth again:

[[File:X-15-iceland05.jpg|600px|The X-15 on the falling leg of a high-altitude ballistic trajectory above Iceland]]

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|Help:Traducir]].
|}

== Community news ==
=== FlightGear on YouTube ===

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===

{{cquote|There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.

Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :)

So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too,
if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch.
Suggestions for that means in practice, are most welcome!

Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my
latencies here are measured in weeks.
Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

=== Call for volunteers ===
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support

=== Did you know ===

[[Category:FlightGear Newsletter|2014 01]]
[[Category:Changes after 2.12]]

File:DC-10-30ER Over Mt Everest.jpg

2014-02-02T03:43:30Z

Drdavid: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=FlightGear DC-10-30ER in Lufthansa livery flying in front of Mt Everest.}}
|date=2014-02-01 11:25:44
|source={{own}}
|author=[[User:Drdavid|David]]
|permission=
|other_versions=
|other_fields=
}}
{{Location dec|0|0}}

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

[[Category:FlightGear Newsletter]]

FlightGear Newsletter February 2014

2014-02-02T01:45:52Z

Drdavid: DC-10-30 Getting a Flightdeck Refit Incorporating Latest NavDisplay

== '''DC-10-30 Getting a Flightdeck Refit''' ==

'''David Waggoner, “DrDavid”'''

The DC-10-30 (by Ryan Miller) is getting an updated flightdeck with state of the art glass cockpit avionics. The purpose of the project is to create a theoretical refit of the aircraft as if Boeing/McDonnell-Douglas had continued to produce the airplane. The original instrument panel is historically accurate, but as FlightGear has evolved, the advances in avionics technologies have opened up a whole new universe for giving the pilot real-time situational awareness. It proved too good of a prospect to pass by.

The DC-10-30 makes a great platform for this kind of revision because of its sophisticated flight dynamics, autopilot and it is Rembrandt enabled. Rembrandt provides superior lighting capabilities both outside and inside the aircraft, but not all FG instruments are Rembrandt-compatible. Therefore, a new avionics package had to be functional in that environment.

[[File:DC-10-30_Flightdeck_Day_Screenshot.jpg]]

Fortunately, the CRJ-700 Family Series (also by Ryan Miller) has a glass cockpit set up for Rembrandt. The PFD, MFD, EICAS, CDU, Radio Stack, Upper Light Switch Panel, and Side Panels were transferred from the CRJ700 to the DC-10-30. After much tweaking and trial and error, many, but not all of the CRJ’s screens are functional. In addition, a set of standby instruments have been added to support the three glass screens. Note there is cleanup work to be done on the panel—this is a work in development. The choice of instruments and layout are designed to meet my preferences, but that is expected to continue to progress.
The two screenshots illustrate the great effectiveness of having Rembrandt.

[[File:DC-10-30_Flightdeck_Night_Screenshot.jpg]]

A brilliant opportunity has popped up, however. The release of the new Canvas-ready NavDisplay screens, which will be developed by FlightGear over time to match specific aircraft, is now available. I am now in the process of installing the ND in the DC-10’s MFD. Once a stable MFD is achieved, the aircraft will be uploaded into Git for the FlightGear Community to take a look at. I have a long TODO list for other improvements to the model, and will welcome other collaborators—I suspect you have some ideas I haven’t even thought of that would be great to include. There is also the opportunity to create more liveries for the airplane.

File:DC-10-30 Flightdeck Night Screenshot.jpg

2014-02-02T00:56:31Z

Drdavid: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Screenshot off a FlightGear DC-10-30 with an refitted flightdeck. Night time perspective.}}
|date=2014-02-01 16:50:59
|source={{own}}
|author=[[User:Drdavid|David Waggoner, PhD]]
|permission=
|other_versions=
|other_fields=
}}
{{Location dec|0|0}}
KPDX: Portland International Airport

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

[[Category:FlightGear cockpit screenshots]]

File:DC-10-30 Flightdeck Day Screenshot.jpg

2014-02-02T00:56:29Z

Drdavid: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Screenshot off a FlightGear DC-10-30 with an refitted flightdeck. Daytime perspective.}}
|date=2014-02-01 16:50:58
|source={{own}}
|author=[[User:Drdavid|David Waggoner, PhD]]
|permission=
|other_versions=
|other_fields=
}}
{{Location dec|0|0}}
KPDX: Portland International Airport

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

[[Category:FlightGear cockpit screenshots]]

FlightGear Newsletter February 2014

2014-02-02T00:44:46Z

Drdavid: DC-10-30 Getting a Flightdeck Refit

== '''DC-10-30 Getting a Flightdeck Refit''' ==

'''David Waggoner, “DrDavid”'''

The DC-10-30 (by Ryan Miller) is getting an updated flightdeck with state of the art glass cockpit avionics. The purpose of the project is to create a theoretical refit of the aircraft as if Boeing/McDonnell-Douglas had continued to produce the airplane. The original instrument panel is historically accurate, but as FlightGear has evolved, the advances in avionics technologies have opened up a whole new universe for giving the pilot real-time situational awareness. It proved too good of a prospect to pass by.

The DC-10-30 makes a great platform for this kind of revision because of its sophisticated flight dynamics, autopilot and it is Rembrandt enabled. Rembrandt provides superior lighting capabilities both outside and inside the aircraft, but not all FG instruments are Rembrandt-compatible. Therefore, a new avionics package had to be functional in that environment.

[insert daytime screenshot here]

Fortunately, the CRJ-700 Family Series (also by Ryan Miller) has a glass cockpit set up for Rembrandt. The PFD, MFD, EICAS, CDU, Radio Stack, Upper Light Switch Panel, and Side Panels were transferred from the CRJ700 to the DC-10-30. After much tweaking and trial and error, many, but not all of the CRJ’s screens are functional. In addition, a set of standby instruments have been added to support the three glass screens. Note there is cleanup work to be done on the panel—this is a work in development. The choice of instruments and layout are designed to meet my preferences, but that is expected to continue to progress.
The two screenshots illustrate the great effectiveness of having Rembrandt.

[insert nighttime screenshot here]

A brilliant opportunity has popped up, however. The release of the new Canvas-ready NavDisplay screens, which will be developed by FlightGear over time to match specific aircraft, is now available. I am now in the process of installing the ND in the DC-10’s MFD. Once a stable MFD is achieved, the aircraft will be uploaded into Git for the FlightGear Community to take a look at. I have a long TODO list for other improvements to the model, and will welcome other collaborators—I suspect you have some ideas I haven’t even thought of that would be great to include. There is also the opportunity to create more liveries for the airplane.