FlightGear wiki - User contributions [en]

FlightGear Newsletter November 2013

2013-12-01T20:14:00Z

Jonsberndt:

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

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

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

=== Atmospheric Light Scattering ===

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

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

Input data can come from a variety of sources including web mapping services or local source data (e.g. geotiff) stored on disk. Once rendering is enabled, the entire FlightGear terrain scene graph is replaced along as well as the scene elevation queries. However, the native terrain implementation remains fully intact and can be restored by disabling osgEarth from its configuration dialog.

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

Learn more at http://forum.flightgear.org/viewtopic.php?f=6&t=21351

=== 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 744 NavDisplay/[[Canvas]] code (fully scripted using [[Nasal]]) 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).

Hyde's 777-200ER 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. Currently, none of this is in fgdata yet, but Gijs and Hyde are going to review the new NavDisplay framework to hopefully get it committed soon.

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

Please get in touch if you have any questions or if you'd like to get involved in some way.

=== Getting started with CppBind ===

FlightGear's built-in [[Nasal]] scripting language comes with a set of standard libraries, and can be extended using FlightGear specific APIs.

Until FlightGear 2.8, the [[Nasal]] scripting engine only provided a C API to expose such hooks/bindings to scripting space or to expose scripting space data structures back to C/C++.

Exposing simulator internals to scripting space is a fairly common and useful thing, because it enables base package developers to access these internals without having to build FlightGear from source, so the barrier to entry is significantly lower and we've seen an increasing number of novel features purely implemented in scripting space, due to powerful APIs being available to aircraft developers and other base package developers.

Unlike the core Nasal engine itself (which is C), FlightGear however is mostly written and being developed in C++. For quite a while, that meant that the Nasal APIs were a bit low-level, and sometimes also awkward to use when making functions, data structures or objects accessible between C++ and Nasal.

Thanks to Tom's [[Canvas]] system, there's now a new bindings framework to be found in simgear/nasal/cppbind. This is fully object oriented and supports modern C++ features.

You will find that most of the "old" code in $FG_SRC/Scripting still uses those old C-APIs for interacting with the Nasal engine. Only the new code, #include'ing <simgear/nasal/cppbind>, uses boost templates to hide low level details.

Most of the code in the Nasal subsystem itself (FGNasalSys) also still uses the legacy C APIs - this is just to explain the two approaches, to avoid unnecessary confusion. You will find the old, low-level APIs explained at [[Howto:Extend Nasal]].

The cppbind framework is much more generic and high level than the bare C APIs, cppbind includes unit testing support and makes use of modern C++ features like templates and STL support, including SimGear specific types like SGPath/SGGeod etc, its overhead is fairly small (not just performance, but also LoC to create new bindings). The cppbind framework is already extensively used by the Canvas system and the NasalPositioned_cppbind bindings, both of which are a good place to look for code examples.

Continue reading at [[Nasal/CppBind]]...

=== JSBSim Flight Dynamics Model Validation Effort ===
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>

... 

</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">

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

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

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

</distributor>

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

=== FGRun repository changes ===
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.

=== The Walker ===
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.

[[File:Walker Waldo.png|400px|The male Walker]]
[[File:Walker Amelie.png|400px|The female Walker]]
[[File:Walker pilot model.png|400px|A Pilot Model, Co-Pilot and Crew are to come.]]
[[File:Walker hand poses.png|400px|Hand Poses that will be selectable within the Animation Dialog]]

=== Random Buildings ===

=== 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 Internals for hackers: Intern'ing symbols ==
''Contributed by Philosopher''

As some of you experienced Nasal/C-code hackers should recall, or even those familiar with scripting languages internals, namespaces are just hashes, with keys representing symbols - right? Well yes, mostly, but each of those symbols are unique in a way from all of the other strings out there: they're interned. (Interning is a process that takes strings and a dictionary and returns a matching string, adding one if needed. That means equal strings are substituted so they have the same pointer, i.e. one string represents all instances of "io", stored in a pool/hash of all used symbols.) Though these interned strings appear at runtime in the keys in namespaces, they get created during code generation (codegen), where the symbols (TOK_SYMBOL) get converted to Nasal strings, are interned to get the correct string (using the globals->symbols hash), and are stored in the naCode's constants' block. From there, the symbol-strings are used to set and get various lvalues (both local/global symbols and objects' members) in an optimized way (that's the whole point of the exercise). Looking at hash.c, there are some specialized functions that make use of the potential optimizations:

* naiHash_sym (looks up an interned symbol)
* naiHash_newsym (adds a symbol in the first empty slot for the hashcode)

(There's another that looks similar, naiHash_tryset, but it does not deal with interned symbols: it uses the findkey() method, which in turn uses the equals() method that checks for more general key equality instead of simple pointer equality.)

The first, naiHash_sym, is pretty neat and the prime example of the optimization: it runs through a hashcode's potential slots, checking only pointer equality (note that interned symbols' hashcodes are computed during interning, so that's another step that doesn't have to be done are runtime). naiHash_newsym is another nice optimization but a little problematic, due to its assumption that the key doesn't exist already. It's basically used for adding another argument as a local key, but it doesn't care about if it exists already, it just sees an occupied slot and keeps going. Consider the following example that illustrates calling with an argument into a hash that already has the argument's key in it:

<syntaxhighlight lang="nasal">
var f_creates_arg = func(arg...) {
foreach (var k; keys(caller(0)[0]))
print(k);
debug.dump(arg);
}
call(f_creates_arg, nil, nil, {arg:nil}); # call into namespace: arg=nil; with arguments of: arg=[]
</syntaxhighlight>

This should print:
<pre>
arg
arg
nil
</pre>

This shows that the key is being set twice (which violates a normal precondition of hashes): once as an argument and once to create an existing key in the namespace. The one set first is the one being picked up (e.g. the arg in {arg:nil} versus the arg... that equals []). And this behavior persists even through resizing: hashset() (which is used to reinitialize a hash after reallocation) only keeps appending keys in empty slots, so the number of keys doesn't change (even if there are multiple of the same keys).

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

== New software tools and projects ==

== FlightGear addons and mods ==
====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 night.png|thumb|220px|Lightmap terrain at night]]
The urban lightmap works using a modified urban shader + modified urban effect, the modified files need to be improve to make work the original urban shader when the random building function is off and enable new shader when the random building function is on.

Installation:

1- unzip the file

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>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>
== In the hangar ==
==== Tupolev Tu-134 ====

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

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 HERE [[https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip download]]. 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}}

Many Thanks to Helijah, Buckaroo, Cossack90.

=== 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
=== Updated aircraft ===
'''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.

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

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

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

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.

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 '''[https://gitorious.org/ec130/ 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

=== Liveries ===

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

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

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

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

=== Did you know ===

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

FlightGear Newsletter November 2013

2013-12-01T20:02:37Z

Jonsberndt:

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

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

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

=== Atmospheric Light Scattering ===

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

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

Input data can come from a variety of sources including web mapping services or local source data (e.g. geotiff) stored on disk. Once rendering is enabled, the entire FlightGear terrain scene graph is replaced along as well as the scene elevation queries. However, the native terrain implementation remains fully intact and can be restored by disabling osgEarth from its configuration dialog.

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

Learn more at http://forum.flightgear.org/viewtopic.php?f=6&t=21351

=== 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 744 NavDisplay/[[Canvas]] code (fully scripted using [[Nasal]]) 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).

Hyde's 777-200ER 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. Currently, none of this is in fgdata yet, but Gijs and Hyde are going to review the new NavDisplay framework to hopefully get it committed soon.

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

Please get in touch if you have any questions or if you'd like to get involved in some way.

=== Getting started with CppBind ===

FlightGear's built-in [[Nasal]] scripting language comes with a set of standard libraries, and can be extended using FlightGear specific APIs.

Until FlightGear 2.8, the [[Nasal]] scripting engine only provided a C API to expose such hooks/bindings to scripting space or to expose scripting space data structures back to C/C++.

Exposing simulator internals to scripting space is a fairly common and useful thing, because it enables base package developers to access these internals without having to build FlightGear from source, so the barrier to entry is significantly lower and we've seen an increasing number of novel features purely implemented in scripting space, due to powerful APIs being available to aircraft developers and other base package developers.

Unlike the core Nasal engine itself (which is C), FlightGear however is mostly written and being developed in C++. For quite a while, that meant that the Nasal APIs were a bit low-level, and sometimes also awkward to use when making functions, data structures or objects accessible between C++ and Nasal.

Thanks to Tom's [[Canvas]] system, there's now a new bindings framework to be found in simgear/nasal/cppbind. This is fully object oriented and supports modern C++ features.

You will find that most of the "old" code in $FG_SRC/Scripting still uses those old C-APIs for interacting with the Nasal engine. Only the new code, #include'ing <simgear/nasal/cppbind>, uses boost templates to hide low level details.

Most of the code in the Nasal subsystem itself (FGNasalSys) also still uses the legacy C APIs - this is just to explain the two approaches, to avoid unnecessary confusion. You will find the old, low-level APIs explained at [[Howto:Extend Nasal]].

The cppbind framework is much more generic and high level than the bare C APIs, cppbind includes unit testing support and makes use of modern C++ features like templates and STL support, including SimGear specific types like SGPath/SGGeod etc, its overhead is fairly small (not just performance, but also LoC to create new bindings). The cppbind framework is already extensively used by the Canvas system and the NasalPositioned_cppbind bindings, both of which are a good place to look for code examples.

Continue reading at [[Nasal/CppBind]]...

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

... 

</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">

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

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

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

</distributor>

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

=== FGRun repository changes ===
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.

=== The Walker ===
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.

[[File:Walker Waldo.png|400px|The male Walker]]
[[File:Walker Amelie.png|400px|The female Walker]]
[[File:Walker pilot model.png|400px|A Pilot Model, Co-Pilot and Crew are to come.]]
[[File:Walker hand poses.png|400px|Hand Poses that will be selectable within the Animation Dialog]]

=== Random Buildings ===

=== 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 Internals for hackers: Intern'ing symbols ==
''Contributed by Philosopher''

As some of you experienced Nasal/C-code hackers should recall, or even those familiar with scripting languages internals, namespaces are just hashes, with keys representing symbols - right? Well yes, mostly, but each of those symbols are unique in a way from all of the other strings out there: they're interned. (Interning is a process that takes strings and a dictionary and returns a matching string, adding one if needed. That means equal strings are substituted so they have the same pointer, i.e. one string represents all instances of "io", stored in a pool/hash of all used symbols.) Though these interned strings appear at runtime in the keys in namespaces, they get created during code generation (codegen), where the symbols (TOK_SYMBOL) get converted to Nasal strings, are interned to get the correct string (using the globals->symbols hash), and are stored in the naCode's constants' block. From there, the symbol-strings are used to set and get various lvalues (both local/global symbols and objects' members) in an optimized way (that's the whole point of the exercise). Looking at hash.c, there are some specialized functions that make use of the potential optimizations:

* naiHash_sym (looks up an interned symbol)
* naiHash_newsym (adds a symbol in the first empty slot for the hashcode)

(There's another that looks similar, naiHash_tryset, but it does not deal with interned symbols: it uses the findkey() method, which in turn uses the equals() method that checks for more general key equality instead of simple pointer equality.)

The first, naiHash_sym, is pretty neat and the prime example of the optimization: it runs through a hashcode's potential slots, checking only pointer equality (note that interned symbols' hashcodes are computed during interning, so that's another step that doesn't have to be done are runtime). naiHash_newsym is another nice optimization but a little problematic, due to its assumption that the key doesn't exist already. It's basically used for adding another argument as a local key, but it doesn't care about if it exists already, it just sees an occupied slot and keeps going. Consider the following example that illustrates calling with an argument into a hash that already has the argument's key in it:

<syntaxhighlight lang="nasal">
var f_creates_arg = func(arg...) {
foreach (var k; keys(caller(0)[0]))
print(k);
debug.dump(arg);
}
call(f_creates_arg, nil, nil, {arg:nil}); # call into namespace: arg=nil; with arguments of: arg=[]
</syntaxhighlight>

This should print:
<pre>
arg
arg
nil
</pre>

This shows that the key is being set twice (which violates a normal precondition of hashes): once as an argument and once to create an existing key in the namespace. The one set first is the one being picked up (e.g. the arg in {arg:nil} versus the arg... that equals []). And this behavior persists even through resizing: hashset() (which is used to reinitialize a hash after reallocation) only keeps appending keys in empty slots, so the number of keys doesn't change (even if there are multiple of the same keys).

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

== New software tools and projects ==

== FlightGear addons and mods ==
====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 night.png|thumb|220px|Lightmap terrain at night]]
The urban lightmap works using a modified urban shader + modified urban effect, the modified files need to be improve to make work the original urban shader when the random building function is off and enable new shader when the random building function is on.

Installation:

1- unzip the file

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>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>
== In the hangar ==
==== Tupolev Tu-134 ====

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

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 HERE [[https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip download]]. 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}}

Many Thanks to Helijah, Buckaroo, Cossack90.

