FlightGear Newsletter November 2013: Difference between revisions

m
Switch to the {{forum link}} template for all forum links.
m (Switch to the {{forum link}} template for all forum links.)
 
(29 intermediate revisions by 8 users not shown)
Line 2: Line 2:
{{TOC_right|limit=2}}
{{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.''
''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.''


Available in: '''English''', [[Es/FlightGear Newsletter November 2013|Spanish]] (contributed by Wallkon)


Available in: '''English'''
Please help us translate in other languages!
Please help us translate in other languages!


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


The Atmospheric Light Scattering rendering framework adpots a technique that has recently been introduced for the default and the Rembrandt rendering framework which allows to utilize a global map of Ocean water depth. This allows to render the shallow waters around islands in a compelling way. Combined with the ability of ALS to change the basic water color based on location and weather conditions/sky appearance, many combination of shallows, mud content and weather conditions can now be addressed by the highest detail water shader effect.
The Atmospheric Light Scattering rendering framework adopts a technique that has recently been introduced for the default and the Rembrandt rendering framework which allows to utilize a global map of Ocean water depth. This allows to render the shallow waters around islands in a compelling way. Combined with the ability of ALS to change the basic water color based on location and weather conditions/sky appearance, many combination of shallows, mud content and weather conditions can now be addressed by the highest detail water shader effect.


[[File:Depth01.jpg|400px|Water depth mapping in ALS]]  
[[File:Depth01.jpg|400px|Water depth mapping in ALS]]  


=== Initial OsgEarth integration ===
=== Initial OsgEarth integration ===
Thanks to recent work by forum user '''poweroftwo''' we now have initial osgEarth integration featuring a runtime selectable option for the terrain scene in FlightGear. Once enabled, osgEarth renders the terrain scene by building the textured geometry at runtime from raw source imagery and elevation data. Load times for an unvisited location are surprisingly fast given a respectable Internet download rate. For locations previously visited, an optimized file cache data is saved for rapid loading.
Thanks to recent work by forum user '''poweroftwo''' we now have initial osgEarth integration featuring a runtime selectable option for the terrain scene in FlightGear. Once enabled, osgEarth renders the terrain scene by building the textured geometry at runtime from raw source imagery and elevation data. Load times for an unvisited location are surprisingly fast given a respectable Internet download rate. For locations previously visited, an optimized file cache data is saved for rapid loading.


Line 26: Line 22:
The benefits gained from this initial osgEarth integration include geo-specific imagery rendered in real-time from a variety of sources that are available worldwide; tiled terrain on demand; and high altitude views from anywhere above the earth. However, this implementation with FlightGear includes some notable limitations listed in the compromises section.
The benefits gained from this initial osgEarth integration include geo-specific imagery rendered in real-time from a variety of sources that are available worldwide; tiled terrain on demand; and high altitude views from anywhere above the earth. However, this implementation with FlightGear includes some notable limitations listed in the compromises section.


{{#ev:youtube|0aUZTvpdLFU}}  {{#ev:youtube|dZ5JuQ9ZDEQ}}
{{#ev:youtube|0aUZTvpdLFU|400}}  {{#ev:youtube|dZ5JuQ9ZDEQ|400}} {{#ev:youtube|tx-hAo8he5w|400}}
 
Learn more at {{forum link|t=21351|text=the forum topic}}
 
=== Introducing two new frameworks: NavDisplay & MapStructure ===
[[File:MapStructureDialog.png|thumb|MapStructure demo]]
[[File:NavDisplay.png|thumb|A NavDisplay-driven Canvas/GUI dialog]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|Independent NavDisplay instances on Hyde's 777-200ER]]
In a joint effort, Gijs' original Boeing 747-400  NavDisplay/[[Canvas]] code (fully scripted using [[Nasal]]; see the [[FlightGear Newsletter October 2013#Updated aircraft|October newsletter]]) has meanwhile been sufficiently generalized to be also usable in other aircraft without having to copy/paste lots of code (typically, ~30 lines will do now).
 
The Boeing 777-200ER in Hyde's fgdata branch being the very first adopter for the time being, with the added bonus that the 777-200ER now also supports independent ND instances, i.e. independent displays and switches for each pilot. Hyde is also planning on implementing missing 777-specific features.
 
In the meantime, Philosopher and Hooray have started working on a new Nasal framework, called [[MapStructure]], to easily create charting displays like the [[NavDisplay]] with very little specialized Nasal code being required. Once the MapStructure framework is completed, we will work towards porting our old *.layer/*.draw/*.model files to make use of the new MapStructure framework and adapt the NavDisplay framework accordingly.
 
MapStructure is going to be common backend for all charting needs in FlightGear, not just in instruments (i.e. MFDs like the ND), but also in GUI dialogs (Map, instructor console, ATC etc).
 
Currently, there are still some minor performance issues (especially on less powerful computers), which we hope to resolve by moving some parts into C++ space, hopefully in time for the 3.0 release (Our Canvas/C++ guys, TheTom and Zakalawe are looking into it).


Learn more at http://forum.flightgear.org/viewtopic.php?f=6&t=21351
Please get in touch if you have any questions or if you'd like to get involved in some way.


=== Getting started with CppBind ===
=== Getting started with CppBind ===
Line 50: Line 62:
Continue reading at [[Nasal/CppBind]]...
Continue reading at [[Nasal/CppBind]]...


=== FGRun repository changes ===
=== JSBSim Flight Dynamics Model Validation Effort ===
The [http://gitorious.org/fg/fgrun FGRun Git repository] now uses the same branch concept as FlightGear and SimGear. Current development takes place in the <code>next</code> branch, while <code>release/X.X</code> branches are created for each release. In addition to that the FGRun version number is now in sync with FlightGear/SimGear, to make it easier to see whether your FGRun and FlightGear builds match.
[[JSBSim]] (one of the flight dynamics models featured in FlightGear) is currently being validated against a set of simulations used at various NASA centers. A set of check cases is under development and is expected to be published next year. The check cases are numerous and rigorous and encompass both atmospheric and orbital scenarios. Early comparisons between JSBSim and the other simulations show very good matching for the atmospheric cases compared so far.
 
=== New Control System Component in JSBSim ===
A new control system component has been added recently to JSBSim. It is called the distributor component. This article is a quick introduction to the distributor component, and it includes a description on one way that it has been used.
You may know that the switch component features a default value that the switch takes if none of the test conditions evaluate to true. The first test condition that evaluates to true also dictates the value that the switch takes.
With the distributor component, the component does not take on a value of its own (in fact, the value of the component – which still must be named – is always zero).
 
The exact syntax of the distributor component is as follows:
<syntaxhighlight lang="xml">
<distributor name="name/is/irrelevant" type="exclusive|inclusive">
 
  <case>
    [<test logic="{AND|OR}" value="{property|value}">
      {property} {conditional} {property|value}
      <test logic="{AND|OR}">
        {property} {conditional} {property|value}
        ...
      </test>
      ...
    </test>]
    <property value="number|property"> property_name </property>
    ...
  </case>
 
  ... <!-- Additional optional cases -->
 
</distributor>
</syntaxhighlight>
There’s more to this, though, as this is one of the more capable, but complex, components in the set of JSBSim control system components. The distributor component features one or more <case> elements. Each <case> element may contain a <test> element (which may contain either conditional test statements, or one or more nested tests). Each <case> element will also contain one or more property statements with a value to be set. A <case> element with no tests will always be executed (have its property values set as stated). A distributor component can have a type of either exclusive or inclusive. An exclusive distributor will only execute the first <case> element that is encountered that has a test that evaluates to true. An inclusive distributor will execute all <case> elements for which the supplied test evaluates to true. In both cases, any and all <case> elements that have no tests will always be executed in the order that they are encountered.
Each <case> element will have one or more property values to be set, and each <case> element does not need to feature the same set of properties to be set.
 
This component is very useful in cases where (for example) guidance, navigation, and control laws are defined, where - for certain modes of operation - various control system approaches and target values must be set simultaneously. The distributor component can also serve as a sort of relay, featuring a <case> element with no test, and several <property> elements.
Here’s an example where one might have a set of sequential “modes” that a launch vehicle might cycle through in order during ascent:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<!DOCTYPE system [
  <!ENTITY Off "0">
  <!ENTITY On  "1">
  <!ENTITY InitialRise  "1">
  <!ENTITY GravityTurn  "1">
  <!ENTITY EngineCutoff "2">
  <!ENTITY RateHold    "0">
]>
<system name="Demo Rocket Guidance Executive"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://jsbsim.sf.net/JSBSimSystem.xsd"
        xsi:noNamespaceSchemaLocation="http://jsbsim.sf.net/JSBSimSystem.xsd">
 
  <property value="0"> executive/mode </property>
  <property value="0"> executive/clock/advance-burn-clock </property>
  <property value="1"> executive/clock/advance-met-clock </property>
  <property value="0"> guidance/pitch/rate-target-rad_sec </property>
  <property value="0"> guidance/yaw/rate-target-rad_sec </property>
  <property value="0"> guidance/roll/rate-target-rad_sec </property>
 
  <channel name="Executive Mode Sequencer">
 
    <integrator name="executive/clock/mission-elapsed-time">
      <input> executive/clock/advance-met-clock </input>
      <c1> 1 </c1>
    </integrator>
 
    <integrator name="executive/clock/elapsed-burn-time">
      <input> executive/clock/advance-burn-clock </input>
      <c1> 1 </c1>
    </integrator>
   
    <distributor name="executive/sequencer" type="exclusive">


=== Random Buildings ===
      <case>
        <test>
          executive/clock/mission-elapsed-time gt 0.1
          executive/mode eq &Off;
        </test>
        <property value="&InitialRise;"> executive/mode </property>
        <property value="&On;"> propulsion/engine[0]/throttle-cmd </property>
        <property value="&On;"> propulsion/engine[1]/throttle-cmd </property>
        <property value="&RateHold;"> control/pitch/mode </property>
        <property value="&RateHold;"> control/roll/mode </property>
        <property value="&RateHold;"> control/yaw/mode </property>
        <property value="&On"> executive/clock/advance-burn-clock </property>
      </case>


=== Canvas System ===
      <case>
        <test>
          executive/clock/mission-elapsed-time ge 10
          executive/mode eq &InitialRise;
        </test>
        <property value="&GravityTurn;"> executive/mode </property>
        <property value="-0.05"> guidance/pitch/rate-target-rad_sec </property>
      </case>


=== High Level Architecture ===
      <case>
        <test>
          executive/clock/mission-elapsed-time gt 122
          executive/mode eq &GravityTurn;
        </test>
        <property value="&EngineCutoff;"> executive/mode </property>
        <property value="&Off;"> propulsion/engine[0]/throttle-cmd </property>
        <property value="&Off;"> propulsion/engine[1]/throttle-cmd </property>
        <property value="&Off;"> executive/clock/advance-burn-clock </property>
      </case>


=== Usability Improvements ===
    </distributor>


=== Getting involved as a programmer ===
  </channel>
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.
</syntaxhighlight>
As you can see, each mode occurs sequentially and causes a number of properties to be set for each case. Note also the definitions used in the various elements and attributes – these can be used to make the code more readable and comprehensible. Definitions (similar to #defines in C/C++) are declared at the top of the file using the !ENTITY construct.  


If you are interested in contributing as a core developer, please see [[Howto:Start core development]].
=== FGRun repository changes ===
The {{gitorious source|proj=fg|repo=fgrun|text=FGRun Git repository}} now uses the same branch concept as FlightGear and SimGear. Current development takes place in the <code>next</code> branch, while <code>release/X.X</code> branches are created for each release. In addition to that the FGRun version number is now in sync with FlightGear/SimGear, to make it easier to see whether your FGRun and FlightGear builds match.


== Release ChangeLog ==
=== The Walker ===
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.
The Walker is currently made portable to be easily incorporated in arbitrary aircraft. Additionally, an animatable pilot model for cockpit placement is in development. Walker and crew will be supporting different hand poses, such as pointing, a fist, thumbsup or a victory sign.


== Interview with a contributor (NAME) ==
[[File:Walker Waldo.png|400px|The male Walker]] [[File:Walker Amelie.png|400px|The female Walker]]
''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?
[[File:Walker pilot model.png|400px|A pilot model, co-pilot and crew are to come.]] [[File:Walker hand poses.png|x211px|Hand Poses that will be selectable within the animation dialog]]
* 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]].
=== 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.


Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX
If you are interested in contributing as a core developer, please see [[Howto:Start core development]].


== Nasal Internals for hackers: Intern'ing symbols ==
== Nasal Internals for hackers: Intern'ing symbols ==
Line 117: Line 219:
For this reason, I would suggest amending naiHash_newsym to check keys' pointer equality before continuing; that way symbols aren't "trodden" over like this. (Please note that if "arg" exists in the hash as non-interned, then it will be trodden over anyways; having to look for non-interned symbols would mainly violate the point of the optimization at this step, and doesn't actually matter in the long run.) I would argue that finding an existing key (a few simple pointer comparisons!) would be more efficient generally, because the hash would never need to be resized if an existing one is found, whereas the old version would append regardless. (I think I once counted well over a hundred "arg" symbols in the __js0 namespace from the continual firing of bindings, which obviously isn't good.)
For this reason, I would suggest amending naiHash_newsym to check keys' pointer equality before continuing; that way symbols aren't "trodden" over like this. (Please note that if "arg" exists in the hash as non-interned, then it will be trodden over anyways; having to look for non-interned symbols would mainly violate the point of the optimization at this step, and doesn't actually matter in the long run.) I would argue that finding an existing key (a few simple pointer comparisons!) would be more efficient generally, because the hash would never need to be resized if an existing one is found, whereas the old version would append regardless. (I think I once counted well over a hundred "arg" symbols in the __js0 namespace from the continual firing of bindings, which obviously isn't good.)


Continue reading at [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].
Continue reading at {{forum link|p=193935}}.
 
== New software tools and projects ==


== FlightGear addons and mods ==
== FlightGear addons and mods ==
====New textures and lightmaps for random buildings====
=== New textures and lightmaps for random buildings ===
 
New textures and lightmaps for the random buildings areas.
[[File:Lightmap terrain at noon.png|thumb|220px|Lightmap terrain at noon]]
[[File:Lightmap terrain at noon.png|thumb|220px|Lightmap terrain at noon]]
[[File:Lightmap terrain at night.png|thumb|220px|Lightmap terrain at night]]
[[File:Lightmap terrain at night.png|thumb|220px|Lightmap terrain at night]]
Line 130: Line 228:


Installation:
Installation:
# Download from [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# Unzip the file
# Copy, paste and replace
#* urban.eff at [[$FG_ROOT]]/Effects/
#* urban.frag , urban-gbuffer.frag and urban-lightfield.frag at $FG ROOT/Shaders/
#* buildings.png and buildings-lightmap at $FG ROOT/Textures/
# I suggest to change the random building density to the middle of your computer default settings, you can make this by edit at [[FlightGear configuration via XML|autosave.xml or autosave_2_12.xml]] (depend your version), at the line "<building-density type="double">1</building-density>"


1- unzip the file
If you want to go back to the default effects, please download [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip this package] and follow the installation instructions again.
 
2- copy, paste and replace
a) urban.eff at $FG ROOT/Effects/
b) urban.frag , urban-gbuffer.frag and urban-lightfield.frag at $FG ROOT/Shaders/
c) buildings.png and buildings-lightmap at $FG ROOT/Textures/
 
3- i suggest to change the random building density to the middle of your computer default settings, you can make this by edit at autosave.xml or autosave_2_12.xml (depend your version), at the line "<building-density type="double">1</building-density>"
 
4- FAQ
 
Where is $FG ROOT? please click [[$FG ROOT|here]]
 
Where is autosave.xml or autosave_2_12.xml? please click [[FlightGear configuration via XML|here]]
 
If you want to go back to the default effects, please download this package and follow the installation instructions again
 
Download from [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
 
Download default textures and effects from [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip here]
 
 
 


<gallery>
<gallery>
Line 162: Line 245:
File:Reflection map at night.png
File:Reflection map at night.png
</gallery>
</gallery>
== In the hangar ==
== In the hangar ==
==== Tupolev Tu-134 ====
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|The "whistle" taking speed for take-off.]]
[[File:Tu134_aeroflot.png|thumb|270px|The "whistle" taking speed for take-off.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|You can choose one of the 3 noses.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|You can choose one of the 3 noses.]]
The [[Tupolev Tu-134]] development team proudly announce a new soviet airliner for FlightGear! Some have already read a topic about it at the forum. The release of version 1.0 is available for download [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip from here]. This YAsim aircraft has a very good FDM, great exterior and a basic cockpit. To contribute (improve the cockpit for example) contact us at the {{forum link|t=15908|text=forum}}
The [[Tupolev Tu-134]] dev team proudly announce a new soviet airliner for FlightGear! Some have already read a topic about it at the Forum. The release of version 1.0 is underway and will arrive soon. This YAsim aircraft has a very good FDM, great exterior and a basic cockpit. To contribute (read improve cockpit for example) contact us at the [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 forum]
 
'''Promo movie'''
{{#ev:youtube|IbUMgRvEih0}}
{{#ev:youtube|IbUMgRvEih0}}
 
 
Many Thanks to Helijah, Buckaroo, Cossack90.
Many thanks to Helijah, Buckaroo, Cossack90.
 
=== New aircraft ===
=== New aircraft ===
The Oasis of the Seas has been released to the public and getting updates, it's sister ships and ferries are coming in from the ACJZA Hangar as well! If you have any skill with coding, it'll be thankful if you could help me. http://forum.flightgear.org/viewtopic.php?f=4&t=21277  
Not an aircraft but a cruise ship, Oasis of the Seas has been released to the public and getting updates, it's sister ships and ferries are coming in from the ACJZA Hangar as well! If you have any skill with coding, it'll be thankful if you could help me. More information and download at {{forum link|t=21277|text=the forum topic}}
 
=== Updated aircraft ===
=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|Even the pilot window can be opened now]]
The [[Eurocopter EC130 B4]] helicopter is on short final for a new major upgrade.
The existing model, which already had been of very high quality, has been refined in various aspects with lots of effort by '''mhab'''. The outside model has been enriched to a degree which should justify a '''''5*''''' rating and the overall status of the aircraft improves to "'''''production'''''".
The '''Rotorhead''' has been brought to a new level of detail, a full detailed '''Fenestron''' was added and animations were introduced to all moving parts.


=== Liveries ===
'''Cockpit''' was enriched for Pilot/Copilot controls, seats are textured now and a variable cabin configuration allows to set up an '''Emergency Medical Services (EMS) variant''', which comes preconfigured with a new Livery of '''N130NE MedFlight''' (Ohio).


== Scenery corner ==
Fans of '''Grand Canyon Helicopters''' now find a livery of the N155GC and the colorful painting in red/gold.
=== Airports ===


== Aircraft of the month ==
A lot of '''equipment''' (most of which was there already but hidden) can now be used, including a full blown '''SX16-Nightsun searchlight'''.
== Airport of the month ==
== Screenshot of the month ==


== Suggested flights ==
All of this has been brought together in a fully integrated configuration dialog which allows to set-up livery, fuel, extra views, weights, cabin setup and equipment.
== Aircraft reviews ==
 
Extra gimmics include a fully animated pilot, glass reflection on windows and front shield and variable rotor wakes depending on the strength of the downwash.
 
'''If you can't wait''' for the next release '''{{gitorious source|proj=ec130|repo=ec130|text=check it out from the Git-Hangar}}'''
 
<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>
 
'''Some of the most interesting changes:'''
 
* '''Mainrotor''' fully animated and adapted to original                                 
* '''Fenestron''' fully designed and animated, incl. control rod                         
* '''Cockpit Controls''' added: Stick, Collective, Pedals,  Co-Pilot Controls (optional)                                                           
* '''Doors''' movable                                                                 
* '''Searchlight'''                                                                     
* '''Snowshoes'''                                                                         
* '''Hoist/Hook'''                                                                       
* '''Checklists''' implemented with conditional display                                   
* '''Pilot''': ''fully animated''                                                             
* '''Autostart/Autoshutdown''' enabled after 15 flights                                  
* '''Rotor-Wakes''' off-low-medium-high cyclable                                         
* '''Sound improved''' (doors moving, low/high rotor rpm, overspeed warning, and noise inside depends on open doors/window)                                                                   
 
 
'''Configuration Dialogs and Help Screens:'''
 
<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>
 
'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing


== Wiki updates ==
== Wiki updates ==
Line 212: Line 338:
|}
|}


== Community news ==
=== FlightGear on YouTube ===
=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===
== Useful links ==
== And finally ... ==
== And finally ... ==
=== Contributing ===
=== Contributing ===
Line 228: Line 344:
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].
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]].
To learn more about how the project works, please see {{forum link|p=149971|text=this short essay}} written by Thorsten, for a more detailed article see [[How the FlightGear project works]].


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


[[Category:FlightGear Newsletter|2013 11]]
[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]
[[Category:Changes after 2.12]]