FlightGear wiki - User contributions [en]

FlightGear Newsletter April 2014

2014-04-30T02:21:07Z

Noah:

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

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

=== Splitting fgdata ===
{{Conversational}}
http://sourceforge.net/p/flightgear/mailman/message/32238780/
<pre>

</pre>
=== Text-to-Speech: ATIS via FLITE ===
Torsten and James started adding FLITE support to FlightGear/next:
{{Conversational}}
<pre>thanks to James' finding of flite+hts_engine
(http://flite-hts-engine.sp.nitech.ac.jp/)
we are now again able to listen to spoken atis and probably any other
kind of spoken messages soon.
This is a complete text-to-speech system (currently only english
language) that generates wav files from plain text on the fly with
surprisingly good quality speech and small memory footprint.

I have just pushed some code that uses the flite+hts_engine to
synthesize the generated atis text for comm radios into a SGSoundSample
and feed this into our sound manager. To make use of this feature you
have to rebuild FlightGear from source and call cmake with
-DENABLE_FLITE=On. When ready, tune your comm radio to the ATIS
frequency of your airport. After a few seconds, you should hear a lady
talking about flightgear weather.

The code contains some ugly hacks and not everything is working
perfectly yet. But I'd like to get some feedback regarding performance,
sound quality and cross platform compatibility. So please give it a try.

Torsten
</pre>

=== YaSim versioning ===
{{Conversational}}

<pre>Hi all,

as promised, I have just added a versioning scheme to yasim
configuration files.
The <airplane> element of the yasim config file now understands the
"version" attribute that can be currently one of these values:

YASIM_VERSION_ORIGINAL
The original version of YASim as implemented up to FlightGear 3.0.0
(this is the default)

YASIM_VERSION_32
The version of YASim currently implemented in FlightGear 3.1 (current
git HEAD)

YASIM_VERSION_CURRENT
The current and latest version of YASim (which is currently the same as
YASIM_VERSION_32)

Example:
<airplane mass="1344" version="YASIM_VERSION_32">

A missing "version" attribute will cause yasim to use the original
(buggy) implementation without the latest patches. This should restore
the original behavior to all yasim aircraft. Aircraft that were adapted
to the new version of yasim (with the latest patches from Colin Douglas
Howell) should set version=" YASIM_VERSION_32" to re-enable those changes.

The idea is to add a new YASIM_VERSION_xx with every release cycle where
xx is the next to-be-released version number (32 for 3.2 for the current
cycle and 34 for the next cycle etc).

I hope this is somewhat useful and works as described.
Please test some yasim aircraft and provide feedback.

Greetings,
Torsten
</pre>

=== Proof-of-Concept: A TerraGear Web Service (by F-JJTH) ===
As part of prototyping a [[TerraGear scenery build server]], F-JJTH has started working on a proof-of-concept for a web-based TerraGear GUI/build service. This can use the precompiled-TerraGear packages created and provided by saiarcot895. We are currently looking for people interested in picking up this prototype to continue developing it over time. All the difficult bits are now in place (namely the TerraGear setup), as well as a compelling web-based interface. People interested in helping with this, should ideally have some web programming experience, for TerraGear specifics you can probably just get in touch with psadro_gm and papillon81 (or refer to the docs for starters). Also, we're hoping to also create Linux packages for the web interface, so that installation/updates can be just as easily handled using the deb/apt/ppa package manager.

Primarily, we are now looking for hosting, not just for the TerraGear setup itself (which should be fairly powerful), but also for those deb/apt packages. If you'd like to help with this, please get in touch via the forum.

<gallery mode=packed widths=230px heights=230px>
TerraGear_build_server_concept_map.png|Schematic of a possible setup for TG GUI or a web interface to access TerraGear services provided by a build server
TerraGear-BuildServer-Prototype.png|TerraGear BuildServer Experiments
TerraGear-hgtchop-VM.png|TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages
F-jjth-tggui-prototype.jpg|Web-based TerraGear GUI prototype developed by F-JJTH in 03/2014
</gallery>

Continue reading at [[TerraGear scenery build server]]...

=== Missions & Adventures via Tutorials ===
{{forum|79|Tutorials, Missions & Adventures}}

[[File:Missionb.png]]

{{#ev:youtube|yWEyRVGJks0}} {{#ev:youtube|LC2bk3UH8jg}} {{#ev:youtube|dU7ikBZOjgk}}

[[File:Non-player-characters 1 20140421 1863384647.png|thumb|DFaber's Walker used for adding NPC support to Stuart's tutorial system]]

Learn more at [[FlightGear Missions and Adventures]]...

=== YASim Bug Fixes ===
As of April 4th, several bug fixes by Colin Howell have been merged into the "next" branch of FlightGear's source. As per issues {{issue|1400|}}, {{issue|1423|}}, and {{issue|1427|}}, these are only small fixes in portions of code, but they still may have noticeable affects on YASim aircraft, including making the solver fail with some aircraft and making other aircraft perform better. Currently these fixes are loaded unconditionally, so there's no opt-in or opt-out system in place, meaning that we need ''you'' to help test as many YASim aircraft as possible. (Please note that these patches are only available with a latest binary, i.e. a nightly from Jenkins or a compilation from source, and a corresponding FGData clone.) Detlef posts, "I have tested the slat patch and the twist patch and found very little problems, in fact most cases I've seen saw an improvment. Of the 15 Aircraft I've tested the twist patch on, only two wouldn't start up at all" [http://forum.flightgear.org/viewtopic.php?f=49&t=22522#p204370]. Having a large number of non-working aircraft in the next release would be undesirable, and would suggest that we need an opt-in system for such fixes, but if most aircraft work well it will be simpler to let the patches load unconditionally.

Please report aircraft that fail to work with latest FG (but that still work in 3.0, i.e. without the fixes) on the devel list or on the forums.

Links to ongoing discussion at the development list:
[http://sourceforge.net/p/flightgear/mailman/message/32183541/] [http://sourceforge.net/p/flightgear/mailman/message/32185064/] [http://sourceforge.net/p/flightgear/mailman/message/32185188/] [http://sourceforge.net/p/flightgear/mailman/message/32185412/] [http://sourceforge.net/p/flightgear/mailman/message/32185690/] [http://sourceforge.net/p/flightgear/mailman/message/32185691/] [http://sourceforge.net/p/flightgear/mailman/message/32185923/]

=== How to troubleshoot FlightGear crashes ===
The recent 2 release cycles have made one thing pretty obvious: more and more end-users are faced with obscure crashes, so called "segfaults" - unfortunately, developers cannot easily reproduce those in most cases. Thus, we need our contributors to provide better diagnostics. However, the process isn't exactly straightforward for non-developers, but at least Linux-based users can typically provide all the required information even without having to be programmers themselves.

A segfault is another word for "application crash", it's a so called "segmentation fault", where the FlightGear program is doing things that it wasn't designed to do, such as accessing invalid memory for example, so that the operating system will terminate the process because its behavior is no longer valid/correct.

These segfaults will typically happen due to coding errors, either in FlightGear or one of its dependencies (libraries like SimGear, plib, OpenSceneGraph or OpenAL), and at times due to a combination of issues in several dependencies.

In order to see what was going on when the crash occurred, you'll need to build a binary with debugging symbols enabled/included, usually this includes FlightGear and SimGear - and possibly even OSG (OpenSceneGraph, normally only if your crash happens inside rendering related code).

A so called backtrace is basically pretty much like a flight data recorder tape/log that is used to conduct a post-crash analysis.

A binary with debugging symbols included will contain additional information that helps developers track down what was causing a certain crash, such as for example the file name, function, line number, variable that was accessed before the crash happened. This is analogous to how a FDR/CVR on an airplane records certain parameters like position, orientation, altitude, velocities, configuration, cockpit conversations etc. This can also be used by developers to see who is responsible for a certain segfault/bug, i.e. which commit introduced the bug.

Debugging FlightGear crashes is significantly simplified by having access to such runtime data, because we can basically go back in time and see what the FlightGear program was doing shortly before the crash.

Learn more at [[Howto:Debugging FlightGear Crashes#Debugging_Segfaults_.26_Obtaining_Backtraces|Debugging Segfaults & Obtaining Backtraces]]...
=== Under the Hood of: Nasal OOP (by Philosopher & galvedro) ===

Nasal does not have the concept of "classes", understanding by a class an object definition that cannot exist as an instance on its own. What we always have in Nasal is hashes that perhaps reference other hashes via the parents vector.

The parents vector is just a symbol lookup trick. The only thing it does is to add other hashes as targets where Nasal can search for symbols that are not defined in the current hash. This servers for implementing object inheritance in a traditional way as long as:

# The symbols that you expect to be gathering from the parented hashes are functions. This is because when you are executing a function in a parent hash, the me symbol will allow you you to resolve the context back to the instance hash down the hierarchy.
# Non function members that are expected to be kept per instance, are defined in the instance hash. Otherwise those members might end up being shared across derived hashes due to the parents lookup mechanism.
# Members that are expected to be shared across different instances are defined in the template hash and not in the instances themselves. Which means that you have to be careful on how you write values to them or you will end up creating a new member in the instance hash that will shadow the shared member. (Mmm, this one is a dangerous pitfall, but I remember seeing this explained in the wiki, and is not that often that you need this...).

The me reference is a syntactic trick, and it can be dangerous to use depending on the usage pattern, so some good practices are in order, in particular

1. When writing a constructor in a template object, do not use me in the parents vector, because me will resolve to a hash reference only when the new() method is called, and which hash will it be depends on how the method is called.

2. When calling a "super" class method from an overriding method, use the Nasal call() library function, specifying the instance hash as the me parameter. If you use the parents vector directly, me will likely end up referring to a template hash instead and you will loose the instance context.
Basically you have an expression on the left side of a dot, and then a lvalue and parenthesis on the right side -- no exceptions! The expression is evaluated once, with the value being DUP'ed (duplicated/copied) and used both for the member get (i.e. what is the function contained in the hash) and as a special argument to the function (now a method) call. That "me" is then set as a symbol like an argument, originating from the left-hand expression, and is otherwise unset.

In other cases, using the call() builtin, it is possible to specify the me reference manually, but what "me" is, is otherwise a consequence of how it is called. If the syntax differs, there is no me local variable. (One common example is passing a MEMBER of an object to a function as a parameter or saving it to a variable - i.e. then it doesn't matter if it is a function or not.) (I use MEMBER here to distinguish from METHODS, where a METHOD uses "me" and a MEMBER doesn't.)

The thing with a func {} expression is that it delays evaluation, so it can keep the proper syntax for the method call and therefore pass the correct me reference, which is preserved in its closure.

Parents inheritance is really simple: to find a member you search for it in the current hash or try finding it in each parent (indexes 0..n), throwing an error if there is too much recursion. Basically, inheritance is implemented such that there's a mutable parents vector that maintains a list of hashes that are used for recursive symbol lookups, me will be defined per instance and point to the outer hash. Which is why shadowing can occur.

'''me''' is also mutable, i.e. if it isn't defined, it can be explicitly defined, or passed via call() - a mehod which we tend to use in MapStructure whenever we want to ensure that the proper instance is passed, i.e. no variable shadowing taking place.

* FUNC() -> no me
* OBJ.METHOD() -> me = OBJ
* (OBJ.MEMBER_FUNC)() -> no me
* (EXPR).METHOD() -> me = (EXPR)

Continue reading at [[Object oriented programming in Nasal]]...

=== Orbital Rendering:Earthview ===

Earthview is an orbital rendering engine for Flightgear designed to get credible visuals when using spacecraft such as Vostok-1. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. Since there's only a single object in the field of view, performance is generally very good provided that there's enough texture memory available.

Textures are taken from the NASA Visible Earth project - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed via GIT, a mode to make the GB-sized hires textures has yet to be determined.

Combined with the ALS shader to render the atmosphere, visuals are generally rather compelling.

[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]

A long standing problem in Flightgear's atmosphere definition has now been addressed and JSBSim spacecraft should now be able to reach any orbital altitude within their capabilities (previously flight was restricted to be below 150 km altitude).

=== FlightGear/Oculus Rift Experiments ===

{{#ev:youtube|v-31tCHpKC0}}

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

=== Random Buildings ===

=== Project Rembrandt ===
A number of Mac users have been reporting issues related to running [[Project Rembrandt]] (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: [[Project Rembrandt#Mac Issues]].

=== Canvas System ===

Tom has updated FlightGear 3.1 to remove a lot of unneeded OpenGL state changes. Depending on the GPU/driver this can lead to quite a noticeable performance improvement. For example, he was able to get from ~120ms down to ~45ms [http://forum.flightgear.org/viewtopic.php?f=71&t=16984&p=204730#p204730].

=== High Level Architecture ===

=== Usability Improvements ===

=== Creating your own keybindings ===
A common request is how to change keys to do different commands. FlightGear makes this as easy as editing an XML file, and possibly adding a parameter to point FG to the new XML file.

In general, the list of keyboard commands is stored in the property tree and is loaded at startup or when the menu option "Debug -> Reload input" is selected. The main list of commands is available in {{Git link|gitorious|fg/fgdata|master|keyboard.xml|pre=$FG_ROOT/}}, but each aircraft can add/change its own bindings through its -set.xml file, and additional [[config file]]s can do the same.

Continue reading [[Howto:Reassign keyboard keys]]...

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

If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

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

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

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

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

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

== Nasal for newbies ==

== New software tools and projects ==

=== Free SVG VFR & IFR Symbol Sets===

[[File:Helichartsbroadcaststationsexampleflagandunderscore.png]]

This is a free set created by Michat that will be available soon in order to support whatever any project related with FlightGear in need to use navigation symbols. I.e FGMap, manuals , route explanation charts, virtual schools, virtual airliners, Android app, ATC or whatever project related with FG that need it.

The project consists of a very high detailed VFR Symbols Advanced Set, and a IFR Basic Set that you can use freely for your FlightGear project.

[[File:Vfrwaypointsstandalone.png]]
[[File:Rotatinglightwithcourselightsandsitenumberarrowsstarbig.png]]
[[File:Helichartsultralightflightpark.png]]
[[File:Helichartsgliderarea.png]]
[[File:Civilairportwithnocontroltower.png]]
[[File:Rotatinglightwithcourselightsandsitenumberairportsmall.png]]
[[File:Airmarkedidentification.png]]
[[File:Wrecksexposed.png]]
[[File:Helicopterchartsseaplane.png]]
[[File:Collocatedwithvfrcheckpoint.png]]
[[File:Helichartsrco.png]]

[[File:Canvastest.png|thumb|Tests with IFR Icons Set for FGCanvas]]

[[File:Highintensityobstructionlights4big.png]]
[[File:Groupobstruction3big.png]]
[[File:Highintensityobstructionlights3big.png]]
[[File:Highintensityobstructionlights5small.png]]

Here are shown some examples of Obstruction Symbols based on the AOPA's VFR Charts.
As you can see It was 'another night space invaders' design session.

'''Also IFR Symbols will be available soon to support your project.'''

[[File:Helichartsvor.png]]
[[File:Helichartsvortac.png]]
[[File:Helichartsvordme.png]]

=== osm2city.py update ===
[[File:LOWI with OSM buildings from FL300.jpg|thumb|Aerial view of LOWI, with 60k OSM buildings]]
Following Mathias' suggestion at FS Weekend 2013, Radi changed the code such that it merges all buildings per (osm2city) tile into one object, reducing the number of drawables from O(10k) to O(10) and thereby improving performance. On an i7/Intel HD 5000/2560x1440, a scene looking down at LOWI from FL300 with 60k buildings would render previously at 6 fps. That has more than doubled to 14 fps. Plain Scenery 2.0 (no buildings) gives 19 fps. For the moment, LOD and textures are broken but will be fixed soon.

== FlightGear addons and mods ==

== In the hangar ==

=== New aircraft ===

==== Beech V35 Bonanza ====
Flyingfisch is working on the Beech 35 Bonanza.
![http://img.ourl.ca/02.png]
![http://img.ourl.ca/20.png]

'''Embraer ERJ 145'''

'''Emmanuel Baranger, (helijah)'''

The Embraer ERJ 145 family is a series of regional jets produced by Embraer, a Brazilian aerospace company. Family members include the ERJ 135 (37 passengers), ERJ 140 (44 passengers), and ERJ 145 (50 passengers), as well as the Legacy business jet and the R-99 family of military aircraft. The ERJ 145 is the largest of the group. Each jet in the series is powered by two turbofan engines. The family's primary competition comes from the Bombardier CRJ regional jets.(Source wikipedia)

[[File:Erj145-splash.png|thumb|ERJ 145 : SplashScreen]]
[[File:Erj145.png|thumb|ERJ 145 in flight]]

'''Focke Wulf Ta 154 "Moskito"'''

'''Emmanuel Baranger, (helijah)'''

The Focke-Wulf Ta 154 Moskito was a fast twin-engined German night fighter aircraft designed by Kurt Tank and produced by Focke-Wulf during late World War II. Only a few were produced and proved to have less impressive performance than the prototypes.

[[File:Ta154-splash.png|thumb|Ta 154 : SplashScreen]]
[[File:Ta154.png|thumb|Ta 154 in flight]]

=== Updated aircraft ===
{{Conversational}}

Updated: http://sourceforge.net/p/flightgear/mailman/message/32241203/

==== PA24-250 ====
[[File:Pa24-250 cockpit.png|thumb|Interior of the updated pa24-250]]
[[File:Pa24-250 updated.png|thumb|Livery support now available]]
flyingfisch has added livery support and more to an updated version of the PA24 available at https://github.com/flyingfisch/pa24-250.

=== Liveries ===
[[File:FAC.png|thumb|Screenshot of EC-137D FAC livery - FlightGear Aviation Commission]]

FAC (FlightGear Aviation Commission)
Download here: [https://drive.google.com/file/d/0B1neCIlnSm2hYVlWdmtVSjgtS1k/edit?usp=sharing] under Creative Commons Attribution-Share Alike 3.0 Unported license from original FG Logos [http://wiki.flightgear.org/FlightGear_logos]

== Scenery corner ==
=== The Making of a new World Scenery ===
A frequently asked question about scenery is: "Why isn't the terrain updated more often?". Most of us are probably unaware about what is required to build a new World Scenery and what is required to ship a complete set of data for rendering the world in FlightGear. As there is actually a new build in progress, we are able to present some naked numbers to give a rough impression about the resources involved.
First, there is the raw data. Roughly half a dozen databases containing more than 100GB of elevation, coast lines, water ways, roads, land cover, navigation data and all the things that make up the details of our planets surface. [[File:terrain-generation-memory-consumption.png|right|thumb|Memory consumption during scenery creation]]
All these information have to be converted into files understandable by FlightGear. The earth's surface in FlightGear is cut into tiles, each tile containing a 3d model for that area. While generating a single tile is a not too complicated task, generating the entire world is. Roads, coastlines, run- and taxiways do sometimes cross tile boundaries so the 3d surface has to be sliced at the tile boundary. The vertices on both edges have to be at the exact same position. To guarantee, you can't fall into the abyss while taxiing across an unclosed tile boundary, all tiles have to be created in a single run with the current toolchain.
The machine performing that task has to crunch all the 100GB of raw data, keep the results more or less in memory and write the results to disk. This is an extremly time and resource hungry job. The current vectorization job has been started on Feb. 28th and is still running (Apr. 6th). Probably most impressive is the memory consumption which has grown to nearly 130GB. This is RAM, not Harddisk. As the machine is unfortunately ''only'' equipped with 100GB of RAM has started to use nearly 30GB of swap space.
All this only works because of just a few people working hard and usually undiscovered in the background.

=== 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 ===
{{#ev:youtube|PW36zkuHyBA}}

Retrospective flight in B707 via Rembrant

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
==== The Northern-Italy ATC Controlled Area (NIATCA) ====
NIATCA was born between December 2013 and January 2014 to offer Air Traffic Control in Northern Italy and in the neighboring area; the project originally covered only LIPA, LIPX, LSZS and LIMC.

Today, its members' efforts allow you to enjoy professional services at the following airports:
* Milano Linate (LIML)
* Milano Malpensa (LIMC)
* Samedan (LSZS)
* Bergamo Orio al Serio (LIME)
* Verona Villafranca (LIPX)
* Bologna (LIPE)
* Aviano Air Base (LIPA)
* Trieste-Ronchi dei Legionari (LIPQ)
* Venezia Tessera (LIPZ)
* Innsbruck-Kranebitten (LOWI)

ATC sessions take place throughout the week and are planned on [http://flightgear-atc.alwaysdata.net/ Lenny's website]. Airport briefings and links to charts are available [http://forum.flightgear.org/viewtopic.php?f=10&t=21959 on the forum].

For more informations, you can visit [https://plus.google.com/113151232487920064268 the project's Google+ page] or [https://www.youtube.com/user/NIATCAproject its YouTube channel]. The project is also searching for new members to extend coverage; current open positions are Torino Caselle (LIMF), Genova Sestri (LIMJ), Treviso "San Angelo" (LIPH),Rimini-Miramare (LIPR), Bolzano-Dolomiti (LIPB), Base aerea di Rivolto (LIPI), Base aerea militare di Istrana (LIPS). If you want to contribute, just [https://docs.google.com/forms/d/1Yh5QqEHGZ-64tvUHUBoEa43SLMF8jwOm2Sis9otyPpo/viewform apply to become a member].

Candidates are required to:
* know ATC phraseology;
* know the English language (knowledge of Italian is a plus);
* be able to read charts and to let pilots follow real SIDs/STARs;
* be able to man their position(s) at least one/two hours a week.

=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===

{{Volunteer Intro|mode=showlogo}}



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

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

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

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

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

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

<references/>

=== Call for volunteers ===
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support

=== Did you know ===

[[Category:FlightGear Newsletter]]


[[Category:Changes after 3.00]]

Carrier over MP

2014-04-28T23:59:19Z

Noah:

'''Carrier over MP''' is available in [[FlightGear]] 2.0.0 and later and makes it possible to command the [[Howto: Carrier|Nimitz]] and other [[aircraft carrier]]s. Other pilots on the [[Howto: Multiplayer|multiplayer network]] can ''elect'' to be able to see and land on the carrier controlled by the MP carrier player.

== Usage examples ==

=== Commander ===
Command the Nimitz:
% fgfs --aircraft=nimitz
Command the Eisenhower:
% fgfs --aircraft=eisenhower

Command the Nimitz for MP operation:
% fgfs --aircraft=nimitz --callsign='Nimitz7' --multiplay=...

=== Pilot ===
To enable MP control of a carrier when on the multiplayer network use the MP carrier dialog available from Multiplayer->"MPCarrier selection" to select which MP carrier players you wish to see. Note that the AI scenario for the corresponding carrier MUST be active.

[[File:MPCarrier-dialog.png|thumb|center|The MPCarrier selection dialog. The user 'Nimitz' is currently selected as the controller of the carrier Nimitz.]]

It is also possible to select MP carrier players from the command line using the following --prop: argument (change nimitz to the
% fgfs --ai-scenario=nimitz_demo --prop:/sim/mp-carriers/nimitz-callsign=<callsign of the player commanding mp-nimitz> --multiplay=.....

== Important ==

The MP carrier will not be active unless you specify the callsign of the player on MP running Nimitz with the MP carrier dialog or
--prop:/sim/mp-carriers/nimitz-callsign=<callsign of the mp-nimitz player>
This ensures that MPCarriers won't interfer with the normal nimitz_demo scenario unless you explicitly ask for that.

Please also note that '''''<big>the AI scenario corresponding to the carrier you want to see must also be active!</big>''''' Many pilots forget this at setup.

And remember, have fun :) .

=== For the carrier captain ===
I sometimes get questions about driving the carriers, so here are the principal tips:

First see the aircraft help. Press '?'.

If you don't know how to change orientation and position of the carrier (apart from using the rudder and speed, but that take a long time to cross ocean :) ), you can use the properties.

The tip is that you need to change the properties of the ai-carrier you are driving, e.g. for the Nimitz,find the /ai/models/carrier[i] that got Nimitz as name.

In /ai/models/carrier[i]/position/ you can change lat, lon, and elevation to put it where you want, and in /ai/models/carrier[i]/orientation you can make it face wind. Facing wind is important (with real weather fetch) to make the FLOLS green on approach.

Set speed using PgUp/PgDown in manual control.

To have a better sync between the pilots using the Nimitz, i prefer to keep a speed of 0 so that there's no drift between pilots.

== Installation ==

===FlightGear 2.0.0 and later===

Download from the MPCarrier aircraft archive from [http://www.flightgear.org/Downloads/ the main FlightGear page].
Unpack the archive into the Aircraft subdirectory of the FlightGear data directory.

=== FlightGear 1.9.1 ===

The download the [http://www.gidenstam.org/FlightGear/misc/Carrier_over_MP/MPCarrier_fgfs1.9.1.tar.gz MPCarrier aircraft archive] available here: [http://www.gidenstam.org/FlightGear/misc/Carrier_over_MP/ http://www.gidenstam.org/FlightGear/misc/Carrier_over_MP/]

# Unpack the archive into <tt>data/Aircraft</tt>. For windows users, you can use 7zip and apply it twice (one to unzip, one to untar), until you've got the MPCarrier folder. Once MPCarrier in your Aircraft directory, you will find a new "aircraft" called 'nimitz' in your aircraft list.
# Make sure that the AI scenario nimitz_demo is active.
# To see a mp carrier, set the property: /sim/mp-carriers/nimitz-callsign (see below "important")
# Optional: To get a MPCarrier dialog entry in the Network menu. Apply the changes in mpcarrier_menubar.diff to FG_ROOT/gui/menubar.xml. The diff is for FlightGear/CVS. However, the structure of menubar.xml is so simple that I expect almost anyone could figure out how to add the menu entry :)

[[Category:Multiplayer]]

FlightGear Newsletter April 2014

2014-04-28T23:24:55Z

Noah:

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

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

=== Splitting fgdata ===
{{Conversational}}
http://sourceforge.net/p/flightgear/mailman/message/32238780/
<pre>

</pre>
=== Text-to-Speech: ATIS via FLITE ===
Torsten and James started adding FLITE support to FlightGear/next:
{{Conversational}}
<pre>thanks to James' finding of flite+hts_engine
(http://flite-hts-engine.sp.nitech.ac.jp/)
we are now again able to listen to spoken atis and probably any other
kind of spoken messages soon.
This is a complete text-to-speech system (currently only english
language) that generates wav files from plain text on the fly with
surprisingly good quality speech and small memory footprint.

I have just pushed some code that uses the flite+hts_engine to
synthesize the generated atis text for comm radios into a SGSoundSample
and feed this into our sound manager. To make use of this feature you
have to rebuild FlightGear from source and call cmake with
-DENABLE_FLITE=On. When ready, tune your comm radio to the ATIS
frequency of your airport. After a few seconds, you should hear a lady
talking about flightgear weather.

The code contains some ugly hacks and not everything is working
perfectly yet. But I'd like to get some feedback regarding performance,
sound quality and cross platform compatibility. So please give it a try.

Torsten
</pre>

=== YaSim versioning ===
{{Conversational}}

<pre>Hi all,

as promised, I have just added a versioning scheme to yasim
configuration files.
The <airplane> element of the yasim config file now understands the
"version" attribute that can be currently one of these values:

YASIM_VERSION_ORIGINAL
The original version of YASim as implemented up to FlightGear 3.0.0
(this is the default)

YASIM_VERSION_32
The version of YASim currently implemented in FlightGear 3.1 (current
git HEAD)

YASIM_VERSION_CURRENT
The current and latest version of YASim (which is currently the same as
YASIM_VERSION_32)

Example:
<airplane mass="1344" version="YASIM_VERSION_32">

A missing "version" attribute will cause yasim to use the original
(buggy) implementation without the latest patches. This should restore
the original behavior to all yasim aircraft. Aircraft that were adapted
to the new version of yasim (with the latest patches from Colin Douglas
Howell) should set version=" YASIM_VERSION_32" to re-enable those changes.

The idea is to add a new YASIM_VERSION_xx with every release cycle where
xx is the next to-be-released version number (32 for 3.2 for the current
cycle and 34 for the next cycle etc).

I hope this is somewhat useful and works as described.
Please test some yasim aircraft and provide feedback.

Greetings,
Torsten
</pre>

=== Proof-of-Concept: A TerraGear Web Service (by F-JJTH) ===
As part of prototyping a [[TerraGear scenery build server]], F-JJTH has started working on a proof-of-concept for a web-based TerraGear GUI/build service. This can use the precompiled-TerraGear packages created and provided by saiarcot895. We are currently looking for people interested in picking up this prototype to continue developing it over time. All the difficult bits are now in place (namely the TerraGear setup), as well as a compelling web-based interface. People interested in helping with this, should ideally have some web programming experience, for TerraGear specifics you can probably just get in touch with psadro_gm and papillon81 (or refer to the docs for starters). Also, we're hoping to also create Linux packages for the web interface, so that installation/updates can be just as easily handled using the deb/apt/ppa package manager.

Primarily, we are now looking for hosting, not just for the TerraGear setup itself (which should be fairly powerful), but also for those deb/apt packages. If you'd like to help with this, please get in touch via the forum.

<gallery mode=packed widths=230px heights=230px>
TerraGear_build_server_concept_map.png|Schematic of a possible setup for TG GUI or a web interface to access TerraGear services provided by a build server
TerraGear-BuildServer-Prototype.png|TerraGear BuildServer Experiments
TerraGear-hgtchop-VM.png|TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages
F-jjth-tggui-prototype.jpg|Web-based TerraGear GUI prototype developed by F-JJTH in 03/2014
</gallery>

Continue reading at [[TerraGear scenery build server]]...

=== Missions & Adventures via Tutorials ===
{{forum|79|Tutorials, Missions & Adventures}}

[[File:Missionb.png]]

{{#ev:youtube|yWEyRVGJks0}} {{#ev:youtube|LC2bk3UH8jg}} {{#ev:youtube|dU7ikBZOjgk}}

[[File:Non-player-characters 1 20140421 1863384647.png|thumb|DFaber's Walker used for adding NPC support to Stuart's tutorial system]]

Learn more at [[FlightGear Missions and Adventures]]...

=== YASim Bug Fixes ===
As of April 4th, several bug fixes by Colin Howell have been merged into the "next" branch of FlightGear's source. As per issues {{issue|1400|}}, {{issue|1423|}}, and {{issue|1427|}}, these are only small fixes in portions of code, but they still may have noticeable affects on YASim aircraft, including making the solver fail with some aircraft and making other aircraft perform better. Currently these fixes are loaded unconditionally, so there's no opt-in or opt-out system in place, meaning that we need ''you'' to help test as many YASim aircraft as possible. (Please note that these patches are only available with a latest binary, i.e. a nightly from Jenkins or a compilation from source, and a corresponding FGData clone.) Detlef posts, "I have tested the slat patch and the twist patch and found very little problems, in fact most cases I've seen saw an improvment. Of the 15 Aircraft I've tested the twist patch on, only two wouldn't start up at all" [http://forum.flightgear.org/viewtopic.php?f=49&t=22522#p204370]. Having a large number of non-working aircraft in the next release would be undesirable, and would suggest that we need an opt-in system for such fixes, but if most aircraft work well it will be simpler to let the patches load unconditionally.

Please report aircraft that fail to work with latest FG (but that still work in 3.0, i.e. without the fixes) on the devel list or on the forums.

Links to ongoing discussion at the development list:
[http://sourceforge.net/p/flightgear/mailman/message/32183541/] [http://sourceforge.net/p/flightgear/mailman/message/32185064/] [http://sourceforge.net/p/flightgear/mailman/message/32185188/] [http://sourceforge.net/p/flightgear/mailman/message/32185412/] [http://sourceforge.net/p/flightgear/mailman/message/32185690/] [http://sourceforge.net/p/flightgear/mailman/message/32185691/] [http://sourceforge.net/p/flightgear/mailman/message/32185923/]

=== How to troubleshoot FlightGear crashes ===
The recent 2 release cycles have made one thing pretty obvious: more and more end-users are faced with obscure crashes, so called "segfaults" - unfortunately, developers cannot easily reproduce those in most cases. Thus, we need our contributors to provide better diagnostics. However, the process isn't exactly straightforward for non-developers, but at least Linux-based users can typically provide all the required information even without having to be programmers themselves.

A segfault is another word for "application crash", it's a so called "segmentation fault", where the FlightGear program is doing things that it wasn't designed to do, such as accessing invalid memory for example, so that the operating system will terminate the process because its behavior is no longer valid/correct.

These segfaults will typically happen due to coding errors, either in FlightGear or one of its dependencies (libraries like SimGear, plib, OpenSceneGraph or OpenAL), and at times due to a combination of issues in several dependencies.

In order to see what was going on when the crash occurred, you'll need to build a binary with debugging symbols enabled/included, usually this includes FlightGear and SimGear - and possibly even OSG (OpenSceneGraph, normally only if your crash happens inside rendering related code).

A so called backtrace is basically pretty much like a flight data recorder tape/log that is used to conduct a post-crash analysis.

A binary with debugging symbols included will contain additional information that helps developers track down what was causing a certain crash, such as for example the file name, function, line number, variable that was accessed before the crash happened. This is analogous to how a FDR/CVR on an airplane records certain parameters like position, orientation, altitude, velocities, configuration, cockpit conversations etc. This can also be used by developers to see who is responsible for a certain segfault/bug, i.e. which commit introduced the bug.

Debugging FlightGear crashes is significantly simplified by having access to such runtime data, because we can basically go back in time and see what the FlightGear program was doing shortly before the crash.

Learn more at [[Howto:Debugging FlightGear Crashes#Debugging_Segfaults_.26_Obtaining_Backtraces|Debugging Segfaults & Obtaining Backtraces]]...
=== Under the Hood of: Nasal OOP (by Philosopher & galvedro) ===

Nasal does not have the concept of "classes", understanding by a class an object definition that cannot exist as an instance on its own. What we always have in Nasal is hashes that perhaps reference other hashes via the parents vector.

The parents vector is just a symbol lookup trick. The only thing it does is to add other hashes as targets where Nasal can search for symbols that are not defined in the current hash. This servers for implementing object inheritance in a traditional way as long as:

# The symbols that you expect to be gathering from the parented hashes are functions. This is because when you are executing a function in a parent hash, the me symbol will allow you you to resolve the context back to the instance hash down the hierarchy.
# Non function members that are expected to be kept per instance, are defined in the instance hash. Otherwise those members might end up being shared across derived hashes due to the parents lookup mechanism.
# Members that are expected to be shared across different instances are defined in the template hash and not in the instances themselves. Which means that you have to be careful on how you write values to them or you will end up creating a new member in the instance hash that will shadow the shared member. (Mmm, this one is a dangerous pitfall, but I remember seeing this explained in the wiki, and is not that often that you need this...).

The me reference is a syntactic trick, and it can be dangerous to use depending on the usage pattern, so some good practices are in order, in particular

1. When writing a constructor in a template object, do not use me in the parents vector, because me will resolve to a hash reference only when the new() method is called, and which hash will it be depends on how the method is called.

2. When calling a "super" class method from an overriding method, use the Nasal call() library function, specifying the instance hash as the me parameter. If you use the parents vector directly, me will likely end up referring to a template hash instead and you will loose the instance context.
Basically you have an expression on the left side of a dot, and then a lvalue and parenthesis on the right side -- no exceptions! The expression is evaluated once, with the value being DUP'ed (duplicated/copied) and used both for the member get (i.e. what is the function contained in the hash) and as a special argument to the function (now a method) call. That "me" is then set as a symbol like an argument, originating from the left-hand expression, and is otherwise unset.

In other cases, using the call() builtin, it is possible to specify the me reference manually, but what "me" is, is otherwise a consequence of how it is called. If the syntax differs, there is no me local variable. (One common example is passing a MEMBER of an object to a function as a parameter or saving it to a variable - i.e. then it doesn't matter if it is a function or not.) (I use MEMBER here to distinguish from METHODS, where a METHOD uses "me" and a MEMBER doesn't.)

The thing with a func {} expression is that it delays evaluation, so it can keep the proper syntax for the method call and therefore pass the correct me reference, which is preserved in its closure.

Parents inheritance is really simple: to find a member you search for it in the current hash or try finding it in each parent (indexes 0..n), throwing an error if there is too much recursion. Basically, inheritance is implemented such that there's a mutable parents vector that maintains a list of hashes that are used for recursive symbol lookups, me will be defined per instance and point to the outer hash. Which is why shadowing can occur.

'''me''' is also mutable, i.e. if it isn't defined, it can be explicitly defined, or passed via call() - a mehod which we tend to use in MapStructure whenever we want to ensure that the proper instance is passed, i.e. no variable shadowing taking place.

* FUNC() -> no me
* OBJ.METHOD() -> me = OBJ
* (OBJ.MEMBER_FUNC)() -> no me
* (EXPR).METHOD() -> me = (EXPR)

Continue reading at [[Object oriented programming in Nasal]]...

=== Orbital Rendering:Earthview ===

Earthview is an orbital rendering engine for Flightgear designed to get credible visuals when using spacecraft such as Vostok-1. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. Since there's only a single object in the field of view, performance is generally very good provided that there's enough texture memory available.

Textures are taken from the NASA Visible Earth project - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed via GIT, a mode to make the GB-sized hires textures has yet to be determined.

Combined with the ALS shader to render the atmosphere, visuals are generally rather compelling.

[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]

A long standing problem in Flightgear's atmosphere definition has now been addressed and JSBSim spacecraft should now be able to reach any orbital altitude within their capabilities (previously flight was restricted to be below 150 km altitude).

=== FlightGear/Oculus Rift Experiments ===

{{#ev:youtube|v-31tCHpKC0}}

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

=== Random Buildings ===

=== Project Rembrandt ===
A number of Mac users have been reporting issues related to running [[Project Rembrandt]] (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: [[Project Rembrandt#Mac Issues]].

=== Canvas System ===

Tom has updated FlightGear 3.1 to remove a lot of unneeded OpenGL state changes. Depending on the GPU/driver this can lead to quite a noticeable performance improvement. For example, he was able to get from ~120ms down to ~45ms [http://forum.flightgear.org/viewtopic.php?f=71&t=16984&p=204730#p204730].

=== High Level Architecture ===

=== Usability Improvements ===

=== Creating your own keybindings ===
A common request is how to change keys to do different commands. FlightGear makes this as easy as editing an XML file, and possibly adding a parameter to point FG to the new XML file.

In general, the list of keyboard commands is stored in the property tree and is loaded at startup or when the menu option "Debug -> Reload input" is selected. The main list of commands is available in {{Git link|gitorious|fg/fgdata|master|keyboard.xml|pre=$FG_ROOT/}}, but each aircraft can add/change its own bindings through its -set.xml file, and additional [[config file]]s can do the same.

Continue reading [[Howto:Reassign keyboard keys]]...

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

If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

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

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

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

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

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

== Nasal for newbies ==

== New software tools and projects ==

=== Free SVG VFR & IFR Symbol Sets===

[[File:Helichartsbroadcaststationsexampleflagandunderscore.png]]

This is a free set created by Michat that will be available soon in order to support whatever any project related with FlightGear in need to use navigation symbols. I.e FGMap, manuals , route explanation charts, virtual schools, virtual airliners, Android app, ATC or whatever project related with FG that need it.

The project consists of a very high detailed VFR Symbols Advanced Set, and a IFR Basic Set that you can use freely for your FlightGear project.

[[File:Vfrwaypointsstandalone.png]]
[[File:Rotatinglightwithcourselightsandsitenumberarrowsstarbig.png]]
[[File:Helichartsultralightflightpark.png]]
[[File:Helichartsgliderarea.png]]
[[File:Civilairportwithnocontroltower.png]]
[[File:Rotatinglightwithcourselightsandsitenumberairportsmall.png]]
[[File:Airmarkedidentification.png]]
[[File:Wrecksexposed.png]]
[[File:Helicopterchartsseaplane.png]]
[[File:Collocatedwithvfrcheckpoint.png]]
[[File:Helichartsrco.png]]

[[File:Canvastest.png|thumb|Tests with IFR Icons Set for FGCanvas]]

[[File:Highintensityobstructionlights4big.png]]
[[File:Groupobstruction3big.png]]
[[File:Highintensityobstructionlights3big.png]]
[[File:Highintensityobstructionlights5small.png]]

Here are shown some examples of Obstruction Symbols based on the AOPA's VFR Charts.
As you can see It was 'another night space invaders' design session.

'''Also IFR Symbols will be available soon to support your project.'''

[[File:Helichartsvor.png]]
[[File:Helichartsvortac.png]]
[[File:Helichartsvordme.png]]

=== osm2city.py update ===
[[File:LOWI with OSM buildings from FL300.jpg|thumb|Aerial view of LOWI, with 60k OSM buildings]]
Following Mathias' suggestion at FS Weekend 2013, Radi changed the code such that it merges all buildings per (osm2city) tile into one object, reducing the number of drawables from O(10k) to O(10) and thereby improving performance. On an i7/Intel HD 5000/2560x1440, a scene looking down at LOWI from FL300 with 60k buildings would render previously at 6 fps. That has more than doubled to 14 fps. Plain Scenery 2.0 (no buildings) gives 19 fps. For the moment, LOD and textures are broken but will be fixed soon.

== FlightGear addons and mods ==

== In the hangar ==

=== New aircraft ===

==== Beech V35 Bonanza ====
Flyingfisch is working on the Beech 35 Bonanza.
![http://img.ourl.ca/02.png]
![http://img.ourl.ca/20.png]

'''Embraer ERJ 145'''

'''Emmanuel Baranger, (helijah)'''

The Embraer ERJ 145 family is a series of regional jets produced by Embraer, a Brazilian aerospace company. Family members include the ERJ 135 (37 passengers), ERJ 140 (44 passengers), and ERJ 145 (50 passengers), as well as the Legacy business jet and the R-99 family of military aircraft. The ERJ 145 is the largest of the group. Each jet in the series is powered by two turbofan engines. The family's primary competition comes from the Bombardier CRJ regional jets.(Source wikipedia)

[[File:Erj145-splash.png|thumb|ERJ 145 : SplashScreen]]
[[File:Erj145.png|thumb|ERJ 145 in flight]]

'''Focke Wulf Ta 154 "Moskito"'''

'''Emmanuel Baranger, (helijah)'''

The Focke-Wulf Ta 154 Moskito was a fast twin-engined German night fighter aircraft designed by Kurt Tank and produced by Focke-Wulf during late World War II. Only a few were produced and proved to have less impressive performance than the prototypes.

[[File:Ta154-splash.png|thumb|Ta 154 : SplashScreen]]
[[File:Ta154.png|thumb|Ta 154 in flight]]

=== Updated aircraft ===
{{Conversational}}

Updated: http://sourceforge.net/p/flightgear/mailman/message/32241203/

==== PA24-250 ====
[[File:Pa24-250 cockpit.png|thumb|Interior of the updated pa24-250]]
[[File:Pa24-250 updated.png|thumb|Livery support now available]]
flyingfisch has added livery support and more to an updated version of the PA24 available at https://github.com/flyingfisch/pa24-250.

=== Liveries ===
[[File:FAC.png|thumb|Screenshot of EC-137D FAC livery - FlightGear Aviation Commission]]

FAC (FlightGear Aviation Commission)
Download here: [https://drive.google.com/file/d/0B1neCIlnSm2hYVlWdmtVSjgtS1k/edit?usp=sharing] under Creative Commons Attribution-Share Alike 3.0 Unported license from original FG Logos [http://wiki.flightgear.org/FlightGear_logos]

== Scenery corner ==
=== The Making of a new World Scenery ===
A frequently asked question about scenery is: "Why isn't the terrain updated more often?". Most of us are probably unaware about what is required to build a new World Scenery and what is required to ship a complete set of data for rendering the world in FlightGear. As there is actually a new build in progress, we are able to present some naked numbers to give a rough impression about the resources involved.
First, there is the raw data. Roughly half a dozen databases containing more than 100GB of elevation, coast lines, water ways, roads, land cover, navigation data and all the things that make up the details of our planets surface. [[File:terrain-generation-memory-consumption.png|right|thumb|Memory consumption during scenery creation]]
All these information have to be converted into files understandable by FlightGear. The earth's surface in FlightGear is cut into tiles, each tile containing a 3d model for that area. While generating a single tile is a not too complicated task, generating the entire world is. Roads, coastlines, run- and taxiways do sometimes cross tile boundaries so the 3d surface has to be sliced at the tile boundary. The vertices on both edges have to be at the exact same position. To guarantee, you can't fall into the abyss while taxiing across an unclosed tile boundary, all tiles have to be created in a single run with the current toolchain.
The machine performing that task has to crunch all the 100GB of raw data, keep the results more or less in memory and write the results to disk. This is an extremly time and resource hungry job. The current vectorization job has been started on Feb. 28th and is still running (Apr. 6th). Probably most impressive is the memory consumption which has grown to nearly 130GB. This is RAM, not Harddisk. As the machine is unfortunately ''only'' equipped with 100GB of RAM has started to use nearly 30GB of swap space.
All this only works because of just a few people working hard and usually undiscovered in the background.

=== 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 ===
{{#ev:youtube|PW36zkuHyBA}}

Retrospective flight in B707 via Rembrant

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== New Flightgear Server! (SDD) ===
I'm very pleased to now be a part of the amazing FlightGear community and am happy to say that I have created a new FlightGear server! It's currently its own unit and is not connected to the other core FlightGear servers. It's hosted in beautiful NYC, but I may add other nodes soon, depending on how many people join and how many requests come in on the forum. Feel free to fly in anytime at '''fg.noahbuscher.com''' with port '''5000'''. Submit suggestions over on the forum! [http://forum.flightgear.org/viewtopic.php?f=42&t=22870&p=207328]

==== The Northern-Italy ATC Controlled Area (NIATCA) ====
NIATCA was born between December 2013 and January 2014 to offer Air Traffic Control in Northern Italy and in the neighboring area; the project originally covered only LIPA, LIPX, LSZS and LIMC.

Today, its members' efforts allow you to enjoy professional services at the following airports:
* Milano Linate (LIML)
* Milano Malpensa (LIMC)
* Samedan (LSZS)
* Bergamo Orio al Serio (LIME)
* Verona Villafranca (LIPX)
* Bologna (LIPE)
* Aviano Air Base (LIPA)
* Trieste-Ronchi dei Legionari (LIPQ)
* Venezia Tessera (LIPZ)
* Innsbruck-Kranebitten (LOWI)

ATC sessions take place throughout the week and are planned on [http://flightgear-atc.alwaysdata.net/ Lenny's website]. Airport briefings and links to charts are available [http://forum.flightgear.org/viewtopic.php?f=10&t=21959 on the forum].

For more informations, you can visit [https://plus.google.com/113151232487920064268 the project's Google+ page] or [https://www.youtube.com/user/NIATCAproject its YouTube channel]. The project is also searching for new members to extend coverage; current open positions are Torino Caselle (LIMF), Genova Sestri (LIMJ), Treviso "San Angelo" (LIPH),Rimini-Miramare (LIPR), Bolzano-Dolomiti (LIPB), Base aerea di Rivolto (LIPI), Base aerea militare di Istrana (LIPS). If you want to contribute, just [https://docs.google.com/forms/d/1Yh5QqEHGZ-64tvUHUBoEa43SLMF8jwOm2Sis9otyPpo/viewform apply to become a member].

Candidates are required to:
* know ATC phraseology;
* know the English language (knowledge of Italian is a plus);
* be able to read charts and to let pilots follow real SIDs/STARs;
* be able to man their position(s) at least one/two hours a week.

=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===

{{Volunteer Intro|mode=showlogo}}



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

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

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

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

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

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

<references/>

=== Call for volunteers ===
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support

=== Did you know ===

[[Category:FlightGear Newsletter]]


[[Category:Changes after 3.00]]

FlightGear Newsletter April 2014

2014-04-28T23:13:52Z

Noah: Added a shoutout to my new server.

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

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

=== Splitting fgdata ===
{{Conversational}}
http://sourceforge.net/p/flightgear/mailman/message/32238780/
<pre>

</pre>
=== Text-to-Speech: ATIS via FLITE ===
Torsten and James started adding FLITE support to FlightGear/next:
{{Conversational}}
<pre>thanks to James' finding of flite+hts_engine
(http://flite-hts-engine.sp.nitech.ac.jp/)
we are now again able to listen to spoken atis and probably any other
kind of spoken messages soon.
This is a complete text-to-speech system (currently only english
language) that generates wav files from plain text on the fly with
surprisingly good quality speech and small memory footprint.

I have just pushed some code that uses the flite+hts_engine to
synthesize the generated atis text for comm radios into a SGSoundSample
and feed this into our sound manager. To make use of this feature you
have to rebuild FlightGear from source and call cmake with
-DENABLE_FLITE=On. When ready, tune your comm radio to the ATIS
frequency of your airport. After a few seconds, you should hear a lady
talking about flightgear weather.

The code contains some ugly hacks and not everything is working
perfectly yet. But I'd like to get some feedback regarding performance,
sound quality and cross platform compatibility. So please give it a try.

Torsten
</pre>

=== YaSim versioning ===
{{Conversational}}

<pre>Hi all,

as promised, I have just added a versioning scheme to yasim
configuration files.
The <airplane> element of the yasim config file now understands the
"version" attribute that can be currently one of these values:

YASIM_VERSION_ORIGINAL
The original version of YASim as implemented up to FlightGear 3.0.0
(this is the default)

YASIM_VERSION_32
The version of YASim currently implemented in FlightGear 3.1 (current
git HEAD)

YASIM_VERSION_CURRENT
The current and latest version of YASim (which is currently the same as
YASIM_VERSION_32)

Example:
<airplane mass="1344" version="YASIM_VERSION_32">

A missing "version" attribute will cause yasim to use the original
(buggy) implementation without the latest patches. This should restore
the original behavior to all yasim aircraft. Aircraft that were adapted
to the new version of yasim (with the latest patches from Colin Douglas
Howell) should set version=" YASIM_VERSION_32" to re-enable those changes.

The idea is to add a new YASIM_VERSION_xx with every release cycle where
xx is the next to-be-released version number (32 for 3.2 for the current
cycle and 34 for the next cycle etc).

I hope this is somewhat useful and works as described.
Please test some yasim aircraft and provide feedback.

Greetings,
Torsten
</pre>

=== Proof-of-Concept: A TerraGear Web Service (by F-JJTH) ===
As part of prototyping a [[TerraGear scenery build server]], F-JJTH has started working on a proof-of-concept for a web-based TerraGear GUI/build service. This can use the precompiled-TerraGear packages created and provided by saiarcot895. We are currently looking for people interested in picking up this prototype to continue developing it over time. All the difficult bits are now in place (namely the TerraGear setup), as well as a compelling web-based interface. People interested in helping with this, should ideally have some web programming experience, for TerraGear specifics you can probably just get in touch with psadro_gm and papillon81 (or refer to the docs for starters). Also, we're hoping to also create Linux packages for the web interface, so that installation/updates can be just as easily handled using the deb/apt/ppa package manager.

Primarily, we are now looking for hosting, not just for the TerraGear setup itself (which should be fairly powerful), but also for those deb/apt packages. If you'd like to help with this, please get in touch via the forum.

<gallery mode=packed widths=230px heights=230px>
TerraGear_build_server_concept_map.png|Schematic of a possible setup for TG GUI or a web interface to access TerraGear services provided by a build server
TerraGear-BuildServer-Prototype.png|TerraGear BuildServer Experiments
TerraGear-hgtchop-VM.png|TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages
F-jjth-tggui-prototype.jpg|Web-based TerraGear GUI prototype developed by F-JJTH in 03/2014
</gallery>

Continue reading at [[TerraGear scenery build server]]...

=== New Flightgear Server! (SDD) ===
I'm very pleased to now be a part of the amazing FlightGear community and am happy to say that I have created a new FlightGear server! It's currently its own unit and is not connected to the other core FlightGear servers. It's hosted in beautiful NYC, but I may add other nodes soon, depending on how many people join and how many requests come in on the forum. Feel free to fly in anytime at '''fg.noahbuscher.com''' with port '''5000'''. Submit suggestions over on the forum! [http://forum.flightgear.org/viewtopic.php?f=42&t=22870&p=207328]

=== Missions & Adventures via Tutorials ===
{{forum|79|Tutorials, Missions & Adventures}}

[[File:Missionb.png]]

{{#ev:youtube|yWEyRVGJks0}} {{#ev:youtube|LC2bk3UH8jg}} {{#ev:youtube|dU7ikBZOjgk}}

[[File:Non-player-characters 1 20140421 1863384647.png|thumb|DFaber's Walker used for adding NPC support to Stuart's tutorial system]]

Learn more at [[FlightGear Missions and Adventures]]...

=== YASim Bug Fixes ===
As of April 4th, several bug fixes by Colin Howell have been merged into the "next" branch of FlightGear's source. As per issues {{issue|1400|}}, {{issue|1423|}}, and {{issue|1427|}}, these are only small fixes in portions of code, but they still may have noticeable affects on YASim aircraft, including making the solver fail with some aircraft and making other aircraft perform better. Currently these fixes are loaded unconditionally, so there's no opt-in or opt-out system in place, meaning that we need ''you'' to help test as many YASim aircraft as possible. (Please note that these patches are only available with a latest binary, i.e. a nightly from Jenkins or a compilation from source, and a corresponding FGData clone.) Detlef posts, "I have tested the slat patch and the twist patch and found very little problems, in fact most cases I've seen saw an improvment. Of the 15 Aircraft I've tested the twist patch on, only two wouldn't start up at all" [http://forum.flightgear.org/viewtopic.php?f=49&t=22522#p204370]. Having a large number of non-working aircraft in the next release would be undesirable, and would suggest that we need an opt-in system for such fixes, but if most aircraft work well it will be simpler to let the patches load unconditionally.

Please report aircraft that fail to work with latest FG (but that still work in 3.0, i.e. without the fixes) on the devel list or on the forums.

Links to ongoing discussion at the development list:
[http://sourceforge.net/p/flightgear/mailman/message/32183541/] [http://sourceforge.net/p/flightgear/mailman/message/32185064/] [http://sourceforge.net/p/flightgear/mailman/message/32185188/] [http://sourceforge.net/p/flightgear/mailman/message/32185412/] [http://sourceforge.net/p/flightgear/mailman/message/32185690/] [http://sourceforge.net/p/flightgear/mailman/message/32185691/] [http://sourceforge.net/p/flightgear/mailman/message/32185923/]

=== How to troubleshoot FlightGear crashes ===
The recent 2 release cycles have made one thing pretty obvious: more and more end-users are faced with obscure crashes, so called "segfaults" - unfortunately, developers cannot easily reproduce those in most cases. Thus, we need our contributors to provide better diagnostics. However, the process isn't exactly straightforward for non-developers, but at least Linux-based users can typically provide all the required information even without having to be programmers themselves.

A segfault is another word for "application crash", it's a so called "segmentation fault", where the FlightGear program is doing things that it wasn't designed to do, such as accessing invalid memory for example, so that the operating system will terminate the process because its behavior is no longer valid/correct.

These segfaults will typically happen due to coding errors, either in FlightGear or one of its dependencies (libraries like SimGear, plib, OpenSceneGraph or OpenAL), and at times due to a combination of issues in several dependencies.

In order to see what was going on when the crash occurred, you'll need to build a binary with debugging symbols enabled/included, usually this includes FlightGear and SimGear - and possibly even OSG (OpenSceneGraph, normally only if your crash happens inside rendering related code).

A so called backtrace is basically pretty much like a flight data recorder tape/log that is used to conduct a post-crash analysis.

A binary with debugging symbols included will contain additional information that helps developers track down what was causing a certain crash, such as for example the file name, function, line number, variable that was accessed before the crash happened. This is analogous to how a FDR/CVR on an airplane records certain parameters like position, orientation, altitude, velocities, configuration, cockpit conversations etc. This can also be used by developers to see who is responsible for a certain segfault/bug, i.e. which commit introduced the bug.

Debugging FlightGear crashes is significantly simplified by having access to such runtime data, because we can basically go back in time and see what the FlightGear program was doing shortly before the crash.

Learn more at [[Howto:Debugging FlightGear Crashes#Debugging_Segfaults_.26_Obtaining_Backtraces|Debugging Segfaults & Obtaining Backtraces]]...
=== Under the Hood of: Nasal OOP (by Philosopher & galvedro) ===

Nasal does not have the concept of "classes", understanding by a class an object definition that cannot exist as an instance on its own. What we always have in Nasal is hashes that perhaps reference other hashes via the parents vector.

The parents vector is just a symbol lookup trick. The only thing it does is to add other hashes as targets where Nasal can search for symbols that are not defined in the current hash. This servers for implementing object inheritance in a traditional way as long as:

# The symbols that you expect to be gathering from the parented hashes are functions. This is because when you are executing a function in a parent hash, the me symbol will allow you you to resolve the context back to the instance hash down the hierarchy.
# Non function members that are expected to be kept per instance, are defined in the instance hash. Otherwise those members might end up being shared across derived hashes due to the parents lookup mechanism.
# Members that are expected to be shared across different instances are defined in the template hash and not in the instances themselves. Which means that you have to be careful on how you write values to them or you will end up creating a new member in the instance hash that will shadow the shared member. (Mmm, this one is a dangerous pitfall, but I remember seeing this explained in the wiki, and is not that often that you need this...).

The me reference is a syntactic trick, and it can be dangerous to use depending on the usage pattern, so some good practices are in order, in particular

1. When writing a constructor in a template object, do not use me in the parents vector, because me will resolve to a hash reference only when the new() method is called, and which hash will it be depends on how the method is called.

2. When calling a "super" class method from an overriding method, use the Nasal call() library function, specifying the instance hash as the me parameter. If you use the parents vector directly, me will likely end up referring to a template hash instead and you will loose the instance context.
Basically you have an expression on the left side of a dot, and then a lvalue and parenthesis on the right side -- no exceptions! The expression is evaluated once, with the value being DUP'ed (duplicated/copied) and used both for the member get (i.e. what is the function contained in the hash) and as a special argument to the function (now a method) call. That "me" is then set as a symbol like an argument, originating from the left-hand expression, and is otherwise unset.

In other cases, using the call() builtin, it is possible to specify the me reference manually, but what "me" is, is otherwise a consequence of how it is called. If the syntax differs, there is no me local variable. (One common example is passing a MEMBER of an object to a function as a parameter or saving it to a variable - i.e. then it doesn't matter if it is a function or not.) (I use MEMBER here to distinguish from METHODS, where a METHOD uses "me" and a MEMBER doesn't.)

The thing with a func {} expression is that it delays evaluation, so it can keep the proper syntax for the method call and therefore pass the correct me reference, which is preserved in its closure.

Parents inheritance is really simple: to find a member you search for it in the current hash or try finding it in each parent (indexes 0..n), throwing an error if there is too much recursion. Basically, inheritance is implemented such that there's a mutable parents vector that maintains a list of hashes that are used for recursive symbol lookups, me will be defined per instance and point to the outer hash. Which is why shadowing can occur.

'''me''' is also mutable, i.e. if it isn't defined, it can be explicitly defined, or passed via call() - a mehod which we tend to use in MapStructure whenever we want to ensure that the proper instance is passed, i.e. no variable shadowing taking place.

* FUNC() -> no me
* OBJ.METHOD() -> me = OBJ
* (OBJ.MEMBER_FUNC)() -> no me
* (EXPR).METHOD() -> me = (EXPR)

Continue reading at [[Object oriented programming in Nasal]]...

=== Orbital Rendering:Earthview ===

Earthview is an orbital rendering engine for Flightgear designed to get credible visuals when using spacecraft such as Vostok-1. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. Since there's only a single object in the field of view, performance is generally very good provided that there's enough texture memory available.

Textures are taken from the NASA Visible Earth project - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 m per pixel) and clouds with half of that. Currently there is a much lower texture resolution distributed via GIT, a mode to make the GB-sized hires textures has yet to be determined.

Combined with the ALS shader to render the atmosphere, visuals are generally rather compelling.

[[File:Earthview for low Earth orbit.jpg|450px|Low orbit]] [[File:Earthview hig altitude.jpg|450px|High orbit]]

A dedicated set of shaders for Earth and the cloudsphere is used to create additional effects such a enhanced specular water reflections, cloud shadows and dawnlight color changes:

[[File:Earthview cloud shadows.jpg|450px|Cloud shadows in Earthview]] [[File:Earthview specular water reflections.jpg|450px|Specular water reflections and cloud shadows in Earthview]]

A long standing problem in Flightgear's atmosphere definition has now been addressed and JSBSim spacecraft should now be able to reach any orbital altitude within their capabilities (previously flight was restricted to be below 150 km altitude).

=== FlightGear/Oculus Rift Experiments ===

{{#ev:youtube|v-31tCHpKC0}}

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

=== Random Buildings ===

=== Project Rembrandt ===
A number of Mac users have been reporting issues related to running [[Project Rembrandt]] (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: [[Project Rembrandt#Mac Issues]].

=== Canvas System ===

Tom has updated FlightGear 3.1 to remove a lot of unneeded OpenGL state changes. Depending on the GPU/driver this can lead to quite a noticeable performance improvement. For example, he was able to get from ~120ms down to ~45ms [http://forum.flightgear.org/viewtopic.php?f=71&t=16984&p=204730#p204730].

=== High Level Architecture ===

=== Usability Improvements ===

=== Creating your own keybindings ===
A common request is how to change keys to do different commands. FlightGear makes this as easy as editing an XML file, and possibly adding a parameter to point FG to the new XML file.

In general, the list of keyboard commands is stored in the property tree and is loaded at startup or when the menu option "Debug -> Reload input" is selected. The main list of commands is available in {{Git link|gitorious|fg/fgdata|master|keyboard.xml|pre=$FG_ROOT/}}, but each aircraft can add/change its own bindings through its -set.xml file, and additional [[config file]]s can do the same.

Continue reading [[Howto:Reassign keyboard keys]]...

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

If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

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

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

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

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

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

== Nasal for newbies ==

== New software tools and projects ==

=== Free SVG VFR & IFR Symbol Sets===

[[File:Helichartsbroadcaststationsexampleflagandunderscore.png]]

This is a free set created by Michat that will be available soon in order to support whatever any project related with FlightGear in need to use navigation symbols. I.e FGMap, manuals , route explanation charts, virtual schools, virtual airliners, Android app, ATC or whatever project related with FG that need it.

The project consists of a very high detailed VFR Symbols Advanced Set, and a IFR Basic Set that you can use freely for your FlightGear project.

[[File:Vfrwaypointsstandalone.png]]
[[File:Rotatinglightwithcourselightsandsitenumberarrowsstarbig.png]]
[[File:Helichartsultralightflightpark.png]]
[[File:Helichartsgliderarea.png]]
[[File:Civilairportwithnocontroltower.png]]
[[File:Rotatinglightwithcourselightsandsitenumberairportsmall.png]]
[[File:Airmarkedidentification.png]]
[[File:Wrecksexposed.png]]
[[File:Helicopterchartsseaplane.png]]
[[File:Collocatedwithvfrcheckpoint.png]]
[[File:Helichartsrco.png]]

[[File:Canvastest.png|thumb|Tests with IFR Icons Set for FGCanvas]]

[[File:Highintensityobstructionlights4big.png]]
[[File:Groupobstruction3big.png]]
[[File:Highintensityobstructionlights3big.png]]
[[File:Highintensityobstructionlights5small.png]]

Here are shown some examples of Obstruction Symbols based on the AOPA's VFR Charts.
As you can see It was 'another night space invaders' design session.

'''Also IFR Symbols will be available soon to support your project.'''

[[File:Helichartsvor.png]]
[[File:Helichartsvortac.png]]
[[File:Helichartsvordme.png]]

=== osm2city.py update ===
[[File:LOWI with OSM buildings from FL300.jpg|thumb|Aerial view of LOWI, with 60k OSM buildings]]
Following Mathias' suggestion at FS Weekend 2013, Radi changed the code such that it merges all buildings per (osm2city) tile into one object, reducing the number of drawables from O(10k) to O(10) and thereby improving performance. On an i7/Intel HD 5000/2560x1440, a scene looking down at LOWI from FL300 with 60k buildings would render previously at 6 fps. That has more than doubled to 14 fps. Plain Scenery 2.0 (no buildings) gives 19 fps. For the moment, LOD and textures are broken but will be fixed soon.

== FlightGear addons and mods ==

== In the hangar ==

=== New aircraft ===

==== Beech V35 Bonanza ====
Flyingfisch is working on the Beech 35 Bonanza.
![http://img.ourl.ca/02.png]
![http://img.ourl.ca/20.png]

'''Embraer ERJ 145'''

'''Emmanuel Baranger, (helijah)'''

The Embraer ERJ 145 family is a series of regional jets produced by Embraer, a Brazilian aerospace company. Family members include the ERJ 135 (37 passengers), ERJ 140 (44 passengers), and ERJ 145 (50 passengers), as well as the Legacy business jet and the R-99 family of military aircraft. The ERJ 145 is the largest of the group. Each jet in the series is powered by two turbofan engines. The family's primary competition comes from the Bombardier CRJ regional jets.(Source wikipedia)

[[File:Erj145-splash.png|thumb|ERJ 145 : SplashScreen]]
[[File:Erj145.png|thumb|ERJ 145 in flight]]

'''Focke Wulf Ta 154 "Moskito"'''

'''Emmanuel Baranger, (helijah)'''

The Focke-Wulf Ta 154 Moskito was a fast twin-engined German night fighter aircraft designed by Kurt Tank and produced by Focke-Wulf during late World War II. Only a few were produced and proved to have less impressive performance than the prototypes.

[[File:Ta154-splash.png|thumb|Ta 154 : SplashScreen]]
[[File:Ta154.png|thumb|Ta 154 in flight]]

=== Updated aircraft ===
{{Conversational}}

Updated: http://sourceforge.net/p/flightgear/mailman/message/32241203/

==== PA24-250 ====
[[File:Pa24-250 cockpit.png|thumb|Interior of the updated pa24-250]]
[[File:Pa24-250 updated.png|thumb|Livery support now available]]
flyingfisch has added livery support and more to an updated version of the PA24 available at https://github.com/flyingfisch/pa24-250.

=== Liveries ===
[[File:FAC.png|thumb|Screenshot of EC-137D FAC livery - FlightGear Aviation Commission]]

FAC (FlightGear Aviation Commission)
Download here: [https://drive.google.com/file/d/0B1neCIlnSm2hYVlWdmtVSjgtS1k/edit?usp=sharing] under Creative Commons Attribution-Share Alike 3.0 Unported license from original FG Logos [http://wiki.flightgear.org/FlightGear_logos]

== Scenery corner ==
=== The Making of a new World Scenery ===
A frequently asked question about scenery is: "Why isn't the terrain updated more often?". Most of us are probably unaware about what is required to build a new World Scenery and what is required to ship a complete set of data for rendering the world in FlightGear. As there is actually a new build in progress, we are able to present some naked numbers to give a rough impression about the resources involved.
First, there is the raw data. Roughly half a dozen databases containing more than 100GB of elevation, coast lines, water ways, roads, land cover, navigation data and all the things that make up the details of our planets surface. [[File:terrain-generation-memory-consumption.png|right|thumb|Memory consumption during scenery creation]]
All these information have to be converted into files understandable by FlightGear. The earth's surface in FlightGear is cut into tiles, each tile containing a 3d model for that area. While generating a single tile is a not too complicated task, generating the entire world is. Roads, coastlines, run- and taxiways do sometimes cross tile boundaries so the 3d surface has to be sliced at the tile boundary. The vertices on both edges have to be at the exact same position. To guarantee, you can't fall into the abyss while taxiing across an unclosed tile boundary, all tiles have to be created in a single run with the current toolchain.
The machine performing that task has to crunch all the 100GB of raw data, keep the results more or less in memory and write the results to disk. This is an extremly time and resource hungry job. The current vectorization job has been started on Feb. 28th and is still running (Apr. 6th). Probably most impressive is the memory consumption which has grown to nearly 130GB. This is RAM, not Harddisk. As the machine is unfortunately ''only'' equipped with 100GB of RAM has started to use nearly 30GB of swap space.
All this only works because of just a few people working hard and usually undiscovered in the background.

=== 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 ===
{{#ev:youtube|PW36zkuHyBA}}

Retrospective flight in B707 via Rembrant

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
==== The Northern-Italy ATC Controlled Area (NIATCA) ====
NIATCA was born between December 2013 and January 2014 to offer Air Traffic Control in Northern Italy and in the neighboring area; the project originally covered only LIPA, LIPX, LSZS and LIMC.

Today, its members' efforts allow you to enjoy professional services at the following airports:
* Milano Linate (LIML)
* Milano Malpensa (LIMC)
* Samedan (LSZS)
* Bergamo Orio al Serio (LIME)
* Verona Villafranca (LIPX)
* Bologna (LIPE)
* Aviano Air Base (LIPA)
* Trieste-Ronchi dei Legionari (LIPQ)
* Venezia Tessera (LIPZ)
* Innsbruck-Kranebitten (LOWI)

ATC sessions take place throughout the week and are planned on [http://flightgear-atc.alwaysdata.net/ Lenny's website]. Airport briefings and links to charts are available [http://forum.flightgear.org/viewtopic.php?f=10&t=21959 on the forum].

For more informations, you can visit [https://plus.google.com/113151232487920064268 the project's Google+ page] or [https://www.youtube.com/user/NIATCAproject its YouTube channel]. The project is also searching for new members to extend coverage; current open positions are Torino Caselle (LIMF), Genova Sestri (LIMJ), Treviso "San Angelo" (LIPH),Rimini-Miramare (LIPR), Bolzano-Dolomiti (LIPB), Base aerea di Rivolto (LIPI), Base aerea militare di Istrana (LIPS). If you want to contribute, just [https://docs.google.com/forms/d/1Yh5QqEHGZ-64tvUHUBoEa43SLMF8jwOm2Sis9otyPpo/viewform apply to become a member].

Candidates are required to:
* know ATC phraseology;
* know the English language (knowledge of Italian is a plus);
* be able to read charts and to let pilots follow real SIDs/STARs;
* be able to man their position(s) at least one/two hours a week.

=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===

{{Volunteer Intro|mode=showlogo}}



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

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

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

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

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

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

<references/>

=== Call for volunteers ===
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support

=== Did you know ===

[[Category:FlightGear Newsletter]]


[[Category:Changes after 3.00]]

Howto:Multiplayer

2014-04-28T02:21:39Z

Noah:

With the '''multiplayer''' function of [[FlightGear]] you are able to see other pilots and vice-versa. This makes it possible to fly in formation, [[Howto: Air-Air Refueling|connect to tankers]] controlled by real people or contact real [[air traffic control]]lers to ask for landing/takeoff clearence.

Multiplay may cause extreme [[Howto: Improve Framerates|framerate drops]] during loading of aircraft models. Especially heavy models can cause severe lag. Therefore, it is suggested to fly in locations other than San Francisco's [[KSFO]], where there are fewer pilots flying around.

== Getting online ==
[[File:Multiplayer settings dialog.jpg|thumb|300px|Multiplayer settings dialog]]
As of FlightGear 2.4.0, multiplayer settings can be accessed via the in-sime Multiplayer menu. All you need to do is enter a callsign and select a server from the menu. Press Connect to go online.

This is by far the easiest way to get online, but in some cases the methods mentioned below may be prefered.

=== Using the launcher / FGRun ===
[[File:Multiplayer.jpg|thumb|300px|Multiplayer options in [[FlightGear Wizard|FG Launcher]]]]
# Select your [[aircraft]] and starting airport as normal in [[FlightGear Launch Control|FGRun]].
# On the next screen, tick the "Multiplayer" box. Also tick the "AI models" box or you will not be able to see the other pilots' aircraft.
#* '''Callsign:''' of your choice.
#* '''Hostname:''' enter <tt>mpserverXX.flightgear.org</tt> (with <tt>XX</tt> being the [[#Servers|server number]]).
#* '''In/Out:''' set both ports to 5000.
# Click run and you'll soon be flying with other pilots!

To confirm that it's working, you can go to the multiplayer map at; http://mpmap02.flightgear.org/ (in Hong Kong). Once FlightGear has started, you will notice chat messages that say "Hello" indicating pilots that are online and then as they join (you can change this message by editing the <tt><chat type="string">Hello</chat></tt> line in <tt>[[$FG ROOT]]/preferences.xml</tt>). You may wish to use a different server (i.e. "Hostname" entry).

For more advanced settings, the <tt>Advanced > Network</tt> tab can be opened. You are able to remove the in or out lines only through this method for example.

=== Using fgfs from the command line ===
First, for those who are very impatient and have a vague idea about what they're doing, the basic arguments to pass to fgfs for multiplayer are these;

--multiplay=out,10,server.ip.address,5000
--callsign=anything

where 5000 is the port number the server is listening on (which is 5000 for the official servers).

If you for some reason need to specify which local port and/or interface FlightGear should use add the following argument:

--multiplay=in,10,your.ip.address,portnumber

where portnumber is usually 5000 and your.ip.address is the ip address of the network interface being used by FG to connect to the server - even if that's a local 192.168 type address. You can also leave your.ip.address blank. FlightGear will then listen on all network interfaces:

--multiplay=in,10,,5000

''If you are using fgrun, please note that fgrun expects you to enter a valid (non-loopback, i.e. not 127.0.0.1) IP address or hostname for the local network interface.''

Check [http://fgfs.i-net.hu/modules/fgtracker/ this page] to see whether your callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems!

==== Now, going more slowly for those who are completely lost... ====
Try the above first, and if it doesn't work, read on.

First of all, you need to know the IP address of the network interface you'll be using for multiplayer FG. If your Internet connection is via an ADSL modem that plugs directly into your computer with a USB connection, you should be able to find your IP address by visiting http://www.whatismyip.com . Please note that your ISP might not give you the same IP address each time - if MP stops working, check this first.

Otherwise, your connection is likely via some kind of router that connects to your computer via an RJ-45, or "Ethernet" connector (similar shape to most Western telephone plugs), or by a wireless link. You need to find the IP address of that network interface.

* Under '''Linux''', this can be found by logging in as root and typing "ifconfig". You may find more than one interface listed, beginning with "lo" - ignore that one. You should have something like "eth0" or "wlan0" also listed - look through this block of text for "inet addr". This will be followed directly by the number you're looking for, e.g. "inet addr:192.168.0.150"
* Under '''Windows XP or later''', click start, run, and type "cmd". In the terminal window which appears, type "ipconfig" This should show you your IP address - write it down.
* With '''Windows 98''', click start, run, and type "winipcfg" to get information about your IP address.

This section _ought_ to be unnecessary now with recent versions of the FG server. If you have problems though, it won't hurt to follow through.

Now, all (!) that remains is to configure your router to forward UDP port 5000 to the IP address you've just found. This is not something that can be described in step-by-step detail, because each manufacturer's configuration interfaces differ greatly. Some tips are given here - if you get stuck, ask nicely on the [[FlightGear IRC channel]] for help (details on the flightgear website).

You should know how to log on to your router's configuration page, usually via a web browser. You are looking for settings pertaining to "port forwarding" "virtual server" "Forwarding Rules" or similar. When you have found the relevant settings, you need to add a rule that forwards port 5000 to the IP address you discovered earlier. If there is a choice given, ensure it is UDP ports that are forwarded. If there is no choice, you may assume that both TCP and UDP are being forwarded. Save your configuration, and most routers will probably then need to be rebooted to apply the changes.

Note: (for BSD users) If you are using a ADSL modem, you might have to put the port forward command into the ppp.conf file rather than firewall. This is because the firewall script will only run each time the machine is booted rather than the ppp line coming back online.

Finally, start FG using the command line given right at the start (if you're using the windows launcher you will find entry boxes for Multiplayer arguments - insert the relevant details there). You will end up with something like this;

fgfs --callsign=test --multiplay=in,10,192.168.0.2,5000 --multiplay=out,10,mpserver05.flightgear.org,5000 \
--airport=KSFO --runway=28R --aircraft=hunter

Choose your own callsign - this is currently limited to seven characters. Check [http://fgfs.i-net.hu/modules/fgtracker/ this page] to see whether your callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems!

Once you have started FG, you should, if others are flying, see messages in the terminal from which FG was started, similar to the following;

Initialising john51a using 'Aircraft/ufo/Models/ufo.xml'
FGMultiplayRxMgr::ProcessRxData - Add new player. IP: 10.0.0.36,
Call: john51a,model: Aircraft/ufo/Models/ufo.xml

You MUST give your local, behind-the-router IP address for MultiPlayer to work. Trust me on this one!

You should check that your firewall is not causing problems - either turn it off _temporarily_ or add an exception to allow incoming connections on port 5000.

If it's still just not working for you, ask nicely on the [[FlightGear IRC channel]] and someone should be able to assist.

=== Multiple connections per computer ===
It is possible to run multiple FlightGear instances on a single computer and connect them all to the multiplayer network. However, this requires some extras to keep in mind:
* both instances use the same out-port.
* one instance uses in port=5001, the other port 5002.
* and of course should both instances have unique callsigns.

== Multiplayer chat ==
{{Main article|Chat Menu}}

To chat with other pilots, go to the "Network" menu and select "Chat" or "Chat Menu" at the bottom of the menu. Note that the other pilots may not have their chat box open nor chat messages enabled, so they may not see your messages.

The shortcut for chatting is "_" (underscore) and it brings up a small window where you can type. By default, other people's messages are displayed at the top of Flightgear's window for a few seconds, but it will appear for a much longer time in the window at <tt>Network > Chat</tt>. So if you think you have missed anything, go check there.

'''NOTE:''' Multiplayer chat is not supported by FlightGear 0.9.10 or older.

== Coping with abusive behaviour ==
Should you become victim of abusive or annoying behaviour by any pilot you have option to ignore him or her. To activate the ignore function open the Multiplayer > Pilot list dialog and click the ignore button next to the pilot's call sign. As of FlightGear 2.0.0 this will prevent chat messages from the ignored pilot from appearing and in FlightGear 2.4.0 and later it will additionally prevent his aircraft from appearing.

== Multiplayer map ==
[[File:MP_Server.jpg|thumb|300px|[[MPMap]] screenshot]]
{{Main article|MPMap}}

There is a very nice online map which displays the location of online pilots at [http://mpmap01.flightgear.org mpmap01] and/or [http://mpmap02.flightgear.org mpmap02]. You will also find this useful to check that you are successfully connecting to the server.

== Servers ==
'''Please Note:''' The multiplayer servers are interconnected; you '''do not''' need to connect to a specific server in order to see other pilots who are on that server. For best performance, you should connect to the server that is geographically closest to you, has the lowest latency (ping time) or is the least busy.

{| class="prettytable" border="1px solid" cellspacing="0" cellpadding="2" style="border-collapse: collapse;"
! style="background:#efefef" |Server
! style="background:#efefef" |Location
! style="background:#efefef" |[http://mpserver15.flightgear.org Tracked]
! style="background:#efefef" |Maintainer
! style="background:#efefef" |[[IRC]] Name
! style="background:#efefef" |[http://flightgear.org/forums Forum] Name
! style="background:#efefef" |Comments
|-
|fg.noahbuscher.com
|US
|{{no}}
|Noah Buscher
|Noah
|Noah
|May be merged with main servers in the near future.
|-
|-
|mpserver01.flightgear.org
|Germany
|{{yes|[http://mpserver15.flightgear.org mpserver15]}}
|Oliver Schroeder
|os
|
|
|-
|mpserver02.flightgear.org
|Los Angeles, USA
|{{yes|[http://mpserver15.flightgear.org mpserver15]}}
|Lloyd Stevens
|ls4680
|ls4680
|
|-
|mpserver03.flightgear.org
|Germany
|{{yes|[http://mpserver15.flightgear.org mpserver15]}}
|Hergen
|
|
|
|-
|mpserver04.flightgear.org
|UK
|{{no}}
|Jon Stockill
|Nav
|JonS
|
|-
|mpserver05.flightgear.org
|Chicago, USA
|{{yes|[http://mpserver15.flightgear.org mpserver15]}}
|Brant
|IonCannon218
|
|
|-
|mpserver06.flightgear.org
|Berlin, Germany
|{{yes|[http://mpserver15.flightgear.org mpserver15]}}
|Sven Teichmann
|
|D-SAMI
|Unlimited traffic
|-
|mpserver07.flightgear.org
|Wisconsin, USA
|{{n/a}}
|Tom Betka
|TB
|
|Offline
|-
|mpserver08.flightgear.org
|Frankfurt am Main, Germany
|{{no}}
|Roland
|Quix0r
|Quix0r
|10 TByte traffic, mostly short pings
|-
|mpserver09.flightgear.org
|Köln, Germany
|{{n/a}}
|Daniel Vigano
|Fauchi95
|
|Offline
|-
|mpserver10.flightgear.org
|Montpellier, France
|{{yes|[http://mpserver15.flightgear.org mpserver15]}}
|Alexis Bory
|xiii
|xiii
|
|-
|mpserver11.flightgear.org
|Vilnius, Lithuania
|{{no}}
|Darius
|
|ffg
|
|-
|mpserver12.flightgear.org
|Amsterdam, the Netherlands
|{{yes|[http://mpserver12.flightgear.org mpserver12]}}
|Rob
|evilslut
|evilslut
|
|-
|mpserver13.flightgear.org
|Grenoble, France
|{{no}}
|Charles Ingels
|charles
|cbz-026
|
|-
|mpserver14.flightgear.org
|Zurich, Switzerland
|{{yes|[http://mpserver15.flightgear.org mpserver15]}}
|Yves Sablonier
|gral
|gral
|
|-
|mpserver15.flightgear.org
|North Point, Hong Kong
|{{n/a}}
|Hazuki Amamiya
|Hazuki
|Hazuki
|This is FGTracker, not a multiplayer server
|-
|mpserver16.flightgear.org
|Kansas City, Missouri, USA
|{{yes|[http://mpserver15.flightgear.org mpserver15]}}
|Rob Dosogne
|truthsolo
|truthsolo
|
|-
|mpserver17.flightgear.org
|Cluj, Romania
|{{n/a}}
|Marius
|tuxum
|tuxum
|Offline
|-
|mpserver18.flightgear.org
|Germany
|{{yes|[http://mpserver15.flightgear.org mpserver15]}}
|
|
|
|
|}
''Information as at 2014-01-04''

Use [http://mpserver16.flightgear.org/ this], [http://mpmap01.flightgear.org/mpstatus/ this] or [http://flightgear.mxchange.org/mpstatus/ this] link to check if the MP servers are online. As of FlightGear 2.10.0, the in-sim dialog only displays servers that are available.

Geographic locations of the servers are also available at [http://goo.gl/maps/jBwUd Google Maps].

If you are interested in hosting your own multiplayer server, you may want to check out [[Howto: Set up a multiplayer server]].

== Related content ==
* [[FlightGear Multiplayer Server]]
* [[Howto: Set up a multiplayer server]]
* [[Multiplayer protocol]]

[[Category:Multiplayer]]
[[Category:Howto|Multiplayer]]

[[de:Howto: Multiplayer]]
[[es:Howto: Multijugador]]
[[fr:Howto: Multijoueur]]
[[nl:Howto: Multiplayer]]
[[pl: Konfiguracja trybu multiplayer]]