=== 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
=== Updated aircraft ===
'''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.

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

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

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

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.

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 '''[https://gitorious.org/ec130/ 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

=== Liveries ===

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

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

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

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

=== Did you know ===

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

FlightGear Newsletter May 2012

2012-05-10T04:00:33Z

Jonsberndt: /* Interview with a contributor (Jon Berndt) */

FlightGear Newsletter May 2012

2012-05-10T04:00:11Z

Jonsberndt: /* Interview with a contributor (Jon Berndt) */

FlightGear Newsletter May 2012

2012-05-10T03:52:21Z

Jonsberndt: /* Interview with a contributor (Jon Berndt) */

File:Jon B..jpg

2012-05-10T03:51:18Z

Jonsberndt:

=={{int:filedesc}}==
{{Information
|description={{en|1=Photo of Jon S. Berndt, JSBSim Development Coordinator}}
|date=2011-05-08
|source={{own}}
|author=[[User:Jonsberndt|Jonsberndt]]
|permission=
|other_versions=
|other_fields=
}}

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

FlightGear Newsletter May 2012

2012-05-10T03:36:45Z

Jonsberndt: /* Interview with a contributor (Jon Berndt) */

FlightGear Newsletter May 2012

2012-05-10T03:35:48Z

Jonsberndt: /* Interview with a contributor (Jon Berndt) */

FlightGear Newsletter May 2012

2012-05-09T12:39:01Z

Jonsberndt: Beginning to answer questions and add new ones.

FlightGear Newsletter May 2012

2012-05-09T04:37:45Z

Jonsberndt: /* Interview with a contributor (NAME) */

JSBSim Aerodynamics

2011-09-07T12:14:24Z

Jonsberndt: /* Frames */ Fixed definition of Wind frame.

[[JSBSim]] provides a framework for aerodynamics. This page will attempt to explain how to translate traditional aerodynamics concepts into the [[JSBSim]] framework, and how to create [[FDM]]s that are sane for any flight value.

This page uses the term "coefficient" both the traditional sense of a constant multiplicative factor or in the [[JSBSim]] sense of the output of a function derived from a coefficient.

JSBSim provides three [[#Forces|Forces]] and three [[#Moments|Moments]] (a moment is a twisting or turning force), therefore it is a 'six degree of freedom' simulation.

== Frames ==
JSBSim incorporates several frame of reference. The body frame and wind frame are the most important to the aerodynamic model.
* '''Body XYZ''' The body frame uses the X axis for forward and aft, with + to the front. The Y axis is side to side with + to the right. The Z axis is up and down, with + being up. The origin of this frame is the Center of Gravity (CG), about which the aircraft forces and moments are summed and the resulting accelerations are integrated to get velocities.

* '''Wind XYZ''' The wind frame X-axis points directly into the relative wind. The Z-axis is perpendicular to the X-axis, and remains within the aircraft body axis XZ plane (also called the reference plane). The Y-axis completes a right hand coordinate system. The origin of this frame is the AeroRP.

* '''Wind UVW''' This isn't really a frame, but it is the components of the wind velocity vector. The relative wind is imposed on the body frame using variables U,V, and W. U to represent the velocity of the wind flowing past the aircraft. U represents the wind blowing down the X or longitudinal axis of the aircraft. V represents the wind blowing down the body frame Y axis, that is, wind in your ear. W represents wind blowing down the body frame Z axis, or wind from above.

== Angles ==
These two angles define the direction the relative wind is blowing in regard to the body frame.
* '''Alpha''' Alpha is the angle between the X body axis and the X wind axis measured on the UV plane. In standard aerodynamics Alpha is often referenced to the main wing chord line, this is not the case in [[JSBSim]].
* '''Beta''' Beta is the angle between the X body axis and the X wind axis measured in the UW plane.

== QBar ==
QBar, or dynamic pressure, is the product of velocity^2*(air density)/2
* '''QBarUV''' Use this value for formula involving Alpha. It is the value of QBar restricted to the vertical plane.
* '''QBarUW''' Use this value for formula involving Beta. It is the value of QBar restricted to the horizontal plane.

== Metrics ==
The metrics section provides a standard place to record common aircraft dimensions. [[Aeromatic]] built [[FDM]]s only use three of the defined properties.
* Wing Area - metrics/Sw-sqft
* Wing Span - metrics/bw-ft
* Wing Chord - metrics/cbarw-ft

Other dimensions [[Aeromatic]] creates but does not use are: (tail arms are used by the JSBSim Turbulence code)
* Horizontal Tail Area - Sh-sqft
* Horizontal Tail Arm - lh-ft
* Vertical Tail Area - Sv-sqft
* Vertical Tail Arm - lv-ft

== Forces ==
For purposes of the Aerodynamics section the entire aircraft creates a single, unified aerodynamic force. This force is split into three component vectors. The most common way of splitting this force into vectors is the Lift Drag Side method. Another, potential better way from the perspective of generating a full 360 degree capable [[FDM]], is the Normal, Axial, Side method.
* '''Lift: CL''' Lift is the portion of the aerodynamic force that is at a right angle to the relative wind, and points up.
** Lift is a function of QBar * Wing Area * Cl<sub>lift</sub>. Cl<sub>lift</sub> is generally derived from a 2D table as a function of AoA. In the real world it is also a function of the Reynolds and Mach Numbers.
* '''Drag: CD''' Drag is the portion of the aerodynamic force that is parallel to the relative wind.
** It is important to ensure all coefficient functions in the drag section remain positive. When drag coefficient functions are negative, drag is effectively acting as thrust opposite the relative wind.
* '''Side: CY''' Side is the portion of the aerodynamic force that is at a right angle to the relative wind and points to the side.

This system was developed by and for people using wind tunnels. Lift is to the top of the wind tunnel, drag is out the back and side is to the side. As a real aircraft in free space yanks and banks it becomes somewhat ambiguous which direction the forces are applied. For example, an aircraft is diving straight at the ground, 90 degrees nose down pitch. Its angle of attack, and the relative wind, is almost 0. 'Lift' is supposed to be perpendicular to the relative wind and point to the heavens, but there is not a vector that satisfies that description in this case.

Enter the Axial, Normal, Side system.
* '''Axial: CA''' Axial force is the portion of the aerodynamic force that is parallel to the aircraft's longitudinal (X) axis. For very small angles of attack it is analogous to Drag.
* '''Normal: CN''' Normal force is the portion of the aerodynamic force that is parallel to the aircraft's vertical (Z) axis. For very small angles of attack it is analogous to Lift.
* '''Side: CY''' Side is the portion of the aerodynamic force that is parallel to the aircraft's lateral (Y) axis.

Which ever system is used, the forces are applied at the Aerodynamic Reference Point (AeroRP). If the AeroRP is not coincident to the model's center of gravity (CG), yaw, pitch and roll moments are created that do not appear in the moments sections.

== Moments ==
* '''Roll: Cl''' Aerodynamic rolling moment comes from multiple sources:
** One is the lift generated by the vertical tail. On most aircraft the center of pressure for the vertical tail is not on the X body axis. This sets up a moment arm creating a moment of (moment arm length)*(vertical tail lift force).
** Another roll moment source is main wing dihedral angle. FIXME: explain how dihedral contributes to roll moment.
* '''Pitch: Cm''' The primary contributor to the pitching moment is the lift generated by the horizontal tail. The pitching moment of the main wing airfoil is a secondary contributor. Because of this fact it makes sense that the value for Cm will resemble the CL curve for the horizontal tail airfoil. The standard CL curve does not take into account the changes in tail Angle of Attack (AoA) and QBar due to main wing down-wash and rotational velocity around the Y axis. Using QBarUV is more appropriate for Cm than the generic QBar.
* '''Yaw: Cn''' The primary contributor to the yawing moment is the lift generated by the vertical tail. The wind force on the fuselage is a secondary contributor. Because of this fact it makes sense that the value for Cn will resemble the CL curve for the vertical tail airfoil. Changes in QBar due to the vertical tail moving into the 'shadow' of a stalled main wing may need to be accounted for, as well. The source for vertical tail Angle of Attack (AoA) should be Beta and QBarUW is more appropriate for Cn than the generic QBar.

== Effects ==
* '''Stall''' - A 'stall' is generally regarded as a loss of lift due to flow separation over the top of a wing, however, examination of lift polar for an airfoil over a full 360 degrees shows that significant amounts of lift are NOT lost as the stall occurs. The biggest aerodynamic effect of a stall is a large and rapid increase in drag.
* '''Spin''' - Spins are caused loss of stability in the Yaw Moment axis. A stock [[Aeromatic]] [[FDM]] yaw section does not take alpha into account when calculating the yaw moment.

{{JSBSim}}

FlightGear Newsletter September 2010

2010-09-23T01:45:33Z

Jonsberndt: /* New MIL-STD Turbulence Model for JSBSim */

{{newsletter}}
{{TOC_right}}
''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 projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== FlightGear events ==
== Development news ==

===Local Weather v0.85===
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the Local Weather package is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.

The increased performance means that 3d clouds on fast systems can be rendered out to 45 km, and high altitude 2d cloud sheets sometimes up to 80 km - vastly improving the visual impression of the sky from airliner altitudes.

In addition, some bugs in the wind modelling and long-range weather patterns have been ironed out - with Flightgear 2.0.0, the package performs good in tests.

In the works:
* better hard-coded support for e.g. terrain sampling
* a METAR interface to use real-time weather and wind data
* full dynamics of the life cycle of convective clouds as they drift over the terrain
* and as always - improvements to cloud placement algorithms and cloud textures

Stay tuned!

A small feature gallery:
<gallery>
Image:local_weather_0.85_01.jpg| Cumulus and Cirrocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_02.jpg| Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)
Image:local_weather_0.85_03.jpg| 45 km cloud visibility range (Local Weather v0.85)
Image:local_weather_0.85_04.jpg| Realistic cloud bottoms (Local Weather v0.85)
Image:local_weather_0.85_05.jpg| Cumulus and Altocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_06.jpg| Multiple 3d layered clouds (Local Weather v0.85)
</gallery>

[[File:new_weather_dialog.png|thumb|200px|The new weather dialog]]
=== Weather supporting core code ===
The weather supporting core of FlightGear [http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51 has been modified] during the last weeks to better support new weather models like the above mentioned Local Weather system. Data flow between environment systems is now defined in XML config files using well [[Autopilot Configuration Reference|known syntax and elements from the autopilot]]. Complex rules using predefined filters and arbitrary expressions can be defined without the need for C++ or Nasal coding.
Along with this patch comes a unified weather settings dialog, combining previous dialogs for weather conditions, scenario, clouds and precipitation. Further plans are to integrate a new real world data source [http://www.navlost.eu/nwxs/doc/desc/ NWX], providing METAR, aloft and temperature at altitude.

=== Download & Compile script ===
For the Debian/Ubuntu users, an improvement to the [[Scripted Compilation on Linux Debian/Ubuntu|download and compile]]. If svn/git compilation fails from lates revisions (generally caused by sources among different softwares not in sync) you can still compile and obtain the lates known compiling version using the -s switch.

Beware that this feature is under testing, but should work fine.

[[File:AIWingmenandAITanker.jpg|thumb|200px|AIWingmen and AITanker]]
=== AI Objects ===
Some of the AI code has been revisited and tidied up, in a somewhat vain attempt to reduce the impact on frame rate. The facilities in Slaved Ballistic Objects, Wingmen, Ground Vehicles, and Escorts have been generalized. Now, any of these types can be subordinated, or parented, on any AI object which has a <name> tag. Thus, a wingman can be formated on a an AI Tanker, and can have a slaved droptank.

A Wingman can be formated on a Wingman to build larger formations, of which an example is shown by [http://www.youtube.com/v/YaBghBIZZWI this video].

With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.

[[File:Water shader Ju 52.jpg|thumb|270px|[[Junkers Ju 52]] flying over a lake in the French custom scenery.]]
===Water shader improvements===
Our all-time favourite shader-artist, Gral, picked up yet another project. This time it is something that covers over 70% of the entire scenery and is thus of great importance in a flight simulator: water. The new shader includes more realistic wave movements and much nicer sun "reflections". The extreme goal is to have real-time reflective water, which is still a long way to go, but with Gral's latest improvements we've at least made a step into the right direction. Transatlantic or Carribean flights have never been so exiting in FlightGear!

=== FlightGear, JSBSim, and SciCos/SciLab ===
James Goppert (an Aero Engineering graduate student at Purdue) has been doing some fascinating work using JSBSim integrated with SciCos, along with having added some new trimming algorithms and code to JSBSim. The [http://www.purduehsl.dynalias.com/index.php?page=unmanned-vehicles Purdue Flight Dynamics and Control / Hybrid Systems Lab web page] features an interesting demo video. You can also see the [http://www.youtube.com/user/jgoppert?feature=mhum#p/u/6/-B0nQbcyo-o video directly on YouTube].

And here’s another video from James, [http://www.youtube.com/watch?v=mHN-Vb9l0v8 ArduPilotMega Hardware in the Loop with SciCos/SciLab].

=== New MIL-STD Turbulence Model for JSBSim ===

Andreas Gaeb has added to JSBSim an initial release of the turbulence models from [http://cafefoundation.org/v2/pdf_tech/Flying.Qualities/PAV.FlyQual.Mil1797A.pdf MILSTD-1797A] and [http://jagger.berkeley.edu/~pack/certify/sharedpapers/8785c.pdf MIL-F-8785C] as described in [http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980028448_1998081596.pdf NASA Contractor Report NASA CR-1998-206937].
Both the MILSTD and the Tustin transform versions are included.

To do a quick test, set the following properties:
*atmosphere/turb-type=4
*atmosphere/turbulence/milspec/windspeed_at_20ft_AGL-fps=50
*atmosphere/turbulence/milspec/severity=4
which should give moderate turbulence conditions. Further options can be found in the documentation in the header file (FGAtmosphere.h) in the JSBSim source code distribution.

In early tests of the code, both turbulence versions were seen to give reasonable results for large aircraft. For RC model size aircraft, the MIL-STD version is reasonable as well, while the Tustin version tends to diverge.

=== JSBSim, and Matlab ===

Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.

Where the project is now:
*New release ready to compile and test for 32-bit Windows.
*Some bugs have been fixed (with a couple more to squash).
*Finally have some user documentation.
*The GUI and trim feature are now nicely integrated and the user experience is much better.
*The GUI is now tabbed/multi-paned and much more powerful.
*The project size is pared down considerably and the file duplication is gone.
*The Visual Studio project files have been fixed for better portability.

Where the project is going:
*[http://www.simauthor.com/flightviz.html FlightViz visualization tool] is currently in work.
*Environmental parameters (winds, wind-shear etc) controlled by the GUI.
*Data plotting and initial trimmed control inputs prediction.
*Closed-loop PID stabilization for finding trim points.
*Improvements to trim function.
*Flight profile scripting controllable from the GUI.
*Linux compiled version.
*Improve the documentation.
*Author a white paper.

This gives an overall picture of the current and future scope of the project. The JSBSim SFunction should become a very useful tool for flight model development and research. Agostino is also working an a MEX file (Matlab Executable) that wraps JSBSim.

==Nasal syntax highlighting file for Notepad++ users ==

Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out http://flightgear.org/forums/viewtopic.php?f=30&t=9260&p=95391#p92127 to download the file and for installation instructions.

== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).

These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.

In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.

This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.

For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);

That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.

This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.

Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.

So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).

Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".

Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".

Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.

For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.

This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.

Of course, one may still use objects like conventional variables for passing and returning parameters.

== New software tools ==
== FlightGear addons and mods ==
== In the hangar ==
===BAe-146===
"Pilot Penguin" and "[[User:Nickyivyca|nickyivyca]]" have begun work on the BAe-146. Pilot Penguin will be doing mostly 3D work, and nick will be doing mostly FDM and systems work. [http://flightgear.org/forums/viewtopic.php?f=4&t=9494&start=15 See the forum thread for more info.]

===Launch Vehicles: Jupiter J-246, and NASA Ares-1===
Gérard has taken some [http://www.nasa.gov/multimedia/3d_resources/models.html NASA 3D models] and prepared them for use with FlightGear. The historic [http://en.wikipedia.org/wiki/Kennedy_Space_Center_Launch_Complex_39 Kennedy Space Center Launch Complex 39] 3D model has been prepared, as well as the [http://www.nasa.gov/mission_pages/constellation/ares/aresl/index.html Ares-1 launch vehicle] 3D model. Jon Berndt ([http://www.jsbsim.org JSBSim Project] Development Coordinator) has built an approximate Ares-1 flight model based on publicly available information. Resting on the launch pad.]]
Work is progressing on getting that flight model integrated with the 3D model.
<gallery>
Image:Ares-1.jpg|Ares-1 Launch Vehicle resting on the launch pad
Image:CLV_090606-3D.jpg|DIRECT J-246 Launch Vehicle
Image:launch complex 39-img1.jpg|Launch Complex 39
</gallery>
Gérard has also fabricated a model of the notional DIRECT launch vehicle variant known as the "Jupiter" J-246, shown in this [http://www.launchcomplexmodels.com/Direct/documents/Baseball_Cards/J246-41.4003.10050_CLV_090606.pdf informational flyer]. Jon has created an approximate flight model for this vehicle, as well.

===Livery hangar reaches 300===
Early September, the [http://liveries.flightgear.org/ FlightGear Livery Database] welcomed its [http://liveries.flightgear.org/liveries.php?id=301 300th livery]! It is a livery of the Polish Air Force's [[Lockheed C130]], created by Maciej Zgódka, one of the latest additions to the painters-team. In the same time, the database was upgraded with a couple of new "features":
* thumbnails of liveries pop up when you hover over a link.
* a contact page was added, to ease contacting the database maintainer.
* each livery has a "Report this livery" button, through which visitors can notify the maintainer of a broken download, incorrect or unknown author, licensing issues etc.

I would like to emphasize that lots of liveries are not yet assigned an author. Please check for yourself if there is any [http://liveries.flightgear.org/authors.php unknown-author-livery] of which you known/are the author. Lots of liveries are still in the need for a thumbnail, so those are welcome as well.

== Scenery corner ==
===Historic Nike Hercules Missile Sites===
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These Sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each Site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into flightgear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.

===UK Football Stadiums===
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.

===Liverpool John Lennon Airport===
Andyramone has begun modeling Liverpool Airport (EGGP) in the UK. The terminal is completed and will be submitted to the database this month. Work has already begun on the control tower.

===KSFO Terminal 2===
[[San Francisco International Airport]]'s Terminal 2 has been fully remodelled by Karla in Blender 2.49b, using handmade textures in Gimp 2.46. New additions include: linking wings, antennae, railings, supports, ground floors interiors, ATC equipment, vigilant controller, architecture, light masts and night textures.

It has been released and is available via [[TerraSync]].

After improving the terminal, Karla wrote a howto on how to create realistic textures for buildings. More on that in the [[#Wiki updates|Wiki updates]] section of this newsletter.

===Dublin Airport===
"eag1e" (on the forum, D-ELLE callsign) is working on the buildings of [[Dublin Airport]] (EIDW). The airport seems quite well advanced, it has been submitted to the model repository and it is available for direct download at [http://www.knatterkasten.de/ knatterkasten.de].

See the [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8874 forum post] for more info.

===Innsbruck ÖAMTC helicopter base===
[[File:LOWI_oamtc_helicopter_base.jpg|thumb|Innsbruck ÖAMTC helicopter base]]
The ÖAMTC and Flugpolizei (police) Helicopter base at Innsbruck airport (LOWI) is currently under development by ot-666. Most likely it will be outfitted with moving helipads that are under development by HHS.

===Power plants===
Power plants, with their red and white striped tall stacks, are outstanding visual aids for VFR flying.

Scighera has modeled two Italian power plants in Blender :
* "'''ENEL Piombino 4x330 MW Power Plant'''", located in Piombino, right in front of the Isola d'Elba (Tuscany, Italy). It represent the standard Italian heavy fuel oil fired 330 MW unit of the early 70ies, with 220 m high stacks provided with red obstruction lights. The model includes a Fuel oil unloading pier, with a mooring tankership
* "'''a2a 1000 MW Combined Cycle Power Plant'''" located in Cassano d'Adda (Lombardy, Italy, 30 km away from Milano Linate (LIME)). The plant is provided with 3 Turbogas, 3 Heat Recovery Steam Generators feeding the pre-existing steam turbines. There is a 220 m high red & white striped stack and a lower 80 m stack.

The models have been submitted to the models repository (Piombino is already available via [[TerraSync]]), and available for download at [http://digilander.libero.it/scighera_fg/index.html Scighera's website].

scighera is also working on the '''Poolbeg Power Plant''', on the Dublin peninsula, very close to Dublin Airport (EIDW); the plant has two outstanding 208 m high stacks ...

<gallery>
Image:ENEL-Piombino-1.jpg| ENEL Piombino 4x330 MW Power Plant
Image:Cassano.jpg| Cassano d'Adda 1000MW Power Plant
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
</gallery>

[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]

===Harbors===
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.

== Video of the month ==
Inspired by an idea posted by Mogthor, redneck has turned a part of the "Getting started" manual into a series of youtube videos, please see: http://flightgear.org/forums/viewtopic.php?f=25&t=9476&p=96015#p96015

[[File:Clip0437_0002.jpg]] [[File:Clip0437_0001.jpg]]

== Aircraft of the month ==

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

== Suggested flights ==
===Hawai'i===
[[Image:Maui03.jpg|thumb]]
Do you use [[TerraSync]]? If so, try a flight around Hawaii! Take off from PHNL in a light aircraft and head west until you hit Pearl Harbor; a right turn north will take you post the USS Arizona Memorial, and the Punchbowl Crater will be to your right. Or, fly east from PHNL past volcanic craters Diamond Head and Koko Head. If you follow the O'ahu coastline north from Koko Head, you can land at either old World War II airbase Bellows Field (now a wildlife reserve in real life) or at Keahole MCAS.

For a potentially more scenic route, fly east toward Molokai, and stay to the north (left) of the island. The northern part of Molokai features huge sea cliffs and a tiny airstrip on the Kalaupapa peninsula - the peninsula being the only respite from the cliffs. A former leper colony existed near the airstrip!

Also of interest are the volcanoes on Maui and the 'Big Island' of Hawai'i - flying VFR in a small plane from PHTO to PHKO over the plateau between Mauna Kea and Mauna Loa can be a challenge, as you have to take off from sea level, fly through a pass of 6500 feet, and then drop back down to sea level to land! The Hana coast of northern Maui is also a nice flight - a circumnavigation of Haleakala, starting and ending at PHOG, is quite a nice flight.

The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.

== Aircraft reviews ==

== Wiki updates ==
===Creating realistic textures for buildings===
Texture and modelling artist karla, who recently [[#KSFO Terminal 2|remodeled terminal 2 of KSFO]], wrote a nice article on how to create (photo) realistic textures for buildings. The article explains the texturing process from start to end. Several techniques for creating light-effects, non-repeating surfaces and making faces look weathered are discussed and explained step by step.

Read the howto at [[Howto: Texture a building‎‎]] and provide the FlightGear community with some nice scenery additions!

===Creating cumulus cloud textures for the weather system ===
WooT has provided a short tutorial on extracting cumulus cloud textures from images. This will be useful for providing improved textures for the local weather system. Read the howto at [[Howto:Cumulus cloud texture extraction]].

===Running FlightGear on less modern hardware ===
A number of recent forum discussions were about running FlightGear on older hardware, we have now created a new article that focuses on just that: [[Howto: Build a cheap FlightGear box]].

== Community news ==
=== FlightGear on youtube ===
* Ten students at NASA's LARSS (Langley Aerospace Research Summer Scholars), put together [http://www.youtube.com/watch?v=YmnFP-1UlSY an autonomous robotics lab], using mostly open source tools. One of which is a FlightGear Multiplayer Server.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

=== Forum news ===

Thanks to Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45

=== New Spanish-Latin American FG community website ===

NiTuS and El Flauta have created ''[http://www.vivefg.org| Vive FG!]'' (translation: Live FG!), a new version of the Spanish-Latin American FG community website. Powered by Joomla!, it's now much more dynamic and clearer than the previous one, including many FG tutorials about aircraft, scenery and FG-itself-related ''how-to'', as well as additional aircraft and sceneries created by the community, and much more. We encourage everyone to come in, regardless the language you speak!

=== Multiplayer ===
=== Virtual airlines ===

== Useful links ==
== And finally ... ==
Next [http://www.fsweekend.com/ FSWeekend] event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at [[Lelystad_Airport|Lelystad's airport]].

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

===Reminder: FSweekend===
With just two months togo, the largest flight simulator event in the world (the [[FSweekend]] at [[Lelystad Airport]], the Netherlands) is coming close. Make sure to mark the weekend of 6&7 November in your agenda as "occupied". A team of FlightGear developers will be present in Lelystad to promote FlightGear to the public. They highly appreciate it if you are able to stop over at the airport!

Last year we organised a [[Howto: Multiplayer|multiplayer]] event in which FlightGear users from all over the world could virtually visit Lelystad. Something similar for this year is currently being discussed. Expect more details in next month's newsletter.

=== Reminder: Google's Summer of Code 2011 ===
We would like to remind all readers that the FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].

=== Did you know ===

[[Category:FlightGear Newsletter|2010 09]]

FlightGear Newsletter September 2010

2010-09-21T04:06:36Z

Jonsberndt: /* Launch Vehicles: Jupiter J-246, and NASA Ares-1 */

{{newsletter}}
{{TOC_right}}
''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 projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== FlightGear events ==
== Development news ==

===Local Weather v0.85===
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the Local Weather package is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.

The increased performance means that 3d clouds on fast systems can be rendered out to 45 km, and high altitude 2d cloud sheets sometimes up to 80 km - vastly improving the visual impression of the sky from airliner altitudes.

In addition, some bugs in the wind modelling and long-range weather patterns have been ironed out - with Flightgear 2.0.0, the package performs good in tests.

In the works:
* better hard-coded support for e.g. terrain sampling
* a METAR interface to use real-time weather and wind data
* full dynamics of the life cycle of convective clouds as they drift over the terrain
* and as always - improvements to cloud placement algorithms and cloud textures

Stay tuned!

A small feature gallery:
<gallery>
Image:local_weather_0.85_01.jpg| Cumulus and Cirrocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_02.jpg| Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)
Image:local_weather_0.85_03.jpg| 45 km cloud visibility range (Local Weather v0.85)
Image:local_weather_0.85_04.jpg| Realistic cloud bottoms (Local Weather v0.85)
Image:local_weather_0.85_05.jpg| Cumulus and Altocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_06.jpg| Multiple 3d layered clouds (Local Weather v0.85)
</gallery>

[[File:new_weather_dialog.png|thumb|200px|The new weather dialog]]
=== Weather supporting core code ===
The weather supporting core of FlightGear [http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51 has been modified] during the last weeks to better support new weather models like the above mentioned Local Weather system. Data flow between environment systems is now defined in XML config files using well [[Autopilot Configuration Reference|known syntax and elements from the autopilot]]. Complex rules using predefined filters and arbitrary expressions can be defined without the need for C++ or Nasal coding.
Along with this patch comes a unified weather settings dialog, combining previous dialogs for weather conditions, scenario, clouds and precipitation. Further plans are to integrate a new real world data source [http://www.navlost.eu/nwxs/doc/desc/ NWX], providing METAR, aloft and temperature at altitude.

=== Download & Compile script ===
For the Debian/Ubuntu users, an improvement to the [[Scripted Compilation on Linux Debian/Ubuntu|download and compile]]. If svn/git compilation fails from lates revisions (generally caused by sources among different softwares not in sync) you can still compile and obtain the lates known compiling version using the -s switch.

Beware that this feature is under testing, but should work fine.

[[File:AIWingmenandAITanker.jpg|thumb|200px|AIWingmen and AITanker]]
=== AI Objects ===
Some of the AI code has been revisited and tidied up, in a somewhat vain attempt to reduce the impact on frame rate. The facilities in Slaved Ballistic Objects, Wingmen, Ground Vehicles, and Escorts have been generalized. Now, any of these types can be subordinated, or parented, on any AI object which has a <name> tag. Thus, a wingman can be formated on a an AI Tanker, and can have a slaved droptank.

A Wingman can be formated on a Wingman to build larger formations, of which an example is shown by [http://www.youtube.com/v/YaBghBIZZWI this video].

With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.

[[File:Water shader Ju 52.jpg|thumb|270px|[[Junkers Ju 52]] flying over a lake in the French custom scenery.]]
===Water shader improvements===
Our all-time favourite shader-artist, Gral, picked up yet another project. This time it is something that covers over 70% of the entire scenery and is thus of great importance in a flight simulator: water. The new shader includes more realistic wave movements and much nicer sun "reflections". The extreme goal is to have real-time reflective water, which is still a long way to go, but with Gral's latest improvements we've at least made a step into the right direction. Transatlantic or Carribean flights have never been so exiting in FlightGear!

=== FlightGear, JSBSim, and SciCos/SciLab ===
James Goppert (an Aero Engineering graduate student at Purdue) has been doing some fascinating work using JSBSim integrated with SciCos, along with having added some new trimming algorithms and code to JSBSim. The [http://www.purduehsl.dynalias.com/index.php?page=unmanned-vehicles Purdue Flight Dynamics and Control / Hybrid Systems Lab web page] features an interesting demo video. You can also see the [http://www.youtube.com/user/jgoppert?feature=mhum#p/u/6/-B0nQbcyo-o video directly on YouTube].

And here’s another video from James, [http://www.youtube.com/watch?v=mHN-Vb9l0v8 ArduPilotMega Hardware in the Loop with SciCos/SciLab].

=== New MIL-STD Turbulence Model for JSBSim ===

Andreas Gaeb has added to JSBSim an initial release of the turbulence models from [http://cafefoundation.org/v2/pdf_tech/Flying.Qualities/PAV.FlyQual.Mil1797A.pdf MILSTD-1797A] and [http://jagger.berkeley.edu/~pack/certify/sharedpapers/8785c.pdf MIL-F-8785C] as described in [http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980028448_1998081596.pdf NAsA Contractor Report NASA CR-1998-206937].
Both the MILSTD and the Tustin transform versions are included.

To do a quick test, set the following properties:
*atmosphere/turb-type=4
*atmosphere/turbulence/milspec/windspeed_at_20ft_AGL-fps=50
*atmosphere/turbulence/milspec/severity=4
which should give moderate turbulence conditions. Further options can be found in the documentation in the header file (FGAtmosphere.h) in the JSBSim source code distribution.

In early tests of the code, both turbulence versions were seen to give reasonable results for large aircraft. For RC model size aircraft, the MIL-STD version is reasonable as well, while the Tustin version tends to diverge.

=== JSBSim, and Matlab ===

Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.

Where the project is now:
*New release ready to compile and test for 32-bit Windows.
*Some bugs have been fixed (with a couple more to squash).
*Finally have some user documentation.
*The GUI and trim feature are now nicely integrated and the user experience is much better.
*The GUI is now tabbed/multi-paned and much more powerful.
*The project size is pared down considerably and the file duplication is gone.
*The Visual Studio project files have been fixed for better portability.

Where the project is going:
*[http://www.simauthor.com/flightviz.html FlightViz visualization tool] is currently in work.
*Environmental parameters (winds, wind-shear etc) controlled by the GUI.
*Data plotting and initial trimmed control inputs prediction.
*Closed-loop PID stabilization for finding trim points.
*Improvements to trim function.
*Flight profile scripting controllable from the GUI.
*Linux compiled version.
*Improve the documentation.
*Author a white paper.

This gives an overall picture of the current and future scope of the project. The JSBSim SFunction should become a very useful tool for flight model development and research. Agostino is also working an a MEX file (Matlab Executable) that wraps JSBSim.

==Nasal syntax highlighting file for Notepad++ users ==

Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out http://flightgear.org/forums/viewtopic.php?f=30&t=9260&p=95391#p92127 to download the file and for installation instructions.

== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).

These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.

In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.

This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.

For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);

That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.

This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.

Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.

So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).

Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".

Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".

Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.

For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.

This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.

Of course, one may still use objects like conventional variables for passing and returning parameters.

== New software tools ==
== FlightGear addons and mods ==
== In the hangar ==
===BAe-146===
"Pilot Penguin" and "[[User:Nickyivyca|nickyivyca]]" have begun work on the BAe-146. Pilot Penguin will be doing mostly 3D work, and nick will be doing mostly FDM and systems work. [http://flightgear.org/forums/viewtopic.php?f=4&t=9494&start=15 See the forum thread for more info.]

===Launch Vehicles: Jupiter J-246, and NASA Ares-1===
Gérard has taken some [http://www.nasa.gov/multimedia/3d_resources/models.html NASA 3D models] and prepared them for use with FlightGear. The historic [http://en.wikipedia.org/wiki/Kennedy_Space_Center_Launch_Complex_39 Kennedy Space Center Launch Complex 39] 3D model has been prepared, as well as the [http://www.nasa.gov/mission_pages/constellation/ares/aresl/index.html Ares-1 launch vehicle] 3D model. Jon Berndt ([http://www.jsbsim.org JSBSim Project] Development Coordinator) has built an approximate Ares-1 flight model based on publicly available information. Resting on the launch pad.]]
Work is progressing on getting that flight model integrated with the 3D model.
<gallery>
Image:Ares-1.jpg|Ares-1 Launch Vehicle resting on the launch pad
Image:CLV_090606-3D.jpg|DIRECT J-246 Launch Vehicle
Image:launch complex 39-img1.jpg|Launch Complex 39
</gallery>
Gérard has also fabricated a model of the notional DIRECT launch vehicle variant known as the "Jupiter" J-246, shown in this [http://www.launchcomplexmodels.com/Direct/documents/Baseball_Cards/J246-41.4003.10050_CLV_090606.pdf informational flyer]. Jon has created an approximate flight model for this vehicle, as well.

===Livery hangar reaches 300===
Early September, the [http://liveries.flightgear.org/ FlightGear Livery Database] welcomed its [http://liveries.flightgear.org/liveries.php?id=301 300th livery]! It is a livery of the Polish Air Force's [[Lockheed C130]], created by Maciej Zgódka, one of the latest additions to the painters-team. In the same time, the database was upgraded with a couple of new "features":
* thumbnails of liveries pop up when you hover over a link.
* a contact page was added, to ease contacting the database maintainer.
* each livery has a "Report this livery" button, through which visitors can notify the maintainer of a broken download, incorrect or unknown author, licensing issues etc.

I would like to emphasize that lots of liveries are not yet assigned an author. Please check for yourself if there is any [http://liveries.flightgear.org/authors.php unknown-author-livery] of which you known/are the author. Lots of liveries are still in the need for a thumbnail, so those are welcome as well.

== Scenery corner ==
===Historic Nike Hercules Missile Sites===
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These Sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each Site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into flightgear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.

===UK Football Stadiums===
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.

===Liverpool John Lennon Airport===
Andyramone has begun modeling Liverpool Airport (EGGP) in the UK. The terminal is completed and will be submitted to the database this month. Work has already begun on the control tower.

===KSFO Terminal 2===
[[San Francisco International Airport]]'s Terminal 2 has been fully remodelled by Karla in Blender 2.49b, using handmade textures in Gimp 2.46. New additions include: linking wings, antennae, railings, supports, ground floors interiors, ATC equipment, vigilant controller, architecture, light masts and night textures.

It has been released and is available via [[TerraSync]].

After improving the terminal, Karla wrote a howto on how to create realistic textures for buildings. More on that in the [[#Wiki updates|Wiki updates]] section of this newsletter.

===Dublin Airport===
"eag1e" (on the forum, D-ELLE callsign) is working on the buildings of [[Dublin Airport]] (EIDW). The airport seems quite well advanced, it has been submitted to the model repository and it is available for direct download at [http://www.knatterkasten.de/ knatterkasten.de].

See the [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8874 forum post] for more info.

===Innsbruck ÖAMTC helicopter base===
[[File:LOWI_oamtc_helicopter_base.jpg|thumb|Innsbruck ÖAMTC helicopter base]]
The ÖAMTC and Flugpolizei (police) Helicopter base at Innsbruck airport (LOWI) is currently under development by ot-666. Most likely it will be outfitted with moving helipads that are under development by HHS.

===Power plants===
Power plants, with their red and white striped tall stacks, are outstanding visual aids for VFR flying.

Scighera has modeled two Italian power plants in Blender :
* "'''ENEL Piombino 4x330 MW Power Plant'''", located in Piombino, right in front of the Isola d'Elba (Tuscany, Italy). It represent the standard Italian heavy fuel oil fired 330 MW unit of the early 70ies, with 220 m high stacks provided with red obstruction lights. The model includes a Fuel oil unloading pear, with a mooring tankership
* "'''a2a 1000 MW Combined Cycle Power Plant'''" located in Cassano d'Adda (Lombardy, Italy, 30 km away from Milano Linate (LIME)). The plant is provided with 3 Turbogas, 3 Heat Recovery Steam Generators feeding the pre-existing steam turbines. There is a 220 m high red & white stiped stack and a lower 80 m stack.

The models have been submitted to the models repository (Piombino is already available via [[TerraSync]]), and available for download at [http://digilander.libero.it/scighera_fg/index.html Scighera's website].

scighera is also working on the '''Poolbeg Power Plant''', on the Dublin peninsula, very close to Dublin Airport (EIDW); the plant has two outstanding 208 m high stacks ...

<gallery>
Image:ENEL-Piombino-1.jpg| ENEL Piombino 4x330 MW Power Plant
Image:Cassano.jpg| Cassano d'Adda 1000MW Power Plant
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
</gallery>

[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]
===Harbors===
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.

== Video of the month ==
Inspired by an idea posted by Mogthor, redneck has turned a part of the "Getting started" manual into a series of youtube videos, please see: http://flightgear.org/forums/viewtopic.php?f=25&t=9476&p=96015#p96015

== Aircraft of the month ==

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

== Suggested flights ==
===Hawai'i===
[[Image:Maui03.jpg|thumb]]
Do you use [[TerraSync]]? If so, try a flight around Hawaii! Take off from PHNL in a light aircraft and head west until you hit Pearl Harbor; a right turn north will take you post the USS Arizona Memorial, and the Punchbowl Crater will be to your right. Or, fly east from PHNL past volcanic craters Diamond Head and Koko Head. If you follow the O'ahu coastline north from Koko Head, you can land at either old World War II airbase Bellows Field (now a wildlife reserve in real life) or at Keahole MCAS.

For a potentially more scenic route, fly east toward Molokai, and stay to the north (left) of the island. The northern part of Molokai features huge sea cliffs and a tiny airstrip on the Kalaupapa peninsula - the peninsula being the only respite from the cliffs. A former leper colony existed near the airstrip!

Also of interest are the volcanoes on Maui and the 'Big Island' of Hawai'i - flying VFR in a small plane from PHTO to PHKO over the plateau between Mauna Kea and Mauna Loa can be a challenge, as you have to take off from sea level, fly through a pass of 6500 feet, and then drop back down to sea level to land! The Hana coast of northern Maui is also a nice flight - a circumnavigation of Haleakala, starting and ending at PHOG, is quite a nice flight.

The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.

== Aircraft reviews ==

== Wiki updates ==
===Creating realistic textures for buildings===
Texture and modelling artist karla, who recently [[#KSFO Terminal 2|remodeled terminal 2 of KSFO]], wrote a nice article on how to create (photo) realistic textures for buildings. The article explains the texturing process from start to end. Several techniques for creating light-effects, non-repeating surfaces and making faces look weathered are discussed and explained step by step.

Read the howto at [[Howto: Texture a building‎‎]] and provide the FlightGear community with some nice scenery additions!

===Creating cumulus cloud textures for the weather system ===
WooT has provided a short tutorial on extracting cumulus cloud textures from images. This will be useful for providing improved textures for the local weather system. Read the howto at [[Howto:Cumulus cloud texture extraction]].

===Running FlightGear on less modern hardware ===
A number of recent forum discussions were about running FlightGear on older hardware, we have now created a new article that focuses on just that: [[Howto: Build a cheap FlightGear box]].

== Community news ==
=== FlightGear on youtube ===
* Ten students at NASA's LARSS (Langley Aerospace Research Summer Scholars), put together [http://www.youtube.com/watch?v=YmnFP-1UlSY an autonomous robotics lab], using mostly open source tools. One of which is a FlightGear Multiplayer Server.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

=== Forum news ===

Thanks to Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45

=== Multiplayer ===
=== Virtual airlines ===

== Useful links ==
== And finally ... ==
Next [http://www.fsweekend.com/ FSWeekend] event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at [[Lelystad_Airport|Lelystad's airport]].

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

===Reminder: FSweekend===
With just two months togo, the largest flight simulator event in the world (the [[FSweekend]] at [[Lelystad Airport]], the Netherlands) is coming close. Make sure to mark the weekend of 6&7 November in your agenda as "occupied". A team of FlightGear developers will be present in Lelystad to promote FlightGear to the public. They highly appreciate it if you are able to stop over at the airport!

Last year we organised a [[Howto: Multiplayer|multiplayer]] event in which FlightGear users from all over the world could virtually visit Lelystad. Something similar for this year is currently being discussed. Expect more details in next month's newsletter.

=== Reminder: Google's Summer of Code 2011 ===
We would like to remind all readers that the FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].

=== Did you know ===

[[Category:FlightGear Newsletter|2010 09]]

FlightGear Newsletter September 2010

2010-09-21T04:04:36Z

Jonsberndt: /* Launch Vehicles: Jupiter J-246, and NASA Ares-1 */

{{newsletter}}
{{TOC_right}}
''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 projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== FlightGear events ==
== Development news ==

===Local Weather v0.85===
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the Local Weather package is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.

The increased performance means that 3d clouds on fast systems can be rendered out to 45 km, and high altitude 2d cloud sheets sometimes up to 80 km - vastly improving the visual impression of the sky from airliner altitudes.

In addition, some bugs in the wind modelling and long-range weather patterns have been ironed out - with Flightgear 2.0.0, the package performs good in tests.

In the works:
* better hard-coded support for e.g. terrain sampling
* a METAR interface to use real-time weather and wind data
* full dynamics of the life cycle of convective clouds as they drift over the terrain
* and as always - improvements to cloud placement algorithms and cloud textures

Stay tuned!

A small feature gallery:
<gallery>
Image:local_weather_0.85_01.jpg| Cumulus and Cirrocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_02.jpg| Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)
Image:local_weather_0.85_03.jpg| 45 km cloud visibility range (Local Weather v0.85)
Image:local_weather_0.85_04.jpg| Realistic cloud bottoms (Local Weather v0.85)
Image:local_weather_0.85_05.jpg| Cumulus and Altocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_06.jpg| Multiple 3d layered clouds (Local Weather v0.85)
</gallery>

[[File:new_weather_dialog.png|thumb|200px|The new weather dialog]]
=== Weather supporting core code ===
The weather supporting core of FlightGear [http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51 has been modified] during the last weeks to better support new weather models like the above mentioned Local Weather system. Data flow between environment systems is now defined in XML config files using well [[Autopilot Configuration Reference|known syntax and elements from the autopilot]]. Complex rules using predefined filters and arbitrary expressions can be defined without the need for C++ or Nasal coding.
Along with this patch comes a unified weather settings dialog, combining previous dialogs for weather conditions, scenario, clouds and precipitation. Further plans are to integrate a new real world data source [http://www.navlost.eu/nwxs/doc/desc/ NWX], providing METAR, aloft and temperature at altitude.

=== Download & Compile script ===
For the Debian/Ubuntu users, an improvement to the [[Scripted Compilation on Linux Debian/Ubuntu|download and compile]]. If svn/git compilation fails from lates revisions (generally caused by sources among different softwares not in sync) you can still compile and obtain the lates known compiling version using the -s switch.

Beware that this feature is under testing, but should work fine.

[[File:AIWingmenandAITanker.jpg|thumb|200px|AIWingmen and AITanker]]
=== AI Objects ===
Some of the AI code has been revisited and tidied up, in a somewhat vain attempt to reduce the impact on frame rate. The facilities in Slaved Ballistic Objects, Wingmen, Ground Vehicles, and Escorts have been generalized. Now, any of these types can be subordinated, or parented, on any AI object which has a <name> tag. Thus, a wingman can be formated on a an AI Tanker, and can have a slaved droptank.

A Wingman can be formated on a Wingman to build larger formations, of which an example is shown by [http://www.youtube.com/v/YaBghBIZZWI this video].

With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.

[[File:Water shader Ju 52.jpg|thumb|270px|[[Junkers Ju 52]] flying over a lake in the French custom scenery.]]
===Water shader improvements===
Our all-time favourite shader-artist, Gral, picked up yet another project. This time it is something that covers over 70% of the entire scenery and is thus of great importance in a flight simulator: water. The new shader includes more realistic wave movements and much nicer sun "reflections". The extreme goal is to have real-time reflective water, which is still a long way to go, but with Gral's latest improvements we've at least made a step into the right direction. Transatlantic or Carribean flights have never been so exiting in FlightGear!

=== FlightGear, JSBSim, and SciCos/SciLab ===
James Goppert (an Aero Engineering graduate student at Purdue) has been doing some fascinating work using JSBSim integrated with SciCos, along with having added some new trimming algorithms and code to JSBSim. The [http://www.purduehsl.dynalias.com/index.php?page=unmanned-vehicles Purdue Flight Dynamics and Control / Hybrid Systems Lab web page] features an interesting demo video. You can also see the [http://www.youtube.com/user/jgoppert?feature=mhum#p/u/6/-B0nQbcyo-o video directly on YouTube].

And here’s another video from James, [http://www.youtube.com/watch?v=mHN-Vb9l0v8 ArduPilotMega Hardware in the Loop with SciCos/SciLab].

=== New MIL-STD Turbulence Model for JSBSim ===

Andreas Gaeb has added to JSBSim an initial release of the turbulence models from [http://cafefoundation.org/v2/pdf_tech/Flying.Qualities/PAV.FlyQual.Mil1797A.pdf MILSTD-1797A] and [http://jagger.berkeley.edu/~pack/certify/sharedpapers/8785c.pdf MIL-F-8785C] as described in [http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980028448_1998081596.pdf NAsA Contractor Report NASA CR-1998-206937].
Both the MILSTD and the Tustin transform versions are included.

To do a quick test, set the following properties:
*atmosphere/turb-type=4
*atmosphere/turbulence/milspec/windspeed_at_20ft_AGL-fps=50
*atmosphere/turbulence/milspec/severity=4
which should give moderate turbulence conditions. Further options can be found in the documentation in the header file (FGAtmosphere.h) in the JSBSim source code distribution.

In early tests of the code, both turbulence versions were seen to give reasonable results for large aircraft. For RC model size aircraft, the MIL-STD version is reasonable as well, while the Tustin version tends to diverge.

=== JSBSim, and Matlab ===

Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.

Where the project is now:
*New release ready to compile and test for 32-bit Windows.
*Some bugs have been fixed (with a couple more to squash).
*Finally have some user documentation.
*The GUI and trim feature are now nicely integrated and the user experience is much better.
*The GUI is now tabbed/multi-paned and much more powerful.
*The project size is pared down considerably and the file duplication is gone.
*The Visual Studio project files have been fixed for better portability.

Where the project is going:
*[http://www.simauthor.com/flightviz.html FlightViz visualization tool] is currently in work.
*Environmental parameters (winds, wind-shear etc) controlled by the GUI.
*Data plotting and initial trimmed control inputs prediction.
*Closed-loop PID stabilization for finding trim points.
*Improvements to trim function.
*Flight profile scripting controllable from the GUI.
*Linux compiled version.
*Improve the documentation.
*Author a white paper.

This gives an overall picture of the current and future scope of the project. The JSBSim SFunction should become a very useful tool for flight model development and research. Agostino is also working an a MEX file (Matlab Executable) that wraps JSBSim.

==Nasal syntax highlighting file for Notepad++ users ==

Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out http://flightgear.org/forums/viewtopic.php?f=30&t=9260&p=95391#p92127 to download the file and for installation instructions.

== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).

These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.

In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.

This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.

For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);

That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.

This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.

Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.

So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).

Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".

Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".

Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.

For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.

This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.

Of course, one may still use objects like conventional variables for passing and returning parameters.

== New software tools ==
== FlightGear addons and mods ==
== In the hangar ==
===BAe-146===
"Pilot Penguin" and "[[User:Nickyivyca|nickyivyca]]" have begun work on the BAe-146. Pilot Penguin will be doing mostly 3D work, and nick will be doing mostly FDM and systems work. [http://flightgear.org/forums/viewtopic.php?f=4&t=9494&start=15 See the forum thread for more info.]

===Launch Vehicles: Jupiter J-246, and NASA Ares-1===
Gérard has taken some [http://www.nasa.gov/multimedia/3d_resources/models.html NASA 3D models] and prepared them for use with FlightGear. The historic [http://en.wikipedia.org/wiki/Kennedy_Space_Center_Launch_Complex_39 Kennedy Space Center Launch Complex 39] 3D model has been prepared, as well as the [http://www.nasa.gov/mission_pages/constellation/ares/aresl/index.html Ares-1 launch vehicle] 3D model. Jon Berndt ([http://www.jsbsim.org JSBSim Project] Development Coordinator) has built an approximate Ares-1 flight model based on publicly available information. Resting on the launch pad.]]
Work is progressing on getting that flight model integrated with the 3D model.
<gallery>
[[Image:Ares-1.jpg|thumb|270px|[[Ares-1 Launch Vehicle]] Resting on the launch pad.]]
[[Image:CLV_090606-3D.jpg|thumb|270px|[[DIRECT J-246 Launch Vehicle]]
[[Image:launch complex 39-img1.jpg|thumb|270px|[[Launch Complex 39]].]]
</gallery>
Gérard has also fabricated a model of the notional DIRECT launch vehicle variant known as the "Jupiter" J-246, shown in this [http://www.launchcomplexmodels.com/Direct/documents/Baseball_Cards/J246-41.4003.10050_CLV_090606.pdf informational flyer]. Jon has created an approximate flight model for this vehicle, as well.

===Livery hangar reaches 300===
Early September, the [http://liveries.flightgear.org/ FlightGear Livery Database] welcomed its [http://liveries.flightgear.org/liveries.php?id=301 300th livery]! It is a livery of the Polish Air Force's [[Lockheed C130]], created by Maciej Zgódka, one of the latest additions to the painters-team. In the same time, the database was upgraded with a couple of new "features":
* thumbnails of liveries pop up when you hover over a link.
* a contact page was added, to ease contacting the database maintainer.
* each livery has a "Report this livery" button, through which visitors can notify the maintainer of a broken download, incorrect or unknown author, licensing issues etc.

I would like to emphasize that lots of liveries are not yet assigned an author. Please check for yourself if there is any [http://liveries.flightgear.org/authors.php unknown-author-livery] of which you known/are the author. Lots of liveries are still in the need for a thumbnail, so those are welcome as well.

== Scenery corner ==
===Historic Nike Hercules Missile Sites===
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These Sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each Site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into flightgear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.

===UK Football Stadiums===
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.

===Liverpool John Lennon Airport===
Andyramone has begun modeling Liverpool Airport (EGGP) in the UK. The terminal is completed and will be submitted to the database this month. Work has already begun on the control tower.

===KSFO Terminal 2===
[[San Francisco International Airport]]'s Terminal 2 has been fully remodelled by Karla in Blender 2.49b, using handmade textures in Gimp 2.46. New additions include: linking wings, antennae, railings, supports, ground floors interiors, ATC equipment, vigilant controller, architecture, light masts and night textures.

It has been released and is available via [[TerraSync]].

After improving the terminal, Karla wrote a howto on how to create realistic textures for buildings. More on that in the [[#Wiki updates|Wiki updates]] section of this newsletter.

===Dublin Airport===
"eag1e" (on the forum, D-ELLE callsign) is working on the buildings of [[Dublin Airport]] (EIDW). The airport seems quite well advanced, it has been submitted to the model repository and it is available for direct download at [http://www.knatterkasten.de/ knatterkasten.de].

See the [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8874 forum post] for more info.

===Innsbruck ÖAMTC helicopter base===
[[File:LOWI_oamtc_helicopter_base.jpg|thumb|Innsbruck ÖAMTC helicopter base]]
The ÖAMTC and Flugpolizei (police) Helicopter base at Innsbruck airport (LOWI) is currently under development by ot-666. Most likely it will be outfitted with moving helipads that are under development by HHS.

===Power plants===
Power plants, with their red and white striped tall stacks, are outstanding visual aids for VFR flying.

Scighera has modeled two Italian power plants in Blender :
* "'''ENEL Piombino 4x330 MW Power Plant'''", located in Piombino, right in front of the Isola d'Elba (Tuscany, Italy). It represent the standard Italian heavy fuel oil fired 330 MW unit of the early 70ies, with 220 m high stacks provided with red obstruction lights. The model includes a Fuel oil unloading pear, with a mooring tankership
* "'''a2a 1000 MW Combined Cycle Power Plant'''" located in Cassano d'Adda (Lombardy, Italy, 30 km away from Milano Linate (LIME)). The plant is provided with 3 Turbogas, 3 Heat Recovery Steam Generators feeding the pre-existing steam turbines. There is a 220 m high red & white stiped stack and a lower 80 m stack.

The models have been submitted to the models repository (Piombino is already available via [[TerraSync]]), and available for download at [http://digilander.libero.it/scighera_fg/index.html Scighera's website].

scighera is also working on the '''Poolbeg Power Plant''', on the Dublin peninsula, very close to Dublin Airport (EIDW); the plant has two outstanding 208 m high stacks ...

<gallery>
Image:ENEL-Piombino-1.jpg| ENEL Piombino 4x330 MW Power Plant
Image:Cassano.jpg| Cassano d'Adda 1000MW Power Plant
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
</gallery>

[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]
===Harbors===
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.

== Video of the month ==
Inspired by an idea posted by Mogthor, redneck has turned a part of the "Getting started" manual into a series of youtube videos, please see: http://flightgear.org/forums/viewtopic.php?f=25&t=9476&p=96015#p96015

== Aircraft of the month ==

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

== Suggested flights ==
===Hawai'i===
[[Image:Maui03.jpg|thumb]]
Do you use [[TerraSync]]? If so, try a flight around Hawaii! Take off from PHNL in a light aircraft and head west until you hit Pearl Harbor; a right turn north will take you post the USS Arizona Memorial, and the Punchbowl Crater will be to your right. Or, fly east from PHNL past volcanic craters Diamond Head and Koko Head. If you follow the O'ahu coastline north from Koko Head, you can land at either old World War II airbase Bellows Field (now a wildlife reserve in real life) or at Keahole MCAS.

For a potentially more scenic route, fly east toward Molokai, and stay to the north (left) of the island. The northern part of Molokai features huge sea cliffs and a tiny airstrip on the Kalaupapa peninsula - the peninsula being the only respite from the cliffs. A former leper colony existed near the airstrip!

Also of interest are the volcanoes on Maui and the 'Big Island' of Hawai'i - flying VFR in a small plane from PHTO to PHKO over the plateau between Mauna Kea and Mauna Loa can be a challenge, as you have to take off from sea level, fly through a pass of 6500 feet, and then drop back down to sea level to land! The Hana coast of northern Maui is also a nice flight - a circumnavigation of Haleakala, starting and ending at PHOG, is quite a nice flight.

The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.

== Aircraft reviews ==

== Wiki updates ==
===Creating realistic textures for buildings===
Texture and modelling artist karla, who recently [[#KSFO Terminal 2|remodeled terminal 2 of KSFO]], wrote a nice article on how to create (photo) realistic textures for buildings. The article explains the texturing process from start to end. Several techniques for creating light-effects, non-repeating surfaces and making faces look weathered are discussed and explained step by step.

Read the howto at [[Howto: Texture a building‎‎]] and provide the FlightGear community with some nice scenery additions!

===Creating cumulus cloud textures for the weather system ===
WooT has provided a short tutorial on extracting cumulus cloud textures from images. This will be useful for providing improved textures for the local weather system. Read the howto at [[Howto:Cumulus cloud texture extraction]].

===Running FlightGear on less modern hardware ===
A number of recent forum discussions were about running FlightGear on older hardware, we have now created a new article that focuses on just that: [[Howto: Build a cheap FlightGear box]].

== Community news ==
=== FlightGear on youtube ===
* Ten students at NASA's LARSS (Langley Aerospace Research Summer Scholars), put together [http://www.youtube.com/watch?v=YmnFP-1UlSY an autonomous robotics lab], using mostly open source tools. One of which is a FlightGear Multiplayer Server.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

=== Forum news ===

Thanks to Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45

=== Multiplayer ===
=== Virtual airlines ===

== Useful links ==
== And finally ... ==
Next [http://www.fsweekend.com/ FSWeekend] event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at [[Lelystad_Airport|Lelystad's airport]].

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

===Reminder: FSweekend===
With just two months togo, the largest flight simulator event in the world (the [[FSweekend]] at [[Lelystad Airport]], the Netherlands) is coming close. Make sure to mark the weekend of 6&7 November in your agenda as "occupied". A team of FlightGear developers will be present in Lelystad to promote FlightGear to the public. They highly appreciate it if you are able to stop over at the airport!

Last year we organised a [[Howto: Multiplayer|multiplayer]] event in which FlightGear users from all over the world could virtually visit Lelystad. Something similar for this year is currently being discussed. Expect more details in next month's newsletter.

=== Reminder: Google's Summer of Code 2011 ===
We would like to remind all readers that the FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].

=== Did you know ===

[[Category:FlightGear Newsletter|2010 09]]

FlightGear Newsletter September 2010

2010-09-21T04:00:36Z

Jonsberndt: /* Launch Vehicles: Jupiter J-246, and NASA Ares-1 */

{{newsletter}}
{{TOC_right}}
''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 projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== FlightGear events ==
== Development news ==

===Local Weather v0.85===
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the Local Weather package is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.

The increased performance means that 3d clouds on fast systems can be rendered out to 45 km, and high altitude 2d cloud sheets sometimes up to 80 km - vastly improving the visual impression of the sky from airliner altitudes.

In addition, some bugs in the wind modelling and long-range weather patterns have been ironed out - with Flightgear 2.0.0, the package performs good in tests.

In the works:
* better hard-coded support for e.g. terrain sampling
* a METAR interface to use real-time weather and wind data
* full dynamics of the life cycle of convective clouds as they drift over the terrain
* and as always - improvements to cloud placement algorithms and cloud textures

Stay tuned!

A small feature gallery:
<gallery>
Image:local_weather_0.85_01.jpg| Cumulus and Cirrocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_02.jpg| Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)
Image:local_weather_0.85_03.jpg| 45 km cloud visibility range (Local Weather v0.85)
Image:local_weather_0.85_04.jpg| Realistic cloud bottoms (Local Weather v0.85)
Image:local_weather_0.85_05.jpg| Cumulus and Altocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_06.jpg| Multiple 3d layered clouds (Local Weather v0.85)
</gallery>

[[File:new_weather_dialog.png|thumb|200px|The new weather dialog]]
=== Weather supporting core code ===
The weather supporting core of FlightGear [http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51 has been modified] during the last weeks to better support new weather models like the above mentioned Local Weather system. Data flow between environment systems is now defined in XML config files using well [[Autopilot Configuration Reference|known syntax and elements from the autopilot]]. Complex rules using predefined filters and arbitrary expressions can be defined without the need for C++ or Nasal coding.
Along with this patch comes a unified weather settings dialog, combining previous dialogs for weather conditions, scenario, clouds and precipitation. Further plans are to integrate a new real world data source [http://www.navlost.eu/nwxs/doc/desc/ NWX], providing METAR, aloft and temperature at altitude.

=== Download & Compile script ===
For the Debian/Ubuntu users, an improvement to the [[Scripted Compilation on Linux Debian/Ubuntu|download and compile]]. If svn/git compilation fails from lates revisions (generally caused by sources among different softwares not in sync) you can still compile and obtain the lates known compiling version using the -s switch.

Beware that this feature is under testing, but should work fine.

[[File:AIWingmenandAITanker.jpg|thumb|200px|AIWingmen and AITanker]]
=== AI Objects ===
Some of the AI code has been revisited and tidied up, in a somewhat vain attempt to reduce the impact on frame rate. The facilities in Slaved Ballistic Objects, Wingmen, Ground Vehicles, and Escorts have been generalized. Now, any of these types can be subordinated, or parented, on any AI object which has a <name> tag. Thus, a wingman can be formated on a an AI Tanker, and can have a slaved droptank.

A Wingman can be formated on a Wingman to build larger formations, of which an example is shown by [http://www.youtube.com/v/YaBghBIZZWI this video].

With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.

[[File:Water shader Ju 52.jpg|thumb|270px|[[Junkers Ju 52]] flying over a lake in the French custom scenery.]]
===Water shader improvements===
Our all-time favourite shader-artist, Gral, picked up yet another project. This time it is something that covers over 70% of the entire scenery and is thus of great importance in a flight simulator: water. The new shader includes more realistic wave movements and much nicer sun "reflections". The extreme goal is to have real-time reflective water, which is still a long way to go, but with Gral's latest improvements we've at least made a step into the right direction. Transatlantic or Carribean flights have never been so exiting in FlightGear!

=== FlightGear, JSBSim, and SciCos/SciLab ===
James Goppert (an Aero Engineering graduate student at Purdue) has been doing some fascinating work using JSBSim integrated with SciCos, along with having added some new trimming algorithms and code to JSBSim. The [http://www.purduehsl.dynalias.com/index.php?page=unmanned-vehicles Purdue Flight Dynamics and Control / Hybrid Systems Lab web page] features an interesting demo video. You can also see the [http://www.youtube.com/user/jgoppert?feature=mhum#p/u/6/-B0nQbcyo-o video directly on YouTube].

And here’s another video from James, [http://www.youtube.com/watch?v=mHN-Vb9l0v8 ArduPilotMega Hardware in the Loop with SciCos/SciLab].

=== New MIL-STD Turbulence Model for JSBSim ===

Andreas Gaeb has added to JSBSim an initial release of the turbulence models from [http://cafefoundation.org/v2/pdf_tech/Flying.Qualities/PAV.FlyQual.Mil1797A.pdf MILSTD-1797A] and [http://jagger.berkeley.edu/~pack/certify/sharedpapers/8785c.pdf MIL-F-8785C] as described in [http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980028448_1998081596.pdf NAsA Contractor Report NASA CR-1998-206937].
Both the MILSTD and the Tustin transform versions are included.

To do a quick test, set the following properties:
*atmosphere/turb-type=4
*atmosphere/turbulence/milspec/windspeed_at_20ft_AGL-fps=50
*atmosphere/turbulence/milspec/severity=4
which should give moderate turbulence conditions. Further options can be found in the documentation in the header file (FGAtmosphere.h) in the JSBSim source code distribution.

In early tests of the code, both turbulence versions were seen to give reasonable results for large aircraft. For RC model size aircraft, the MIL-STD version is reasonable as well, while the Tustin version tends to diverge.

=== JSBSim, and Matlab ===

Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.

Where the project is now:
*New release ready to compile and test for 32-bit Windows.
*Some bugs have been fixed (with a couple more to squash).
*Finally have some user documentation.
*The GUI and trim feature are now nicely integrated and the user experience is much better.
*The GUI is now tabbed/multi-paned and much more powerful.
*The project size is pared down considerably and the file duplication is gone.
*The Visual Studio project files have been fixed for better portability.

Where the project is going:
*[http://www.simauthor.com/flightviz.html FlightViz visualization tool] is currently in work.
*Environmental parameters (winds, wind-shear etc) controlled by the GUI.
*Data plotting and initial trimmed control inputs prediction.
*Closed-loop PID stabilization for finding trim points.
*Improvements to trim function.
*Flight profile scripting controllable from the GUI.
*Linux compiled version.
*Improve the documentation.
*Author a white paper.

This gives an overall picture of the current and future scope of the project. The JSBSim SFunction should become a very useful tool for flight model development and research. Agostino is also working an a MEX file (Matlab Executable) that wraps JSBSim.

==Nasal syntax highlighting file for Notepad++ users ==

Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out http://flightgear.org/forums/viewtopic.php?f=30&t=9260&p=95391#p92127 to download the file and for installation instructions.

== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).

These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.

In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.

This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.

For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);

That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.

This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.

Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.

So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).

Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".

Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".

Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.

For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.

This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.

Of course, one may still use objects like conventional variables for passing and returning parameters.

== New software tools ==
== FlightGear addons and mods ==
== In the hangar ==
===BAe-146===
"Pilot Penguin" and "[[User:Nickyivyca|nickyivyca]]" have begun work on the BAe-146. Pilot Penguin will be doing mostly 3D work, and nick will be doing mostly FDM and systems work. [http://flightgear.org/forums/viewtopic.php?f=4&t=9494&start=15 See the forum thread for more info.]

===Launch Vehicles: Jupiter J-246, and NASA Ares-1===
[[File:Ares-1.jpg|thumb|270px|[[Ares-1 Launch Vehicle]] Resting on the launch pad.]]
Gérard has taken some [http://www.nasa.gov/multimedia/3d_resources/models.html NASA 3D models] and prepared them for use with FlightGear. The historic [http://en.wikipedia.org/wiki/Kennedy_Space_Center_Launch_Complex_39 Kennedy Space Center Launch Complex 39] 3D model has been prepared, as well as the [http://www.nasa.gov/mission_pages/constellation/ares/aresl/index.html Ares-1 launch vehicle] 3D model. Jon Berndt ([http://www.jsbsim.org JSBSim Project] Development Coordinator) has built an approximate Ares-1 flight model based on publicly available information. [[File:CLV_090606-3D.jpg|thumb|270px|[[DIRECT J-246 Launch Vehicle]] Resting on the launch pad.]]
Work is progressing on getting that flight model integrated with the 3D model.
[[File:launch complex 39-img1.jpg|thumb|270px|[[Launch Complex 39]].]]
Gérard has also fabricated a model of the notional DIRECT launch vehicle variant known as the "Jupiter" J-246, shown in this [http://www.launchcomplexmodels.com/Direct/documents/Baseball_Cards/J246-41.4003.10050_CLV_090606.pdf informational flyer]. Jon has created a flight model for this vehicle, as well.

===Livery hangar reaches 300===
Early September, the [http://liveries.flightgear.org/ FlightGear Livery Database] welcomed its [http://liveries.flightgear.org/liveries.php?id=301 300th livery]! It is a livery of the Polish Air Force's [[Lockheed C130]], created by Maciej Zgódka, one of the latest additions to the painters-team. In the same time, the database was upgraded with a couple of new "features":
* thumbnails of liveries pop up when you hover over a link.
* a contact page was added, to ease contacting the database maintainer.
* each livery has a "Report this livery" button, through which visitors can notify the maintainer of a broken download, incorrect or unknown author, licensing issues etc.

I would like to emphasize that lots of liveries are not yet assigned an author. Please check for yourself if there is any [http://liveries.flightgear.org/authors.php unknown-author-livery] of which you known/are the author. Lots of liveries are still in the need for a thumbnail, so those are welcome as well.

== Scenery corner ==
===Historic Nike Hercules Missile Sites===
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These Sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each Site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into flightgear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.

===UK Football Stadiums===
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.

===Liverpool John Lennon Airport===
Andyramone has begun modeling Liverpool Airport (EGGP) in the UK. The terminal is completed and will be submitted to the database this month. Work has already begun on the control tower.

===KSFO Terminal 2===
[[San Francisco International Airport]]'s Terminal 2 has been fully remodelled by Karla in Blender 2.49b, using handmade textures in Gimp 2.46. New additions include: linking wings, antennae, railings, supports, ground floors interiors, ATC equipment, vigilant controller, architecture, light masts and night textures.

It has been released and is available via [[TerraSync]].

After improving the terminal, Karla wrote a howto on how to create realistic textures for buildings. More on that in the [[#Wiki updates|Wiki updates]] section of this newsletter.

===Dublin Airport===
"eag1e" (on the forum, D-ELLE callsign) is working on the buildings of [[Dublin Airport]] (EIDW). The airport seems quite well advanced, it has been submitted to the model repository and it is available for direct download at [http://www.knatterkasten.de/ knatterkasten.de].

See the [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8874 forum post] for more info.

===Innsbruck ÖAMTC helicopter base===
[[File:LOWI_oamtc_helicopter_base.jpg|thumb|Innsbruck ÖAMTC helicopter base]]
The ÖAMTC and Flugpolizei (police) Helicopter base at Innsbruck airport (LOWI) is currently under development by ot-666. Most likely it will be outfitted with moving helipads that are under development by HHS.

===Power plants===
Power plants, with their red and white striped tall stacks, are outstanding visual aids for VFR flying.

Scighera has modeled two Italian power plants in Blender :
* "'''ENEL Piombino 4x330 MW Power Plant'''", located in Piombino, right in front of the Isola d'Elba (Tuscany, Italy). It represent the standard Italian heavy fuel oil fired 330 MW unit of the early 70ies, with 220 m high stacks provided with red obstruction lights. The model includes a Fuel oil unloading pear, with a mooring tankership
* "'''a2a 1000 MW Combined Cycle Power Plant'''" located in Cassano d'Adda (Lombardy, Italy, 30 km away from Milano Linate (LIME)). The plant is provided with 3 Turbogas, 3 Heat Recovery Steam Generators feeding the pre-existing steam turbines. There is a 220 m high red & white stiped stack and a lower 80 m stack.

The models have been submitted to the models repository (Piombino is already available via [[TerraSync]]), and available for download at [http://digilander.libero.it/scighera_fg/index.html Scighera's website].

scighera is also working on the '''Poolbeg Power Plant''', on the Dublin peninsula, very close to Dublin Airport (EIDW); the plant has two outstanding 208 m high stacks ...

<gallery>
Image:ENEL-Piombino-1.jpg| ENEL Piombino 4x330 MW Power Plant
Image:Cassano.jpg| Cassano d'Adda 1000MW Power Plant
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
</gallery>

[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]
===Harbors===
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.

== Video of the month ==
Inspired by an idea posted by Mogthor, redneck has turned a part of the "Getting started" manual into a series of youtube videos, please see: http://flightgear.org/forums/viewtopic.php?f=25&t=9476&p=96015#p96015

== Aircraft of the month ==

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

== Suggested flights ==
===Hawai'i===
[[Image:Maui03.jpg|thumb]]
Do you use [[TerraSync]]? If so, try a flight around Hawaii! Take off from PHNL in a light aircraft and head west until you hit Pearl Harbor; a right turn north will take you post the USS Arizona Memorial, and the Punchbowl Crater will be to your right. Or, fly east from PHNL past volcanic craters Diamond Head and Koko Head. If you follow the O'ahu coastline north from Koko Head, you can land at either old World War II airbase Bellows Field (now a wildlife reserve in real life) or at Keahole MCAS.

For a potentially more scenic route, fly east toward Molokai, and stay to the north (left) of the island. The northern part of Molokai features huge sea cliffs and a tiny airstrip on the Kalaupapa peninsula - the peninsula being the only respite from the cliffs. A former leper colony existed near the airstrip!

Also of interest are the volcanoes on Maui and the 'Big Island' of Hawai'i - flying VFR in a small plane from PHTO to PHKO over the plateau between Mauna Kea and Mauna Loa can be a challenge, as you have to take off from sea level, fly through a pass of 6500 feet, and then drop back down to sea level to land! The Hana coast of northern Maui is also a nice flight - a circumnavigation of Haleakala, starting and ending at PHOG, is quite a nice flight.

The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.

== Aircraft reviews ==

== Wiki updates ==
===Creating realistic textures for buildings===
Texture and modelling artist karla, who recently [[#KSFO Terminal 2|remodeled terminal 2 of KSFO]], wrote a nice article on how to create (photo) realistic textures for buildings. The article explains the texturing process from start to end. Several techniques for creating light-effects, non-repeating surfaces and making faces look weathered are discussed and explained step by step.

Read the howto at [[Howto: Texture a building‎‎]] and provide the FlightGear community with some nice scenery additions!

===Creating cumulus cloud textures for the weather system ===
WooT has provided a short tutorial on extracting cumulus cloud textures from images. This will be useful for providing improved textures for the local weather system. Read the howto at [[Howto:Cumulus cloud texture extraction]].

===Running FlightGear on less modern hardware ===
A number of recent forum discussions were about running FlightGear on older hardware, we have now created a new article that focuses on just that: [[Howto: Build a cheap FlightGear box]].

== Community news ==
=== FlightGear on youtube ===
* Ten students at NASA's LARSS (Langley Aerospace Research Summer Scholars), put together [http://www.youtube.com/watch?v=YmnFP-1UlSY an autonomous robotics lab], using mostly open source tools. One of which is a FlightGear Multiplayer Server.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

=== Forum news ===

Thanks to Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45

=== Multiplayer ===
=== Virtual airlines ===

== Useful links ==
== And finally ... ==
Next [http://www.fsweekend.com/ FSWeekend] event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at [[Lelystad_Airport|Lelystad's airport]].

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

===Reminder: FSweekend===
With just two months togo, the largest flight simulator event in the world (the [[FSweekend]] at [[Lelystad Airport]], the Netherlands) is coming close. Make sure to mark the weekend of 6&7 November in your agenda as "occupied". A team of FlightGear developers will be present in Lelystad to promote FlightGear to the public. They highly appreciate it if you are able to stop over at the airport!

Last year we organised a [[Howto: Multiplayer|multiplayer]] event in which FlightGear users from all over the world could virtually visit Lelystad. Something similar for this year is currently being discussed. Expect more details in next month's newsletter.

=== Reminder: Google's Summer of Code 2011 ===
We would like to remind all readers that the FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].

=== Did you know ===

[[Category:FlightGear Newsletter|2010 09]]

FlightGear Newsletter September 2010

2010-09-21T03:59:45Z

Jonsberndt: /* Launch Vehicles: Jupiter J-246, and NASA Ares-1 */

{{newsletter}}
{{TOC_right}}
''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 projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== FlightGear events ==
== Development news ==

===Local Weather v0.85===
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the Local Weather package is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.

The increased performance means that 3d clouds on fast systems can be rendered out to 45 km, and high altitude 2d cloud sheets sometimes up to 80 km - vastly improving the visual impression of the sky from airliner altitudes.

In addition, some bugs in the wind modelling and long-range weather patterns have been ironed out - with Flightgear 2.0.0, the package performs good in tests.

In the works:
* better hard-coded support for e.g. terrain sampling
* a METAR interface to use real-time weather and wind data
* full dynamics of the life cycle of convective clouds as they drift over the terrain
* and as always - improvements to cloud placement algorithms and cloud textures

Stay tuned!

A small feature gallery:
<gallery>
Image:local_weather_0.85_01.jpg| Cumulus and Cirrocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_02.jpg| Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)
Image:local_weather_0.85_03.jpg| 45 km cloud visibility range (Local Weather v0.85)
Image:local_weather_0.85_04.jpg| Realistic cloud bottoms (Local Weather v0.85)
Image:local_weather_0.85_05.jpg| Cumulus and Altocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_06.jpg| Multiple 3d layered clouds (Local Weather v0.85)
</gallery>

[[File:new_weather_dialog.png|thumb|200px|The new weather dialog]]
=== Weather supporting core code ===
The weather supporting core of FlightGear [http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51 has been modified] during the last weeks to better support new weather models like the above mentioned Local Weather system. Data flow between environment systems is now defined in XML config files using well [[Autopilot Configuration Reference|known syntax and elements from the autopilot]]. Complex rules using predefined filters and arbitrary expressions can be defined without the need for C++ or Nasal coding.
Along with this patch comes a unified weather settings dialog, combining previous dialogs for weather conditions, scenario, clouds and precipitation. Further plans are to integrate a new real world data source [http://www.navlost.eu/nwxs/doc/desc/ NWX], providing METAR, aloft and temperature at altitude.

=== Download & Compile script ===
For the Debian/Ubuntu users, an improvement to the [[Scripted Compilation on Linux Debian/Ubuntu|download and compile]]. If svn/git compilation fails from lates revisions (generally caused by sources among different softwares not in sync) you can still compile and obtain the lates known compiling version using the -s switch.

Beware that this feature is under testing, but should work fine.

[[File:AIWingmenandAITanker.jpg|thumb|200px|AIWingmen and AITanker]]
=== AI Objects ===
Some of the AI code has been revisited and tidied up, in a somewhat vain attempt to reduce the impact on frame rate. The facilities in Slaved Ballistic Objects, Wingmen, Ground Vehicles, and Escorts have been generalized. Now, any of these types can be subordinated, or parented, on any AI object which has a <name> tag. Thus, a wingman can be formated on a an AI Tanker, and can have a slaved droptank.

A Wingman can be formated on a Wingman to build larger formations, of which an example is shown by [http://www.youtube.com/v/YaBghBIZZWI this video].

With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.

[[File:Water shader Ju 52.jpg|thumb|270px|[[Junkers Ju 52]] flying over a lake in the French custom scenery.]]
===Water shader improvements===
Our all-time favourite shader-artist, Gral, picked up yet another project. This time it is something that covers over 70% of the entire scenery and is thus of great importance in a flight simulator: water. The new shader includes more realistic wave movements and much nicer sun "reflections". The extreme goal is to have real-time reflective water, which is still a long way to go, but with Gral's latest improvements we've at least made a step into the right direction. Transatlantic or Carribean flights have never been so exiting in FlightGear!

=== FlightGear, JSBSim, and SciCos/SciLab ===
James Goppert (an Aero Engineering graduate student at Purdue) has been doing some fascinating work using JSBSim integrated with SciCos, along with having added some new trimming algorithms and code to JSBSim. The [http://www.purduehsl.dynalias.com/index.php?page=unmanned-vehicles Purdue Flight Dynamics and Control / Hybrid Systems Lab web page] features an interesting demo video. You can also see the [http://www.youtube.com/user/jgoppert?feature=mhum#p/u/6/-B0nQbcyo-o video directly on YouTube].

And here’s another video from James, [http://www.youtube.com/watch?v=mHN-Vb9l0v8 ArduPilotMega Hardware in the Loop with SciCos/SciLab].

=== New MIL-STD Turbulence Model for JSBSim ===

Andreas Gaeb has added to JSBSim an initial release of the turbulence models from [http://cafefoundation.org/v2/pdf_tech/Flying.Qualities/PAV.FlyQual.Mil1797A.pdf MILSTD-1797A] and [http://jagger.berkeley.edu/~pack/certify/sharedpapers/8785c.pdf MIL-F-8785C] as described in [http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980028448_1998081596.pdf NAsA Contractor Report NASA CR-1998-206937].
Both the MILSTD and the Tustin transform versions are included.

To do a quick test, set the following properties:
*atmosphere/turb-type=4
*atmosphere/turbulence/milspec/windspeed_at_20ft_AGL-fps=50
*atmosphere/turbulence/milspec/severity=4
which should give moderate turbulence conditions. Further options can be found in the documentation in the header file (FGAtmosphere.h) in the JSBSim source code distribution.

In early tests of the code, both turbulence versions were seen to give reasonable results for large aircraft. For RC model size aircraft, the MIL-STD version is reasonable as well, while the Tustin version tends to diverge.

=== JSBSim, and Matlab ===

Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.

Where the project is now:
*New release ready to compile and test for 32-bit Windows.
*Some bugs have been fixed (with a couple more to squash).
*Finally have some user documentation.
*The GUI and trim feature are now nicely integrated and the user experience is much better.
*The GUI is now tabbed/multi-paned and much more powerful.
*The project size is pared down considerably and the file duplication is gone.
*The Visual Studio project files have been fixed for better portability.

Where the project is going:
*[http://www.simauthor.com/flightviz.html FlightViz visualization tool] is currently in work.
*Environmental parameters (winds, wind-shear etc) controlled by the GUI.
*Data plotting and initial trimmed control inputs prediction.
*Closed-loop PID stabilization for finding trim points.
*Improvements to trim function.
*Flight profile scripting controllable from the GUI.
*Linux compiled version.
*Improve the documentation.
*Author a white paper.

This gives an overall picture of the current and future scope of the project. The JSBSim SFunction should become a very useful tool for flight model development and research. Agostino is also working an a MEX file (Matlab Executable) that wraps JSBSim.

==Nasal syntax highlighting file for Notepad++ users ==

Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out http://flightgear.org/forums/viewtopic.php?f=30&t=9260&p=95391#p92127 to download the file and for installation instructions.

== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).

These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.

In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.

This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.

For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);

That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.

This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.

Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.

So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).

Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".

Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".

Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.

For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.

This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.

Of course, one may still use objects like conventional variables for passing and returning parameters.

== New software tools ==
== FlightGear addons and mods ==
== In the hangar ==
===BAe-146===
"Pilot Penguin" and "[[User:Nickyivyca|nickyivyca]]" have begun work on the BAe-146. Pilot Penguin will be doing mostly 3D work, and nick will be doing mostly FDM and systems work. [http://flightgear.org/forums/viewtopic.php?f=4&t=9494&start=15 See the forum thread for more info.]

===Launch Vehicles: Jupiter J-246, and NASA Ares-1===
Gérard has taken some [http://www.nasa.gov/multimedia/3d_resources/models.html NASA 3D models] and prepared them for use with FlightGear. The historic [http://en.wikipedia.org/wiki/Kennedy_Space_Center_Launch_Complex_39 Kennedy Space Center Launch Complex 39] 3D model has been prepared, as well as the [http://www.nasa.gov/mission_pages/constellation/ares/aresl/index.html Ares-1 launch vehicle] 3D model. Jon Berndt ([http://www.jsbsim.org JSBSim Project] Development Coordinator) has built an approximate Ares-1 flight model based on publicly available information. Work is progressing on getting that flight model integrated with the 3D model.
[[File:Ares-1.jpg|thumb|270px|[[Ares-1 Launch Vehicle]] Resting on the launch pad.]]
[[File:CLV_090606-3D.jpg|thumb|270px|[[DIRECT J-246 Launch Vehicle]] Resting on the launch pad.]]
[[File:launch complex 39-img1.jpg|thumb|270px|[[Launch Complex 39]].]]
Gérard has also fabricated a model of the notional DIRECT launch vehicle variant known as the "Jupiter" J-246, shown in this [http://www.launchcomplexmodels.com/Direct/documents/Baseball_Cards/J246-41.4003.10050_CLV_090606.pdf informational flyer]. Jon has created a flight model for this vehicle, as well.

===Livery hangar reaches 300===
Early September, the [http://liveries.flightgear.org/ FlightGear Livery Database] welcomed its [http://liveries.flightgear.org/liveries.php?id=301 300th livery]! It is a livery of the Polish Air Force's [[Lockheed C130]], created by Maciej Zgódka, one of the latest additions to the painters-team. In the same time, the database was upgraded with a couple of new "features":
* thumbnails of liveries pop up when you hover over a link.
* a contact page was added, to ease contacting the database maintainer.
* each livery has a "Report this livery" button, through which visitors can notify the maintainer of a broken download, incorrect or unknown author, licensing issues etc.

I would like to emphasize that lots of liveries are not yet assigned an author. Please check for yourself if there is any [http://liveries.flightgear.org/authors.php unknown-author-livery] of which you known/are the author. Lots of liveries are still in the need for a thumbnail, so those are welcome as well.

== Scenery corner ==
===Historic Nike Hercules Missile Sites===
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These Sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each Site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into flightgear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.

===UK Football Stadiums===
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.

===Liverpool John Lennon Airport===
Andyramone has begun modeling Liverpool Airport (EGGP) in the UK. The terminal is completed and will be submitted to the database this month. Work has already begun on the control tower.

===KSFO Terminal 2===
[[San Francisco International Airport]]'s Terminal 2 has been fully remodelled by Karla in Blender 2.49b, using handmade textures in Gimp 2.46. New additions include: linking wings, antennae, railings, supports, ground floors interiors, ATC equipment, vigilant controller, architecture, light masts and night textures.

It has been released and is available via [[TerraSync]].

After improving the terminal, Karla wrote a howto on how to create realistic textures for buildings. More on that in the [[#Wiki updates|Wiki updates]] section of this newsletter.

===Dublin Airport===
"eag1e" (on the forum, D-ELLE callsign) is working on the buildings of [[Dublin Airport]] (EIDW). The airport seems quite well advanced, it has been submitted to the model repository and it is available for direct download at [http://www.knatterkasten.de/ knatterkasten.de].

See the [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8874 forum post] for more info.

===Innsbruck ÖAMTC helicopter base===
[[File:LOWI_oamtc_helicopter_base.jpg|thumb|Innsbruck ÖAMTC helicopter base]]
The ÖAMTC and Flugpolizei (police) Helicopter base at Innsbruck airport (LOWI) is currently under development by ot-666. Most likely it will be outfitted with moving helipads that are under development by HHS.

===Power plants===
Power plants, with their red and white striped tall stacks, are outstanding visual aids for VFR flying.

Scighera has modeled two Italian power plants in Blender :
* "'''ENEL Piombino 4x330 MW Power Plant'''", located in Piombino, right in front of the Isola d'Elba (Tuscany, Italy). It represent the standard Italian heavy fuel oil fired 330 MW unit of the early 70ies, with 220 m high stacks provided with red obstruction lights. The model includes a Fuel oil unloading pear, with a mooring tankership
* "'''a2a 1000 MW Combined Cycle Power Plant'''" located in Cassano d'Adda (Lombardy, Italy, 30 km away from Milano Linate (LIME)). The plant is provided with 3 Turbogas, 3 Heat Recovery Steam Generators feeding the pre-existing steam turbines. There is a 220 m high red & white stiped stack and a lower 80 m stack.

The models have been submitted to the models repository (Piombino is already available via [[TerraSync]]), and available for download at [http://digilander.libero.it/scighera_fg/index.html Scighera's website].

scighera is also working on the '''Poolbeg Power Plant''', on the Dublin peninsula, very close to Dublin Airport (EIDW); the plant has two outstanding 208 m high stacks ...

<gallery>
Image:ENEL-Piombino-1.jpg| ENEL Piombino 4x330 MW Power Plant
Image:Cassano.jpg| Cassano d'Adda 1000MW Power Plant
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
</gallery>

[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]
===Harbors===
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.

== Video of the month ==
Inspired by an idea posted by Mogthor, redneck has turned a part of the "Getting started" manual into a series of youtube videos, please see: http://flightgear.org/forums/viewtopic.php?f=25&t=9476&p=96015#p96015

== Aircraft of the month ==

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

== Suggested flights ==
===Hawai'i===
[[Image:Maui03.jpg|thumb]]
Do you use [[TerraSync]]? If so, try a flight around Hawaii! Take off from PHNL in a light aircraft and head west until you hit Pearl Harbor; a right turn north will take you post the USS Arizona Memorial, and the Punchbowl Crater will be to your right. Or, fly east from PHNL past volcanic craters Diamond Head and Koko Head. If you follow the O'ahu coastline north from Koko Head, you can land at either old World War II airbase Bellows Field (now a wildlife reserve in real life) or at Keahole MCAS.

For a potentially more scenic route, fly east toward Molokai, and stay to the north (left) of the island. The northern part of Molokai features huge sea cliffs and a tiny airstrip on the Kalaupapa peninsula - the peninsula being the only respite from the cliffs. A former leper colony existed near the airstrip!

Also of interest are the volcanoes on Maui and the 'Big Island' of Hawai'i - flying VFR in a small plane from PHTO to PHKO over the plateau between Mauna Kea and Mauna Loa can be a challenge, as you have to take off from sea level, fly through a pass of 6500 feet, and then drop back down to sea level to land! The Hana coast of northern Maui is also a nice flight - a circumnavigation of Haleakala, starting and ending at PHOG, is quite a nice flight.

The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.

== Aircraft reviews ==

== Wiki updates ==
===Creating realistic textures for buildings===
Texture and modelling artist karla, who recently [[#KSFO Terminal 2|remodeled terminal 2 of KSFO]], wrote a nice article on how to create (photo) realistic textures for buildings. The article explains the texturing process from start to end. Several techniques for creating light-effects, non-repeating surfaces and making faces look weathered are discussed and explained step by step.

Read the howto at [[Howto: Texture a building‎‎]] and provide the FlightGear community with some nice scenery additions!

===Creating cumulus cloud textures for the weather system ===
WooT has provided a short tutorial on extracting cumulus cloud textures from images. This will be useful for providing improved textures for the local weather system. Read the howto at [[Howto:Cumulus cloud texture extraction]].

===Running FlightGear on less modern hardware ===
A number of recent forum discussions were about running FlightGear on older hardware, we have now created a new article that focuses on just that: [[Howto: Build a cheap FlightGear box]].

== Community news ==
=== FlightGear on youtube ===
* Ten students at NASA's LARSS (Langley Aerospace Research Summer Scholars), put together [http://www.youtube.com/watch?v=YmnFP-1UlSY an autonomous robotics lab], using mostly open source tools. One of which is a FlightGear Multiplayer Server.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

=== Forum news ===

Thanks to Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45

=== Multiplayer ===
=== Virtual airlines ===

== Useful links ==
== And finally ... ==
Next [http://www.fsweekend.com/ FSWeekend] event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at [[Lelystad_Airport|Lelystad's airport]].

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

===Reminder: FSweekend===
With just two months togo, the largest flight simulator event in the world (the [[FSweekend]] at [[Lelystad Airport]], the Netherlands) is coming close. Make sure to mark the weekend of 6&7 November in your agenda as "occupied". A team of FlightGear developers will be present in Lelystad to promote FlightGear to the public. They highly appreciate it if you are able to stop over at the airport!

Last year we organised a [[Howto: Multiplayer|multiplayer]] event in which FlightGear users from all over the world could virtually visit Lelystad. Something similar for this year is currently being discussed. Expect more details in next month's newsletter.

=== Reminder: Google's Summer of Code 2011 ===
We would like to remind all readers that the FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].

=== Did you know ===

[[Category:FlightGear Newsletter|2010 09]]

FlightGear Newsletter September 2010

2010-09-21T03:53:46Z

Jonsberndt: /* Launch Vehicles: Jupiter J-246, and NASA Ares-1 */

{{newsletter}}
{{TOC_right}}
''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 projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== FlightGear events ==
== Development news ==

===Local Weather v0.85===
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the Local Weather package is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.

The increased performance means that 3d clouds on fast systems can be rendered out to 45 km, and high altitude 2d cloud sheets sometimes up to 80 km - vastly improving the visual impression of the sky from airliner altitudes.

In addition, some bugs in the wind modelling and long-range weather patterns have been ironed out - with Flightgear 2.0.0, the package performs good in tests.

In the works:
* better hard-coded support for e.g. terrain sampling
* a METAR interface to use real-time weather and wind data
* full dynamics of the life cycle of convective clouds as they drift over the terrain
* and as always - improvements to cloud placement algorithms and cloud textures

Stay tuned!

A small feature gallery:
<gallery>
Image:local_weather_0.85_01.jpg| Cumulus and Cirrocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_02.jpg| Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)
Image:local_weather_0.85_03.jpg| 45 km cloud visibility range (Local Weather v0.85)
Image:local_weather_0.85_04.jpg| Realistic cloud bottoms (Local Weather v0.85)
Image:local_weather_0.85_05.jpg| Cumulus and Altocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_06.jpg| Multiple 3d layered clouds (Local Weather v0.85)
</gallery>

[[File:new_weather_dialog.png|thumb|200px|The new weather dialog]]
=== Weather supporting core code ===
The weather supporting core of FlightGear [http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51 has been modified] during the last weeks to better support new weather models like the above mentioned Local Weather system. Data flow between environment systems is now defined in XML config files using well [[Autopilot Configuration Reference|known syntax and elements from the autopilot]]. Complex rules using predefined filters and arbitrary expressions can be defined without the need for C++ or Nasal coding.
Along with this patch comes a unified weather settings dialog, combining previous dialogs for weather conditions, scenario, clouds and precipitation. Further plans are to integrate a new real world data source [http://www.navlost.eu/nwxs/doc/desc/ NWX], providing METAR, aloft and temperature at altitude.

=== Download & Compile script ===
For the Debian/Ubuntu users, an improvement to the [[Scripted Compilation on Linux Debian/Ubuntu|download and compile]]. If svn/git compilation fails from lates revisions (generally caused by sources among different softwares not in sync) you can still compile and obtain the lates known compiling version using the -s switch.

Beware that this feature is under testing, but should work fine.

[[File:AIWingmenandAITanker.jpg|thumb|200px|AIWingmen and AITanker]]
=== AI Objects ===
Some of the AI code has been revisited and tidied up, in a somewhat vain attempt to reduce the impact on frame rate. The facilities in Slaved Ballistic Objects, Wingmen, Ground Vehicles, and Escorts have been generalized. Now, any of these types can be subordinated, or parented, on any AI object which has a <name> tag. Thus, a wingman can be formated on a an AI Tanker, and can have a slaved droptank.

A Wingman can be formated on a Wingman to build larger formations, of which an example is shown by [http://www.youtube.com/v/YaBghBIZZWI this video].

With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.

[[File:Water shader Ju 52.jpg|thumb|270px|[[Junkers Ju 52]] flying over a lake in the French custom scenery.]]
===Water shader improvements===
Our all-time favourite shader-artist, Gral, picked up yet another project. This time it is something that covers over 70% of the entire scenery and is thus of great importance in a flight simulator: water. The new shader includes more realistic wave movements and much nicer sun "reflections". The extreme goal is to have real-time reflective water, which is still a long way to go, but with Gral's latest improvements we've at least made a step into the right direction. Transatlantic or Carribean flights have never been so exiting in FlightGear!

=== FlightGear, JSBSim, and SciCos/SciLab ===
James Goppert (an Aero Engineering graduate student at Purdue) has been doing some fascinating work using JSBSim integrated with SciCos, along with having added some new trimming algorithms and code to JSBSim. The [http://www.purduehsl.dynalias.com/index.php?page=unmanned-vehicles Purdue Flight Dynamics and Control / Hybrid Systems Lab web page] features an interesting demo video. You can also see the [http://www.youtube.com/user/jgoppert?feature=mhum#p/u/6/-B0nQbcyo-o video directly on YouTube].

And here’s another video from James, [http://www.youtube.com/watch?v=mHN-Vb9l0v8 ArduPilotMega Hardware in the Loop with SciCos/SciLab].

=== New MIL-STD Turbulence Model for JSBSim ===

Andreas Gaeb has added to JSBSim an initial release of the turbulence models from [http://cafefoundation.org/v2/pdf_tech/Flying.Qualities/PAV.FlyQual.Mil1797A.pdf MILSTD-1797A] and [http://jagger.berkeley.edu/~pack/certify/sharedpapers/8785c.pdf MIL-F-8785C] as described in [http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980028448_1998081596.pdf NAsA Contractor Report NASA CR-1998-206937].
Both the MILSTD and the Tustin transform versions are included.

To do a quick test, set the following properties:
*atmosphere/turb-type=4
*atmosphere/turbulence/milspec/windspeed_at_20ft_AGL-fps=50
*atmosphere/turbulence/milspec/severity=4
which should give moderate turbulence conditions. Further options can be found in the documentation in the header file (FGAtmosphere.h) in the JSBSim source code distribution.

In early tests of the code, both turbulence versions were seen to give reasonable results for large aircraft. For RC model size aircraft, the MIL-STD version is reasonable as well, while the Tustin version tends to diverge.

=== JSBSim, and Matlab ===

Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.

Where the project is now:
*New release ready to compile and test for 32-bit Windows.
*Some bugs have been fixed (with a couple more to squash).
*Finally have some user documentation.
*The GUI and trim feature are now nicely integrated and the user experience is much better.
*The GUI is now tabbed/multi-paned and much more powerful.
*The project size is pared down considerably and the file duplication is gone.
*The Visual Studio project files have been fixed for better portability.

Where the project is going:
*[http://www.simauthor.com/flightviz.html FlightViz visualization tool] is currently in work.
*Environmental parameters (winds, wind-shear etc) controlled by the GUI.
*Data plotting and initial trimmed control inputs prediction.
*Closed-loop PID stabilization for finding trim points.
*Improvements to trim function.
*Flight profile scripting controllable from the GUI.
*Linux compiled version.
*Improve the documentation.
*Author a white paper.

This gives an overall picture of the current and future scope of the project. The JSBSim SFunction should become a very useful tool for flight model development and research. Agostino is also working an a MEX file (Matlab Executable) that wraps JSBSim.

==Nasal syntax highlighting file for Notepad++ users ==

Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out http://flightgear.org/forums/viewtopic.php?f=30&t=9260&p=95391#p92127 to download the file and for installation instructions.

== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).

These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.

In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.

This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.

For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);

That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.

This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.

Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.

So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).

Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".

Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".

Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.

For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.

This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.

Of course, one may still use objects like conventional variables for passing and returning parameters.

== New software tools ==
== FlightGear addons and mods ==
== In the hangar ==
===BAe-146===
"Pilot Penguin" and "[[User:Nickyivyca|nickyivyca]]" have begun work on the BAe-146. Pilot Penguin will be doing mostly 3D work, and nick will be doing mostly FDM and systems work. [http://flightgear.org/forums/viewtopic.php?f=4&t=9494&start=15 See the forum thread for more info.]

===Launch Vehicles: Jupiter J-246, and NASA Ares-1===
Gérard has taken some [http://www.nasa.gov/multimedia/3d_resources/models.html NASA 3D models] and prepared them for use with FlightGear. The historic [http://en.wikipedia.org/wiki/Kennedy_Space_Center_Launch_Complex_39 Kennedy Space Center Launch Complex 39] 3D model has been prepared, as well as the [http://www.nasa.gov/mission_pages/constellation/ares/aresl/index.html Ares-1 launch vehicle] 3D model. Jon Berndt ([http://www.jsbsim.org JSBSim Project] Development Coordinator) has built an approximate Ares-1 flight model based on publicly available information. Work is progressing on getting that flight model integrated with the 3D model.
[[File:Ares-1.jpg]]
Gérard has also fabricated a model of the notional DIRECT launch vehicle variant known as the "Jupiter" J-246, shown in this [http://www.launchcomplexmodels.com/Direct/documents/Baseball_Cards/J246-41.4003.10050_CLV_090606.pdf informational flyer]. Jon has created a flight model for this vehicle, as well.

===Livery hangar reaches 300===
Early September, the [http://liveries.flightgear.org/ FlightGear Livery Database] welcomed its [http://liveries.flightgear.org/liveries.php?id=301 300th livery]! It is a livery of the Polish Air Force's [[Lockheed C130]], created by Maciej Zgódka, one of the latest additions to the painters-team. In the same time, the database was upgraded with a couple of new "features":
* thumbnails of liveries pop up when you hover over a link.
* a contact page was added, to ease contacting the database maintainer.
* each livery has a "Report this livery" button, through which visitors can notify the maintainer of a broken download, incorrect or unknown author, licensing issues etc.

I would like to emphasize that lots of liveries are not yet assigned an author. Please check for yourself if there is any [http://liveries.flightgear.org/authors.php unknown-author-livery] of which you known/are the author. Lots of liveries are still in the need for a thumbnail, so those are welcome as well.

== Scenery corner ==
===Historic Nike Hercules Missile Sites===
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These Sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each Site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into flightgear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.

===UK Football Stadiums===
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.

===Liverpool John Lennon Airport===
Andyramone has begun modeling Liverpool Airport (EGGP) in the UK. The terminal is completed and will be submitted to the database this month. Work has already begun on the control tower.

===KSFO Terminal 2===
[[San Francisco International Airport]]'s Terminal 2 has been fully remodelled by Karla in Blender 2.49b, using handmade textures in Gimp 2.46. New additions include: linking wings, antennae, railings, supports, ground floors interiors, ATC equipment, vigilant controller, architecture, light masts and night textures.

It has been released and is available via [[TerraSync]].

After improving the terminal, Karla wrote a howto on how to create realistic textures for buildings. More on that in the [[#Wiki updates|Wiki updates]] section of this newsletter.

===Dublin Airport===
"eag1e" (on the forum, D-ELLE callsign) is working on the buildings of [[Dublin Airport]] (EIDW). The airport seems quite well advanced, it has been submitted to the model repository and it is available for direct download at [http://www.knatterkasten.de/ knatterkasten.de].

See the [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8874 forum post] for more info.

===Innsbruck ÖAMTC helicopter base===
[[File:LOWI_oamtc_helicopter_base.jpg|thumb|Innsbruck ÖAMTC helicopter base]]
The ÖAMTC and Flugpolizei (police) Helicopter base at Innsbruck airport (LOWI) is currently under development by ot-666. Most likely it will be outfitted with moving helipads that are under development by HHS.

===Power plants===
Power plants, with their red and white striped tall stacks, are outstanding visual aids for VFR flying.

Scighera has modeled two Italian power plants in Blender :
* "'''ENEL Piombino 4x330 MW Power Plant'''", located in Piombino, right in front of the Isola d'Elba (Tuscany, Italy). It represent the standard Italian heavy fuel oil fired 330 MW unit of the early 70ies, with 220 m high stacks provided with red obstruction lights. The model includes a Fuel oil unloading pear, with a mooring tankership
* "'''a2a 1000 MW Combined Cycle Power Plant'''" located in Cassano d'Adda (Lombardy, Italy, 30 km away from Milano Linate (LIME)). The plant is provided with 3 Turbogas, 3 Heat Recovery Steam Generators feeding the pre-existing steam turbines. There is a 220 m high red & white stiped stack and a lower 80 m stack.

The models have been submitted to the models repository (Piombino is already available via [[TerraSync]]), and available for download at [http://digilander.libero.it/scighera_fg/index.html Scighera's website].

scighera is also working on the '''Poolbeg Power Plant''', on the Dublin peninsula, very close to Dublin Airport (EIDW); the plant has two outstanding 208 m high stacks ...

<gallery>
Image:ENEL-Piombino-1.jpg| ENEL Piombino 4x330 MW Power Plant
Image:Cassano.jpg| Cassano d'Adda 1000MW Power Plant
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
</gallery>

[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]
===Harbors===
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.

== Video of the month ==
Inspired by an idea posted by Mogthor, redneck has turned a part of the "Getting started" manual into a series of youtube videos, please see: http://flightgear.org/forums/viewtopic.php?f=25&t=9476&p=96015#p96015

== Aircraft of the month ==

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

== Suggested flights ==
===Hawai'i===
[[Image:Maui03.jpg|thumb]]
Do you use [[TerraSync]]? If so, try a flight around Hawaii! Take off from PHNL in a light aircraft and head west until you hit Pearl Harbor; a right turn north will take you post the USS Arizona Memorial, and the Punchbowl Crater will be to your right. Or, fly east from PHNL past volcanic craters Diamond Head and Koko Head. If you follow the O'ahu coastline north from Koko Head, you can land at either old World War II airbase Bellows Field (now a wildlife reserve in real life) or at Keahole MCAS.

For a potentially more scenic route, fly east toward Molokai, and stay to the north (left) of the island. The northern part of Molokai features huge sea cliffs and a tiny airstrip on the Kalaupapa peninsula - the peninsula being the only respite from the cliffs. A former leper colony existed near the airstrip!

Also of interest are the volcanoes on Maui and the 'Big Island' of Hawai'i - flying VFR in a small plane from PHTO to PHKO over the plateau between Mauna Kea and Mauna Loa can be a challenge, as you have to take off from sea level, fly through a pass of 6500 feet, and then drop back down to sea level to land! The Hana coast of northern Maui is also a nice flight - a circumnavigation of Haleakala, starting and ending at PHOG, is quite a nice flight.

The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.

== Aircraft reviews ==

== Wiki updates ==
===Creating realistic textures for buildings===
Texture and modelling artist karla, who recently [[#KSFO Terminal 2|remodeled terminal 2 of KSFO]], wrote a nice article on how to create (photo) realistic textures for buildings. The article explains the texturing process from start to end. Several techniques for creating light-effects, non-repeating surfaces and making faces look weathered are discussed and explained step by step.

Read the howto at [[Howto: Texture a building‎‎]] and provide the FlightGear community with some nice scenery additions!

===Creating cumulus cloud textures for the weather system ===
WooT has provided a short tutorial on extracting cumulus cloud textures from images. This will be useful for providing improved textures for the local weather system. Read the howto at [[Howto:Cumulus cloud texture extraction]].

===Running FlightGear on less modern hardware ===
A number of recent forum discussions were about running FlightGear on older hardware, we have now created a new article that focuses on just that: [[Howto: Build a cheap FlightGear box]].

== Community news ==
=== FlightGear on youtube ===
* Ten students at NASA's LARSS (Langley Aerospace Research Summer Scholars), put together [http://www.youtube.com/watch?v=YmnFP-1UlSY an autonomous robotics lab], using mostly open source tools. One of which is a FlightGear Multiplayer Server.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

=== Forum news ===

Thanks to Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45

=== Multiplayer ===
=== Virtual airlines ===

== Useful links ==
== And finally ... ==
Next [http://www.fsweekend.com/ FSWeekend] event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at [[Lelystad_Airport|Lelystad's airport]].

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

===Reminder: FSweekend===
With just two months togo, the largest flight simulator event in the world (the [[FSweekend]] at [[Lelystad Airport]], the Netherlands) is coming close. Make sure to mark the weekend of 6&7 November in your agenda as "occupied". A team of FlightGear developers will be present in Lelystad to promote FlightGear to the public. They highly appreciate it if you are able to stop over at the airport!

Last year we organised a [[Howto: Multiplayer|multiplayer]] event in which FlightGear users from all over the world could virtually visit Lelystad. Something similar for this year is currently being discussed. Expect more details in next month's newsletter.

=== Reminder: Google's Summer of Code 2011 ===
We would like to remind all readers that the FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].

=== Did you know ===

[[Category:FlightGear Newsletter|2010 09]]

File:Launch complex 39-img1.jpg

2010-09-21T03:52:12Z

Jonsberndt:

File:CLV 090606-3D.jpg

2010-09-21T03:51:48Z

Jonsberndt:

File:Ares-1.jpg

2010-09-21T03:51:27Z

Jonsberndt:

FlightGear Newsletter September 2010

2010-09-21T03:48:45Z

Jonsberndt: /* In the hangar */

{{newsletter}}
{{TOC_right}}
''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 projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== FlightGear events ==
== Development news ==

===Local Weather v0.85===
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the Local Weather package is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.

The increased performance means that 3d clouds on fast systems can be rendered out to 45 km, and high altitude 2d cloud sheets sometimes up to 80 km - vastly improving the visual impression of the sky from airliner altitudes.

In addition, some bugs in the wind modelling and long-range weather patterns have been ironed out - with Flightgear 2.0.0, the package performs good in tests.

In the works:
* better hard-coded support for e.g. terrain sampling
* a METAR interface to use real-time weather and wind data
* full dynamics of the life cycle of convective clouds as they drift over the terrain
* and as always - improvements to cloud placement algorithms and cloud textures

Stay tuned!

A small feature gallery:
<gallery>
Image:local_weather_0.85_01.jpg| Cumulus and Cirrocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_02.jpg| Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)
Image:local_weather_0.85_03.jpg| 45 km cloud visibility range (Local Weather v0.85)
Image:local_weather_0.85_04.jpg| Realistic cloud bottoms (Local Weather v0.85)
Image:local_weather_0.85_05.jpg| Cumulus and Altocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_06.jpg| Multiple 3d layered clouds (Local Weather v0.85)
</gallery>

[[File:new_weather_dialog.png|thumb|200px|The new weather dialog]]
=== Weather supporting core code ===
The weather supporting core of FlightGear [http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51 has been modified] during the last weeks to better support new weather models like the above mentioned Local Weather system. Data flow between environment systems is now defined in XML config files using well [[Autopilot Configuration Reference|known syntax and elements from the autopilot]]. Complex rules using predefined filters and arbitrary expressions can be defined without the need for C++ or Nasal coding.
Along with this patch comes a unified weather settings dialog, combining previous dialogs for weather conditions, scenario, clouds and precipitation. Further plans are to integrate a new real world data source [http://www.navlost.eu/nwxs/doc/desc/ NWX], providing METAR, aloft and temperature at altitude.

=== Download & Compile script ===
For the Debian/Ubuntu users, an improvement to the [[Scripted Compilation on Linux Debian/Ubuntu|download and compile]]. If svn/git compilation fails from lates revisions (generally caused by sources among different softwares not in sync) you can still compile and obtain the lates known compiling version using the -s switch.

Beware that this feature is under testing, but should work fine.

[[File:AIWingmenandAITanker.jpg|thumb|200px|AIWingmen and AITanker]]
=== AI Objects ===
Some of the AI code has been revisited and tidied up, in a somewhat vain attempt to reduce the impact on frame rate. The facilities in Slaved Ballistic Objects, Wingmen, Ground Vehicles, and Escorts have been generalized. Now, any of these types can be subordinated, or parented, on any AI object which has a <name> tag. Thus, a wingman can be formated on a an AI Tanker, and can have a slaved droptank.

A Wingman can be formated on a Wingman to build larger formations, of which an example is shown by [http://www.youtube.com/v/YaBghBIZZWI this video].

With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.

[[File:Water shader Ju 52.jpg|thumb|270px|[[Junkers Ju 52]] flying over a lake in the French custom scenery.]]
===Water shader improvements===
Our all-time favourite shader-artist, Gral, picked up yet another project. This time it is something that covers over 70% of the entire scenery and is thus of great importance in a flight simulator: water. The new shader includes more realistic wave movements and much nicer sun "reflections". The extreme goal is to have real-time reflective water, which is still a long way to go, but with Gral's latest improvements we've at least made a step into the right direction. Transatlantic or Carribean flights have never been so exiting in FlightGear!

=== FlightGear, JSBSim, and SciCos/SciLab ===
James Goppert (an Aero Engineering graduate student at Purdue) has been doing some fascinating work using JSBSim integrated with SciCos, along with having added some new trimming algorithms and code to JSBSim. The [http://www.purduehsl.dynalias.com/index.php?page=unmanned-vehicles Purdue Flight Dynamics and Control / Hybrid Systems Lab web page] features an interesting demo video. You can also see the [http://www.youtube.com/user/jgoppert?feature=mhum#p/u/6/-B0nQbcyo-o video directly on YouTube].

And here’s another video from James, [http://www.youtube.com/watch?v=mHN-Vb9l0v8 ArduPilotMega Hardware in the Loop with SciCos/SciLab].

=== New MIL-STD Turbulence Model for JSBSim ===

Andreas Gaeb has added to JSBSim an initial release of the turbulence models from [http://cafefoundation.org/v2/pdf_tech/Flying.Qualities/PAV.FlyQual.Mil1797A.pdf MILSTD-1797A] and [http://jagger.berkeley.edu/~pack/certify/sharedpapers/8785c.pdf MIL-F-8785C] as described in [http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980028448_1998081596.pdf NAsA Contractor Report NASA CR-1998-206937].
Both the MILSTD and the Tustin transform versions are included.

To do a quick test, set the following properties:
*atmosphere/turb-type=4
*atmosphere/turbulence/milspec/windspeed_at_20ft_AGL-fps=50
*atmosphere/turbulence/milspec/severity=4
which should give moderate turbulence conditions. Further options can be found in the documentation in the header file (FGAtmosphere.h) in the JSBSim source code distribution.

In early tests of the code, both turbulence versions were seen to give reasonable results for large aircraft. For RC model size aircraft, the MIL-STD version is reasonable as well, while the Tustin version tends to diverge.

=== JSBSim, and Matlab ===

Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.

Where the project is now:
*New release ready to compile and test for 32-bit Windows.
*Some bugs have been fixed (with a couple more to squash).
*Finally have some user documentation.
*The GUI and trim feature are now nicely integrated and the user experience is much better.
*The GUI is now tabbed/multi-paned and much more powerful.
*The project size is pared down considerably and the file duplication is gone.
*The Visual Studio project files have been fixed for better portability.

Where the project is going:
*[http://www.simauthor.com/flightviz.html FlightViz visualization tool] is currently in work.
*Environmental parameters (winds, wind-shear etc) controlled by the GUI.
*Data plotting and initial trimmed control inputs prediction.
*Closed-loop PID stabilization for finding trim points.
*Improvements to trim function.
*Flight profile scripting controllable from the GUI.
*Linux compiled version.
*Improve the documentation.
*Author a white paper.

This gives an overall picture of the current and future scope of the project. The JSBSim SFunction should become a very useful tool for flight model development and research. Agostino is also working an a MEX file (Matlab Executable) that wraps JSBSim.

==Nasal syntax highlighting file for Notepad++ users ==

Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out http://flightgear.org/forums/viewtopic.php?f=30&t=9260&p=95391#p92127 to download the file and for installation instructions.

== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).

These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.

In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.

This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.

For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);

That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.

This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.

Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.

So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).

Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".

Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".

Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.

For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.

This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.

Of course, one may still use objects like conventional variables for passing and returning parameters.

== New software tools ==
== FlightGear addons and mods ==
== In the hangar ==
===BAe-146===
"Pilot Penguin" and "[[User:Nickyivyca|nickyivyca]]" have begun work on the BAe-146. Pilot Penguin will be doing mostly 3D work, and nick will be doing mostly FDM and systems work. [http://flightgear.org/forums/viewtopic.php?f=4&t=9494&start=15 See the forum thread for more info.]

===Launch Vehicles: Jupiter J-246, and NASA Ares-1===
Gérard has taken some [http://www.nasa.gov/multimedia/3d_resources/models.html NASA 3D models] and prepared them for use with FlightGear. The historic [http://en.wikipedia.org/wiki/Kennedy_Space_Center_Launch_Complex_39 Kennedy Space Center Launch Complex 39] 3D model has been prepared, as well as the [http://www.nasa.gov/mission_pages/constellation/ares/aresl/index.html Ares-1 launch vehicle] 3D model. Jon Berndt ([http://www.jsbsim.org JSBSim Project] Development Coordinator) has built an approximate Ares-1 flight model based on publicly available information. Work is progressing on getting that flight model integrated with the 3D model.

Gérard has also fabricated a model of the notional DIRECT launch vehicle variant known as the "Jupiter" J-246, shown in this [http://www.launchcomplexmodels.com/Direct/documents/Baseball_Cards/J246-41.4003.10050_CLV_090606.pdf informational flyer]. Jon has created a flight model for this vehicle, as well.

===Livery hangar reaches 300===
Early September, the [http://liveries.flightgear.org/ FlightGear Livery Database] welcomed its [http://liveries.flightgear.org/liveries.php?id=301 300th livery]! It is a livery of the Polish Air Force's [[Lockheed C130]], created by Maciej Zgódka, one of the latest additions to the painters-team. In the same time, the database was upgraded with a couple of new "features":
* thumbnails of liveries pop up when you hover over a link.
* a contact page was added, to ease contacting the database maintainer.
* each livery has a "Report this livery" button, through which visitors can notify the maintainer of a broken download, incorrect or unknown author, licensing issues etc.

I would like to emphasize that lots of liveries are not yet assigned an author. Please check for yourself if there is any [http://liveries.flightgear.org/authors.php unknown-author-livery] of which you known/are the author. Lots of liveries are still in the need for a thumbnail, so those are welcome as well.

== Scenery corner ==
===Historic Nike Hercules Missile Sites===
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These Sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each Site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into flightgear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.

===UK Football Stadiums===
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.

===Liverpool John Lennon Airport===
Andyramone has begun modeling Liverpool Airport (EGGP) in the UK. The terminal is completed and will be submitted to the database this month. Work has already begun on the control tower.

===KSFO Terminal 2===
[[San Francisco International Airport]]'s Terminal 2 has been fully remodelled by Karla in Blender 2.49b, using handmade textures in Gimp 2.46. New additions include: linking wings, antennae, railings, supports, ground floors interiors, ATC equipment, vigilant controller, architecture, light masts and night textures.

It has been released and is available via [[TerraSync]].

After improving the terminal, Karla wrote a howto on how to create realistic textures for buildings. More on that in the [[#Wiki updates|Wiki updates]] section of this newsletter.

===Dublin Airport===
"eag1e" (on the forum, D-ELLE callsign) is working on the buildings of [[Dublin Airport]] (EIDW). The airport seems quite well advanced, it has been submitted to the model repository and it is available for direct download at [http://www.knatterkasten.de/ knatterkasten.de].

See the [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8874 forum post] for more info.

===Innsbruck ÖAMTC helicopter base===
[[File:LOWI_oamtc_helicopter_base.jpg|thumb|Innsbruck ÖAMTC helicopter base]]
The ÖAMTC and Flugpolizei (police) Helicopter base at Innsbruck airport (LOWI) is currently under development by ot-666. Most likely it will be outfitted with moving helipads that are under development by HHS.

===Power plants===
Power plants, with their red and white striped tall stacks, are outstanding visual aids for VFR flying.

Scighera has modeled two Italian power plants in Blender :
* "'''ENEL Piombino 4x330 MW Power Plant'''", located in Piombino, right in front of the Isola d'Elba (Tuscany, Italy). It represent the standard Italian heavy fuel oil fired 330 MW unit of the early 70ies, with 220 m high stacks provided with red obstruction lights. The model includes a Fuel oil unloading pear, with a mooring tankership
* "'''a2a 1000 MW Combined Cycle Power Plant'''" located in Cassano d'Adda (Lombardy, Italy, 30 km away from Milano Linate (LIME)). The plant is provided with 3 Turbogas, 3 Heat Recovery Steam Generators feeding the pre-existing steam turbines. There is a 220 m high red & white stiped stack and a lower 80 m stack.

The models have been submitted to the models repository (Piombino is already available via [[TerraSync]]), and available for download at [http://digilander.libero.it/scighera_fg/index.html Scighera's website].

scighera is also working on the '''Poolbeg Power Plant''', on the Dublin peninsula, very close to Dublin Airport (EIDW); the plant has two outstanding 208 m high stacks ...

<gallery>
Image:ENEL-Piombino-1.jpg| ENEL Piombino 4x330 MW Power Plant
Image:Cassano.jpg| Cassano d'Adda 1000MW Power Plant
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
</gallery>

[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]
===Harbors===
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.

== Video of the month ==
Inspired by an idea posted by Mogthor, redneck has turned a part of the "Getting started" manual into a series of youtube videos, please see: http://flightgear.org/forums/viewtopic.php?f=25&t=9476&p=96015#p96015

== Aircraft of the month ==

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

== Suggested flights ==
===Hawai'i===
[[Image:Maui03.jpg|thumb]]
Do you use [[TerraSync]]? If so, try a flight around Hawaii! Take off from PHNL in a light aircraft and head west until you hit Pearl Harbor; a right turn north will take you post the USS Arizona Memorial, and the Punchbowl Crater will be to your right. Or, fly east from PHNL past volcanic craters Diamond Head and Koko Head. If you follow the O'ahu coastline north from Koko Head, you can land at either old World War II airbase Bellows Field (now a wildlife reserve in real life) or at Keahole MCAS.

For a potentially more scenic route, fly east toward Molokai, and stay to the north (left) of the island. The northern part of Molokai features huge sea cliffs and a tiny airstrip on the Kalaupapa peninsula - the peninsula being the only respite from the cliffs. A former leper colony existed near the airstrip!

Also of interest are the volcanoes on Maui and the 'Big Island' of Hawai'i - flying VFR in a small plane from PHTO to PHKO over the plateau between Mauna Kea and Mauna Loa can be a challenge, as you have to take off from sea level, fly through a pass of 6500 feet, and then drop back down to sea level to land! The Hana coast of northern Maui is also a nice flight - a circumnavigation of Haleakala, starting and ending at PHOG, is quite a nice flight.

The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.

== Aircraft reviews ==

== Wiki updates ==
===Creating realistic textures for buildings===
Texture and modelling artist karla, who recently [[#KSFO Terminal 2|remodeled terminal 2 of KSFO]], wrote a nice article on how to create (photo) realistic textures for buildings. The article explains the texturing process from start to end. Several techniques for creating light-effects, non-repeating surfaces and making faces look weathered are discussed and explained step by step.

Read the howto at [[Howto: Texture a building‎‎]] and provide the FlightGear community with some nice scenery additions!

===Creating cumulus cloud textures for the weather system ===
WooT has provided a short tutorial on extracting cumulus cloud textures from images. This will be useful for providing improved textures for the local weather system. Read the howto at [[Howto:Cumulus cloud texture extraction]].

===Running FlightGear on less modern hardware ===
A number of recent forum discussions were about running FlightGear on older hardware, we have now created a new article that focuses on just that: [[Howto: Build a cheap FlightGear box]].

== Community news ==
=== FlightGear on youtube ===
* Ten students at NASA's LARSS (Langley Aerospace Research Summer Scholars), put together [http://www.youtube.com/watch?v=YmnFP-1UlSY an autonomous robotics lab], using mostly open source tools. One of which is a FlightGear Multiplayer Server.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

=== Forum news ===

Thanks to Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45

=== Multiplayer ===
=== Virtual airlines ===

== Useful links ==
== And finally ... ==
Next [http://www.fsweekend.com/ FSWeekend] event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at [[Lelystad_Airport|Lelystad's airport]].

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

===Reminder: FSweekend===
With just two months togo, the largest flight simulator event in the world (the [[FSweekend]] at [[Lelystad Airport]], the Netherlands) is coming close. Make sure to mark the weekend of 6&7 November in your agenda as "occupied". A team of FlightGear developers will be present in Lelystad to promote FlightGear to the public. They highly appreciate it if you are able to stop over at the airport!

Last year we organised a [[Howto: Multiplayer|multiplayer]] event in which FlightGear users from all over the world could virtually visit Lelystad. Something similar for this year is currently being discussed. Expect more details in next month's newsletter.

=== Reminder: Google's Summer of Code 2011 ===
We would like to remind all readers that the FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].

=== Did you know ===

[[Category:FlightGear Newsletter|2010 09]]

FlightGear Newsletter September 2010

2010-09-21T03:34:23Z

Jonsberndt: Added JSBSim related content

{{newsletter}}
{{TOC_right}}
''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 projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== FlightGear events ==
== Development news ==

===Local Weather v0.85===
The [http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.85.tgz version 0.85] (also on GIT) of the Local Weather package is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.

The increased performance means that 3d clouds on fast systems can be rendered out to 45 km, and high altitude 2d cloud sheets sometimes up to 80 km - vastly improving the visual impression of the sky from airliner altitudes.

In addition, some bugs in the wind modelling and long-range weather patterns have been ironed out - with Flightgear 2.0.0, the package performs good in tests.

In the works:
* better hard-coded support for e.g. terrain sampling
* a METAR interface to use real-time weather and wind data
* full dynamics of the life cycle of convective clouds as they drift over the terrain
* and as always - improvements to cloud placement algorithms and cloud textures

Stay tuned!

A small feature gallery:
<gallery>
Image:local_weather_0.85_01.jpg| Cumulus and Cirrocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_02.jpg| Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)
Image:local_weather_0.85_03.jpg| 45 km cloud visibility range (Local Weather v0.85)
Image:local_weather_0.85_04.jpg| Realistic cloud bottoms (Local Weather v0.85)
Image:local_weather_0.85_05.jpg| Cumulus and Altocumulus clouds (Local Weather v0.85)
Image:local_weather_0.85_06.jpg| Multiple 3d layered clouds (Local Weather v0.85)
</gallery>

[[File:new_weather_dialog.png|thumb|200px|The new weather dialog]]
=== Weather supporting core code ===
The weather supporting core of FlightGear [http://gitorious.org/fg/flightgear/commit/5c6fe952598053fa63631fc0161d666f22a50f51 has been modified] during the last weeks to better support new weather models like the above mentioned Local Weather system. Data flow between environment systems is now defined in XML config files using well [[Autopilot Configuration Reference|known syntax and elements from the autopilot]]. Complex rules using predefined filters and arbitrary expressions can be defined without the need for C++ or Nasal coding.
Along with this patch comes a unified weather settings dialog, combining previous dialogs for weather conditions, scenario, clouds and precipitation. Further plans are to integrate a new real world data source [http://www.navlost.eu/nwxs/doc/desc/ NWX], providing METAR, aloft and temperature at altitude.

=== Download & Compile script ===
For the Debian/Ubuntu users, an improvement to the [[Scripted Compilation on Linux Debian/Ubuntu|download and compile]]. If svn/git compilation fails from lates revisions (generally caused by sources among different softwares not in sync) you can still compile and obtain the lates known compiling version using the -s switch.

Beware that this feature is under testing, but should work fine.

[[File:AIWingmenandAITanker.jpg|thumb|200px|AIWingmen and AITanker]]
=== AI Objects ===
Some of the AI code has been revisited and tidied up, in a somewhat vain attempt to reduce the impact on frame rate. The facilities in Slaved Ballistic Objects, Wingmen, Ground Vehicles, and Escorts have been generalized. Now, any of these types can be subordinated, or parented, on any AI object which has a <name> tag. Thus, a wingman can be formated on a an AI Tanker, and can have a slaved droptank.

A Wingman can be formated on a Wingman to build larger formations, of which an example is shown by [http://www.youtube.com/v/YaBghBIZZWI this video].

With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.

[[File:Water shader Ju 52.jpg|thumb|270px|[[Junkers Ju 52]] flying over a lake in the French custom scenery.]]
===Water shader improvements===
Our all-time favourite shader-artist, Gral, picked up yet another project. This time it is something that covers over 70% of the entire scenery and is thus of great importance in a flight simulator: water. The new shader includes more realistic wave movements and much nicer sun "reflections". The extreme goal is to have real-time reflective water, which is still a long way to go, but with Gral's latest improvements we've at least made a step into the right direction. Transatlantic or Carribean flights have never been so exiting in FlightGear!

=== FlightGear, JSBSim, and SciCos/SciLab ===
James Goppert (an Aero Engineering graduate student at Purdue) has been doing some fascinating work using JSBSim integrated with SciCos, along with having added some new trimming algorithms and code to JSBSim. The [http://www.purduehsl.dynalias.com/index.php?page=unmanned-vehicles Purdue Flight Dynamics and Control / Hybrid Systems Lab web page] features an interesting demo video. You can also see the [http://www.youtube.com/user/jgoppert?feature=mhum#p/u/6/-B0nQbcyo-o video directly on YouTube].

And here’s another video from James, [http://www.youtube.com/watch?v=mHN-Vb9l0v8 ArduPilotMega Hardware in the Loop with SciCos/SciLab].

=== New MIL-STD Turbulence Model for JSBSim ===

Andreas Gaeb has added to JSBSim an initial release of the turbulence models from [http://cafefoundation.org/v2/pdf_tech/Flying.Qualities/PAV.FlyQual.Mil1797A.pdf MILSTD-1797A] and [http://jagger.berkeley.edu/~pack/certify/sharedpapers/8785c.pdf MIL-F-8785C] as described in [http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980028448_1998081596.pdf NAsA Contractor Report NASA CR-1998-206937].
Both the MILSTD and the Tustin transform versions are included.

To do a quick test, set the following properties:
*atmosphere/turb-type=4
*atmosphere/turbulence/milspec/windspeed_at_20ft_AGL-fps=50
*atmosphere/turbulence/milspec/severity=4
which should give moderate turbulence conditions. Further options can be found in the documentation in the header file (FGAtmosphere.h) in the JSBSim source code distribution.

In early tests of the code, both turbulence versions were seen to give reasonable results for large aircraft. For RC model size aircraft, the MIL-STD version is reasonable as well, while the Tustin version tends to diverge.

=== JSBSim, and Matlab ===

Brian Mills and Agostino De Marco have been working at preparing a new release of a Matlab SFunction that wraps JSBSim.

Where the project is now:
*New release ready to compile and test for 32-bit Windows.
*Some bugs have been fixed (with a couple more to squash).
*Finally have some user documentation.
*The GUI and trim feature are now nicely integrated and the user experience is much better.
*The GUI is now tabbed/multi-paned and much more powerful.
*The project size is pared down considerably and the file duplication is gone.
*The Visual Studio project files have been fixed for better portability.

Where the project is going:
*[http://www.simauthor.com/flightviz.html FlightViz visualization tool] is currently in work.
*Environmental parameters (winds, wind-shear etc) controlled by the GUI.
*Data plotting and initial trimmed control inputs prediction.
*Closed-loop PID stabilization for finding trim points.
*Improvements to trim function.
*Flight profile scripting controllable from the GUI.
*Linux compiled version.
*Improve the documentation.
*Author a white paper.

This gives an overall picture of the current and future scope of the project. The JSBSim SFunction should become a very useful tool for flight model development and research. Agostino is also working an a MEX file (Matlab Executable) that wraps JSBSim.

==Nasal syntax highlighting file for Notepad++ users ==

Forum member c.harms has created a syntax highlighting file for Notepad++ users, please check out http://flightgear.org/forums/viewtopic.php?f=30&t=9260&p=95391#p92127 to download the file and for installation instructions.

== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).

These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.

In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.

This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.

For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);

That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.

This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.

Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.

So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).

Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".

Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".

Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.

For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.

This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.

Of course, one may still use objects like conventional variables for passing and returning parameters.

== New software tools ==
== FlightGear addons and mods ==
== In the hangar ==
===BAe-146===
"Pilot Penguin" and "[[User:Nickyivyca|nickyivyca]]" have begun work on the BAe-146. Pilot Penguin will be doing mostly 3D work, and nick will be doing mostly FDM and systems work. [http://flightgear.org/forums/viewtopic.php?f=4&t=9494&start=15 See the forum thread for more info.]

===Livery hangar reaches 300===
Early September, the [http://liveries.flightgear.org/ FlightGear Livery Database] welcomed its [http://liveries.flightgear.org/liveries.php?id=301 300th livery]! It is a livery of the Polish Air Force's [[Lockheed C130]], created by Maciej Zgódka, one of the latest additions to the painters-team. In the same time, the database was upgraded with a couple of new "features":
* thumbnails of liveries pop up when you hover over a link.
* a contact page was added, to ease contacting the database maintainer.
* each livery has a "Report this livery" button, through which visitors can notify the maintainer of a broken download, incorrect or unknown author, licensing issues etc.

I would like to emphasize that lots of liveries are not yet assigned an author. Please check for yourself if there is any [http://liveries.flightgear.org/authors.php unknown-author-livery] of which you known/are the author. Lots of liveries are still in the need for a thumbnail, so those are welcome as well.

== Scenery corner ==
===Historic Nike Hercules Missile Sites===
[[File:nike missile site3.png|thumb|One of 3 Sites.]]
Jack Mermod has begun modeling Historical Nike Hercules Missile Sites. They will all be in the Bay Area. These Sites were the last stand of defense in the event of a Soviet Bombing. You can still find evidence of these sites today, and they are a important part of history. Each Site has a helipad, in hopes of attracting helicopter pilots to come and explore the sights. So far there are 3 sites that have been made and placed into flightgear, and the plan is to make 12. The sites will hopefully be available through terrasync soon, but for now you can [http://www.flightgear.org/forums/viewtopic.php?f=5&t=9521 watch this forum topic] to see updates for the sites and download them.

===UK Football Stadiums===
[[File:Emiratesstadium.jpg|thumb|Emirates Stadium in Flightgear]]
Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.

===Liverpool John Lennon Airport===
Andyramone has begun modeling Liverpool Airport (EGGP) in the UK. The terminal is completed and will be submitted to the database this month. Work has already begun on the control tower.

===KSFO Terminal 2===
[[San Francisco International Airport]]'s Terminal 2 has been fully remodelled by Karla in Blender 2.49b, using handmade textures in Gimp 2.46. New additions include: linking wings, antennae, railings, supports, ground floors interiors, ATC equipment, vigilant controller, architecture, light masts and night textures.

It has been released and is available via [[TerraSync]].

After improving the terminal, Karla wrote a howto on how to create realistic textures for buildings. More on that in the [[#Wiki updates|Wiki updates]] section of this newsletter.

===Dublin Airport===
"eag1e" (on the forum, D-ELLE callsign) is working on the buildings of [[Dublin Airport]] (EIDW). The airport seems quite well advanced, it has been submitted to the model repository and it is available for direct download at [http://www.knatterkasten.de/ knatterkasten.de].

See the [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8874 forum post] for more info.

===Innsbruck ÖAMTC helicopter base===
[[File:LOWI_oamtc_helicopter_base.jpg|thumb|Innsbruck ÖAMTC helicopter base]]
The ÖAMTC and Flugpolizei (police) Helicopter base at Innsbruck airport (LOWI) is currently under development by ot-666. Most likely it will be outfitted with moving helipads that are under development by HHS.

===Power plants===
Power plants, with their red and white striped tall stacks, are outstanding visual aids for VFR flying.

Scighera has modeled two Italian power plants in Blender :
* "'''ENEL Piombino 4x330 MW Power Plant'''", located in Piombino, right in front of the Isola d'Elba (Tuscany, Italy). It represent the standard Italian heavy fuel oil fired 330 MW unit of the early 70ies, with 220 m high stacks provided with red obstruction lights. The model includes a Fuel oil unloading pear, with a mooring tankership
* "'''a2a 1000 MW Combined Cycle Power Plant'''" located in Cassano d'Adda (Lombardy, Italy, 30 km away from Milano Linate (LIME)). The plant is provided with 3 Turbogas, 3 Heat Recovery Steam Generators feeding the pre-existing steam turbines. There is a 220 m high red & white stiped stack and a lower 80 m stack.

The models have been submitted to the models repository (Piombino is already available via [[TerraSync]]), and available for download at [http://digilander.libero.it/scighera_fg/index.html Scighera's website].

scighera is also working on the '''Poolbeg Power Plant''', on the Dublin peninsula, very close to Dublin Airport (EIDW); the plant has two outstanding 208 m high stacks ...

<gallery>
Image:ENEL-Piombino-1.jpg| ENEL Piombino 4x330 MW Power Plant
Image:Cassano.jpg| Cassano d'Adda 1000MW Power Plant
Image:PoolbegPP-01.jpg|Poolbeg Power Station (Dublin) in progress
</gallery>

[[File:VadoLigureHarbor.jpg|thumb|Vado Ligure Container Ship Terminal]]
===Harbors===
Harbors, with their huge cranes and long peers, may be as well noticeable landmarks for VFR flying. Scighera is presently working on the model of Vado Ligure Harbor, having completed the Container unloading pier.

== Video of the month ==
Inspired by an idea posted by Mogthor, redneck has turned a part of the "Getting started" manual into a series of youtube videos, please see: http://flightgear.org/forums/viewtopic.php?f=25&t=9476&p=96015#p96015

== Aircraft of the month ==

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

== Suggested flights ==
===Hawai'i===
[[Image:Maui03.jpg|thumb]]
Do you use [[TerraSync]]? If so, try a flight around Hawaii! Take off from PHNL in a light aircraft and head west until you hit Pearl Harbor; a right turn north will take you post the USS Arizona Memorial, and the Punchbowl Crater will be to your right. Or, fly east from PHNL past volcanic craters Diamond Head and Koko Head. If you follow the O'ahu coastline north from Koko Head, you can land at either old World War II airbase Bellows Field (now a wildlife reserve in real life) or at Keahole MCAS.

For a potentially more scenic route, fly east toward Molokai, and stay to the north (left) of the island. The northern part of Molokai features huge sea cliffs and a tiny airstrip on the Kalaupapa peninsula - the peninsula being the only respite from the cliffs. A former leper colony existed near the airstrip!

Also of interest are the volcanoes on Maui and the 'Big Island' of Hawai'i - flying VFR in a small plane from PHTO to PHKO over the plateau between Mauna Kea and Mauna Loa can be a challenge, as you have to take off from sea level, fly through a pass of 6500 feet, and then drop back down to sea level to land! The Hana coast of northern Maui is also a nice flight - a circumnavigation of Haleakala, starting and ending at PHOG, is quite a nice flight.

The islands will be available through the download center with the next major scenery release, but for now, fire up [[TerraSync]] and your favorite VFR aircraft and have a blast.

== Aircraft reviews ==

== Wiki updates ==
===Creating realistic textures for buildings===
Texture and modelling artist karla, who recently [[#KSFO Terminal 2|remodeled terminal 2 of KSFO]], wrote a nice article on how to create (photo) realistic textures for buildings. The article explains the texturing process from start to end. Several techniques for creating light-effects, non-repeating surfaces and making faces look weathered are discussed and explained step by step.

Read the howto at [[Howto: Texture a building‎‎]] and provide the FlightGear community with some nice scenery additions!

===Creating cumulus cloud textures for the weather system ===
WooT has provided a short tutorial on extracting cumulus cloud textures from images. This will be useful for providing improved textures for the local weather system. Read the howto at [[Howto:Cumulus cloud texture extraction]].

===Running FlightGear on less modern hardware ===
A number of recent forum discussions were about running FlightGear on older hardware, we have now created a new article that focuses on just that: [[Howto: Build a cheap FlightGear box]].

== Community news ==
=== FlightGear on youtube ===
* Ten students at NASA's LARSS (Langley Aerospace Research Summer Scholars), put together [http://www.youtube.com/watch?v=YmnFP-1UlSY an autonomous robotics lab], using mostly open source tools. One of which is a FlightGear Multiplayer Server.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

=== Forum news ===

Thanks to Gijs, we have now a new sub forum for all issues related to building FlightGear from source. Hopefully, this will make it easier for new users (and developers!) to get support for compiling FlightGear. So if you are having problems building FlightGear from source, please check out http://flightgear.org/forums/viewforum.php?f=45

=== Multiplayer ===
=== Virtual airlines ===

== Useful links ==
== And finally ... ==
Next [http://www.fsweekend.com/ FSWeekend] event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at [[Lelystad_Airport|Lelystad's airport]].

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

===Reminder: FSweekend===
With just two months togo, the largest flight simulator event in the world (the [[FSweekend]] at [[Lelystad Airport]], the Netherlands) is coming close. Make sure to mark the weekend of 6&7 November in your agenda as "occupied". A team of FlightGear developers will be present in Lelystad to promote FlightGear to the public. They highly appreciate it if you are able to stop over at the airport!

Last year we organised a [[Howto: Multiplayer|multiplayer]] event in which FlightGear users from all over the world could virtually visit Lelystad. Something similar for this year is currently being discussed. Expect more details in next month's newsletter.

=== Reminder: Google's Summer of Code 2011 ===
We would like to remind all readers that the FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].

=== Did you know ===

[[Category:FlightGear Newsletter|2010 09]]

JSBSim

2008-08-25T03:40:28Z

Jonsberndt:

{{stub}}
'''JSBSim''' is an open source [[Flight Dynamics Model]] (FDM) software library that models the flight dynamics of an aerospace vehicle. The library has been incorporated into the flight simulation packages FlightGear and OpenEaagles. It can also be called from a small standalone program to create a batch simulation tool. JSBSim has been in development and use since 1996, and has been built on all of the most popular platforms in use today including those running Linux, Macintosh, and Microsoft Windows operating systems. JSBSim is written in C++ and uses XML configuration files.

==External links==
* [http://www.jsbsim.org/ JSBSim web site]
* [http://www.jsbsim.org/JSBSimReferenceManual.pdf JSBSim Reference Manual] (in-work, PDF)
* [http://jsbsimcommander.sf.net/ JSBSim Commander] (beta)

JSBSim

2008-08-25T03:40:05Z

Jonsberndt:

{{stub}}
'''JSBSim''' is an open source [[Flight Dynamics Model]] (FDM) software library that models the flight dynamics of an aerospace vehicle. The library has been incorporated into the flight simulation packages FlightGear and OpenEaagles. It can also be called from a small standalone program to create a batch simulation tool. JSBSim has been in development and use since 1996, and has been built on all of the most popular platforms in use today including those running Linux, Macintosh, and Microsoft Windows operating systems. JSBSim is written in C++ and uses XML configuration files.

==External links==
* [http://www.jsbsim.org/ JSBSim web site]
* [http://www.jsbsim.org/JSBSimReferenceManual.pdf JSBSim Reference Manual (in-work, PDF)]
* [http://jsbsimcommander.sf.net/ JSBSim Commander] (beta)

JSBSim

2008-08-25T03:17:22Z

Jonsberndt: Revised links

{{stub}}
'''JSBSim''' is an open source [[Flight Dynamics Model]] (FDM) software library that models the flight dynamics of an aerospace vehicle. The library has been incorporated into the flight simulation packages FlightGear and OpenEaagles. It can also be called from a small standalone program to create a batch simulation tool. JSBSim has been in development and use since 1996, and has been built on all of the most popular platforms in use today including those running Linux, Macintosh, and Microsoft Windows operating systems. JSBSim is written in C++ and uses XML configuration files.

==External links==
* [http://www.jsbsim.org/ JSBSim]
* [http://www.jsbsim.org/JSBSimReferenceManual.pdf JSBSim Reference Manual (PDF)]
* [http://jsbsimcommander.sf.net/ JSBSim Commander] (beta)

Bugs

2007-04-01T03:34:24Z

Jonsberndt: /* Broken startup banner. */

== Known Bugs ==

This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.

==== Incorrect altimetry. ====

There is evidently at least one serious misconception in the
code that calculates atmospheric pressure, altimeter settings,
et cetera. This can be easily demonstrated:

Park at or near the threshold of runway 33 at Aspen (KASE).
Under standard conditions, observe that the altimeter reads
7820 feet MSL, as it should.

Use the Weather : Weather Conditions dialog popup to
look at the ground-level altimeter setting (QNH).
This is bottom row in the "Alt (inHg)" column of the popup.
Verify that it is 29.92.

Now use the dialog box to change this property. Change it
to 30.92, a one-inch difference.

Go to your altimeter instrument and enter the new altimeter
setting in the Kollsman window. Ideally, this '''should'''
cause the instrument to read the correct altitude once
again, namely 7820 feet MSL.

However, due to bugs, it is likely that you will observe
something closer to 8120. This means the airplane is 300
feet lower than the altimeter says it is.

In case it wasn't obvious, when flying around near Aspen,
being 300 feet lower than you think you are can be very
bad for your health.

The absolutely correct formulas for computing the altimeter
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

A patch to fix the altimeter has been offered.

==== Altimetry misnomers and misconceptions. ====

Both the Weather Conditions popup and the atis.cxx code
rely on the "pressure-sea-level-inhg" property and use
it in ways that the altimeter setting should be used.

For some people this may be merely a misnomer, but for
others it is clearly a misconception, as recent events
have shown.

The fact is, the altimeter setting is '''not''' the same
thing as the pressure at sea level (Psl), especially when
the airmass has a non-standard temperature profile.
The altimeter setting is something
else; it is properly called the altimeter setting. It
is also properly called the QNH, although private pilots
who fly only in the US may be unfamiliar with the QNH
terminology.

In the Remarks section of a METAR, you can sometimes
find the ''Reduced'' Sea Level Pressure, which is
unfortunately denoted SLP. This METAR SLP serves
the same function as the altimeter setting. Despite
its name, the METAR SLP is not equal to the honest-to-goodness
pressure at honest-to-goodness sea level (Psl), as
discussed in more detail on
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

There needs to be a facility whereby routines that need
the altimeter setting can obtain the altimeter setting.

Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

Existing code sometimes treads the "pressure-sea-level-inhg"
property as if it were Psl, and sometimes as if it were
METAR SLP. All this needs to be vetted.

==== Newton's laws violated by environment.cxx ====

Consider the following results of an experiment using fgfs:

alt: 662 mM: 0.0288 P: 99000.8462 T: 286.8563 rho: 1.1975
alt: 3462 mM: 0.0288 P: 89341.6721 T: 281.3920 rho: 1.1009

alt: 662 mM: 0.0289 P: 99000.8422 T: 256.9910 rho: 1.3404
alt: 3462 mM: 0.0289 P: 89341.6740 T: 252.0956 rho: 1.2333

The first pair of lines represent before and after a simple
flight from one airport to another, with a net gain in altitude of
2800 feet, under standard conditions. So far so good.

The second pair of lines represent exactly the same flight,
except that the ambient temperature was 30 degrees colder
than before. You can see that the density (rho) is greater,
in accordance with the ideal gas law.

The problem is that the delta_P is exactly the same for the two
flights. This is a problem because P is connected to the weight
of the air column. If the air is 12% denser, the laws of physics
require it to have a 12% steeper pressure gradient dP/dh ... but
alas this is not observed.

This incorrect pressure profile P(h) has many consequences affecting
engine performance, airfoil performance, altimetry, et cetera.

==== Z-buffer burn-through. ====

Sometimes distant objects can be seen through nearer objects that
are not supposed to be transparent. For example: Runway lights
sometimes burn through a solid cloud layer. Also runway lights
sometimes burn through aircraft structure. Some instruments
burn through the yoke.

It seems that so-called "2D" objects in the
background are likely to burn through "3D" objects in the
foreground. This is particularly noticeable in aircraft
that have a mixture of 2D and 3D instruments.

The ''position'' in space of the offending objects is OK, as
you can verify by shifting your PoV to get a little bit of
a side view. The obvious hypothesis is that the Z-order
is being mishandled in a Z-buffer somewhere.

==== Memory leak. ====

The simulator will gobble up about 3 gigabytes
of virtual memory overnight, while paused.
Without the
leak, the memory footprint would be less than 300 meg. The
difference between 300 meg and 3 gig is quite
significant on machines that have only 1 or 2 gig
of main memory.

A rather steady leak of 2 meg per minute is observed
during pause, no matter whether the aircraft is aloft
or parked on the ground. '''Vastly less leakage''' (two
orders of magnitude less, possibly zero) is observed
when the simulator is not paused, and the aircraft
is simply sitting on the ground with the parking
brake set.

This bug has been observed in multiple versions of fgfs,
including one compiled back in May, 2006 as well as
the most current CVS version.

This is 100% reproducible with a
ATI RV350 [Mobility Radeon 9600 M10] chipset
and the ati-fglrx driver.
The leak is observed whether or not
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.

==== Numerous bugs in ATIS feature. ====

1) The ATIS is supposed to change whenever there is a
significant change in the weather. The comments mention
this, but the code makes no attempt to implement this.

2) The code assumes that ATIS is prepared on the hour.
In practice this is virtually never the case; a new
ATIS is prepared hourly, but not on the hour. Also
this assumption is inconsistent with ATIS changes
based on the weather.

3) The code attempts to issue a station identifier, but
none is heard.

4) Multiple departures from standard phraseology.

5) The volume is too low; ATIS is not readable over engine noise.
This defeats much of the purpose of ATIS. The volume does
not respond to the /instrumentation/comm[N]/volume property.

6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.

x) Et cetera.

A patch to fix a few dozen ATIS bugs is available, but has not been
incorporated into FG CVS.

==== Problems with --altitude option. ====

When the aircraft is initialzed aloft using the
command-line --altitude=6000
option, 0.9.10 is observed to put up a blank screen
(no scenery, no panel) and to spew on the console
page after page like this:

Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..
altitude = -1.69132e-41
sea level radius = -6.54575e-42
latitude = 6.9874e-316
longitude = 6.79737e-313
OpenAL error (AL_INVALID_VALUE): set_pitch
OpenAL error (AL_INVALID_VALUE): set_volume

==== Multiple bugs in the location-in-air popup. ====

The location-in-air popup turns off the magnetos and extends
the landing gear. Some pilots and flight instructors
deem this to be undesirable behavior, especially if all
they are trying to do is relocate from one airborne position to
another.

Similarly, it strongly perturbs the throttle setting,
aileron trim, elevator trim, rudder trim,
view angles, PoV position, and who-knows-what else.
Again, people who know about airplanes consider this to
be undesirable behavior.

There is also a tendency to place the aircraft into
dangerous unusual attitudes, and other bugs too numerous
to mention.

Evidently, though, there is at least one person who likes
things the way they are. Code that would have fixed these
bugs was rejected. Neither specific nor constructive criticism
of the code was offered. For details see the flightgear-devel
mailing list archives.

==== Nearest fix. ====

Did you know that there are 8 different BRAVO intersections
in the database?

Until now there was no support in the code for this; all but
one of the entries was thrown away at the lowest level. There
is a comment in the code saying that fixing this is on the
TODO list.

As for navaids (as opposed to waypoints), the low-level code
already provides support for ambiguous IDs, but the information
is not being used very wisely by the higher layers.

Code to fix these problems was offered to the community.
So far it has been completely ignored.

==== HSI instrument failure. ====

If you use the "heading indicator" checkbox on the
"instrument failure" popup to command a failure,
it has no effect on the HSI instrument used by
many aircraft in the simulator fleet.

This is because of wrong code in hsi.xml.

Backend code to handle this correctly exists, but has
apparently never been used. It needs one small fix,
followed by recompilation. A patchset to take care
of all this was offered to the community, but has
not been incorporated.

==== Flux gate not really a flux gate. ====

In the Instrumentation director, there are three heading-related
.cxx files.
* heading_indicator.cxx : vacuum driven, with drift
* heading_indicator_dg.cxx : electrically driven, with drift
* heading_indicator_fg.cxx : electrically driven, no drift

The "fg" in "heading_indicator_fg" is documented to stand for
"flux gate", as if the heading were slaved to a flux-gate
compass ... but the code does not implement any such thing.
All it really does is initialize the indicated heading to
the correct magnetic heading value, and then implement a
no-drift policy. This is incorrect behavior, as can be
seen by flying to an area where the magnetic variation is
different from what it was at the start of the flight. A
true slaved heading indicator would gradually accommodate
the new magvar.

The correct behavior ought to be easy to implement.

==== Weird noises during initialization. ====

It is observed that sometimes while the simulator is starting
up, before things are fully operational, weird noises are
produced. For example, in the c182rg, gear-in-transit
noises are produced for several seconds before the first
display becomes visible. (According to a dump of the
relevant variables, there is no evidence that the gear is
actually in transit, and no reason why it should be.)

Code to fix this was submitted. So far it has been
ignored.

==== Weird displays during fullscreen initialization. ====

If the --enable-fullscreen command-line option is used,
the window is enlarged to full-screen size at a time
when initialization is only half-complete. From this
time until the end of initialization, the display
contains weird combinations of leftover graphic objects
and other junk.

This is observed no matter whether the splash-screen feature
is enabled or disabled.

==== Fullscreen window sometimes misplaced. ====

About 20% of the time, when the --enable-fullscreen command-line
option is used, it opens a window of the correct size, but
badly misplaced relative to the screen, such that only one half
or one quarter of the window is on-screen.

==== Navigation databases out-of-date ====

The database of navigation waypoints and fixes has an internal
date of early 2005. It is missing quite a few useful fixes.
The FAA has defined quite a few new approaches in recent years,
and has revised others.

An updated version, based on a pull of the much more
current x-plane database, was made available. So far
it has been ignored.

Similar remarks apply to the ''navaids'' database.

==== Ident from phantom DME. ====

In the real world, some VOR stations and even some localizers
have a colocated DME station ... but there are plenty that
don't.

The DME has its own Morse ident, with a distinctive higher pitch.

In the simulator, due to a bug in the code, all stations
transmit the DME Morse ident ... even stations where no
DME is present.

The code in navradio.cxx finds the nearest VOR or LOC on the
frequency, and checks to see if it is in range. It also asks
for the "nearest" DME on the frequency, but makes no attempt
to check that it is in range. To say the same thing the
other way, there is no attempt to check that the aircraft is
within the service volume of the DME. Since there is almost always
a DME /somewhere/ on the frequency, the has_dme variable will
always be set true.

For a demonstration of this bug, park at KAOO airport and
tune up the AOO VOR (which has no DME). Or park at almost
any airport and tune up the localizer (since relatively few
localizers have DME).

==== Wild accelerations at low speeds. ====

Improper inclinometer ball indications have been observed:
-- When parked, the ball was pegged to one side.
-- When taxiing at low speeds (a few knots or less) the ball
oscillated wildly back and forth.

This was observed in the c182 model and in the default c172 model.

Tracing indicates that the problem is not within the slip_skid_ball.cxx
code, but rather upstream of there, in the flight dynamics. Tracing
shows that the y-accel-fps_sec values are wildly fluctuating in
direction, and enormous in magnitude.

Additional evidence pointing to the FDM comes from the fact that
the problem is observed with JSBSim and not with larcsim (although
larcsim has other problems, such as drifting slowly sideways while
parked).

This is important from a procedures training point of view.
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi. In a real aircraft, a pilot who found the
inclinometer pegged would cancel the flight before even starting
the engine.

Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:

*velocities/vdot-fps
*velocities/a-pilot-y-ft sec2
*velocities/n-pilot-y-norm

This item needs to be revisited to see if it has been cleared up.

==== Airport lighting in poor weather. ====

The code in tileentry.cxx turns on airport lights according to
the position of the sun relative to the horizon. One consequence
is that the lights are off during the day.

In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower airports, the lights are turned on during bad weather -- including weather that
is only slightly bad -- and also turned on if requested by the pilot. For
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].

At non-towered airports, the lights are usually pilot-controlled,
via radio.

The absence of lighting during daytime in poor weather detracts
significantly from the realism, because it affects both the
legality and the practicality of performing instrument approaches
under such conditions.

==== Holes in the ground. ====

Ever since the first win32-build of FG-OSG, there are at least two huge
ground scenery holes in the the Rhine/Main/Neckar-region in Germany.
The first one gapes at
the place which was formerly known as the city of Mannheim (near the
airport EDFM, which is still there), the second one has swallowed up a
big piece of Frankfurt am Main (near EDDF) and surrounding land.

First posted to the flightgear-devel list in November, 2006.

==== Mixture versus Altitude. ====

It is observed in the default c172p and in the c182 that at
high altitude airports (e.g. KGCN or KASE), to obtain max
static RPM, it suffices to move the mixture control only a
few mm aft of the full-forward (full-rich) position.

This is unrealistic. In a real aircraft under such conditions,
it would be necessary to pull the mixture control back about
an inch to obtain max RPM.

It's hard to say whether the carburetor is underreacting to the
altitude, or overreacting to the mixture control.

==== EGT reads high. ====

It is observed in the default c172p and in the c182 that the
EGT reads toward the high end of the scale under all conditions,
including idle. This is unrealistic.

Also, the EGT reads ''off-scale'' high under high-power conditions.

==== Flags missing from instruments. ====

Some of the standard instruments lack status flags. For example,
the GS needle goes to mid-scale if there is no valid signal. That'll kill you for sure. Reportedly the hi-res instruments implement flags, but the lo-res ones don't. Many aircraft are using the lo-res instruments.

Either the aircraft should be upgraded to use instruments that
display flags, or the instruments should be upgraded to be
display flags.

==== Problems with --model-hz option. ====

Specifying the --model-hz=10 command-line option results in the
following mess:
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml
Sorry, wdot doesn't appear to be trimmable
Trim Failed
Trim Results:
Angle of Attack: 7.50 wdot: 3.21e+01 Tolerance: 1e-03 Failed
Throttle: 0.50 udot: 0.00e+00 Tolerance: 1e-03 Passed
Pitch Trim: 0.00 qdot: -5.44e-11 Tolerance: 1e-04 Passed
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
WWarning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
[many repeats]
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
altitude = 9
sea level radius = 4.62829e-268
latitude = 1.52075e-314
longitude = -0.0967923
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = nan
sea level radius = nan
latitude = nan
longitude = nan

and so forth.

* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.

==== CPU hogging. ====

The fsgs program will happily eat up >98% of the cpu cycles,
even when the simulator is paused. That seems excessive,
particularly during pause. This is on a 2GHz machine
with hardware acceleration. As a point of reference,
glxgears uses only a fraction of one percent of the cpu.

* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)

==== Misdirected diagnostic in JSBSim.cxx ====

The file JSBSim.cxx contains the following code:

if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
"FGInterface is being called without scenery below the aircraft!");
cout << "altitude = " << alt << endl;
cout << "sea level radius = " << slr << endl;
cout << "latitude = " << lat << endl;
cout << "longitude = " << lon << endl;
//return;
}

Apparently this "ought" to be a five-line diagnostic message.

In fact, the first line is directed to the SG_LOG at priority SG_WARN,
while the other four lines are directed to cout regardless of
priority. This makes both the log and the console record hard
to interpret.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim but not yet pulled into the FG version.

==== Out-of-bounds array reference in JSBSim ====

This is in the interpolation table code.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.

==== Memory leak in JSBSim ====

This is in the "message" handling code.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.

==== Glideslope service volume. ====

The code in navradio.cxx appears to assume the glideslope
service volume is the same as the localizer service
volume. This is quite unrealistic.

==== Extended service volume. ====

In some parts of the world, a goodly fraction of the
localizers have an expanded service volume (ESV),
often quite a bit larger than the standard service
volume you see in the AIM. The code in navradio.cxx
was ignoring the service volume information in the
database and wrongly assuming the default values
applied everywhere. Code to fix the range-related
part of the problem has been offered
but not yet incorporated.

==== Other service volume issues. ====

The code in navradio.cxx has no understanding of how
'''azimuth''' affects the
localizer. There is more to the story than reception range.
It is perfectly possible to be outside the LOC service volume
for reasons having to do with azimuth, not range.

Good ident will be heard, but false localizer courses will
cause serious trouble for the unwary pilot.

A patch to fix this (along with the ESV issue) has been
offered, but ignored.

There are also azimuthal issues with the /glideslope/
service volume. This has not yet been patched.

==== Menu buttons having a get-together. ====

This concerns "radio buttons" on menus, such as on the
location-in-air popup and elsewhere. By definition, it should be
impossible to have more than one radio button pushed down at a time.
However, illegal situations of this sort can be created
using a click-and-drag gesture. Aim at
a radio button, hold the mouse-button down, and drag ...
as if you wanted to drag the radio button to a new location.
This allows you to set a radio button without the others
being unset. If you persist, you can have every one of
the buttons in the pushed-down state at the same time.

Before you say, "well, don't do that then" or "garbage in,
garbage out", let me point out that it is possible for
a pilot to inadvertently make a tiny dragging gesture
when intending only a click. Also, when the desired
button is in the pushed-down state, it is easy to not
notice that other buttons are in the undesired state.

==== Altimeter setting unreadable. ====

The standard altimeter (used by the default c172p aircraft
and many others) had been using an unhappy hodgepodge of
layers. The analog Kollsman window was unusable, because
it was unlabeled, and the digital altimeter setting was
unusable, especially at altitudes near 2500 feet, partly
from being behind the needle. On a real altimeter, things
are positioned so that cannot happen.

Fixing this requires using a more suitable font, moving
the digits over, and getting rid of conflicting extraneous
markings.

A patch to implement this fix has been offered.

==== Broken startup banner. ====

On startup, the simulator prints Author: Unknown and prints a bogus Date.

The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.

==== Memory mismanagement in subsystem_mgr. ====

It is bad luck to apply "delete" to an object that was not
created with "new" ... as in line 219 of subsystem_mgr.cxx

A patch is available, but has not been incorporated.

==== Yet more memory mismanagement. ====

When FG is trying to exit, it is very likely to abort
with a message such as

*** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***

There are at least three different instances of this bug,
each producing a different traceback. Here is one such
traceback:

<code>
#0 0xb7573947 in raise () from /lib/tls/libc.so.6
#1 0xb75750c9 in abort () from /lib/tls/libc.so.6
#2 0xb75a908a in __libc_message () from /lib/tls/libc.so.6
#3 0xb75b094f in _int_free () from /lib/tls/libc.so.6
#4 0xb75b09f2 in free () from /lib/tls/libc.so.6
#5 0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6
#6 0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766
#7 0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93
#8 0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93
#9 0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6
#12 0x080919c7 in fgExit (status=0) at util.cxx:120
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224
</code>

== Missing Features and Traps for the Unwary ==

==== Version number, please. ====

It would be helpful to have an easy, documented way to ascertain the
version number. A --version option on the command line would be
nice. Maybe also a help::about menu item, for use while fgfs is
already running.

One could imagine that info about key libraries would also be
helpful.

==== Rabbits extinct. ====

In the real world, many airports have '''sequenced flashers'''
(aka the rabbit) as part of the approach-light system.

In the FlightGear world, the sequenced flashers are inoperative
everywhere. Grepping through the code suggests that no attempt
has been made to implement this.

==== No comm volume control. ====

In many aircraft including the default c172p, the comm
radios have no volume control knob. In other aircraft
including the pa24-250, there is such a knob, but it
apparently isn't clickable and apparently doesn't do
anything.

In contrast, the SenecaII exemplifies the ''desired'' behavior:
the knob rotates when clicked and
correctly controls the /instrumentation/comm[N]/volume
property. (This alas has no effect on the volume of ATIS
audio, but that must be considered an ATIS bug not a
Seneca bug.)

==== Incomplete Scenery. ====

Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ] without installing the shared models, will get you messages such as the following:

Failed to open file .../data/Models/fgfsdb/localizer.xml
Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml

You might get only a few such messages, or you might get
screenful after screenful.

So, make sure you download all scenery files that are needed for fgfs.

This obviously counts as a trap for the unwary.

- This is patently not a bug and should be moved to a "tips" section or similar. The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...

==== ASOS and AWOS are AWOL. ====

At many non-tower airports (and even some tower airports) there
is automatic weather reporting of some kind.

It ought to be straightforward to implement this, as a slight
variation on the existing ATIS feature.

==== Roundoff problems with textranslate step and scroll. ====

The textranslate animation is delightful for 3D animation
of mechanical drum-type displays as on old-fashioned
odometers and Hobbs meters.

It is not, however, a convenient way to implement digital
readouts. It works OK for integers, but the code in
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the ".1" in 122.1 MHz, particularly when the scroll-value is zero.
* One workaround is to stick to integers, e.g. integer kHz
rather than fractional MHz.
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.
* A final option (with CVS) is to use the bias tag to let the code know how to
handle round-off. Use a bias value of 1/2 your smallest step value, and
use the same bias value on all digits.

What we really need is a whole new support routine for dealing
with 3D digital displays, something at least as nice as the
support for 2D instruments.

== Fixed Bugs ==

If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).

==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====

The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.

Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)

* '''This bug has not been observed in 0.9.10.'''

==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting "Could not gen source" ====

Any further reports or stacktraces on this bug would be appreciated.
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.
Update your sound card drivers.

* '''This bug has been fixed in 0.9.8a'''

==== 0.9.7 - ? Linux - Joystick crash with correct config files ====

Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.

* ''' This bug has been fixed.'''

== See Also ==

==== Individual Aircraft ====

Bugs associated with a particular aircraft should be listed
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.

==== OpenSceneGraph ====

There is a separate page for issues related to [[OpenSceneGraph]].

Bugs

2007-04-01T03:24:45Z

Jonsberndt: /* Wild accelerations at low speeds. */

== Known Bugs ==

This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.

==== Incorrect altimetry. ====

There is evidently at least one serious misconception in the
code that calculates atmospheric pressure, altimeter settings,
et cetera. This can be easily demonstrated:

Park at or near the threshold of runway 33 at Aspen (KASE).
Under standard conditions, observe that the altimeter reads
7820 feet MSL, as it should.

Use the Weather : Weather Conditions dialog popup to
look at the ground-level altimeter setting (QNH).
This is bottom row in the "Alt (inHg)" column of the popup.
Verify that it is 29.92.

Now use the dialog box to change this property. Change it
to 30.92, a one-inch difference.

Go to your altimeter instrument and enter the new altimeter
setting in the Kollsman window. Ideally, this '''should'''
cause the instrument to read the correct altitude once
again, namely 7820 feet MSL.

However, due to bugs, it is likely that you will observe
something closer to 8120. This means the airplane is 300
feet lower than the altimeter says it is.

In case it wasn't obvious, when flying around near Aspen,
being 300 feet lower than you think you are can be very
bad for your health.

The absolutely correct formulas for computing the altimeter
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

A patch to fix the altimeter has been offered.

==== Altimetry misnomers and misconceptions. ====

Both the Weather Conditions popup and the atis.cxx code
rely on the "pressure-sea-level-inhg" property and use
it in ways that the altimeter setting should be used.

For some people this may be merely a misnomer, but for
others it is clearly a misconception, as recent events
have shown.

The fact is, the altimeter setting is '''not''' the same
thing as the pressure at sea level (Psl), especially when
the airmass has a non-standard temperature profile.
The altimeter setting is something
else; it is properly called the altimeter setting. It
is also properly called the QNH, although private pilots
who fly only in the US may be unfamiliar with the QNH
terminology.

In the Remarks section of a METAR, you can sometimes
find the ''Reduced'' Sea Level Pressure, which is
unfortunately denoted SLP. This METAR SLP serves
the same function as the altimeter setting. Despite
its name, the METAR SLP is not equal to the honest-to-goodness
pressure at honest-to-goodness sea level (Psl), as
discussed in more detail on
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

There needs to be a facility whereby routines that need
the altimeter setting can obtain the altimeter setting.

Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

Existing code sometimes treads the "pressure-sea-level-inhg"
property as if it were Psl, and sometimes as if it were
METAR SLP. All this needs to be vetted.

==== Newton's laws violated by environment.cxx ====

Consider the following results of an experiment using fgfs:

alt: 662 mM: 0.0288 P: 99000.8462 T: 286.8563 rho: 1.1975
alt: 3462 mM: 0.0288 P: 89341.6721 T: 281.3920 rho: 1.1009

alt: 662 mM: 0.0289 P: 99000.8422 T: 256.9910 rho: 1.3404
alt: 3462 mM: 0.0289 P: 89341.6740 T: 252.0956 rho: 1.2333

The first pair of lines represent before and after a simple
flight from one airport to another, with a net gain in altitude of
2800 feet, under standard conditions. So far so good.

The second pair of lines represent exactly the same flight,
except that the ambient temperature was 30 degrees colder
than before. You can see that the density (rho) is greater,
in accordance with the ideal gas law.

The problem is that the delta_P is exactly the same for the two
flights. This is a problem because P is connected to the weight
of the air column. If the air is 12% denser, the laws of physics
require it to have a 12% steeper pressure gradient dP/dh ... but
alas this is not observed.

This incorrect pressure profile P(h) has many consequences affecting
engine performance, airfoil performance, altimetry, et cetera.

==== Z-buffer burn-through. ====

Sometimes distant objects can be seen through nearer objects that
are not supposed to be transparent. For example: Runway lights
sometimes burn through a solid cloud layer. Also runway lights
sometimes burn through aircraft structure. Some instruments
burn through the yoke.

It seems that so-called "2D" objects in the
background are likely to burn through "3D" objects in the
foreground. This is particularly noticeable in aircraft
that have a mixture of 2D and 3D instruments.

The ''position'' in space of the offending objects is OK, as
you can verify by shifting your PoV to get a little bit of
a side view. The obvious hypothesis is that the Z-order
is being mishandled in a Z-buffer somewhere.

==== Memory leak. ====

The simulator will gobble up about 3 gigabytes
of virtual memory overnight, while paused.
Without the
leak, the memory footprint would be less than 300 meg. The
difference between 300 meg and 3 gig is quite
significant on machines that have only 1 or 2 gig
of main memory.

A rather steady leak of 2 meg per minute is observed
during pause, no matter whether the aircraft is aloft
or parked on the ground. '''Vastly less leakage''' (two
orders of magnitude less, possibly zero) is observed
when the simulator is not paused, and the aircraft
is simply sitting on the ground with the parking
brake set.

This bug has been observed in multiple versions of fgfs,
including one compiled back in May, 2006 as well as
the most current CVS version.

This is 100% reproducible with a
ATI RV350 [Mobility Radeon 9600 M10] chipset
and the ati-fglrx driver.
The leak is observed whether or not
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.

==== Numerous bugs in ATIS feature. ====

1) The ATIS is supposed to change whenever there is a
significant change in the weather. The comments mention
this, but the code makes no attempt to implement this.

2) The code assumes that ATIS is prepared on the hour.
In practice this is virtually never the case; a new
ATIS is prepared hourly, but not on the hour. Also
this assumption is inconsistent with ATIS changes
based on the weather.

3) The code attempts to issue a station identifier, but
none is heard.

4) Multiple departures from standard phraseology.

5) The volume is too low; ATIS is not readable over engine noise.
This defeats much of the purpose of ATIS. The volume does
not respond to the /instrumentation/comm[N]/volume property.

6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.

x) Et cetera.

A patch to fix a few dozen ATIS bugs is available, but has not been
incorporated into FG CVS.

==== Problems with --altitude option. ====

When the aircraft is initialzed aloft using the
command-line --altitude=6000
option, 0.9.10 is observed to put up a blank screen
(no scenery, no panel) and to spew on the console
page after page like this:

Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..
altitude = -1.69132e-41
sea level radius = -6.54575e-42
latitude = 6.9874e-316
longitude = 6.79737e-313
OpenAL error (AL_INVALID_VALUE): set_pitch
OpenAL error (AL_INVALID_VALUE): set_volume

==== Multiple bugs in the location-in-air popup. ====

The location-in-air popup turns off the magnetos and extends
the landing gear. Some pilots and flight instructors
deem this to be undesirable behavior, especially if all
they are trying to do is relocate from one airborne position to
another.

Similarly, it strongly perturbs the throttle setting,
aileron trim, elevator trim, rudder trim,
view angles, PoV position, and who-knows-what else.
Again, people who know about airplanes consider this to
be undesirable behavior.

There is also a tendency to place the aircraft into
dangerous unusual attitudes, and other bugs too numerous
to mention.

Evidently, though, there is at least one person who likes
things the way they are. Code that would have fixed these
bugs was rejected. Neither specific nor constructive criticism
of the code was offered. For details see the flightgear-devel
mailing list archives.

==== Nearest fix. ====

Did you know that there are 8 different BRAVO intersections
in the database?

Until now there was no support in the code for this; all but
one of the entries was thrown away at the lowest level. There
is a comment in the code saying that fixing this is on the
TODO list.

As for navaids (as opposed to waypoints), the low-level code
already provides support for ambiguous IDs, but the information
is not being used very wisely by the higher layers.

Code to fix these problems was offered to the community.
So far it has been completely ignored.

==== HSI instrument failure. ====

If you use the "heading indicator" checkbox on the
"instrument failure" popup to command a failure,
it has no effect on the HSI instrument used by
many aircraft in the simulator fleet.

This is because of wrong code in hsi.xml.

Backend code to handle this correctly exists, but has
apparently never been used. It needs one small fix,
followed by recompilation. A patchset to take care
of all this was offered to the community, but has
not been incorporated.

==== Flux gate not really a flux gate. ====

In the Instrumentation director, there are three heading-related
.cxx files.
* heading_indicator.cxx : vacuum driven, with drift
* heading_indicator_dg.cxx : electrically driven, with drift
* heading_indicator_fg.cxx : electrically driven, no drift

The "fg" in "heading_indicator_fg" is documented to stand for
"flux gate", as if the heading were slaved to a flux-gate
compass ... but the code does not implement any such thing.
All it really does is initialize the indicated heading to
the correct magnetic heading value, and then implement a
no-drift policy. This is incorrect behavior, as can be
seen by flying to an area where the magnetic variation is
different from what it was at the start of the flight. A
true slaved heading indicator would gradually accommodate
the new magvar.

The correct behavior ought to be easy to implement.

==== Weird noises during initialization. ====

It is observed that sometimes while the simulator is starting
up, before things are fully operational, weird noises are
produced. For example, in the c182rg, gear-in-transit
noises are produced for several seconds before the first
display becomes visible. (According to a dump of the
relevant variables, there is no evidence that the gear is
actually in transit, and no reason why it should be.)

Code to fix this was submitted. So far it has been
ignored.

==== Weird displays during fullscreen initialization. ====

If the --enable-fullscreen command-line option is used,
the window is enlarged to full-screen size at a time
when initialization is only half-complete. From this
time until the end of initialization, the display
contains weird combinations of leftover graphic objects
and other junk.

This is observed no matter whether the splash-screen feature
is enabled or disabled.

==== Fullscreen window sometimes misplaced. ====

About 20% of the time, when the --enable-fullscreen command-line
option is used, it opens a window of the correct size, but
badly misplaced relative to the screen, such that only one half
or one quarter of the window is on-screen.

==== Navigation databases out-of-date ====

The database of navigation waypoints and fixes has an internal
date of early 2005. It is missing quite a few useful fixes.
The FAA has defined quite a few new approaches in recent years,
and has revised others.

An updated version, based on a pull of the much more
current x-plane database, was made available. So far
it has been ignored.

Similar remarks apply to the ''navaids'' database.

==== Ident from phantom DME. ====

In the real world, some VOR stations and even some localizers
have a colocated DME station ... but there are plenty that
don't.

The DME has its own Morse ident, with a distinctive higher pitch.

In the simulator, due to a bug in the code, all stations
transmit the DME Morse ident ... even stations where no
DME is present.

The code in navradio.cxx finds the nearest VOR or LOC on the
frequency, and checks to see if it is in range. It also asks
for the "nearest" DME on the frequency, but makes no attempt
to check that it is in range. To say the same thing the
other way, there is no attempt to check that the aircraft is
within the service volume of the DME. Since there is almost always
a DME /somewhere/ on the frequency, the has_dme variable will
always be set true.

For a demonstration of this bug, park at KAOO airport and
tune up the AOO VOR (which has no DME). Or park at almost
any airport and tune up the localizer (since relatively few
localizers have DME).

==== Wild accelerations at low speeds. ====

Improper inclinometer ball indications have been observed:
-- When parked, the ball was pegged to one side.
-- When taxiing at low speeds (a few knots or less) the ball
oscillated wildly back and forth.

This was observed in the c182 model and in the default c172 model.

Tracing indicates that the problem is not within the slip_skid_ball.cxx
code, but rather upstream of there, in the flight dynamics. Tracing
shows that the y-accel-fps_sec values are wildly fluctuating in
direction, and enormous in magnitude.

Additional evidence pointing to the FDM comes from the fact that
the problem is observed with JSBSim and not with larcsim (although
larcsim has other problems, such as drifting slowly sideways while
parked).

This is important from a procedures training point of view.
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi. In a real aircraft, a pilot who found the
inclinometer pegged would cancel the flight before even starting
the engine.

Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:

*velocities/vdot-fps
*velocities/a-pilot-y-ft sec2
*velocities/n-pilot-y-norm

This item needs to be revisited to see if it has been cleared up.

==== Airport lighting in poor weather. ====

The code in tileentry.cxx turns on airport lights according to
the position of the sun relative to the horizon. One consequence
is that the lights are off during the day.

In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower airports, the lights are turned on during bad weather -- including weather that
is only slightly bad -- and also turned on if requested by the pilot. For
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].

At non-towered airports, the lights are usually pilot-controlled,
via radio.

The absence of lighting during daytime in poor weather detracts
significantly from the realism, because it affects both the
legality and the practicality of performing instrument approaches
under such conditions.

==== Holes in the ground. ====

Ever since the first win32-build of FG-OSG, there are at least two huge
ground scenery holes in the the Rhine/Main/Neckar-region in Germany.
The first one gapes at
the place which was formerly known as the city of Mannheim (near the
airport EDFM, which is still there), the second one has swallowed up a
big piece of Frankfurt am Main (near EDDF) and surrounding land.

First posted to the flightgear-devel list in November, 2006.

==== Mixture versus Altitude. ====

It is observed in the default c172p and in the c182 that at
high altitude airports (e.g. KGCN or KASE), to obtain max
static RPM, it suffices to move the mixture control only a
few mm aft of the full-forward (full-rich) position.

This is unrealistic. In a real aircraft under such conditions,
it would be necessary to pull the mixture control back about
an inch to obtain max RPM.

It's hard to say whether the carburetor is underreacting to the
altitude, or overreacting to the mixture control.

==== EGT reads high. ====

It is observed in the default c172p and in the c182 that the
EGT reads toward the high end of the scale under all conditions,
including idle. This is unrealistic.

Also, the EGT reads ''off-scale'' high under high-power conditions.

==== Flags missing from instruments. ====

Some of the standard instruments lack status flags. For example,
the GS needle goes to mid-scale if there is no valid signal. That'll kill you for sure. Reportedly the hi-res instruments implement flags, but the lo-res ones don't. Many aircraft are using the lo-res instruments.

Either the aircraft should be upgraded to use instruments that
display flags, or the instruments should be upgraded to be
display flags.

==== Problems with --model-hz option. ====

Specifying the --model-hz=10 command-line option results in the
following mess:
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml
Sorry, wdot doesn't appear to be trimmable
Trim Failed
Trim Results:
Angle of Attack: 7.50 wdot: 3.21e+01 Tolerance: 1e-03 Failed
Throttle: 0.50 udot: 0.00e+00 Tolerance: 1e-03 Passed
Pitch Trim: 0.00 qdot: -5.44e-11 Tolerance: 1e-04 Passed
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
WWarning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
[many repeats]
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
altitude = 9
sea level radius = 4.62829e-268
latitude = 1.52075e-314
longitude = -0.0967923
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = nan
sea level radius = nan
latitude = nan
longitude = nan

and so forth.

* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.

==== CPU hogging. ====

The fsgs program will happily eat up >98% of the cpu cycles,
even when the simulator is paused. That seems excessive,
particularly during pause. This is on a 2GHz machine
with hardware acceleration. As a point of reference,
glxgears uses only a fraction of one percent of the cpu.

* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)

==== Misdirected diagnostic in JSBSim.cxx ====

The file JSBSim.cxx contains the following code:

if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
"FGInterface is being called without scenery below the aircraft!");
cout << "altitude = " << alt << endl;
cout << "sea level radius = " << slr << endl;
cout << "latitude = " << lat << endl;
cout << "longitude = " << lon << endl;
//return;
}

Apparently this "ought" to be a five-line diagnostic message.

In fact, the first line is directed to the SG_LOG at priority SG_WARN,
while the other four lines are directed to cout regardless of
priority. This makes both the log and the console record hard
to interpret.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim but not yet pulled into the FG version.

==== Out-of-bounds array reference in JSBSim ====

This is in the interpolation table code.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.

==== Memory leak in JSBSim ====

This is in the "message" handling code.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.

==== Glideslope service volume. ====

The code in navradio.cxx appears to assume the glideslope
service volume is the same as the localizer service
volume. This is quite unrealistic.

==== Extended service volume. ====

In some parts of the world, a goodly fraction of the
localizers have an expanded service volume (ESV),
often quite a bit larger than the standard service
volume you see in the AIM. The code in navradio.cxx
was ignoring the service volume information in the
database and wrongly assuming the default values
applied everywhere. Code to fix the range-related
part of the problem has been offered
but not yet incorporated.

==== Other service volume issues. ====

The code in navradio.cxx has no understanding of how
'''azimuth''' affects the
localizer. There is more to the story than reception range.
It is perfectly possible to be outside the LOC service volume
for reasons having to do with azimuth, not range.

Good ident will be heard, but false localizer courses will
cause serious trouble for the unwary pilot.

A patch to fix this (along with the ESV issue) has been
offered, but ignored.

There are also azimuthal issues with the /glideslope/
service volume. This has not yet been patched.

==== Menu buttons having a get-together. ====

This concerns "radio buttons" on menus, such as on the
location-in-air popup and elsewhere. By definition, it should be
impossible to have more than one radio button pushed down at a time.
However, illegal situations of this sort can be created
using a click-and-drag gesture. Aim at
a radio button, hold the mouse-button down, and drag ...
as if you wanted to drag the radio button to a new location.
This allows you to set a radio button without the others
being unset. If you persist, you can have every one of
the buttons in the pushed-down state at the same time.

Before you say, "well, don't do that then" or "garbage in,
garbage out", let me point out that it is possible for
a pilot to inadvertently make a tiny dragging gesture
when intending only a click. Also, when the desired
button is in the pushed-down state, it is easy to not
notice that other buttons are in the undesired state.

==== Altimeter setting unreadable. ====

The standard altimeter (used by the default c172p aircraft
and many others) had been using an unhappy hodgepodge of
layers. The analog Kollsman window was unusable, because
it was unlabeled, and the digital altimeter setting was
unusable, especially at altitudes near 2500 feet, partly
from being behind the needle. On a real altimeter, things
are positioned so that cannot happen.

Fixing this requires using a more suitable font, moving
the digits over, and getting rid of conflicting extraneous
markings.

A patch to implement this fix has been offered.

==== Broken startup banner. ====

On startup, the simulator prints Author: Unknown and
prints a bogus Date, even when an author and a date
have been specified in the *-set.xml file. Apparently
the code is having trouble reading elements from
the file. This has been observed on a wide variety
of aircraft.

* It is likely that the offending printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. Whether that is a bug or not can be debated...

==== Memory mismanagement in subsystem_mgr. ====

It is bad luck to apply "delete" to an object that was not
created with "new" ... as in line 219 of subsystem_mgr.cxx

A patch is available, but has not been incorporated.

==== Yet more memory mismanagement. ====

When FG is trying to exit, it is very likely to abort
with a message such as

*** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***

There are at least three different instances of this bug,
each producing a different traceback. Here is one such
traceback:

<code>
#0 0xb7573947 in raise () from /lib/tls/libc.so.6
#1 0xb75750c9 in abort () from /lib/tls/libc.so.6
#2 0xb75a908a in __libc_message () from /lib/tls/libc.so.6
#3 0xb75b094f in _int_free () from /lib/tls/libc.so.6
#4 0xb75b09f2 in free () from /lib/tls/libc.so.6
#5 0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6
#6 0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766
#7 0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93
#8 0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93
#9 0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6
#12 0x080919c7 in fgExit (status=0) at util.cxx:120
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224
</code>

== Missing Features and Traps for the Unwary ==

==== Version number, please. ====

It would be helpful to have an easy, documented way to ascertain the
version number. A --version option on the command line would be
nice. Maybe also a help::about menu item, for use while fgfs is
already running.

One could imagine that info about key libraries would also be
helpful.

==== Rabbits extinct. ====

In the real world, many airports have '''sequenced flashers'''
(aka the rabbit) as part of the approach-light system.

In the FlightGear world, the sequenced flashers are inoperative
everywhere. Grepping through the code suggests that no attempt
has been made to implement this.

==== No comm volume control. ====

In many aircraft including the default c172p, the comm
radios have no volume control knob. In other aircraft
including the pa24-250, there is such a knob, but it
apparently isn't clickable and apparently doesn't do
anything.

In contrast, the SenecaII exemplifies the ''desired'' behavior:
the knob rotates when clicked and
correctly controls the /instrumentation/comm[N]/volume
property. (This alas has no effect on the volume of ATIS
audio, but that must be considered an ATIS bug not a
Seneca bug.)

==== Incomplete Scenery. ====

Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ] without installing the shared models, will get you messages such as the following:

Failed to open file .../data/Models/fgfsdb/localizer.xml
Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml

You might get only a few such messages, or you might get
screenful after screenful.

So, make sure you download all scenery files that are needed for fgfs.

This obviously counts as a trap for the unwary.

- This is patently not a bug and should be moved to a "tips" section or similar. The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...

==== ASOS and AWOS are AWOL. ====

At many non-tower airports (and even some tower airports) there
is automatic weather reporting of some kind.

It ought to be straightforward to implement this, as a slight
variation on the existing ATIS feature.

==== Roundoff problems with textranslate step and scroll. ====

The textranslate animation is delightful for 3D animation
of mechanical drum-type displays as on old-fashioned
odometers and Hobbs meters.

It is not, however, a convenient way to implement digital
readouts. It works OK for integers, but the code in
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the ".1" in 122.1 MHz, particularly when the scroll-value is zero.
* One workaround is to stick to integers, e.g. integer kHz
rather than fractional MHz.
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.
* A final option (with CVS) is to use the bias tag to let the code know how to
handle round-off. Use a bias value of 1/2 your smallest step value, and
use the same bias value on all digits.

What we really need is a whole new support routine for dealing
with 3D digital displays, something at least as nice as the
support for 2D instruments.

== Fixed Bugs ==

If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).

==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====

The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.

Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)

* '''This bug has not been observed in 0.9.10.'''

==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting "Could not gen source" ====

Any further reports or stacktraces on this bug would be appreciated.
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.
Update your sound card drivers.

* '''This bug has been fixed in 0.9.8a'''

==== 0.9.7 - ? Linux - Joystick crash with correct config files ====

Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.

* ''' This bug has been fixed.'''

== See Also ==

==== Individual Aircraft ====

Bugs associated with a particular aircraft should be listed
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.

==== OpenSceneGraph ====

There is a separate page for issues related to [[OpenSceneGraph]].

Bugs

2007-04-01T03:10:41Z

Jonsberndt: /* Memory leak in JSBSim */

== Known Bugs ==

This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.

==== Incorrect altimetry. ====

There is evidently at least one serious misconception in the
code that calculates atmospheric pressure, altimeter settings,
et cetera. This can be easily demonstrated:

Park at or near the threshold of runway 33 at Aspen (KASE).
Under standard conditions, observe that the altimeter reads
7820 feet MSL, as it should.

Use the Weather : Weather Conditions dialog popup to
look at the ground-level altimeter setting (QNH).
This is bottom row in the "Alt (inHg)" column of the popup.
Verify that it is 29.92.

Now use the dialog box to change this property. Change it
to 30.92, a one-inch difference.

Go to your altimeter instrument and enter the new altimeter
setting in the Kollsman window. Ideally, this '''should'''
cause the instrument to read the correct altitude once
again, namely 7820 feet MSL.

However, due to bugs, it is likely that you will observe
something closer to 8120. This means the airplane is 300
feet lower than the altimeter says it is.

In case it wasn't obvious, when flying around near Aspen,
being 300 feet lower than you think you are can be very
bad for your health.

The absolutely correct formulas for computing the altimeter
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

A patch to fix the altimeter has been offered.

==== Altimetry misnomers and misconceptions. ====

Both the Weather Conditions popup and the atis.cxx code
rely on the "pressure-sea-level-inhg" property and use
it in ways that the altimeter setting should be used.

For some people this may be merely a misnomer, but for
others it is clearly a misconception, as recent events
have shown.

The fact is, the altimeter setting is '''not''' the same
thing as the pressure at sea level (Psl), especially when
the airmass has a non-standard temperature profile.
The altimeter setting is something
else; it is properly called the altimeter setting. It
is also properly called the QNH, although private pilots
who fly only in the US may be unfamiliar with the QNH
terminology.

In the Remarks section of a METAR, you can sometimes
find the ''Reduced'' Sea Level Pressure, which is
unfortunately denoted SLP. This METAR SLP serves
the same function as the altimeter setting. Despite
its name, the METAR SLP is not equal to the honest-to-goodness
pressure at honest-to-goodness sea level (Psl), as
discussed in more detail on
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

There needs to be a facility whereby routines that need
the altimeter setting can obtain the altimeter setting.

Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

Existing code sometimes treads the "pressure-sea-level-inhg"
property as if it were Psl, and sometimes as if it were
METAR SLP. All this needs to be vetted.

==== Newton's laws violated by environment.cxx ====

Consider the following results of an experiment using fgfs:

alt: 662 mM: 0.0288 P: 99000.8462 T: 286.8563 rho: 1.1975
alt: 3462 mM: 0.0288 P: 89341.6721 T: 281.3920 rho: 1.1009

alt: 662 mM: 0.0289 P: 99000.8422 T: 256.9910 rho: 1.3404
alt: 3462 mM: 0.0289 P: 89341.6740 T: 252.0956 rho: 1.2333

The first pair of lines represent before and after a simple
flight from one airport to another, with a net gain in altitude of
2800 feet, under standard conditions. So far so good.

The second pair of lines represent exactly the same flight,
except that the ambient temperature was 30 degrees colder
than before. You can see that the density (rho) is greater,
in accordance with the ideal gas law.

The problem is that the delta_P is exactly the same for the two
flights. This is a problem because P is connected to the weight
of the air column. If the air is 12% denser, the laws of physics
require it to have a 12% steeper pressure gradient dP/dh ... but
alas this is not observed.

This incorrect pressure profile P(h) has many consequences affecting
engine performance, airfoil performance, altimetry, et cetera.

==== Z-buffer burn-through. ====

Sometimes distant objects can be seen through nearer objects that
are not supposed to be transparent. For example: Runway lights
sometimes burn through a solid cloud layer. Also runway lights
sometimes burn through aircraft structure. Some instruments
burn through the yoke.

It seems that so-called "2D" objects in the
background are likely to burn through "3D" objects in the
foreground. This is particularly noticeable in aircraft
that have a mixture of 2D and 3D instruments.

The ''position'' in space of the offending objects is OK, as
you can verify by shifting your PoV to get a little bit of
a side view. The obvious hypothesis is that the Z-order
is being mishandled in a Z-buffer somewhere.

==== Memory leak. ====

The simulator will gobble up about 3 gigabytes
of virtual memory overnight, while paused.
Without the
leak, the memory footprint would be less than 300 meg. The
difference between 300 meg and 3 gig is quite
significant on machines that have only 1 or 2 gig
of main memory.

A rather steady leak of 2 meg per minute is observed
during pause, no matter whether the aircraft is aloft
or parked on the ground. '''Vastly less leakage''' (two
orders of magnitude less, possibly zero) is observed
when the simulator is not paused, and the aircraft
is simply sitting on the ground with the parking
brake set.

This bug has been observed in multiple versions of fgfs,
including one compiled back in May, 2006 as well as
the most current CVS version.

This is 100% reproducible with a
ATI RV350 [Mobility Radeon 9600 M10] chipset
and the ati-fglrx driver.
The leak is observed whether or not
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.

==== Numerous bugs in ATIS feature. ====

1) The ATIS is supposed to change whenever there is a
significant change in the weather. The comments mention
this, but the code makes no attempt to implement this.

2) The code assumes that ATIS is prepared on the hour.
In practice this is virtually never the case; a new
ATIS is prepared hourly, but not on the hour. Also
this assumption is inconsistent with ATIS changes
based on the weather.

3) The code attempts to issue a station identifier, but
none is heard.

4) Multiple departures from standard phraseology.

5) The volume is too low; ATIS is not readable over engine noise.
This defeats much of the purpose of ATIS. The volume does
not respond to the /instrumentation/comm[N]/volume property.

6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.

x) Et cetera.

A patch to fix a few dozen ATIS bugs is available, but has not been
incorporated into FG CVS.

==== Problems with --altitude option. ====

When the aircraft is initialzed aloft using the
command-line --altitude=6000
option, 0.9.10 is observed to put up a blank screen
(no scenery, no panel) and to spew on the console
page after page like this:

Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..
altitude = -1.69132e-41
sea level radius = -6.54575e-42
latitude = 6.9874e-316
longitude = 6.79737e-313
OpenAL error (AL_INVALID_VALUE): set_pitch
OpenAL error (AL_INVALID_VALUE): set_volume

==== Multiple bugs in the location-in-air popup. ====

The location-in-air popup turns off the magnetos and extends
the landing gear. Some pilots and flight instructors
deem this to be undesirable behavior, especially if all
they are trying to do is relocate from one airborne position to
another.

Similarly, it strongly perturbs the throttle setting,
aileron trim, elevator trim, rudder trim,
view angles, PoV position, and who-knows-what else.
Again, people who know about airplanes consider this to
be undesirable behavior.

There is also a tendency to place the aircraft into
dangerous unusual attitudes, and other bugs too numerous
to mention.

Evidently, though, there is at least one person who likes
things the way they are. Code that would have fixed these
bugs was rejected. Neither specific nor constructive criticism
of the code was offered. For details see the flightgear-devel
mailing list archives.

==== Nearest fix. ====

Did you know that there are 8 different BRAVO intersections
in the database?

Until now there was no support in the code for this; all but
one of the entries was thrown away at the lowest level. There
is a comment in the code saying that fixing this is on the
TODO list.

As for navaids (as opposed to waypoints), the low-level code
already provides support for ambiguous IDs, but the information
is not being used very wisely by the higher layers.

Code to fix these problems was offered to the community.
So far it has been completely ignored.

==== HSI instrument failure. ====

If you use the "heading indicator" checkbox on the
"instrument failure" popup to command a failure,
it has no effect on the HSI instrument used by
many aircraft in the simulator fleet.

This is because of wrong code in hsi.xml.

Backend code to handle this correctly exists, but has
apparently never been used. It needs one small fix,
followed by recompilation. A patchset to take care
of all this was offered to the community, but has
not been incorporated.

==== Flux gate not really a flux gate. ====

In the Instrumentation director, there are three heading-related
.cxx files.
* heading_indicator.cxx : vacuum driven, with drift
* heading_indicator_dg.cxx : electrically driven, with drift
* heading_indicator_fg.cxx : electrically driven, no drift

The "fg" in "heading_indicator_fg" is documented to stand for
"flux gate", as if the heading were slaved to a flux-gate
compass ... but the code does not implement any such thing.
All it really does is initialize the indicated heading to
the correct magnetic heading value, and then implement a
no-drift policy. This is incorrect behavior, as can be
seen by flying to an area where the magnetic variation is
different from what it was at the start of the flight. A
true slaved heading indicator would gradually accommodate
the new magvar.

The correct behavior ought to be easy to implement.

==== Weird noises during initialization. ====

It is observed that sometimes while the simulator is starting
up, before things are fully operational, weird noises are
produced. For example, in the c182rg, gear-in-transit
noises are produced for several seconds before the first
display becomes visible. (According to a dump of the
relevant variables, there is no evidence that the gear is
actually in transit, and no reason why it should be.)

Code to fix this was submitted. So far it has been
ignored.

==== Weird displays during fullscreen initialization. ====

If the --enable-fullscreen command-line option is used,
the window is enlarged to full-screen size at a time
when initialization is only half-complete. From this
time until the end of initialization, the display
contains weird combinations of leftover graphic objects
and other junk.

This is observed no matter whether the splash-screen feature
is enabled or disabled.

==== Fullscreen window sometimes misplaced. ====

About 20% of the time, when the --enable-fullscreen command-line
option is used, it opens a window of the correct size, but
badly misplaced relative to the screen, such that only one half
or one quarter of the window is on-screen.

==== Navigation databases out-of-date ====

The database of navigation waypoints and fixes has an internal
date of early 2005. It is missing quite a few useful fixes.
The FAA has defined quite a few new approaches in recent years,
and has revised others.

An updated version, based on a pull of the much more
current x-plane database, was made available. So far
it has been ignored.

Similar remarks apply to the ''navaids'' database.

==== Ident from phantom DME. ====

In the real world, some VOR stations and even some localizers
have a colocated DME station ... but there are plenty that
don't.

The DME has its own Morse ident, with a distinctive higher pitch.

In the simulator, due to a bug in the code, all stations
transmit the DME Morse ident ... even stations where no
DME is present.

The code in navradio.cxx finds the nearest VOR or LOC on the
frequency, and checks to see if it is in range. It also asks
for the "nearest" DME on the frequency, but makes no attempt
to check that it is in range. To say the same thing the
other way, there is no attempt to check that the aircraft is
within the service volume of the DME. Since there is almost always
a DME /somewhere/ on the frequency, the has_dme variable will
always be set true.

For a demonstration of this bug, park at KAOO airport and
tune up the AOO VOR (which has no DME). Or park at almost
any airport and tune up the localizer (since relatively few
localizers have DME).

==== Wild accelerations at low speeds. ====

Improper inclinometer ball indications have been observed:
-- When parked, the ball was pegged to one side.
-- When taxiing at low speeds (a few knots or less) the ball
oscillated wildly back and forth.

This was observed in the c182 model and in the default c172 model.

Tracing indicates that the problem is not within the slip_skid_ball.cxx
code, but rather upstream of there, in the flight dynamics. Tracing
shows that the y-accel-fps_sec values are wildly fluctuating in
direction, and enormous in magnitude.

Additional evidence pointing to the FDM comes from the fact that
the problem is observed with JSBSim and not with larcsim (although
larcsim has other problems, such as drifting slowly sideways while
parked).

This is important from a procedures training point of view.
If you want to have
a realistic flight, one of the checklist items is to verify, insofar
as possible, that the instruments give correct indications during
preflight and taxi. In a real aircraft, a pilot who found the
inclinometer pegged would cancel the flight before even starting
the engine.

==== Airport lighting in poor weather. ====

The code in tileentry.cxx turns on airport lights according to
the position of the sun relative to the horizon. One consequence
is that the lights are off during the day.

In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower airports, the lights are turned on during bad weather -- including weather that
is only slightly bad -- and also turned on if requested by the pilot. For
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].

At non-towered airports, the lights are usually pilot-controlled,
via radio.

The absence of lighting during daytime in poor weather detracts
significantly from the realism, because it affects both the
legality and the practicality of performing instrument approaches
under such conditions.

==== Holes in the ground. ====

Ever since the first win32-build of FG-OSG, there are at least two huge
ground scenery holes in the the Rhine/Main/Neckar-region in Germany.
The first one gapes at
the place which was formerly known as the city of Mannheim (near the
airport EDFM, which is still there), the second one has swallowed up a
big piece of Frankfurt am Main (near EDDF) and surrounding land.

First posted to the flightgear-devel list in November, 2006.

==== Mixture versus Altitude. ====

It is observed in the default c172p and in the c182 that at
high altitude airports (e.g. KGCN or KASE), to obtain max
static RPM, it suffices to move the mixture control only a
few mm aft of the full-forward (full-rich) position.

This is unrealistic. In a real aircraft under such conditions,
it would be necessary to pull the mixture control back about
an inch to obtain max RPM.

It's hard to say whether the carburetor is underreacting to the
altitude, or overreacting to the mixture control.

==== EGT reads high. ====

It is observed in the default c172p and in the c182 that the
EGT reads toward the high end of the scale under all conditions,
including idle. This is unrealistic.

Also, the EGT reads ''off-scale'' high under high-power conditions.

==== Flags missing from instruments. ====

Some of the standard instruments lack status flags. For example,
the GS needle goes to mid-scale if there is no valid signal. That'll kill you for sure. Reportedly the hi-res instruments implement flags, but the lo-res ones don't. Many aircraft are using the lo-res instruments.

Either the aircraft should be upgraded to use instruments that
display flags, or the instruments should be upgraded to be
display flags.

==== Problems with --model-hz option. ====

Specifying the --model-hz=10 command-line option results in the
following mess:
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml
Sorry, wdot doesn't appear to be trimmable
Trim Failed
Trim Results:
Angle of Attack: 7.50 wdot: 3.21e+01 Tolerance: 1e-03 Failed
Throttle: 0.50 udot: 0.00e+00 Tolerance: 1e-03 Passed
Pitch Trim: 0.00 qdot: -5.44e-11 Tolerance: 1e-04 Passed
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
WWarning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
[many repeats]
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
altitude = 9
sea level radius = 4.62829e-268
latitude = 1.52075e-314
longitude = -0.0967923
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = nan
sea level radius = nan
latitude = nan
longitude = nan

and so forth.

* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.

==== CPU hogging. ====

The fsgs program will happily eat up >98% of the cpu cycles,
even when the simulator is paused. That seems excessive,
particularly during pause. This is on a 2GHz machine
with hardware acceleration. As a point of reference,
glxgears uses only a fraction of one percent of the cpu.

* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)

==== Misdirected diagnostic in JSBSim.cxx ====

The file JSBSim.cxx contains the following code:

if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
"FGInterface is being called without scenery below the aircraft!");
cout << "altitude = " << alt << endl;
cout << "sea level radius = " << slr << endl;
cout << "latitude = " << lat << endl;
cout << "longitude = " << lon << endl;
//return;
}

Apparently this "ought" to be a five-line diagnostic message.

In fact, the first line is directed to the SG_LOG at priority SG_WARN,
while the other four lines are directed to cout regardless of
priority. This makes both the log and the console record hard
to interpret.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim but not yet pulled into the FG version.

==== Out-of-bounds array reference in JSBSim ====

This is in the interpolation table code.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.

==== Memory leak in JSBSim ====

This is in the "message" handling code.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.

==== Glideslope service volume. ====

The code in navradio.cxx appears to assume the glideslope
service volume is the same as the localizer service
volume. This is quite unrealistic.

==== Extended service volume. ====

In some parts of the world, a goodly fraction of the
localizers have an expanded service volume (ESV),
often quite a bit larger than the standard service
volume you see in the AIM. The code in navradio.cxx
was ignoring the service volume information in the
database and wrongly assuming the default values
applied everywhere. Code to fix the range-related
part of the problem has been offered
but not yet incorporated.

==== Other service volume issues. ====

The code in navradio.cxx has no understanding of how
'''azimuth''' affects the
localizer. There is more to the story than reception range.
It is perfectly possible to be outside the LOC service volume
for reasons having to do with azimuth, not range.

Good ident will be heard, but false localizer courses will
cause serious trouble for the unwary pilot.

A patch to fix this (along with the ESV issue) has been
offered, but ignored.

There are also azimuthal issues with the /glideslope/
service volume. This has not yet been patched.

==== Menu buttons having a get-together. ====

This concerns "radio buttons" on menus, such as on the
location-in-air popup and elsewhere. By definition, it should be
impossible to have more than one radio button pushed down at a time.
However, illegal situations of this sort can be created
using a click-and-drag gesture. Aim at
a radio button, hold the mouse-button down, and drag ...
as if you wanted to drag the radio button to a new location.
This allows you to set a radio button without the others
being unset. If you persist, you can have every one of
the buttons in the pushed-down state at the same time.

Before you say, "well, don't do that then" or "garbage in,
garbage out", let me point out that it is possible for
a pilot to inadvertently make a tiny dragging gesture
when intending only a click. Also, when the desired
button is in the pushed-down state, it is easy to not
notice that other buttons are in the undesired state.

==== Altimeter setting unreadable. ====

The standard altimeter (used by the default c172p aircraft
and many others) had been using an unhappy hodgepodge of
layers. The analog Kollsman window was unusable, because
it was unlabeled, and the digital altimeter setting was
unusable, especially at altitudes near 2500 feet, partly
from being behind the needle. On a real altimeter, things
are positioned so that cannot happen.

Fixing this requires using a more suitable font, moving
the digits over, and getting rid of conflicting extraneous
markings.

A patch to implement this fix has been offered.

==== Broken startup banner. ====

On startup, the simulator prints Author: Unknown and
prints a bogus Date, even when an author and a date
have been specified in the *-set.xml file. Apparently
the code is having trouble reading elements from
the file. This has been observed on a wide variety
of aircraft.

* It is likely that the offending printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. Whether that is a bug or not can be debated...

==== Memory mismanagement in subsystem_mgr. ====

It is bad luck to apply "delete" to an object that was not
created with "new" ... as in line 219 of subsystem_mgr.cxx

A patch is available, but has not been incorporated.

==== Yet more memory mismanagement. ====

When FG is trying to exit, it is very likely to abort
with a message such as

*** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***

There are at least three different instances of this bug,
each producing a different traceback. Here is one such
traceback:

<code>
#0 0xb7573947 in raise () from /lib/tls/libc.so.6
#1 0xb75750c9 in abort () from /lib/tls/libc.so.6
#2 0xb75a908a in __libc_message () from /lib/tls/libc.so.6
#3 0xb75b094f in _int_free () from /lib/tls/libc.so.6
#4 0xb75b09f2 in free () from /lib/tls/libc.so.6
#5 0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6
#6 0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766
#7 0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93
#8 0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93
#9 0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6
#12 0x080919c7 in fgExit (status=0) at util.cxx:120
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224
</code>

== Missing Features and Traps for the Unwary ==

==== Version number, please. ====

It would be helpful to have an easy, documented way to ascertain the
version number. A --version option on the command line would be
nice. Maybe also a help::about menu item, for use while fgfs is
already running.

One could imagine that info about key libraries would also be
helpful.

==== Rabbits extinct. ====

In the real world, many airports have '''sequenced flashers'''
(aka the rabbit) as part of the approach-light system.

In the FlightGear world, the sequenced flashers are inoperative
everywhere. Grepping through the code suggests that no attempt
has been made to implement this.

==== No comm volume control. ====

In many aircraft including the default c172p, the comm
radios have no volume control knob. In other aircraft
including the pa24-250, there is such a knob, but it
apparently isn't clickable and apparently doesn't do
anything.

In contrast, the SenecaII exemplifies the ''desired'' behavior:
the knob rotates when clicked and
correctly controls the /instrumentation/comm[N]/volume
property. (This alas has no effect on the volume of ATIS
audio, but that must be considered an ATIS bug not a
Seneca bug.)

==== Incomplete Scenery. ====

Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ] without installing the shared models, will get you messages such as the following:

Failed to open file .../data/Models/fgfsdb/localizer.xml
Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml

You might get only a few such messages, or you might get
screenful after screenful.

So, make sure you download all scenery files that are needed for fgfs.

This obviously counts as a trap for the unwary.

- This is patently not a bug and should be moved to a "tips" section or similar. The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...

==== ASOS and AWOS are AWOL. ====

At many non-tower airports (and even some tower airports) there
is automatic weather reporting of some kind.

It ought to be straightforward to implement this, as a slight
variation on the existing ATIS feature.

==== Roundoff problems with textranslate step and scroll. ====

The textranslate animation is delightful for 3D animation
of mechanical drum-type displays as on old-fashioned
odometers and Hobbs meters.

It is not, however, a convenient way to implement digital
readouts. It works OK for integers, but the code in
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the ".1" in 122.1 MHz, particularly when the scroll-value is zero.
* One workaround is to stick to integers, e.g. integer kHz
rather than fractional MHz.
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.
* A final option (with CVS) is to use the bias tag to let the code know how to
handle round-off. Use a bias value of 1/2 your smallest step value, and
use the same bias value on all digits.

What we really need is a whole new support routine for dealing
with 3D digital displays, something at least as nice as the
support for 2D instruments.

== Fixed Bugs ==

If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).

==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====

The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.

Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)

* '''This bug has not been observed in 0.9.10.'''

==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting "Could not gen source" ====

Any further reports or stacktraces on this bug would be appreciated.
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.
Update your sound card drivers.

* '''This bug has been fixed in 0.9.8a'''

==== 0.9.7 - ? Linux - Joystick crash with correct config files ====

Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.

* ''' This bug has been fixed.'''

== See Also ==

==== Individual Aircraft ====

Bugs associated with a particular aircraft should be listed
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.

==== OpenSceneGraph ====

There is a separate page for issues related to [[OpenSceneGraph]].

Bugs

2007-04-01T03:10:13Z

Jonsberndt: /* Out-of-bounds array reference in JSBSim */

== Known Bugs ==

This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.

==== Incorrect altimetry. ====

There is evidently at least one serious misconception in the
code that calculates atmospheric pressure, altimeter settings,
et cetera. This can be easily demonstrated:

Park at or near the threshold of runway 33 at Aspen (KASE).
Under standard conditions, observe that the altimeter reads
7820 feet MSL, as it should.

Use the Weather : Weather Conditions dialog popup to
look at the ground-level altimeter setting (QNH).
This is bottom row in the "Alt (inHg)" column of the popup.
Verify that it is 29.92.

Now use the dialog box to change this property. Change it
to 30.92, a one-inch difference.

Go to your altimeter instrument and enter the new altimeter
setting in the Kollsman window. Ideally, this '''should'''
cause the instrument to read the correct altitude once
again, namely 7820 feet MSL.

However, due to bugs, it is likely that you will observe
something closer to 8120. This means the airplane is 300
feet lower than the altimeter says it is.

In case it wasn't obvious, when flying around near Aspen,
being 300 feet lower than you think you are can be very
bad for your health.

The absolutely correct formulas for computing the altimeter
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

A patch to fix the altimeter has been offered.

==== Altimetry misnomers and misconceptions. ====

Both the Weather Conditions popup and the atis.cxx code
rely on the "pressure-sea-level-inhg" property and use
it in ways that the altimeter setting should be used.

For some people this may be merely a misnomer, but for
others it is clearly a misconception, as recent events
have shown.

The fact is, the altimeter setting is '''not''' the same
thing as the pressure at sea level (Psl), especially when
the airmass has a non-standard temperature profile.
The altimeter setting is something
else; it is properly called the altimeter setting. It
is also properly called the QNH, although private pilots
who fly only in the US may be unfamiliar with the QNH
terminology.

In the Remarks section of a METAR, you can sometimes
find the ''Reduced'' Sea Level Pressure, which is
unfortunately denoted SLP. This METAR SLP serves
the same function as the altimeter setting. Despite
its name, the METAR SLP is not equal to the honest-to-goodness
pressure at honest-to-goodness sea level (Psl), as
discussed in more detail on
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

There needs to be a facility whereby routines that need
the altimeter setting can obtain the altimeter setting.

Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

Existing code sometimes treads the "pressure-sea-level-inhg"
property as if it were Psl, and sometimes as if it were
METAR SLP. All this needs to be vetted.

==== Newton's laws violated by environment.cxx ====

Consider the following results of an experiment using fgfs:

alt: 662 mM: 0.0288 P: 99000.8462 T: 286.8563 rho: 1.1975
alt: 3462 mM: 0.0288 P: 89341.6721 T: 281.3920 rho: 1.1009

alt: 662 mM: 0.0289 P: 99000.8422 T: 256.9910 rho: 1.3404
alt: 3462 mM: 0.0289 P: 89341.6740 T: 252.0956 rho: 1.2333

The first pair of lines represent before and after a simple
flight from one airport to another, with a net gain in altitude of
2800 feet, under standard conditions. So far so good.

The second pair of lines represent exactly the same flight,
except that the ambient temperature was 30 degrees colder
than before. You can see that the density (rho) is greater,
in accordance with the ideal gas law.

The problem is that the delta_P is exactly the same for the two
flights. This is a problem because P is connected to the weight
of the air column. If the air is 12% denser, the laws of physics
require it to have a 12% steeper pressure gradient dP/dh ... but
alas this is not observed.

This incorrect pressure profile P(h) has many consequences affecting
engine performance, airfoil performance, altimetry, et cetera.

==== Z-buffer burn-through. ====

Sometimes distant objects can be seen through nearer objects that
are not supposed to be transparent. For example: Runway lights
sometimes burn through a solid cloud layer. Also runway lights
sometimes burn through aircraft structure. Some instruments
burn through the yoke.

It seems that so-called "2D" objects in the
background are likely to burn through "3D" objects in the
foreground. This is particularly noticeable in aircraft
that have a mixture of 2D and 3D instruments.

The ''position'' in space of the offending objects is OK, as
you can verify by shifting your PoV to get a little bit of
a side view. The obvious hypothesis is that the Z-order
is being mishandled in a Z-buffer somewhere.

==== Memory leak. ====

The simulator will gobble up about 3 gigabytes
of virtual memory overnight, while paused.
Without the
leak, the memory footprint would be less than 300 meg. The
difference between 300 meg and 3 gig is quite
significant on machines that have only 1 or 2 gig
of main memory.

A rather steady leak of 2 meg per minute is observed
during pause, no matter whether the aircraft is aloft
or parked on the ground. '''Vastly less leakage''' (two
orders of magnitude less, possibly zero) is observed
when the simulator is not paused, and the aircraft
is simply sitting on the ground with the parking
brake set.

This bug has been observed in multiple versions of fgfs,
including one compiled back in May, 2006 as well as
the most current CVS version.

This is 100% reproducible with a
ATI RV350 [Mobility Radeon 9600 M10] chipset
and the ati-fglrx driver.
The leak is observed whether or not
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.

==== Numerous bugs in ATIS feature. ====

1) The ATIS is supposed to change whenever there is a
significant change in the weather. The comments mention
this, but the code makes no attempt to implement this.

2) The code assumes that ATIS is prepared on the hour.
In practice this is virtually never the case; a new
ATIS is prepared hourly, but not on the hour. Also
this assumption is inconsistent with ATIS changes
based on the weather.

3) The code attempts to issue a station identifier, but
none is heard.

4) Multiple departures from standard phraseology.

5) The volume is too low; ATIS is not readable over engine noise.
This defeats much of the purpose of ATIS. The volume does
not respond to the /instrumentation/comm[N]/volume property.

6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.

x) Et cetera.

A patch to fix a few dozen ATIS bugs is available, but has not been
incorporated into FG CVS.

==== Problems with --altitude option. ====

When the aircraft is initialzed aloft using the
command-line --altitude=6000
option, 0.9.10 is observed to put up a blank screen
(no scenery, no panel) and to spew on the console
page after page like this:

Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..
altitude = -1.69132e-41
sea level radius = -6.54575e-42
latitude = 6.9874e-316
longitude = 6.79737e-313
OpenAL error (AL_INVALID_VALUE): set_pitch
OpenAL error (AL_INVALID_VALUE): set_volume

==== Multiple bugs in the location-in-air popup. ====

The location-in-air popup turns off the magnetos and extends
the landing gear. Some pilots and flight instructors
deem this to be undesirable behavior, especially if all
they are trying to do is relocate from one airborne position to
another.

Similarly, it strongly perturbs the throttle setting,
aileron trim, elevator trim, rudder trim,
view angles, PoV position, and who-knows-what else.
Again, people who know about airplanes consider this to
be undesirable behavior.

There is also a tendency to place the aircraft into
dangerous unusual attitudes, and other bugs too numerous
to mention.

Evidently, though, there is at least one person who likes
things the way they are. Code that would have fixed these
bugs was rejected. Neither specific nor constructive criticism
of the code was offered. For details see the flightgear-devel
mailing list archives.

==== Nearest fix. ====

Did you know that there are 8 different BRAVO intersections
in the database?

Until now there was no support in the code for this; all but
one of the entries was thrown away at the lowest level. There
is a comment in the code saying that fixing this is on the
TODO list.

As for navaids (as opposed to waypoints), the low-level code
already provides support for ambiguous IDs, but the information
is not being used very wisely by the higher layers.

Code to fix these problems was offered to the community.
So far it has been completely ignored.

==== HSI instrument failure. ====

If you use the "heading indicator" checkbox on the
"instrument failure" popup to command a failure,
it has no effect on the HSI instrument used by
many aircraft in the simulator fleet.

This is because of wrong code in hsi.xml.

Backend code to handle this correctly exists, but has
apparently never been used. It needs one small fix,
followed by recompilation. A patchset to take care
of all this was offered to the community, but has
not been incorporated.

==== Flux gate not really a flux gate. ====

In the Instrumentation director, there are three heading-related
.cxx files.
* heading_indicator.cxx : vacuum driven, with drift
* heading_indicator_dg.cxx : electrically driven, with drift
* heading_indicator_fg.cxx : electrically driven, no drift

The "fg" in "heading_indicator_fg" is documented to stand for
"flux gate", as if the heading were slaved to a flux-gate
compass ... but the code does not implement any such thing.
All it really does is initialize the indicated heading to
the correct magnetic heading value, and then implement a
no-drift policy. This is incorrect behavior, as can be
seen by flying to an area where the magnetic variation is
different from what it was at the start of the flight. A
true slaved heading indicator would gradually accommodate
the new magvar.

The correct behavior ought to be easy to implement.

==== Weird noises during initialization. ====

It is observed that sometimes while the simulator is starting
up, before things are fully operational, weird noises are
produced. For example, in the c182rg, gear-in-transit
noises are produced for several seconds before the first
display becomes visible. (According to a dump of the
relevant variables, there is no evidence that the gear is
actually in transit, and no reason why it should be.)

Code to fix this was submitted. So far it has been
ignored.

==== Weird displays during fullscreen initialization. ====

If the --enable-fullscreen command-line option is used,
the window is enlarged to full-screen size at a time
when initialization is only half-complete. From this
time until the end of initialization, the display
contains weird combinations of leftover graphic objects
and other junk.

This is observed no matter whether the splash-screen feature
is enabled or disabled.

==== Fullscreen window sometimes misplaced. ====

About 20% of the time, when the --enable-fullscreen command-line
option is used, it opens a window of the correct size, but
badly misplaced relative to the screen, such that only one half
or one quarter of the window is on-screen.

==== Navigation databases out-of-date ====

The database of navigation waypoints and fixes has an internal
date of early 2005. It is missing quite a few useful fixes.
The FAA has defined quite a few new approaches in recent years,
and has revised others.

An updated version, based on a pull of the much more
current x-plane database, was made available. So far
it has been ignored.

Similar remarks apply to the ''navaids'' database.

==== Ident from phantom DME. ====

In the real world, some VOR stations and even some localizers
have a colocated DME station ... but there are plenty that
don't.

The DME has its own Morse ident, with a distinctive higher pitch.

In the simulator, due to a bug in the code, all stations
transmit the DME Morse ident ... even stations where no
DME is present.

The code in navradio.cxx finds the nearest VOR or LOC on the
frequency, and checks to see if it is in range. It also asks
for the "nearest" DME on the frequency, but makes no attempt
to check that it is in range. To say the same thing the
other way, there is no attempt to check that the aircraft is
within the service volume of the DME. Since there is almost always
a DME /somewhere/ on the frequency, the has_dme variable will
always be set true.

For a demonstration of this bug, park at KAOO airport and
tune up the AOO VOR (which has no DME). Or park at almost
any airport and tune up the localizer (since relatively few
localizers have DME).

==== Wild accelerations at low speeds. ====

Improper inclinometer ball indications have been observed:
-- When parked, the ball was pegged to one side.
-- When taxiing at low speeds (a few knots or less) the ball
oscillated wildly back and forth.

This was observed in the c182 model and in the default c172 model.

Tracing indicates that the problem is not within the slip_skid_ball.cxx
code, but rather upstream of there, in the flight dynamics. Tracing
shows that the y-accel-fps_sec values are wildly fluctuating in
direction, and enormous in magnitude.

Additional evidence pointing to the FDM comes from the fact that
the problem is observed with JSBSim and not with larcsim (although
larcsim has other problems, such as drifting slowly sideways while
parked).

This is important from a procedures training point of view.
If you want to have
a realistic flight, one of the checklist items is to verify, insofar
as possible, that the instruments give correct indications during
preflight and taxi. In a real aircraft, a pilot who found the
inclinometer pegged would cancel the flight before even starting
the engine.

==== Airport lighting in poor weather. ====

The code in tileentry.cxx turns on airport lights according to
the position of the sun relative to the horizon. One consequence
is that the lights are off during the day.

In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower airports, the lights are turned on during bad weather -- including weather that
is only slightly bad -- and also turned on if requested by the pilot. For
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].

At non-towered airports, the lights are usually pilot-controlled,
via radio.

The absence of lighting during daytime in poor weather detracts
significantly from the realism, because it affects both the
legality and the practicality of performing instrument approaches
under such conditions.

==== Holes in the ground. ====

Ever since the first win32-build of FG-OSG, there are at least two huge
ground scenery holes in the the Rhine/Main/Neckar-region in Germany.
The first one gapes at
the place which was formerly known as the city of Mannheim (near the
airport EDFM, which is still there), the second one has swallowed up a
big piece of Frankfurt am Main (near EDDF) and surrounding land.

First posted to the flightgear-devel list in November, 2006.

==== Mixture versus Altitude. ====

It is observed in the default c172p and in the c182 that at
high altitude airports (e.g. KGCN or KASE), to obtain max
static RPM, it suffices to move the mixture control only a
few mm aft of the full-forward (full-rich) position.

This is unrealistic. In a real aircraft under such conditions,
it would be necessary to pull the mixture control back about
an inch to obtain max RPM.

It's hard to say whether the carburetor is underreacting to the
altitude, or overreacting to the mixture control.

==== EGT reads high. ====

It is observed in the default c172p and in the c182 that the
EGT reads toward the high end of the scale under all conditions,
including idle. This is unrealistic.

Also, the EGT reads ''off-scale'' high under high-power conditions.

==== Flags missing from instruments. ====

Some of the standard instruments lack status flags. For example,
the GS needle goes to mid-scale if there is no valid signal. That'll kill you for sure. Reportedly the hi-res instruments implement flags, but the lo-res ones don't. Many aircraft are using the lo-res instruments.

Either the aircraft should be upgraded to use instruments that
display flags, or the instruments should be upgraded to be
display flags.

==== Problems with --model-hz option. ====

Specifying the --model-hz=10 command-line option results in the
following mess:
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml
Sorry, wdot doesn't appear to be trimmable
Trim Failed
Trim Results:
Angle of Attack: 7.50 wdot: 3.21e+01 Tolerance: 1e-03 Failed
Throttle: 0.50 udot: 0.00e+00 Tolerance: 1e-03 Passed
Pitch Trim: 0.00 qdot: -5.44e-11 Tolerance: 1e-04 Passed
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
WWarning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
[many repeats]
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
altitude = 9
sea level radius = 4.62829e-268
latitude = 1.52075e-314
longitude = -0.0967923
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = nan
sea level radius = nan
latitude = nan
longitude = nan

and so forth.

* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.

==== CPU hogging. ====

The fsgs program will happily eat up >98% of the cpu cycles,
even when the simulator is paused. That seems excessive,
particularly during pause. This is on a 2GHz machine
with hardware acceleration. As a point of reference,
glxgears uses only a fraction of one percent of the cpu.

* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)

==== Misdirected diagnostic in JSBSim.cxx ====

The file JSBSim.cxx contains the following code:

if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
"FGInterface is being called without scenery below the aircraft!");
cout << "altitude = " << alt << endl;
cout << "sea level radius = " << slr << endl;
cout << "latitude = " << lat << endl;
cout << "longitude = " << lon << endl;
//return;
}

Apparently this "ought" to be a five-line diagnostic message.

In fact, the first line is directed to the SG_LOG at priority SG_WARN,
while the other four lines are directed to cout regardless of
priority. This makes both the log and the console record hard
to interpret.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim but not yet pulled into the FG version.

==== Out-of-bounds array reference in JSBSim ====

This is in the interpolation table code.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.

==== Memory leak in JSBSim ====

This is in the "message" handling code.

This is one of many bugs that have been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim

==== Glideslope service volume. ====

The code in navradio.cxx appears to assume the glideslope
service volume is the same as the localizer service
volume. This is quite unrealistic.

==== Extended service volume. ====

In some parts of the world, a goodly fraction of the
localizers have an expanded service volume (ESV),
often quite a bit larger than the standard service
volume you see in the AIM. The code in navradio.cxx
was ignoring the service volume information in the
database and wrongly assuming the default values
applied everywhere. Code to fix the range-related
part of the problem has been offered
but not yet incorporated.

==== Other service volume issues. ====

The code in navradio.cxx has no understanding of how
'''azimuth''' affects the
localizer. There is more to the story than reception range.
It is perfectly possible to be outside the LOC service volume
for reasons having to do with azimuth, not range.

Good ident will be heard, but false localizer courses will
cause serious trouble for the unwary pilot.

A patch to fix this (along with the ESV issue) has been
offered, but ignored.

There are also azimuthal issues with the /glideslope/
service volume. This has not yet been patched.

==== Menu buttons having a get-together. ====

This concerns "radio buttons" on menus, such as on the
location-in-air popup and elsewhere. By definition, it should be
impossible to have more than one radio button pushed down at a time.
However, illegal situations of this sort can be created
using a click-and-drag gesture. Aim at
a radio button, hold the mouse-button down, and drag ...
as if you wanted to drag the radio button to a new location.
This allows you to set a radio button without the others
being unset. If you persist, you can have every one of
the buttons in the pushed-down state at the same time.

Before you say, "well, don't do that then" or "garbage in,
garbage out", let me point out that it is possible for
a pilot to inadvertently make a tiny dragging gesture
when intending only a click. Also, when the desired
button is in the pushed-down state, it is easy to not
notice that other buttons are in the undesired state.

==== Altimeter setting unreadable. ====

The standard altimeter (used by the default c172p aircraft
and many others) had been using an unhappy hodgepodge of
layers. The analog Kollsman window was unusable, because
it was unlabeled, and the digital altimeter setting was
unusable, especially at altitudes near 2500 feet, partly
from being behind the needle. On a real altimeter, things
are positioned so that cannot happen.

Fixing this requires using a more suitable font, moving
the digits over, and getting rid of conflicting extraneous
markings.

A patch to implement this fix has been offered.

==== Broken startup banner. ====

On startup, the simulator prints Author: Unknown and
prints a bogus Date, even when an author and a date
have been specified in the *-set.xml file. Apparently
the code is having trouble reading elements from
the file. This has been observed on a wide variety
of aircraft.

* It is likely that the offending printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. Whether that is a bug or not can be debated...

==== Memory mismanagement in subsystem_mgr. ====

It is bad luck to apply "delete" to an object that was not
created with "new" ... as in line 219 of subsystem_mgr.cxx

A patch is available, but has not been incorporated.

==== Yet more memory mismanagement. ====

When FG is trying to exit, it is very likely to abort
with a message such as

*** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***

There are at least three different instances of this bug,
each producing a different traceback. Here is one such
traceback:

<code>
#0 0xb7573947 in raise () from /lib/tls/libc.so.6
#1 0xb75750c9 in abort () from /lib/tls/libc.so.6
#2 0xb75a908a in __libc_message () from /lib/tls/libc.so.6
#3 0xb75b094f in _int_free () from /lib/tls/libc.so.6
#4 0xb75b09f2 in free () from /lib/tls/libc.so.6
#5 0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6
#6 0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766
#7 0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93
#8 0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93
#9 0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6
#12 0x080919c7 in fgExit (status=0) at util.cxx:120
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224
</code>

== Missing Features and Traps for the Unwary ==

==== Version number, please. ====

It would be helpful to have an easy, documented way to ascertain the
version number. A --version option on the command line would be
nice. Maybe also a help::about menu item, for use while fgfs is
already running.

One could imagine that info about key libraries would also be
helpful.

==== Rabbits extinct. ====

In the real world, many airports have '''sequenced flashers'''
(aka the rabbit) as part of the approach-light system.

In the FlightGear world, the sequenced flashers are inoperative
everywhere. Grepping through the code suggests that no attempt
has been made to implement this.

==== No comm volume control. ====

In many aircraft including the default c172p, the comm
radios have no volume control knob. In other aircraft
including the pa24-250, there is such a knob, but it
apparently isn't clickable and apparently doesn't do
anything.

In contrast, the SenecaII exemplifies the ''desired'' behavior:
the knob rotates when clicked and
correctly controls the /instrumentation/comm[N]/volume
property. (This alas has no effect on the volume of ATIS
audio, but that must be considered an ATIS bug not a
Seneca bug.)

==== Incomplete Scenery. ====

Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ] without installing the shared models, will get you messages such as the following:

Failed to open file .../data/Models/fgfsdb/localizer.xml
Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml

You might get only a few such messages, or you might get
screenful after screenful.

So, make sure you download all scenery files that are needed for fgfs.

This obviously counts as a trap for the unwary.

- This is patently not a bug and should be moved to a "tips" section or similar. The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...

==== ASOS and AWOS are AWOL. ====

At many non-tower airports (and even some tower airports) there
is automatic weather reporting of some kind.

It ought to be straightforward to implement this, as a slight
variation on the existing ATIS feature.

==== Roundoff problems with textranslate step and scroll. ====

The textranslate animation is delightful for 3D animation
of mechanical drum-type displays as on old-fashioned
odometers and Hobbs meters.

It is not, however, a convenient way to implement digital
readouts. It works OK for integers, but the code in
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the ".1" in 122.1 MHz, particularly when the scroll-value is zero.
* One workaround is to stick to integers, e.g. integer kHz
rather than fractional MHz.
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.
* A final option (with CVS) is to use the bias tag to let the code know how to
handle round-off. Use a bias value of 1/2 your smallest step value, and
use the same bias value on all digits.

What we really need is a whole new support routine for dealing
with 3D digital displays, something at least as nice as the
support for 2D instruments.

== Fixed Bugs ==

If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).

==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====

The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.

Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)

* '''This bug has not been observed in 0.9.10.'''

==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting "Could not gen source" ====

Any further reports or stacktraces on this bug would be appreciated.
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.
Update your sound card drivers.

* '''This bug has been fixed in 0.9.8a'''

==== 0.9.7 - ? Linux - Joystick crash with correct config files ====

Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.

* ''' This bug has been fixed.'''

== See Also ==

==== Individual Aircraft ====

Bugs associated with a particular aircraft should be listed
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.

==== OpenSceneGraph ====

There is a separate page for issues related to [[OpenSceneGraph]].

Bugs

2007-04-01T03:09:47Z

Jonsberndt: /* Misdirected diagnostic in JSBSim.cxx */

== Known Bugs ==

This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.

==== Incorrect altimetry. ====

There is evidently at least one serious misconception in the
code that calculates atmospheric pressure, altimeter settings,
et cetera. This can be easily demonstrated:

Park at or near the threshold of runway 33 at Aspen (KASE).
Under standard conditions, observe that the altimeter reads
7820 feet MSL, as it should.

Use the Weather : Weather Conditions dialog popup to
look at the ground-level altimeter setting (QNH).
This is bottom row in the "Alt (inHg)" column of the popup.
Verify that it is 29.92.

Now use the dialog box to change this property. Change it
to 30.92, a one-inch difference.

Go to your altimeter instrument and enter the new altimeter
setting in the Kollsman window. Ideally, this '''should'''
cause the instrument to read the correct altitude once
again, namely 7820 feet MSL.

However, due to bugs, it is likely that you will observe
something closer to 8120. This means the airplane is 300
feet lower than the altimeter says it is.

In case it wasn't obvious, when flying around near Aspen,
being 300 feet lower than you think you are can be very
bad for your health.

The absolutely correct formulas for computing the altimeter
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

A patch to fix the altimeter has been offered.

==== Altimetry misnomers and misconceptions. ====

Both the Weather Conditions popup and the atis.cxx code
rely on the "pressure-sea-level-inhg" property and use
it in ways that the altimeter setting should be used.

For some people this may be merely a misnomer, but for
others it is clearly a misconception, as recent events
have shown.

The fact is, the altimeter setting is '''not''' the same
thing as the pressure at sea level (Psl), especially when
the airmass has a non-standard temperature profile.
The altimeter setting is something
else; it is properly called the altimeter setting. It
is also properly called the QNH, although private pilots
who fly only in the US may be unfamiliar with the QNH
terminology.

In the Remarks section of a METAR, you can sometimes
find the ''Reduced'' Sea Level Pressure, which is
unfortunately denoted SLP. This METAR SLP serves
the same function as the altimeter setting. Despite
its name, the METAR SLP is not equal to the honest-to-goodness
pressure at honest-to-goodness sea level (Psl), as
discussed in more detail on
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

There needs to be a facility whereby routines that need
the altimeter setting can obtain the altimeter setting.

Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

Existing code sometimes treads the "pressure-sea-level-inhg"
property as if it were Psl, and sometimes as if it were
METAR SLP. All this needs to be vetted.

==== Newton's laws violated by environment.cxx ====

Consider the following results of an experiment using fgfs:

alt: 662 mM: 0.0288 P: 99000.8462 T: 286.8563 rho: 1.1975
alt: 3462 mM: 0.0288 P: 89341.6721 T: 281.3920 rho: 1.1009

alt: 662 mM: 0.0289 P: 99000.8422 T: 256.9910 rho: 1.3404
alt: 3462 mM: 0.0289 P: 89341.6740 T: 252.0956 rho: 1.2333

The first pair of lines represent before and after a simple
flight from one airport to another, with a net gain in altitude of
2800 feet, under standard conditions. So far so good.

The second pair of lines represent exactly the same flight,
except that the ambient temperature was 30 degrees colder
than before. You can see that the density (rho) is greater,
in accordance with the ideal gas law.

The problem is that the delta_P is exactly the same for the two
flights. This is a problem because P is connected to the weight
of the air column. If the air is 12% denser, the laws of physics
require it to have a 12% steeper pressure gradient dP/dh ... but
alas this is not observed.

This incorrect pressure profile P(h) has many consequences affecting
engine performance, airfoil performance, altimetry, et cetera.

==== Z-buffer burn-through. ====

Sometimes distant objects can be seen through nearer objects that
are not supposed to be transparent. For example: Runway lights
sometimes burn through a solid cloud layer. Also runway lights
sometimes burn through aircraft structure. Some instruments
burn through the yoke.

It seems that so-called "2D" objects in the
background are likely to burn through "3D" objects in the
foreground. This is particularly noticeable in aircraft
that have a mixture of 2D and 3D instruments.

The ''position'' in space of the offending objects is OK, as
you can verify by shifting your PoV to get a little bit of
a side view. The obvious hypothesis is that the Z-order
is being mishandled in a Z-buffer somewhere.

==== Memory leak. ====

The simulator will gobble up about 3 gigabytes
of virtual memory overnight, while paused.
Without the
leak, the memory footprint would be less than 300 meg. The
difference between 300 meg and 3 gig is quite
significant on machines that have only 1 or 2 gig
of main memory.

A rather steady leak of 2 meg per minute is observed
during pause, no matter whether the aircraft is aloft
or parked on the ground. '''Vastly less leakage''' (two
orders of magnitude less, possibly zero) is observed
when the simulator is not paused, and the aircraft
is simply sitting on the ground with the parking
brake set.

This bug has been observed in multiple versions of fgfs,
including one compiled back in May, 2006 as well as
the most current CVS version.

This is 100% reproducible with a
ATI RV350 [Mobility Radeon 9600 M10] chipset
and the ati-fglrx driver.
The leak is observed whether or not
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.

==== Numerous bugs in ATIS feature. ====

1) The ATIS is supposed to change whenever there is a
significant change in the weather. The comments mention
this, but the code makes no attempt to implement this.

2) The code assumes that ATIS is prepared on the hour.
In practice this is virtually never the case; a new
ATIS is prepared hourly, but not on the hour. Also
this assumption is inconsistent with ATIS changes
based on the weather.

3) The code attempts to issue a station identifier, but
none is heard.

4) Multiple departures from standard phraseology.

5) The volume is too low; ATIS is not readable over engine noise.
This defeats much of the purpose of ATIS. The volume does
not respond to the /instrumentation/comm[N]/volume property.

6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.

x) Et cetera.

A patch to fix a few dozen ATIS bugs is available, but has not been
incorporated into FG CVS.

==== Problems with --altitude option. ====

When the aircraft is initialzed aloft using the
command-line --altitude=6000
option, 0.9.10 is observed to put up a blank screen
(no scenery, no panel) and to spew on the console
page after page like this:

Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..
altitude = -1.69132e-41
sea level radius = -6.54575e-42
latitude = 6.9874e-316
longitude = 6.79737e-313
OpenAL error (AL_INVALID_VALUE): set_pitch
OpenAL error (AL_INVALID_VALUE): set_volume

==== Multiple bugs in the location-in-air popup. ====

The location-in-air popup turns off the magnetos and extends
the landing gear. Some pilots and flight instructors
deem this to be undesirable behavior, especially if all
they are trying to do is relocate from one airborne position to
another.

Similarly, it strongly perturbs the throttle setting,
aileron trim, elevator trim, rudder trim,
view angles, PoV position, and who-knows-what else.
Again, people who know about airplanes consider this to
be undesirable behavior.

There is also a tendency to place the aircraft into
dangerous unusual attitudes, and other bugs too numerous
to mention.

Evidently, though, there is at least one person who likes
things the way they are. Code that would have fixed these
bugs was rejected. Neither specific nor constructive criticism
of the code was offered. For details see the flightgear-devel
mailing list archives.

==== Nearest fix. ====

Did you know that there are 8 different BRAVO intersections
in the database?

Until now there was no support in the code for this; all but
one of the entries was thrown away at the lowest level. There
is a comment in the code saying that fixing this is on the
TODO list.

As for navaids (as opposed to waypoints), the low-level code
already provides support for ambiguous IDs, but the information
is not being used very wisely by the higher layers.

Code to fix these problems was offered to the community.
So far it has been completely ignored.

==== HSI instrument failure. ====

If you use the "heading indicator" checkbox on the
"instrument failure" popup to command a failure,
it has no effect on the HSI instrument used by
many aircraft in the simulator fleet.

This is because of wrong code in hsi.xml.

Backend code to handle this correctly exists, but has
apparently never been used. It needs one small fix,
followed by recompilation. A patchset to take care
of all this was offered to the community, but has
not been incorporated.

==== Flux gate not really a flux gate. ====

In the Instrumentation director, there are three heading-related
.cxx files.
* heading_indicator.cxx : vacuum driven, with drift
* heading_indicator_dg.cxx : electrically driven, with drift
* heading_indicator_fg.cxx : electrically driven, no drift

The "fg" in "heading_indicator_fg" is documented to stand for
"flux gate", as if the heading were slaved to a flux-gate
compass ... but the code does not implement any such thing.
All it really does is initialize the indicated heading to
the correct magnetic heading value, and then implement a
no-drift policy. This is incorrect behavior, as can be
seen by flying to an area where the magnetic variation is
different from what it was at the start of the flight. A
true slaved heading indicator would gradually accommodate
the new magvar.

The correct behavior ought to be easy to implement.

==== Weird noises during initialization. ====

It is observed that sometimes while the simulator is starting
up, before things are fully operational, weird noises are
produced. For example, in the c182rg, gear-in-transit
noises are produced for several seconds before the first
display becomes visible. (According to a dump of the
relevant variables, there is no evidence that the gear is
actually in transit, and no reason why it should be.)

Code to fix this was submitted. So far it has been
ignored.

==== Weird displays during fullscreen initialization. ====

If the --enable-fullscreen command-line option is used,
the window is enlarged to full-screen size at a time
when initialization is only half-complete. From this
time until the end of initialization, the display
contains weird combinations of leftover graphic objects
and other junk.

This is observed no matter whether the splash-screen feature
is enabled or disabled.

==== Fullscreen window sometimes misplaced. ====

About 20% of the time, when the --enable-fullscreen command-line
option is used, it opens a window of the correct size, but
badly misplaced relative to the screen, such that only one half
or one quarter of the window is on-screen.

==== Navigation databases out-of-date ====

The database of navigation waypoints and fixes has an internal
date of early 2005. It is missing quite a few useful fixes.
The FAA has defined quite a few new approaches in recent years,
and has revised others.

An updated version, based on a pull of the much more
current x-plane database, was made available. So far
it has been ignored.

Similar remarks apply to the ''navaids'' database.

==== Ident from phantom DME. ====

In the real world, some VOR stations and even some localizers
have a colocated DME station ... but there are plenty that
don't.

The DME has its own Morse ident, with a distinctive higher pitch.

In the simulator, due to a bug in the code, all stations
transmit the DME Morse ident ... even stations where no
DME is present.

The code in navradio.cxx finds the nearest VOR or LOC on the
frequency, and checks to see if it is in range. It also asks
for the "nearest" DME on the frequency, but makes no attempt
to check that it is in range. To say the same thing the
other way, there is no attempt to check that the aircraft is
within the service volume of the DME. Since there is almost always
a DME /somewhere/ on the frequency, the has_dme variable will
always be set true.

For a demonstration of this bug, park at KAOO airport and
tune up the AOO VOR (which has no DME). Or park at almost
any airport and tune up the localizer (since relatively few
localizers have DME).

==== Wild accelerations at low speeds. ====

Improper inclinometer ball indications have been observed:
-- When parked, the ball was pegged to one side.
-- When taxiing at low speeds (a few knots or less) the ball
oscillated wildly back and forth.

This was observed in the c182 model and in the default c172 model.

Tracing indicates that the problem is not within the slip_skid_ball.cxx
code, but rather upstream of there, in the flight dynamics. Tracing
shows that the y-accel-fps_sec values are wildly fluctuating in
direction, and enormous in magnitude.

Additional evidence pointing to the FDM comes from the fact that
the problem is observed with JSBSim and not with larcsim (although
larcsim has other problems, such as drifting slowly sideways while
parked).

This is important from a procedures training point of view.
If you want to have
a realistic flight, one of the checklist items is to verify, insofar
as possible, that the instruments give correct indications during
preflight and taxi. In a real aircraft, a pilot who found the
inclinometer pegged would cancel the flight before even starting
the engine.

==== Airport lighting in poor weather. ====

The code in tileentry.cxx turns on airport lights according to
the position of the sun relative to the horizon. One consequence
is that the lights are off during the day.

In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower airports, the lights are turned on during bad weather -- including weather that
is only slightly bad -- and also turned on if requested by the pilot. For
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].

At non-towered airports, the lights are usually pilot-controlled,
via radio.

The absence of lighting during daytime in poor weather detracts
significantly from the realism, because it affects both the
legality and the practicality of performing instrument approaches
under such conditions.

==== Holes in the ground. ====

Ever since the first win32-build of FG-OSG, there are at least two huge
ground scenery holes in the the Rhine/Main/Neckar-region in Germany.
The first one gapes at
the place which was formerly known as the city of Mannheim (near the
airport EDFM, which is still there), the second one has swallowed up a
big piece of Frankfurt am Main (near EDDF) and surrounding land.

First posted to the flightgear-devel list in November, 2006.

==== Mixture versus Altitude. ====

It is observed in the default c172p and in the c182 that at
high altitude airports (e.g. KGCN or KASE), to obtain max
static RPM, it suffices to move the mixture control only a
few mm aft of the full-forward (full-rich) position.

This is unrealistic. In a real aircraft under such conditions,
it would be necessary to pull the mixture control back about
an inch to obtain max RPM.

It's hard to say whether the carburetor is underreacting to the
altitude, or overreacting to the mixture control.

==== EGT reads high. ====

It is observed in the default c172p and in the c182 that the
EGT reads toward the high end of the scale under all conditions,
including idle. This is unrealistic.

Also, the EGT reads ''off-scale'' high under high-power conditions.

==== Flags missing from instruments. ====

Some of the standard instruments lack status flags. For example,
the GS needle goes to mid-scale if there is no valid signal. That'll kill you for sure. Reportedly the hi-res instruments implement flags, but the lo-res ones don't. Many aircraft are using the lo-res instruments.

Either the aircraft should be upgraded to use instruments that
display flags, or the instruments should be upgraded to be
display flags.

==== Problems with --model-hz option. ====

Specifying the --model-hz=10 command-line option results in the
following mess:
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml
Sorry, wdot doesn't appear to be trimmable
Trim Failed
Trim Results:
Angle of Attack: 7.50 wdot: 3.21e+01 Tolerance: 1e-03 Failed
Throttle: 0.50 udot: 0.00e+00 Tolerance: 1e-03 Passed
Pitch Trim: 0.00 qdot: -5.44e-11 Tolerance: 1e-04 Passed
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
WWarning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
[many repeats]
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
altitude = 9
sea level radius = 4.62829e-268
latitude = 1.52075e-314
longitude = -0.0967923
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = nan
sea level radius = nan
latitude = nan
longitude = nan

and so forth.

* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.

==== CPU hogging. ====

The fsgs program will happily eat up >98% of the cpu cycles,
even when the simulator is paused. That seems excessive,
particularly during pause. This is on a 2GHz machine
with hardware acceleration. As a point of reference,
glxgears uses only a fraction of one percent of the cpu.

* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)

==== Misdirected diagnostic in JSBSim.cxx ====

The file JSBSim.cxx contains the following code:

if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
"FGInterface is being called without scenery below the aircraft!");
cout << "altitude = " << alt << endl;
cout << "sea level radius = " << slr << endl;
cout << "latitude = " << lat << endl;
cout << "longitude = " << lon << endl;
//return;
}

Apparently this "ought" to be a five-line diagnostic message.

In fact, the first line is directed to the SG_LOG at priority SG_WARN,
while the other four lines are directed to cout regardless of
priority. This makes both the log and the console record hard
to interpret.

This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim but not yet pulled into the FG version.

==== Out-of-bounds array reference in JSBSim ====

This is in the interpolation table code.

This is one of many bugs that have been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim

==== Memory leak in JSBSim ====

This is in the "message" handling code.

This is one of many bugs that have been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim

==== Glideslope service volume. ====

The code in navradio.cxx appears to assume the glideslope
service volume is the same as the localizer service
volume. This is quite unrealistic.

==== Extended service volume. ====

In some parts of the world, a goodly fraction of the
localizers have an expanded service volume (ESV),
often quite a bit larger than the standard service
volume you see in the AIM. The code in navradio.cxx
was ignoring the service volume information in the
database and wrongly assuming the default values
applied everywhere. Code to fix the range-related
part of the problem has been offered
but not yet incorporated.

==== Other service volume issues. ====

The code in navradio.cxx has no understanding of how
'''azimuth''' affects the
localizer. There is more to the story than reception range.
It is perfectly possible to be outside the LOC service volume
for reasons having to do with azimuth, not range.

Good ident will be heard, but false localizer courses will
cause serious trouble for the unwary pilot.

A patch to fix this (along with the ESV issue) has been
offered, but ignored.

There are also azimuthal issues with the /glideslope/
service volume. This has not yet been patched.

==== Menu buttons having a get-together. ====

This concerns "radio buttons" on menus, such as on the
location-in-air popup and elsewhere. By definition, it should be
impossible to have more than one radio button pushed down at a time.
However, illegal situations of this sort can be created
using a click-and-drag gesture. Aim at
a radio button, hold the mouse-button down, and drag ...
as if you wanted to drag the radio button to a new location.
This allows you to set a radio button without the others
being unset. If you persist, you can have every one of
the buttons in the pushed-down state at the same time.

Before you say, "well, don't do that then" or "garbage in,
garbage out", let me point out that it is possible for
a pilot to inadvertently make a tiny dragging gesture
when intending only a click. Also, when the desired
button is in the pushed-down state, it is easy to not
notice that other buttons are in the undesired state.

==== Altimeter setting unreadable. ====

The standard altimeter (used by the default c172p aircraft
and many others) had been using an unhappy hodgepodge of
layers. The analog Kollsman window was unusable, because
it was unlabeled, and the digital altimeter setting was
unusable, especially at altitudes near 2500 feet, partly
from being behind the needle. On a real altimeter, things
are positioned so that cannot happen.

Fixing this requires using a more suitable font, moving
the digits over, and getting rid of conflicting extraneous
markings.

A patch to implement this fix has been offered.

==== Broken startup banner. ====

On startup, the simulator prints Author: Unknown and
prints a bogus Date, even when an author and a date
have been specified in the *-set.xml file. Apparently
the code is having trouble reading elements from
the file. This has been observed on a wide variety
of aircraft.

* It is likely that the offending printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. Whether that is a bug or not can be debated...

==== Memory mismanagement in subsystem_mgr. ====

It is bad luck to apply "delete" to an object that was not
created with "new" ... as in line 219 of subsystem_mgr.cxx

A patch is available, but has not been incorporated.

==== Yet more memory mismanagement. ====

When FG is trying to exit, it is very likely to abort
with a message such as

*** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***

There are at least three different instances of this bug,
each producing a different traceback. Here is one such
traceback:

<code>
#0 0xb7573947 in raise () from /lib/tls/libc.so.6
#1 0xb75750c9 in abort () from /lib/tls/libc.so.6
#2 0xb75a908a in __libc_message () from /lib/tls/libc.so.6
#3 0xb75b094f in _int_free () from /lib/tls/libc.so.6
#4 0xb75b09f2 in free () from /lib/tls/libc.so.6
#5 0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6
#6 0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766
#7 0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93
#8 0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93
#9 0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6
#12 0x080919c7 in fgExit (status=0) at util.cxx:120
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224
</code>

== Missing Features and Traps for the Unwary ==

==== Version number, please. ====

It would be helpful to have an easy, documented way to ascertain the
version number. A --version option on the command line would be
nice. Maybe also a help::about menu item, for use while fgfs is
already running.

One could imagine that info about key libraries would also be
helpful.

==== Rabbits extinct. ====

In the real world, many airports have '''sequenced flashers'''
(aka the rabbit) as part of the approach-light system.

In the FlightGear world, the sequenced flashers are inoperative
everywhere. Grepping through the code suggests that no attempt
has been made to implement this.

==== No comm volume control. ====

In many aircraft including the default c172p, the comm
radios have no volume control knob. In other aircraft
including the pa24-250, there is such a knob, but it
apparently isn't clickable and apparently doesn't do
anything.

In contrast, the SenecaII exemplifies the ''desired'' behavior:
the knob rotates when clicked and
correctly controls the /instrumentation/comm[N]/volume
property. (This alas has no effect on the volume of ATIS
audio, but that must be considered an ATIS bug not a
Seneca bug.)

==== Incomplete Scenery. ====

Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ] without installing the shared models, will get you messages such as the following:

Failed to open file .../data/Models/fgfsdb/localizer.xml
Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml

You might get only a few such messages, or you might get
screenful after screenful.

So, make sure you download all scenery files that are needed for fgfs.

This obviously counts as a trap for the unwary.

- This is patently not a bug and should be moved to a "tips" section or similar. The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...

==== ASOS and AWOS are AWOL. ====

At many non-tower airports (and even some tower airports) there
is automatic weather reporting of some kind.

It ought to be straightforward to implement this, as a slight
variation on the existing ATIS feature.

==== Roundoff problems with textranslate step and scroll. ====

The textranslate animation is delightful for 3D animation
of mechanical drum-type displays as on old-fashioned
odometers and Hobbs meters.

It is not, however, a convenient way to implement digital
readouts. It works OK for integers, but the code in
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the ".1" in 122.1 MHz, particularly when the scroll-value is zero.
* One workaround is to stick to integers, e.g. integer kHz
rather than fractional MHz.
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.
* A final option (with CVS) is to use the bias tag to let the code know how to
handle round-off. Use a bias value of 1/2 your smallest step value, and
use the same bias value on all digits.

What we really need is a whole new support routine for dealing
with 3D digital displays, something at least as nice as the
support for 2D instruments.

== Fixed Bugs ==

If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).

==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====

The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.

Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)

* '''This bug has not been observed in 0.9.10.'''

==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting "Could not gen source" ====

Any further reports or stacktraces on this bug would be appreciated.
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.
Update your sound card drivers.

* '''This bug has been fixed in 0.9.8a'''

==== 0.9.7 - ? Linux - Joystick crash with correct config files ====

Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.

* ''' This bug has been fixed.'''

== See Also ==

==== Individual Aircraft ====

Bugs associated with a particular aircraft should be listed
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.

==== OpenSceneGraph ====

There is a separate page for issues related to [[OpenSceneGraph]].