Frequently asked questions: Difference between revisions

(import flightgear official faq)
 
(243 intermediate revisions by 53 users not shown)
Line 1: Line 1:
''' Feel free to make additions, changes, or corrections.'''
Thank you for your interest in [[FlightGear]]! This '''FAQ''' lists some of the most commonly asked questions. Please create a topic at {{forum link|text=our forum}} if you cannot find the answer on your problem(s).


== The FAQ ==
== Distribution ==
=== Where can I get the latest version of this FAQ? ===
=== Where can I get FlightGear? ===
The official download page is http://www.flightgear.org/download/. Precompiled binaries are available for Windows, and most Linux users will find that most distributions have a packaged version of FlightGear (the package name could be <tt>fgfs</tt> or <tt>flightgear</tt>.)


http://flightgear.org/Docs/FlightGear-FAQ.html
You can also download using torrents at https://flightgearjp.online/torrents - mainly Mac & Win, but also the large data file used when building from source.


=== Who do I contact if I have comments about this FAQ? ===
=== How do I install FlightGear on Linux? ===
Many distributions include FlightGear in their repositories. In addition, in the [https://www.flightgear.org/download/ Download Center] you will also find '''AppImage''', which will run on almost any modern distribution. If you can't find a packaged version for you, consider [[Building FlightGear - Linux|downloading and compiling from sources]].


First contact the author. If you get no response, send your comments to the FlightGear-Users mailing list.
=== Where can I find the latest development source code? ===
=== How old is this document? ===
The latest development code is available for everyone through our [[Flightgear and Git|Git repository]].
 
See the About This Document section at the end of the FAQ.


=== What other important documentation should I read? ===
=== Where do I get the scenery? What is available? ===
While the base package only comes with scenery for the San Francisco Bay area, you can currently fly just about anywhere in the world. Currently [[Terrasync]] is the best option: it downloads the latest scenery while flying. See its page for usage information.


Most FlightGear documentation is linked to from http://flightgear.org/Docs/. Definitely check out the FlightGear Installation and Getting Started document available from the aforementioned location.
However the latest scenery could be too demanding if you have a low end computer or not much RAM, so consider instead to [[Installing Scenery|manually install]] the old scenery from the "graphical interface" available at the [http://www.flightgear.org/download/scenery scenery download page].


Also see the FlightGear/docs-mini/ directory in the source distribution for various other helpful documents.
=== Where can I get additional planes? ===
The latest official [[aircraft]] can be downloaded and installed with a single click through the aircraft tab in the built-in launcher (see [[FlightGear Qt launcher]]).


== Distribution ==
Official FlightGear aircraft can be found at [http://www.flightgear.org/download/ Download central]. Other aircraft in development can be found in the [[FGAddon|official FGAddon aircraft repository]], and some other aircraft can be found in 3rd party [[FlightGear hangars]] (see [[:Howto:Install_aircraft]]).


=== Where can I get FlightGear? ===
=== Why are the aircraft at FlightGear.org out of date? ===
The [http://www.flightgear.org/download/ official aircraft downloads] are only updated at the time of a new release of FlightGear. This is done because aircraft that are currently in development are usually developed on development/unreleased versions of FlightGear. Those development versions have lots of features that are not supported by the (older) stable release. Would we update the aircraft downloads more often, most aircraft wouldn't work on the stable release of FlightGear.


The official download page is http://flightgear.org/Downloads/. Source code is our primary form of distribution, but precompiled binaries are available for Windows and SGI IRIX.
=== How current is the data in FlightGear compared to the real world? ===
We use the same navaid and airport dataset that X-Plane uses. The current dataset can be found in the <tt>[[$FG ROOT]]/Navaids/</tt> and <tt>[[$FG ROOT]]/Airports/</tt> directories. The maintainer can be found at [http://data.x-plane.com/ X-Plane Airport & Navigation Data].


Alternatively, FlightGear is packaged for Linux by SuSE, Debian (sid), and Mandrake (Cooker) and can be directly installed through those distributions.
=== Why don't you charge money for this? ===
FlightGear can be downloaded for free from many locations including the FlightGear website, but can also be bought on a CD. Although we offer that service (see the website), we encourage other groups to redistribute it for their users, especially within an operating system distribution which makes installation even faster and easier for new users.


=== What is the password for the FTP server? ===
Occasionally you may see FlightGear for sale on auction sites or commercial websites under some other name. This can be done quite legitimately as long as the terms of the license are upheld and might be worth the cost if some value-added features such as additional scenery, aircraft or after-sale support are included. Unfortunately, most cases seen to date appear to be just someone trying to make money selling something that is free and providing no real added value.


The FTP server uses standard anonymous login procedures. Login with the username "anonymous" and use your email address as the password. Most FTP clients and web browsers will do this automatically for you.
=== How can I get started with FlightGear? ===
There's no better place than the page [[New to FlightGear]]!


=== Why won't the FTP server let me in with the right login info? ===
== Compiling ==
=== How do I compile FlightGear from source? ===
See [[Building FlightGear]]. There are explanations to compile in Windows, Linux and even scripts to automatically download and compile the whole thing.


This generally means that the server is at it's capacity. You should receive a message saying such, but your FTP client may be hiding it from you. Your options are to keep trying until a slot opens up or try connecting to one of our FTP mirrors listed at http://flightgear.org/mirrors.html.
=== Why won't FlightGear compile? ===
Well, that depends. First make sure you are using the appropriate versions of FlightGear, [[SimGear]], plib, zlib. If any of the packages are out of sync with the others, compilation may fail. See also [[Building FlightGear]]


=== Where can I find the latest development source code? ===
The [http://www.flightgear.org/download/ FlightGear Downloads page] should tell you what versions you need if you are trying to compile the latest stable release. If you are using a development snapshot, make sure all three packages are up-to-date.


The latest development code is available for everyone through our CVS repository. See http://flightgear.org/cvsResources/ for details.
Also ensure that you have some implementation of OpenGL with glut support with the appropriate header files. Linux users with nVidia cards should make sure you have the latest drivers from nVidia. Other Linux users make sure you have Mesa3D (http://mesa3d.org/) and your X server installed correctly.  


Otherwise, you can get relatively up-to-date snapshots of the development tree at ftp://flightgear.sourceforge.net/pub/flightgear/Devel/Snapshots/.
If your problems persist, ask in the {{forum link|text=FlightGear forum}}, on [[IRC]] or subscribe to our FlightGear-Users [[mailing list]] and let us know what problem you're having.


=== What is SimGear, and why do I need it? ===
=== What is SimGear, and why do I need it? ===
[[SimGear]] is a library of supporting code. SimGear is only needed if you plan on compiling FlightGear — it is not needed to run precompiled binaries. For more information see http://www.simgear.org/. Note: When compiling FlightGear it is very important to have the matching version of SimGear.


SimGear is a library of supporting code. SimGear is only needed if you plan on compiling FlightGear -- it is not needed to run precompiled binaries. For more information see http://www.simgear.org/.
== Configuring and running ==
=== How do I start FlightGear? ===
The easiest way is using [[FlightGear Qt launcher|Qt Launcher]]. Otherwise, you can run it from the command line, with the [[Command line options|proper options]].


=== Where can I fly and where do I get the scenery? ===
=== How do I install new scenery? ===
If you really don't want to/can't use [[Terrasync]], the scenery archive files (ie. w100n30.tar.gz) should be decompressed into the Scenery/Terrain directory in your [[$FG_ROOT]]. More at [[Howto: Install scenery]].


While the base package only comes with scenery for the San Francisco Bay area, you can currently fly just about anywhere in the world. See the "Additional Scenery" section of http://flightgear.org/Downloads/ for more information or go directly to our graphical downloader at http://flightgear.org/Downloads/world-scenery.html.
=== How do I setup my joystick(s)? ===
FlightGear supports wonderfully many joysticks/yokes out of the box. However if you're having problems see [[Input device]].


Also visit our "Places to Fly" section of the website (http://flightgear.org/Places/) for some help navigating to some awesome locations.
=== What is fgfsrc? What format should my personal .fgfsrc file be in? ===
[[Fgfsrc|.fgfsrc]] is a file that can contain a list of [[Command line options]] with one option per line. The file is not an XML file. Note that also Windows installations have this file.


=== Where can I get different 3D models for my plane? ===
=== How do I get to see options, help etc? ===
You probably can not see the main menu.  To make it show press {{key press|F10}}.


While we are working toward building our own 3D models, we have been given permission by several people to convert their models (which where originally intended for use with Microsoft Flight Simulator) to use with FlightGear.
== Flying ==
 
=== Why won't my engine(s) start? ===
=== How current is the data in FlightGear compared to the real world? ===
Aircraft vary in their starting procedure. Some may have an auto-start sequence menu entry or instructions in the aircraft help menu (press {{key press|?}} key) and/or at [[Aircraft|the aircraft's wiki]]. Please consider reading the [[FlightGear Manual]], or see this [[New to FlightGear#Starting the engine|quick small guide]].
 
We use the same navaid and airport dataset that X-Plane uses. The current dataset can be found in the $FGROOT/Navaids/ and $FGROOT/Airports/ directories. If you have updates or corrections to the dataset, see http://flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html for instructions on contacting the database maintainer.


=== Where is the moving map? ===
=== Where is the moving map? ===
In game, you can go into the menu "Equipment > [[Map]]", but there won't be any aeronautical chart. A popular moving map display is available under a separate project called [[Atlas]]. Also, [[MPmap]] is an online map for multiplayer.


A popular moving map display is avaliable under a separate project called Atlas. See http://atlas.sf.net/.
If you like an alternative to Atlas with updated graphics and mapping provided by the OpenStreetMap project, then check out Flightgear Mapping [[Phi#Map|Phi]] or [[JMapView]].


=== Why don't you charge money for this? ===
=== Where can I learn about instrument flying and navigation? ===
There is a nice article, [[Understanding navigation]], and a lot is very well explained into the [[FlightGear Manual]]. Other resources are:
* http://www.navfltsm.addr.com/ is a very good site for learning techniques for navigation.
* [http://www.av8n.com/how/ See How It Flies] a very nice book by John S. Denker, freely accessible online


We could do that, since the initial download is about 25 megabytes. Especially for people who have to pay per-minute charges for internet access, buying a CD is a convenient and possibly cheaper option. Although we offer that service (see the website), we encourage other groups to redistribute it for their users, especially within an operating system distribution which makes installation even faster and easier for new users.
=== What is the difference between Aileron and Rudder? ===
There is a bit of info on aileron vs. rudder in the very same book...


== Compiling ==
=== Is there support for multi-player flying? ===
Yes, sure we have it! See [[Howto: Multiplayer]]. Both the Windows and *nix versions of FlightGear are capable of multi-player flying on FlightGear servers. Also voice communication is supported, with [[FGCom]].


=== Why won't FlightGear compile? ===
A map showing players aircraft online in real time is available as [[MPmap]].


Well, that depends. First make sure you are using the appropriate versions of FlightGear, SimGear, plib, zlib. If any of the packages are out of sync with the others, compilation may fail.
=== Where are the best places to fly in FlightGear? ===
FlightGear scenery covers the whole world, but thanks to the FlightGear user community, certain airports and areas are more detailed than others. As a general idea:
* There are a lot of high-quality scenery models around Paris, France.
* EHAM Amsterdam Schiphol, EGKK London Gatwick and LFPG Paris Charles de Gaulle are some of the highest quality airports.
* LOWI Innsbruck is both developed in scenery and airport.
* TNCM St. Maarten is a popular destination, and the surrounding islands (Anguilla, St. Eustatius, Saba, St. Barthélemy, St. Kitts, and Nevis) are all well-modeled.


The FlightGear Downloads page (http://flightgear.org/Downloads/) should tell you what versions you need if you are trying to compile the latest stable release. If you are using a development snapshot, make sure all three packages are up-to-date.
Furthermore, see [[Suggested Flights]], [[Suggested Airports]] and [[Suggested custom scenery]].


Also ensure that you have some implementation of OpenGL with glut support with the appropriate header files. Linux users with nVidia cards should make sure you have the latest drivers from nVidia. Other Linux users make sure you have Mesa3D (http://mesa3d.org/) and your X server installed correctly. Windows users see http://www.x-plane.com/SYSREQ/v5ibm.html, and Mac users see http://www.x-plane.com/SYSREQ/v5mac.html.
=== Where can I find airport info and aeronautical charts online? ===
See [[Getting aeronautical charts]].


If your problems persist, subscribe to our FlightGear-Users mailing list and let us know what problem you're having. See http://flightgear.org/mail.html for help with this.
=== Is there support for any military scenarios like dog fighting or bomb dropping? ===
Yes. Check out the [[Bombable]] add on and the {{forum link|t=5742|title=Bombable}}. There are also third-party bombing scenarios for the [[A-10]] and other aircraft with armament, like the [[North American OV-10A Bronco]], [[General Dynamics F-16]] and [[F-117 Nighthawk]].


=== I'm using RedHat 7, and ...? ===
=== Flying issues ===  


Update your gcc packages. See http://redhat.com/errata/ to fix it and http://www.gnu.org/software/gcc/gcc-2.96.html for an explanation why.
==== Why are my controls returning to a particular position? ====
There are several possibilities that can lead to this:
* If your aircraft's [[autopilot]] is enabled, it will take over (some of) your controls. Switch the autopilot off to regain control.
* Some laptops have an onboard gravity sensor that might be detected as a [[joystick]]. See how to solve that at [[Troubleshooting input devices#Controls returning to a particular position|Troubleshooting input devices]].


== Configuring ==
==== Why does my cockpit disappear when looking around? ====
Probably you're using a 2D-panel version of an aircraft. Be sure to pick the one with a 3D cockpit. Most of the aircraft now have it!


=== How do I install new scenery? ===
==== There are lots of other aircraft flying around ====
FlightGear has a so-called AI Traffic system. This system generates other, computer-controlled aircraft based on real flight plans to make the FlightGear world look more alive. To disable artificial traffic, go to menu "AI" > "Traffic and Scenario Settings" and uncheck the "Enable AI traffic" option.


The scenery archive files (ie. w100n30.tar.gz) should be untarred into the Scenery/Terrain directory in your $FG_ROOT.
If on the contrary you can't see any aircraft other than yours, consider [[AI Traffic|contributing to add traffic]] to your favourite place!


=== How do I setup my joystick(s)? ===
==== I can't make this plane fly straight, it keeps turning left! ====
Yes, FlightGear is a real flight simulator and simulates that too. Exactly, that's how real propeller aircraft behave. See [[Understanding Propeller Torque and P-Factor]].


FlightGear should come with a helpful program called `fgjs` that can help configure your joystick. Run `fgjs` and then copy the dot file it created into your home directory or add its contents to your existing rc file.
Also, doublecheck your weight distribution. Try adding a 180lbs copilot and see if the turn goes away.


Also, see the README.Joystick file located in the FlightGear/docs-mini/ directory of the source distribution. This document is mirrored at http://rockfish.net/fg/README.Joystick.
== Contributing ==
For anyone who's willing to contribute, we have dedicated to you the [[Portal:Developer|Developer portal]] and a [[Volunteer]] page that explains all the nice things you can do.


=== What format should my personal .fgfsrc file be in? ===
=== What language is FlightGear written in? ===
Mostly C++ with some supporting C code that's primarily contained within SimGear. For more details on the used languages:
* [https://www.openhub.net/p/flightgear/analyses/latest/languages_summary FlightGear programm]
* [https://www.openhub.net/p/simgear/analyses/latest/languages_summary SimGear]
* [https://www.openhub.net/p/flightgeardata/analyses/latest/languages_summary FlightGear data] (aircraft, sounds etc.)


Your .fgfsrc file should simply be a list of command-line options with one option per line. The file is not an XML file.
As you seem to be interested in core development, you should really check out [[Howto:Start core development]].


If you would rather use an XML configuration file, you can add something like the following in your .fgfsrc
=== How do I design a flight dynamics model for a new aircraft? ===
FlightGear supports various [[flight dynamics model]]s (FDMs), but just two of them are commonly used:
* [[JSBSim]]: see http://jsbsim.sf.net/.
* [[YASim]]: if you want a simpler FDM to work with, try your hand at YASim. For a guide on creating YASim aircraft, look in the FlightGear base package for <tt>[[$FG_ROOT]]/Docs/README.yasim</tt>.


<code> --config=/path/to/my/config.xml</code>
See the [[Portal:Developer/Aircraft|Aircraft development portal]].


Almost every option corresponds to a property, so you can choose to use whichever method best suits your needs.
=== How do I design or modify a 2D panel? ===
See the <tt>[[$FG_ROOT]]/Docs/README.xmlpanel</tt> file on your computer.


== Running ==
=== How do I place objects, like buildings, into FlightGear? ===
The most up to date solution is using the UFO. See [[Howto:Place 3D objects with the UFO]]. The UFO will give you the interface to choose one of the available objects and place it to some grade of precision into FG world, and then export that data to be uploaded to the official scenery, or for personal use. For more, see the [[Portal:Developer/Scenery|Scenery development portal]].


=== Why do I get an error loading libopenal.so.0? ===
=== Where can I learn 3D programming and how do I get involved? ===
If you'd like to create a 3D cockpit for FlightGear, or to create buildings, external aircraft models, etc., your help is ''desperately'' needed. Try to go easy on the triangles, so that your work will be enjoyed by as many people as possible. The most commonly used tools here are [[Blender]], [[AC3D]], [[Gimp]].


With the default installation, libopenal.so.0 is installed into /usr/local/lib. You need to ensure that that path is listed in /etc/ld.so.conf, then run `ldconfig`as root.
If, on the other hand, you really want to get your hands dirty with C++ coding, you'll have to buy a good [[OpenGL]] book eventually. However, FlightGear uses [[OSG]], a high performance 3D graphics toolkit. To get started with 3D C++ coding, you can take a look at the OSG documentation and learn only as much OpenGL as you need, when you need it.


=== Why do I get "ssgInit called without a valid OpenGL context"? ===
=== How do I add an airport? ===
 
This process includes creating the airport layout in [[WorldEditor]], testing it (you might want to generate part of the scenery, but this is not mandatory) and then, if your data sources are GPL compatible, use [[WorldEditor]] to upload it to the gateway. The airport will be available in the next full rebuild of the scenery, unless you want to generate your own scenery. More at [[Howto:Make an airport]].
In short, your GL libraries are broken. So far only Red Hat 7.x users have experienced this (see http://www.redhat.com/bugzilla/show_bug.cgi?id=18867). The only solutions are possibly complicated ones: you can either change distributions (most of us prefer Debian) or upgrade/downgrade your Mesa libs.


Why do some other GL applications work though? Well, Steve Baker (Mr. PLIB) has explained this on the plib-users list (http://www.geocrawler.com/lists/3/SourceForge/1867/0/6470648/).
=== Can I generate my own scenery? ===
Yes, though it can be a difficult task. FlightGear's scenery generation is handled by a sister project, [[TerraGear]]. The good news, though, is that once you have set everything up it's quite easy (although might be time consuming), and above all that you can easily share it.


=== What happened to the panel, keyboard, etc? ===
== Problems ==
=== X doesn't work / is broken / is wrong / won't run ===
FlightGear is a very complex program. If you need help in general usage of the game you'll find it at the [[Portal:User|User portal]] and on the {{forum link|text=FlightGear forum}}.


The problem is almost certainly that your base package is out of sync with FlightGear. Many configurable parts of FlightGear are defined in XML files contained in the base package.
If your problem is instead software crashes, you're getting errors, etc..., please consider following the indications in [[Troubleshooting problems]].


=== Why doesn't audio work properly under Irix? ===
Some of the most common issues are however listed below. If you can't solve the problem on your own and need the help of someone, please remember that we're ''all'' here for fun, developers included, and that any help ''is'' an act of generosity. So try to be nice, even if the problem is frustrating you.


FlightGear (as of June 2001) uses the Portable Libraries (PLIB) for playing audio. The audio queue implementation of PLIB is far from optimal (in fact it's just wrong). This seems to work on other platforms quite well, but Irix expects things to be programmed properly.
=== Unable to execute file: bin/Win32/fgrun.exe during installation ===
{{Out of date|category=section}}
Your system is missing the MSVC runtime libraries required by FlightGear.
Download and install the following vcredist_x86.exe:
* MSVC9 for FG2.4.0 (and earlier):  http://www.microsoft.com/download/en/details.aspx?id=26368
* MSVC10 for FG2.6.0 (and later): http://www.microsoft.com/download/en/details.aspx?id=5555


There has been discussion about using OpenAL (http://www.openal.org/) for the next release of both PLIB and FlightGear. Tests show that the OpenAL audio implementation does the job right, meaning that these audio problems should be gone by then. In the mean time it is best to disable audio on Irix completely (by adding --disable-sound either on the command line or to your $HOME/.fgfsrc file).
=== What happened to the panel, keyboard, etc? ===
The problem is almost certainly that your base package is out of sync with FlightGear. Many configurable parts of FlightGear are defined in [[XML]] files contained in the base package.


=== Why is FlightGear so slow? ===
=== Why is FlightGear so slow? ===
If it seems just slow, see if you can fiddle with graphics settings here: [[Howto: Improve Framerates]].


FlightGear supports hardware acceleration, but it seems not to be activated. Make sure you have OpenGL libraries installed and configured properly and make sure you have the latest drivers for your video card.
If things are ''pathologically'' slow (i.e. ~1 frame per second), maybe 3D hardware acceleration is not activated. Make sure you have OpenGL libraries installed and [[Graphics drivers configuration|configured properly]] and make sure you have the latest drivers for your video card. Also, be ready because some cards are [[Problematic Video Cards|not well supported]].


Linux users: If you are an nVidia user, follow their directions on getting your card working. For most other users, make sure Mesa is installed property and ensure that you have the appropriate kernel device drivers for your card. Most people (and distributions) use modules for their video card device drivers; run `lsmod` as root to see what modules are loaded. You should also make sure that you are loading the appropriate modules in your XF86Config and that your video device section is correct. Now try running an OpenGL application (other than FlightGear) to see how it performs. You can try the gears demo from Mesa or something like Quake3.
=== How do I see the Frame Rate? ===
On the in-sim [[menu]] select "View" > "View Options", then check the box that says "Show frame rate".


=== Why is my SGI machine so slow? ===
=== How do I toggle 2D cockpit settings? ===
To show/hide the 2D panel, use the key combination {{Key press|Shift|P}}. To show/hide the HUD, press {{Key press|Shift|H}}. You can also enable the alternative HUD by pressing {{Key press|Shift|I}} (press {{Key press|I}} to return to the default one). Use the {{Key press|Shift|H}} key to adjust the brightness of the HUD.


First of all, one of the most common mistakes on SGI hardware is to forget to specify --fog-fastest. On most SGI machines the EXP2 shading model isn't hardware supported resulting in frame rates below 1 frame per second (fps).
=== Stuck upside down after "crash"? ===
In his infinite wisdom the FlightGear Grand Master decided that planes were too valuable to allow them to be destroyed by novice pilots who seemed to crash a lot. The fact that nobody has bothered to model crashes may have something to do with it too. :-)


FlightGear makes extensive use of the OpenGL z-buffer feature,which on most older SGI hardware is only supported in software. This means that the CPU has to do all the z-buffer calculations in addition to the other tasks FlightGear involves (flight dynamics, scenery tracking, pushing commands into the graphics queue, etc). The following features are software rendered on low-end SGI machines (like Indy and Indigo):
The result of this as you have noticed is that with a little practice an ingenuity you can trim the ship to fly inverted along the ground. The quick answer is to reset the sim, via the <tt>File > Reset</tt> menu. This will place your aircraft back at its starting location.


* stencil and accumulation buffer
For the stubborn people out there: The trick to learn is to roll back to normal (non inverted) do this by nursing the elevator to get to about 500 feet or so and use the ailerons to snap roll 180*. This is all good avionics except for the plane not destroying itself. Remember the controls work in reverse when you are inverted and keep that airspeed up!!!
* depth queuing and depth buffering
* fogging, lighting, clipping and transforms
* texturing


This means that running FlightGear with the following options may not even get the desired result:
=== Why won't the latest versions of some aircraft work in my (older) version of FlightGear? ===
Often new aircraft development keeps pace with the latest FlightGear code development. New or newly modified aircraft may rely on files (such as new instrument files) or features, only available with newer versions of FlightGear. If you are stuck with an older version of FlightGear, you can try downloading an earlier version of the aircraft from the corresponding [[FlightGear_hangars#Official_hangars|official FlightGear aircraft hangar]].


<code> ./runfgfs --fog-disable --shading-flat --disable-skyblend --disable-textures --disable-clouds --disable-sound --disable-panel --enable-hud --disable-anti-alias-hud </code>
=== When I start FlightGear I see an error mentioning "SQLite"What do I do? ===
Since FlightGear v2.10 (released in February 2013), the [[navdata cache]] was introduced to improve the FlightGear start times.  This cache is a SQLite database that is a little fragile at times.  If the database is corrupted FlightGear will refuse to start.


I could even imagine that adding --enable-wireframe doesn't work on these machines (I would be happy to be proven wrong though).
To fix this you simply need to delete the <code>[[$FG_HOME]]/navdata.cache</code> file.  The first time FlightGear starts after deletion of the file the navdata cache will be rebuild.  As this process is time consuming, FlightGear will take more time to start.


On a machine like O2 the following options give an acceptable result:
Some will resort to delete the entire <code>$FG_HOME</code> directory or even reinstall FlightGear.  However neither is needed and may cause you to lose any custom preferences you have set up.
<code>./runfgfs --fog-fastest --disable-sound</code>


Since I don't have access to other SGI hardware I can't tell which options would be appropriate for your situation.
A further SQLite related problem indicator is the error message


=== How do I see the frame rate? ===
<tt>
  Sqlite error:attempt to write a readonly database (8) while running:
      INSERT OR REPLACE INTO stat_cache (path, stamp) VALUES (?,?)
</tt>


There are two ways. One way is to hide the panel without the HUD showing. To hide the panel, use Shift+P; To make the HUD disappear, use H. The second way is to use the alternative HUD by Shift+I (Use I to switch back).
In this case a previously started FlightGear instance might still be running and locking the navdata.cache file. Check for a running fgfs process and terminate it.
=== Stuck upside down after "crash"? ===


In his infinite wisdom the FlightGear Grand Master decided that planes were to valuable to allow them to be destroyed by novice pilots who seemed to crash a lot. The fact that nobody has bothered to model crashes may have something to do with it too. :-)
=== My aircraft has grey windows? ===
The problem of opaque grey/gray windows that cannot be seen through is most often due to a version mismatch between the FlightGear program and the aircraft.  Or it could be due to a window effect that is not compatible with the [[Project Rembrandt|Rembrandt]] or [[ALS]] rendering systems. The technical cause is that the renderer and declared effect for the window are incompatible. Some solutions include:


The result of this as you have noticed is that with a little practice an ingenuity you can trim the ship to fly inverted along the ground.
* If you are using a stable FlightGear release, please download the aircraft from the [[FlightGear_hangars#Official_hangars|official FlightGear hangars]] matching your FlightGear version.
* If you are using a cutting-edge [[FlightGear Build Server|nightly build]] or a [[Building FlightGear|version controlled copy of FlightGear]], or you wish to use a cutting-edge aircraft, please see [[FGAddon#Obtaining aircraft]].
* If you are using an aircraft from one of the [[FlightGear_hangars#Unofficial_sites|3rd party hangars]], it is best to contact the original aircraft author or the person in charge of the 3rd party hangar.
* If you are using [[Project Rembrandt|Rembrandt]], try turning this rendering system off.  Aircraft that use <code>model-default.eff</code> for the windows (at the simple expense of doing nothing) rather than <code>model-transparent.eff</code>, <code>model-combined-transparent.eff</code> or <code>glass.eff</code> (which instruct Rembrandt to not use deferred rendering for the glass) will have grey windows when using Rembrandt.


The quick answer is to hit Ctrl+U (with the default key bindings) to warp the plane up 1000ft.
=== My screen becomes completely red right after starting FlightGear ===
The red screen is the visualization of the "Redout" effect. If it occurs right after starting FlightGear, it might be caused by a problem with scenery loading. FlightGear loads scenery on the fly and if scenery cannot be loaded, eg. due to network problems, there might be no ground for the aircraft to be located on. As a result, the aircraft falls through the non existing ground starting to tumble. This in turn causes the readout effect. For verifying the problem you should start your flight in KSFO, whose scenery is already included in the base package.


For the stubborn people out there: The trick to learn is to roll back to normal (non inverted) do this by nursing the elevator to get to about 500 feet or so and use the ailerons to snap roll 180*. This is all good avionics except for the plane not destroying itself. Remember the controls work in reverse when you are inverted and keep that airspeed up!!!
== The FAQ ==
=== Who do I contact if I have comments about this FAQ? ===
Add your comment to this FAQ's [[Talk:Frequently asked questions|discussion page]].


=== Why does FlightGear die on startup saying "time zone reading failed"? ===
=== How old is this document? ===
Check its <span class="plainlinks">[{{fullurl:{{PAGENAME}}|action=history}} history]</span>.


This is probably caused by a line-ending problem in the timezone files. Win32 users can resolve the problem by downloading a DOS to UNIX conversion utility available at http://www.nottingham.ac.uk/~eazdluf/d2u.zip. Run as `d2u *.tab` from within the timezone directory to fix your timezone files.
=== What other important documentation should I read? ===
* [[FlightGear manual]]
* [[New to FlightGear]]
* Also see the FlightGear/docs-mini/ directory in the source distribution for various other helpful documents.


== Hacking ==
== Contributing ==


=== What language is FlightGear written in? ===
=== Content Protection ===
{{See also|FlightGear Plugins}} DRM
{{Cleanup}}


Mostly C++ with some supporting C code that's primary contained within SimGear.
Every once in a while, the question comes up if it is legal to provide closed source plug-in to FlightGear (more exact OSG file reader plug-in). The only need to keep code close is the prevention of reverse engineering. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/27996073/
  |title  =  <nowiki> [Flightgear-devel] Content protection for modders? </nowiki>
  |author =  <nowiki> Paul Guhl </nowiki>
  |date  =  Aug 25th, 2011
  |added  =  Aug 25th, 2011
  |script_version = 0.37
  }}</ref><ref>Soitanen (Aug 28th, 2014). {{forum link|title=Re: Encrypted aircraft dynamics|p=217378}}</ref><ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/34559749/
  |title  =  <nowiki> [Flightgear-devel] External FDM to protect propriety data in a GPL
eviirenment </nowiki>
  |author =  <nowiki> Alan Teeder </nowiki>
  |date  =  Oct 21st, 2015
  |added  =  Oct 21st, 2015
  |script_version = 0.37
  }}</ref>


=== How do I design a flight dynamics model for a new aircraft? ===


To define an aircraft for FlightGear's primary FDM (JSBSIM), see http://jsbsim.sf.net/.
FlightGear in its current form is a product of numerous people working voluntarily on a joint effort to create an open and extensible flight simulator platform. Your very idea of introducing DRM, is against all principles of open source in general.


If you want a simpler FDM to work with, try your hand at YASim, an alternative FDM. For an guide on creating a YASim aircraft, look in the FlightGear base package for Aircraft-yasim/README.yasim.


=== How do I import planes from Microsoft Flight Simulator? ===
You're free to create a non-GPL plane for FG - that's data from the perspective of the sim and doesn't trigger the license. You can sell that without ever allowing to re-distribute the source code. You're required to stay clear of a few things (you can't use Generic instruments, Nasal libs,...) but that should be doable. You can charge license fees for such a plane, and nobody may legally re-distribute it.<ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/35074186/
  |title  = <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author = <nowiki> Thorsten Renk </nowiki>
  |date  = May 9th, 2016
  |added  = May 9th, 2016
  |script_version = 0.37
  }}</ref>


You can import the 3D model and textures, but the flight dynamics (the .AIR file) must be completely redone for FlightGear.
the data is parsed from the XML into dynamic look up tables (IE. STL).  The only resources used beyond that needed to make the FDM function is the overhead of pulling the data out of the XML into memory.  That would have to happen no matter what form the data was in.
Although there may be better ways to store the data than XML if you are unconcerned about human interaction with the data.   I think that making the data human readable/editable is the main point of using XML.  It may be overly verbose but it works and there are standard libraries for reading/parsing XML files so this makes using it for data input fairly simple.  This benefits both FlightGear and JSBSim in terms of limiting the complexity of handling configuration data.  In addition there are a limited number of standardied formats for this type of thing such as JSON and all of those that are human readable/editable have many of the same issues as XML.
Full function FDMs are complex and understanding the XML used to configure a complex FDM is a very minor issue and anyone who actually understands a full function FDM will have very few issues with the XML part of this.<ref>hvengel (Aug 28th, 2014). {{forum link|title=Re: Encrypted aircraft dynamics|p=217408}}</ref>


If you wish to import a model made with gmax, you will need to convert it to .MDL format using Microsoft's MakeMDL SDK which is available at http://zone.msn.com/flightsim/FS02DevDeskSDK08.asp.


=== How do I import BGL scenery from Microsoft Flight Simulator? ===
FG itself is OpenSource, so whatever protection scheme we may code in, anyone is free to remove (and that's quite legal). It'd be a no-brainer to generate a no-copyright-protection version of FG and distribute it on which your content just runs without the key (or whatever). Given that people usually succeed in cracking DRM schemes in the absence of an open source code, trying to do this with the source code open for anyone seems just a waste of time. Second, whatever format OSG reads, before it arrives at the renderer, it's bound to be an array of vertices. The renderer needs this, there's no decryption at the GLSL stage. So chances are that since we run on *Open*GL, again anyone who really wants can write out an unencrypted format.<ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/35074186/
  |title  = <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author = <nowiki> Thorsten Renk </nowiki>
  |date  = May 9th, 2016
  |added  = May 9th, 2016
  |script_version = 0.37
  }}</ref>


See http://chiangt.virtualave.net/BGL/bgl_index.html.
as FlightGear is open source, it is incredibly simple to add some code to access the 3D scene graph and extract the full aircraft model (scripts excluded, though they could be reverse engineered). The information is just sitting there, fully visible, and ready to be picked off the OSG branch like a big juicy peach. I could probably write this code in half a day, but converting into AC3D format, PNG textures, etc. to recreate a new copy of the aircraft would take a little longer. If FlightGear was closed source, it would be much harder to write OSG extractor code, but nevertheless still doable.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35076297/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Edward d'Auvergne </nowiki>
  |date  =  May 10th, 2016
  |added  =  May 10th, 2016
  |script_version = 0.39
  }}</ref>


=== How do I design or modify a panel? ===


See the README.xmlpanel file located in the FlightGear/docs-mini/ directory of the source distribution. This document is mirrored at http://rockfish.net/fg/README.xmlpanel.
We have support for catalogs and external hangars for precisely this reason. We obviously want to encourage GPL aircraft, but not every aircraft developer wishes, or is able to, release their work under the GPL. FlightGear both respects and supports that option. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35076199/
  |title  =  <nowiki> Re: [Flightgear-devel] botom line: if i don't my aircraft to be
subject to GPL FGAddon clauses </nowiki>
  |author =  <nowiki> Stuart Buchanan </nowiki>
  |date  =  May 10th, 2016
  |added  =  May 10th, 2016
  |script_version = 0.39
  }}</ref>


=== How do I place objects, like buildings, into FlightGear? ===
You could certainly run the FDM model externally and use one of the many Network I/O options in FlightGear to pass data back and forth. Quite a few research projects have done this in the past to use FlightGear as a visualiation tool. By extension you could do the same for scripting - have the scripting run externally and interact with FlightGear via one of these protocols.<ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/35076187/
  |title  = <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Stuart Buchanan </nowiki>
  |date  = May 10th, 2016
  |added  = May 10th, 2016
  |script_version = 0.39
  }}</ref>


First, ensure that you have v0.7.7 or later, the scenery files where you plan to place the object, the actual model, and the longitude and latitude where you plan to place the object.


Now get the altitude for your point. If you don't want to calculate this yourself, start FlightGear at your location and take note of the altitude. Here's an example command:
if you actually try to charge 100$ for a FG plane, you won't find too many customers... because FG is mainly popular in the OpenSource community. If you make it too cumbersome with DRM schemes, maybe someone will try to circumvent it just as a matter of principle (people do this for sport...) - but across multiple platforms, it's actually not easy to make this not an annoyance for the user.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35074186/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Thorsten Renk </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>


fgfs --lat=45.50 --lon=-75.73 2>&1 | tee fgfs.log
The thing to keep in mind is that no matter what your source format is (dll, encrypted+signed, binary, etc.), ultimately your model mesh and textures and logical structure are read into internal OSG class structures. Once that has process has completed so the model can be rendered on screen, a person could call the appropriate write*File() function to save out your model's subtree into any of the supported formats. The only thing that is needed is access to the FlightGear source code to insert the function call in a strategic location. Ultimately, you can't completely protect your content work if you don't also completely control the situation at the application source code level. And this is a classic copy protection hacking strategy, insert the magic in the code after the distribution format has been authenticated/loaded/decoded and then write it out in a 'decrypted' format. People do it all the time, even with proprietary code. The value of the target usually determines how hard they are willing to work to steal it.<ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/35074534/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author = <nowiki> Curtis Olson </nowiki>  
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.38
  }}</ref>


The altitude is probably in feet, so divide the starting altitude by 3.28.


Search the output log file for the first occurrence of the string "Loading tile" and take note of the filename. In the above example, the output line looks like:
Adding support for DRM to FlightGear is not going to happen - Nasal scripts are provided in plain text format by default (similar to JavaScript), while obfuscation is of course possible - it doesn't make any sense in the context of FlightGear as an open source project.


Loading tile /usr/local/Scenery/w080n40/w076n45/1712601
Also, scripts can be easily shared and run by users just by exchanging or copying them.


Copy a 3D model in a format that Plib understands to the same directory as the tile file. Edit the text file in that directory consisting of the tile name with the extension ".stg". The file will already exist if there is an airport on the tile; otherwise, you can create it from scratch. In our example, the filename is:
Even if you were to dump intermediate Nasal bytecode to an object file and execute this using the Nasal VM, there would be no way of enforcing DRM.


<code>/usr/local/Scenery/w080n40/w076n45/1712601.stg</code>
Of course, FlightGear being open source, you could also just add support for DSOs/plugins to a fork of FlightGear and base all your work on this fork - on the other hand, your modifications would still need to be made available.


At the end of the file, add a new entry for your object, consisting of the word "OBJECT_STATIC" followed by the model name, the longitude in degrees, the latitude in degrees, the altitude in meters, and the heading in degrees. In our example the line looks like:
there's is a way to make legal closed-source add-ons: You can write all your "secret" c++ as an external application, and let that communicate with FlightGear via sockets. This should work reasonably well. But I don't expect that you'll get many customers. First of all, at least on Linux, nobody is keen to run binary blobs, which could easily wipe out your home directory while you are toying around in FlightGear. And then, there's so much Free aircraft development going on, with a lot of momentum, that you'll probably always be behind. And those developers have close ties to the (or are) FlightGear coders, so they have the advantage that they can change the FlightGear code to their liking, at any time. They can change the interface at will, and you have to catch up ... and deal with customer complaints, who suddenly sit on a broken binary blob that doesn't work with the last FlightGear release. And finally, this socket approach works only via property system, and that's open for inspection to anyone (apart from the recently added semi-secret vector property garbage).


OBJECT_STATIC Towerax.ac -75.73 45.40 60 0
FlightGear has no provision to load aircraft from shared libraries. You can distribute your aircraft under a proprietary license, like Vitos does, but not as a shared library. It would take a lot of work to change FlightGear so it can load aircraft from shared libraries. Who would do that work and why would anyone do that when their time could be spent improving free software? And why would the core developers of FlightGear accept such a "contribution"?<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35073736/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what  legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Ludovic Brenta </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>


Save the changes to the .stg file, restart FlightGear, and enjoy.
Realistically, if you want to sell a commercial aircraft, your customer base is going to be Flight Sim X, X-Plane, Prepar3D. You're simply not going to get any traction in the FlightGear ecosystem. It's not built for it. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35074166/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> geneb </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>


NOTE: The above information was taken from the following mailing list post: http://www.geocrawler.com/archives/3/11854/2001/6/0/5991409/. See that page if this one doesn't make sense.
Besides, OSG's scripting language support (lua) cannot access all the internals Nasal does, simply because there was no glue code implemented in FlightGear. So no properties for you and no access to internal function call which does Nasal provide. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35074133/  
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Erik Hofman </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>


An alternative approach using PPE is described at http://mail.flightgear.org/pipermail/flightgear-devel/2001-December/002239.html by Norman Vine.


===  Where can I learn 3D programming and how do I get involved? ===


Contributing to the 2D panel doesn't require any coding at all, just a minimal knowledge of XML syntax (i.e. five minutes' worth) and good skills with drawing and/or paint programs. Every instrument on the current panel, with the partial exception of the magnetic compass, is defined entirely in XML with no custom C++ code. If you want to get started, take a look at John Check's excellent intro (http://rockfish.net/fg/README.xmlpanel).
You own copyright of your work even if you license it GPL, and you may develop your work further and release a more complete version under a commercial license if you like (that's a variant of dual licensing). The only way to not retain copyright of what you do is to transfer it to someone else or to relinquish it by releasing your work into public domain. If you create a 3d model for a FG aircraft and license it GPL, nobody prevents you from adapting and selling it for X-plane. In fact, you can sell it also for FG (but others may re-distribute it as they like once they buy it since it is GPL, so it may not be a too viable business model) <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35073832/  
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Thorsten Renk </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>


Likewise, if you want to create a 3D cockpit for FlightGear, or to create buildings, external aircraft models, etc., your help is *desperately* needed. The only rule is to go easy on the triangles -- a model with 50,000 triangles probably won't be usable in FlightGear, and one with 5,000 triangles, only marginally. If you can design a nice 3D cockpit interior for a Cessna 172 (for example) in a 3D design program such as ac3D or ppe, we have coders who will be happy to add the support code in the C++.


If, on the other hand, you really want to get your hands dirty with C++ coding, you'll have to buy a good OpenGL book eventually. However, FlightGear uses a high-level library, plib, that hides most of the details of OpenGL. To get started with 3D C++ coding, you can take a look at the plib documentation and learn only as much OpenGL as you need, when you need it.
Do other sims offer content encryption or content protection? For instance, I've been able to locate and test a blender plugin that can open up many MSFS aircraft models. How about xplane? It's been a *long* *long* time since I fiddled with their package, but at the time I was paying attention, all their 3d formats were open and well defined. Often the commercial sims will store things in their own binary formats, but in most cases these aren't encrypted and the end users figure these out pretty quickly -- so they can either edit the content or create new content with the same format. I wouldn't consider a binary format much of a content protection scheme ... especially in an open source project where the source to load and store the binary format is readily available. I understand the desire for content creators to not get "ripped off". But also understand that one of the main reasons that FlightGear can be successful is because we make all the source code and content open. If we didn't make everything open, then we wouldn't get nearly the same amount of volunteer contributions and high quality volunteer contributions is the critical reason why FlightGear has been so successful. If we were a closed off commercial outfit, who would want to pitch in and help someone else make money? But with everything open, you know that your contributions can be enjoyed equally by everyone else, just as much as you are enjoying everyone else's contributions. There are some low-lifes out there that try to make a profit on other people's work, and will gladly lie and misrepresent things to swindle as much money as possible from unsuspecting end users. But the truth is that these people have always existed, and will always exist. They are remarkably good and persistent at copying things ... going so far as to break copy protection schemes, reverse engineer hardware designs, copy the exact look of products (even including the logo.) This isn't a problem that is unique to the FlightGear project -- and it's something we would still face no matter how hard we worked to create copy protection schemes. If you designed a binary content format, someone will reverse engineer it. If you design an encryption scheme, someone will just modify the sim code to dump out the decrypted version after it's been loaded into memory by the proprietary decrypting plugin. (If not outright break the encryption scheme or steal your encryption keys.) In all these case, the content can still be easily copied, replicated, sold, etc. The best scheme I've seen is something that has a node-lock key that will only run on a single PC (key'd to mac address, or processor id.) But this implies a more complicated 2 step install where the user must come back to you after installing the product, report their unique id, get a key, and then install that key before they are able to run. And the problem with all of this is that in an open source project, someone could simply compile a new version of the simulator that skips the key check or accepts a trivial key, or any key. I'm just thinking down various avenues here, but hopefully you can see that what seems like a simple request at first is actually quite complex and creates all kinds of down stream issues (both technically and with user support.) And at the end of the day, the bad guys can usually find work arounds anyway and aren't slowed down too much. When farmers grow crops, they have to put up with weeds. We can try reasonable things to minimie the weeds, but if you are too aggressive at killing the weeds and don't tolerate a single one, then you most likely end up killing much of your crop too. So it's my view that this is something we just have to put up with. We can try to take reasonable steps to minimize the problem, but we can't eliminate all the bad guys without harming all the good things about our project.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/27998023/
  |title  =  <nowiki> Re: [Flightgear-devel] Content protection for modders? </nowiki>
  |author =  <nowiki> Curtis Olson </nowiki>
  |date  =  Aug 25th, 2011
  |added  =  Aug 25th, 2011
  |script_version = 0.37
  }}</ref>


=== How do I add an airport? ===


You can add your airport to the $FGROOT/Airports/default.apt.gz file, but to get the airport to show up visually, you will have to rebuild the scenery around the airport. The format of the default.apt file is documented at http://flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html.
Once you have distributed source code under the GPL you explicitely declared that it's everyones right to redistribute and modify it - as long as he/she doesn't distribute it under a different license But you, as the copyright holder, can change the license for new versions you haven't yet distributed under the GPL - as long as those modifications weren't made by others, i.e., as long as you are still the sole copyright holder (or you'd have to come to an agreement with the other contributors, but you can only ask nicely). You, as the sole copyright holder, also can distribute it under several licenses at once, e.g. the GPL and some propiratory li- cense (making it worth the money people may pay for it by faster bug fixes, only distributed to the paying customers etc.).<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35073990/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Jens Thoms Toerring </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>


=== How do I generate my own scenery? ===


Yes, though it can be a difficult task. FlightGear's scenery generation is handled by a sister project, TerraGear. For more details, see http://terragear.org/.
Another thing to consider is that distributing your aircraft as a .dll or .so doesn't hide or obfuscate your code and textures after they have been loaded into the simulator structures for rendering. The rest of FlightGear is open-source so it wouldn't take much effort to insert an OSG function call to save out the aircraft (models and textures) in some other common 3d format. There would be some loss in terms of the organiation of the source files, but even so, it would give someone who's intention is to copy or modify the work a place to start. All the xml config should be there for free in the property tree. The licensing of nasal (I believe) is written in a way that makes it difficult to distribute proprietary nasal code. So there would be some really significant challenges to making a FlightGear aircraft that is secure from modification, not to mention copying.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35073896/
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Curtis Olson </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.37
  }}</ref>


== Flying ==
The key for an open source project is not if you can win a legal argument or not. Rather, it is to avoid any legal argument in the first place, and at all costs. Meaning  to stay out of court. To use something like this safely in an open source project, I would suggest something along the following lines:
 
* Making your derivative product public, in full (but unlicensed, saying it is copyrighted material),
=== Where can I learn about instrument flying and navigation? ===
* Going to the owners of the original data product, giving them a link to your derivative product,
* Asking them to make a public statement that the derivative product can be licensed using the "GPLv2 or later version" licence,
* Make sure to ask them to identify the public derivative product as a link, and identify all its parts (to avoid them saying at a later date that you included bits of the protected material),


http://www.navfltsm.addr.com/ is a very good site for learning techniques for navigation. Also see http://www.monmouth.com/~jsd/how/.
Any statement they make on the web can be backed up on the web archive ( http://web.archive.org/ ). To simplify the process, you could draft part of the statement detailing the derivative product in full, with all details. With this, there will no longer be any shades of grey! If they are happy to do this, then it is legally no problem to use (i.e. the grey situation has shifted to white). If they are not happy with your proposal, then they could turn around one day and sue (i.e. the grey situation has shifted to a clear black).<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/34561220/  
  |title  =  <nowiki> Re: [Flightgear-devel] External FDM to protect propriety data in a
GPL eviirenment </nowiki>
  |author =  <nowiki> Edward d'Auvergne </nowiki>
  |date  =  Oct 22nd, 2015
  |added  =  Oct 22nd, 2015
  |script_version = 0.37
  }}</ref>


=== What is the difference between Aileron and Rudder? ===


There is a bit of info on aileron vs. rudder here: http://www.monmouth.com/~jsd/how/.
The open-source world depends on license terms and copyrights and cooperation and trust to protect our work. We put up with a small subset of people who willing abuse those terms and hope that larger group peer pressure will keep the bad actors in check. Sometimes there is legal recourse, sometimes it is tough to do anything about it when problems span country boundaries (or when someone just wants to break the rules for their own self serving reasons.) My feeling though is in the long term, most people are honest and do wish to do the right thing, and the small group that is truly there to cause problems or just serve themselves at the expense of others will never endure as long as the larger group of people with good intentions. In the end, you have to make your own determination of how much effort you put into a model, versus how much money you could make selling it, versus the risk of someone copying and distributing it themselves, versus the legal costs to try to stop them.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35074534/  
  |title  =  <nowiki> Re: [Flightgear-devel] can i distribute my airplane as a shared
library, and what legislation issues would that ensue? </nowiki>
  |author =  <nowiki> Curtis Olson </nowiki>
  |date  =  May 9th, 2016
  |added  =  May 9th, 2016
  |script_version = 0.38
  }}</ref>


=== Is there support for multi-player flying? ===
=== DRM workarounds ===
For one of my past projects I had to deal with a proprietary flight dynamics model. I initially used the ethernet interface so it could run as an external stand alone application. Then later I switched to a unix two-way pipe arrangement so I could have tighter synchroniation with the execution order, but still the external program was completely independent and stand alone. I'd love to make everything free and open-source, but this was a case where I didn't have a choice and it was something purchased from a 3rd party company with strict terms. I felt that two independent self sufficient programs (that could talk to each other and exchange information) created sufficient license separation to honor FlightGear's gpl license terms. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/34559783/
  |title  =  <nowiki> Re: [Flightgear-devel] External FDM to protect propriety data in a
GPL eviirenment </nowiki>
  |author =  <nowiki> Curtis Olson </nowiki>
  |date  = Oct 21st, 2015
  |added  = Oct 21st, 2015
  |script_version = 0.37
  }}</ref>


We have an initial stab at this that is incomplete and only seems to work under Linux. We'd love to find someone to pick up the slack here and develop this further. Specifically, plib now has some low level networking support for mult-player games. It would also be nice to develop support for the DIS protocol.


=== Is there support for any military scenarios like dog fighting or bomb dropping? ===
For what it's worth, the "ExternalPipe" fdm was setup to cover much of the areas you have touched on. It's probably not exactly what you want but here was some of my logic in how/why I setup it up the way I did.
* Using a network interface adds some indeterminism ... sometimes network packets are delayed or stack up depending on what is going on with the machine so there isn't a guaranteed lockstep relationship between the simulator the the flight dynamics.
* Usually the network interface is good, but I observed times when it had extra delays in packets getting where they needed to go.
* As an alternative, I setup a pair of "named pipes". Pipes are a unix construct, they look like a file to the program, but what you write into them is collected and held for some other application to read out. Unfortunately these are not supported in windows. Pipes are single direction, thus the need for two of them for bi-directional communication. A pipe is really simple: you open it up like any other file, and one process writes into it; the other process reads from it. In between the OS can buffer some amount of information until the reader grabs it. You can use blocking reads (carefully) to ensure FlightGear and your external FDM run in exact lockstep.
* Pipes imply both processes will run on the same machine, a network interface would allow the processes to live on separate machines.
* The ExternalPipe interface supports a flexible property interface, so the external FDM process can send any name/value pairs it wishes to send and the interface will dutifully copy them into the FlightGear property tree. The FDM side can also send a list of property names it would like to receive in reply and the interface will dutifully send them over the outgoing pipe every frame. This was a nice addition, and there is plenty of bandwidth through a named pipe to do this in clear text, even with a lot of extra property values.


No, not at this time. Most of our developers are primarily interested and focused on civilian aviation. We aren't explicitly excluding these features -- we just haven't had anyone who seriously wanted to develop these areas.
History: I used this as part of a project I did with ATC flight sim. They had their own proprietary flight dynamics applications that modeled specific aircraft in the code itself. These models had all the necessary source documentation and flight test data to satisfy FAA certification testing requirements of the final simulator. In addition, this external code modelled many of the aircraft systems for one of their high end sims. This required the ability to be flexible in what values were sent back and forth and enabled me to drive some instrument gauges directly from the external code.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/31900851/
  |title  =  <nowiki> Re: [Flightgear-devel] Feeding FlightGear data through the Protocol
Pipe </nowiki>
  |author =  <nowiki> Curtis Olson </nowiki>
  |date  =  Jan 29th, 2014
  |added  =  Jan 29th, 2014
  |script_version = 0.37
  }}</ref>


== FlightGear v0.7.6 ==


=== Why do I get an error in viewer.cxx about `exit' being undeclared? ===
[[Category:FlightGear]]


This error cropped up after the release of v0.7.6. To fix the problem, add "#include <stdlib.h>" to the top of viewer.cxx.
[[de:FAQ]]
[[es:Preguntas frecuentes]]
[[fr:Foire aux questions]]
[[it:Domande frequenti]]
[[ja:FAQ]]
[[nl:veel gestelde vragen]]
[[pl:FAQ]]
[[pt:FAQ]]
[[pt-br:Perguntas_frequentes]]
[[sr:FAQ]]

Latest revision as of 17:00, 23 July 2023

Thank you for your interest in FlightGear! This FAQ lists some of the most commonly asked questions. Please create a topic at our forum This is a link to the FlightGear forum. if you cannot find the answer on your problem(s).

Distribution

Where can I get FlightGear?

The official download page is http://www.flightgear.org/download/. Precompiled binaries are available for Windows, and most Linux users will find that most distributions have a packaged version of FlightGear (the package name could be fgfs or flightgear.)

You can also download using torrents at https://flightgearjp.online/torrents - mainly Mac & Win, but also the large data file used when building from source.

How do I install FlightGear on Linux?

Many distributions include FlightGear in their repositories. In addition, in the Download Center you will also find AppImage, which will run on almost any modern distribution. If you can't find a packaged version for you, consider downloading and compiling from sources.

Where can I find the latest development source code?

The latest development code is available for everyone through our Git repository.

Where do I get the scenery? What is available?

While the base package only comes with scenery for the San Francisco Bay area, you can currently fly just about anywhere in the world. Currently Terrasync is the best option: it downloads the latest scenery while flying. See its page for usage information.

However the latest scenery could be too demanding if you have a low end computer or not much RAM, so consider instead to manually install the old scenery from the "graphical interface" available at the scenery download page.

Where can I get additional planes?

The latest official aircraft can be downloaded and installed with a single click through the aircraft tab in the built-in launcher (see FlightGear Qt launcher).

Official FlightGear aircraft can be found at Download central. Other aircraft in development can be found in the official FGAddon aircraft repository, and some other aircraft can be found in 3rd party FlightGear hangars (see Howto:Install_aircraft).

Why are the aircraft at FlightGear.org out of date?

The official aircraft downloads are only updated at the time of a new release of FlightGear. This is done because aircraft that are currently in development are usually developed on development/unreleased versions of FlightGear. Those development versions have lots of features that are not supported by the (older) stable release. Would we update the aircraft downloads more often, most aircraft wouldn't work on the stable release of FlightGear.

How current is the data in FlightGear compared to the real world?

We use the same navaid and airport dataset that X-Plane uses. The current dataset can be found in the $FG ROOT/Navaids/ and $FG ROOT/Airports/ directories. The maintainer can be found at X-Plane Airport & Navigation Data.

Why don't you charge money for this?

FlightGear can be downloaded for free from many locations including the FlightGear website, but can also be bought on a CD. Although we offer that service (see the website), we encourage other groups to redistribute it for their users, especially within an operating system distribution which makes installation even faster and easier for new users.

Occasionally you may see FlightGear for sale on auction sites or commercial websites under some other name. This can be done quite legitimately as long as the terms of the license are upheld and might be worth the cost if some value-added features such as additional scenery, aircraft or after-sale support are included. Unfortunately, most cases seen to date appear to be just someone trying to make money selling something that is free and providing no real added value.

How can I get started with FlightGear?

There's no better place than the page New to FlightGear!

Compiling

How do I compile FlightGear from source?

See Building FlightGear. There are explanations to compile in Windows, Linux and even scripts to automatically download and compile the whole thing.

Why won't FlightGear compile?

Well, that depends. First make sure you are using the appropriate versions of FlightGear, SimGear, plib, zlib. If any of the packages are out of sync with the others, compilation may fail. See also Building FlightGear

The FlightGear Downloads page should tell you what versions you need if you are trying to compile the latest stable release. If you are using a development snapshot, make sure all three packages are up-to-date.

Also ensure that you have some implementation of OpenGL with glut support with the appropriate header files. Linux users with nVidia cards should make sure you have the latest drivers from nVidia. Other Linux users make sure you have Mesa3D (http://mesa3d.org/) and your X server installed correctly.

If your problems persist, ask in the FlightGear forum  , on IRC or subscribe to our FlightGear-Users mailing list and let us know what problem you're having.

What is SimGear, and why do I need it?

SimGear is a library of supporting code. SimGear is only needed if you plan on compiling FlightGear — it is not needed to run precompiled binaries. For more information see http://www.simgear.org/. Note: When compiling FlightGear it is very important to have the matching version of SimGear.

Configuring and running

How do I start FlightGear?

The easiest way is using Qt Launcher. Otherwise, you can run it from the command line, with the proper options.

How do I install new scenery?

If you really don't want to/can't use Terrasync, the scenery archive files (ie. w100n30.tar.gz) should be decompressed into the Scenery/Terrain directory in your $FG_ROOT. More at Howto: Install scenery.

How do I setup my joystick(s)?

FlightGear supports wonderfully many joysticks/yokes out of the box. However if you're having problems see Input device.

What is fgfsrc? What format should my personal .fgfsrc file be in?

.fgfsrc is a file that can contain a list of Command line options with one option per line. The file is not an XML file. Note that also Windows installations have this file.

How do I get to see options, help etc?

You probably can not see the main menu. To make it show press F10.

Flying

Why won't my engine(s) start?

Aircraft vary in their starting procedure. Some may have an auto-start sequence menu entry or instructions in the aircraft help menu (press ? key) and/or at the aircraft's wiki. Please consider reading the FlightGear Manual, or see this quick small guide.

Where is the moving map?

In game, you can go into the menu "Equipment > Map", but there won't be any aeronautical chart. A popular moving map display is available under a separate project called Atlas. Also, MPmap is an online map for multiplayer.

If you like an alternative to Atlas with updated graphics and mapping provided by the OpenStreetMap project, then check out Flightgear Mapping Phi or JMapView.

Where can I learn about instrument flying and navigation?

There is a nice article, Understanding navigation, and a lot is very well explained into the FlightGear Manual. Other resources are:

What is the difference between Aileron and Rudder?

There is a bit of info on aileron vs. rudder in the very same book...

Is there support for multi-player flying?

Yes, sure we have it! See Howto: Multiplayer. Both the Windows and *nix versions of FlightGear are capable of multi-player flying on FlightGear servers. Also voice communication is supported, with FGCom.

A map showing players aircraft online in real time is available as MPmap.

Where are the best places to fly in FlightGear?

FlightGear scenery covers the whole world, but thanks to the FlightGear user community, certain airports and areas are more detailed than others. As a general idea:

  • There are a lot of high-quality scenery models around Paris, France.
  • EHAM Amsterdam Schiphol, EGKK London Gatwick and LFPG Paris Charles de Gaulle are some of the highest quality airports.
  • LOWI Innsbruck is both developed in scenery and airport.
  • TNCM St. Maarten is a popular destination, and the surrounding islands (Anguilla, St. Eustatius, Saba, St. Barthélemy, St. Kitts, and Nevis) are all well-modeled.

Furthermore, see Suggested Flights, Suggested Airports and Suggested custom scenery.

Where can I find airport info and aeronautical charts online?

See Getting aeronautical charts.

Is there support for any military scenarios like dog fighting or bomb dropping?

Yes. Check out the Bombable add on and the Bombable topic on the forum  . There are also third-party bombing scenarios for the A-10 and other aircraft with armament, like the North American OV-10A Bronco, General Dynamics F-16 and F-117 Nighthawk.

Flying issues

Why are my controls returning to a particular position?

There are several possibilities that can lead to this:

  • If your aircraft's autopilot is enabled, it will take over (some of) your controls. Switch the autopilot off to regain control.
  • Some laptops have an onboard gravity sensor that might be detected as a joystick. See how to solve that at Troubleshooting input devices.

Why does my cockpit disappear when looking around?

Probably you're using a 2D-panel version of an aircraft. Be sure to pick the one with a 3D cockpit. Most of the aircraft now have it!

There are lots of other aircraft flying around

FlightGear has a so-called AI Traffic system. This system generates other, computer-controlled aircraft based on real flight plans to make the FlightGear world look more alive. To disable artificial traffic, go to menu "AI" > "Traffic and Scenario Settings" and uncheck the "Enable AI traffic" option.

If on the contrary you can't see any aircraft other than yours, consider contributing to add traffic to your favourite place!

I can't make this plane fly straight, it keeps turning left!

Yes, FlightGear is a real flight simulator and simulates that too. Exactly, that's how real propeller aircraft behave. See Understanding Propeller Torque and P-Factor.

Also, doublecheck your weight distribution. Try adding a 180lbs copilot and see if the turn goes away.

Contributing

For anyone who's willing to contribute, we have dedicated to you the Developer portal and a Volunteer page that explains all the nice things you can do.

What language is FlightGear written in?

Mostly C++ with some supporting C code that's primarily contained within SimGear. For more details on the used languages:

As you seem to be interested in core development, you should really check out Howto:Start core development.

How do I design a flight dynamics model for a new aircraft?

FlightGear supports various flight dynamics models (FDMs), but just two of them are commonly used:

  • JSBSim: see http://jsbsim.sf.net/.
  • YASim: if you want a simpler FDM to work with, try your hand at YASim. For a guide on creating YASim aircraft, look in the FlightGear base package for $FG_ROOT/Docs/README.yasim.

See the Aircraft development portal.

How do I design or modify a 2D panel?

See the $FG_ROOT/Docs/README.xmlpanel file on your computer.

How do I place objects, like buildings, into FlightGear?

The most up to date solution is using the UFO. See Howto:Place 3D objects with the UFO. The UFO will give you the interface to choose one of the available objects and place it to some grade of precision into FG world, and then export that data to be uploaded to the official scenery, or for personal use. For more, see the Scenery development portal.

Where can I learn 3D programming and how do I get involved?

If you'd like to create a 3D cockpit for FlightGear, or to create buildings, external aircraft models, etc., your help is desperately needed. Try to go easy on the triangles, so that your work will be enjoyed by as many people as possible. The most commonly used tools here are Blender, AC3D, Gimp.

If, on the other hand, you really want to get your hands dirty with C++ coding, you'll have to buy a good OpenGL book eventually. However, FlightGear uses OSG, a high performance 3D graphics toolkit. To get started with 3D C++ coding, you can take a look at the OSG documentation and learn only as much OpenGL as you need, when you need it.

How do I add an airport?

This process includes creating the airport layout in WorldEditor, testing it (you might want to generate part of the scenery, but this is not mandatory) and then, if your data sources are GPL compatible, use WorldEditor to upload it to the gateway. The airport will be available in the next full rebuild of the scenery, unless you want to generate your own scenery. More at Howto:Make an airport.

Can I generate my own scenery?

Yes, though it can be a difficult task. FlightGear's scenery generation is handled by a sister project, TerraGear. The good news, though, is that once you have set everything up it's quite easy (although might be time consuming), and above all that you can easily share it.

Problems

X doesn't work / is broken / is wrong / won't run

FlightGear is a very complex program. If you need help in general usage of the game you'll find it at the User portal and on the FlightGear forum  .

If your problem is instead software crashes, you're getting errors, etc..., please consider following the indications in Troubleshooting problems.

Some of the most common issues are however listed below. If you can't solve the problem on your own and need the help of someone, please remember that we're all here for fun, developers included, and that any help is an act of generosity. So try to be nice, even if the problem is frustrating you.

Unable to execute file: bin/Win32/fgrun.exe during installation

This section contains out-of-date information

Please help improve this article by updating it. There may be additional information on the talk page.

Your system is missing the MSVC runtime libraries required by FlightGear. Download and install the following vcredist_x86.exe:

What happened to the panel, keyboard, etc?

The problem is almost certainly that your base package is out of sync with FlightGear. Many configurable parts of FlightGear are defined in XML files contained in the base package.

Why is FlightGear so slow?

If it seems just slow, see if you can fiddle with graphics settings here: Howto: Improve Framerates.

If things are pathologically slow (i.e. ~1 frame per second), maybe 3D hardware acceleration is not activated. Make sure you have OpenGL libraries installed and configured properly and make sure you have the latest drivers for your video card. Also, be ready because some cards are not well supported.

How do I see the Frame Rate?

On the in-sim menu select "View" > "View Options", then check the box that says "Show frame rate".

How do I toggle 2D cockpit settings?

To show/hide the 2D panel, use the key combination Shift+P. To show/hide the HUD, press Shift+H. You can also enable the alternative HUD by pressing Shift+I (press I to return to the default one). Use the Shift+H key to adjust the brightness of the HUD.

Stuck upside down after "crash"?

In his infinite wisdom the FlightGear Grand Master decided that planes were too valuable to allow them to be destroyed by novice pilots who seemed to crash a lot. The fact that nobody has bothered to model crashes may have something to do with it too. :-)

The result of this as you have noticed is that with a little practice an ingenuity you can trim the ship to fly inverted along the ground. The quick answer is to reset the sim, via the File > Reset menu. This will place your aircraft back at its starting location.

For the stubborn people out there: The trick to learn is to roll back to normal (non inverted) do this by nursing the elevator to get to about 500 feet or so and use the ailerons to snap roll 180*. This is all good avionics except for the plane not destroying itself. Remember the controls work in reverse when you are inverted and keep that airspeed up!!!

Why won't the latest versions of some aircraft work in my (older) version of FlightGear?

Often new aircraft development keeps pace with the latest FlightGear code development. New or newly modified aircraft may rely on files (such as new instrument files) or features, only available with newer versions of FlightGear. If you are stuck with an older version of FlightGear, you can try downloading an earlier version of the aircraft from the corresponding official FlightGear aircraft hangar.

When I start FlightGear I see an error mentioning "SQLite". What do I do?

Since FlightGear v2.10 (released in February 2013), the navdata cache was introduced to improve the FlightGear start times. This cache is a SQLite database that is a little fragile at times. If the database is corrupted FlightGear will refuse to start.

To fix this you simply need to delete the $FG_HOME/navdata.cache file. The first time FlightGear starts after deletion of the file the navdata cache will be rebuild. As this process is time consuming, FlightGear will take more time to start.

Some will resort to delete the entire $FG_HOME directory or even reinstall FlightGear. However neither is needed and may cause you to lose any custom preferences you have set up.

A further SQLite related problem indicator is the error message

  Sqlite error:attempt to write a readonly database (8) while running:
     INSERT OR REPLACE INTO stat_cache (path, stamp) VALUES (?,?)

In this case a previously started FlightGear instance might still be running and locking the navdata.cache file. Check for a running fgfs process and terminate it.

My aircraft has grey windows?

The problem of opaque grey/gray windows that cannot be seen through is most often due to a version mismatch between the FlightGear program and the aircraft. Or it could be due to a window effect that is not compatible with the Rembrandt or ALS rendering systems. The technical cause is that the renderer and declared effect for the window are incompatible. Some solutions include:

  • If you are using a stable FlightGear release, please download the aircraft from the official FlightGear hangars matching your FlightGear version.
  • If you are using a cutting-edge nightly build or a version controlled copy of FlightGear, or you wish to use a cutting-edge aircraft, please see FGAddon#Obtaining aircraft.
  • If you are using an aircraft from one of the 3rd party hangars, it is best to contact the original aircraft author or the person in charge of the 3rd party hangar.
  • If you are using Rembrandt, try turning this rendering system off. Aircraft that use model-default.eff for the windows (at the simple expense of doing nothing) rather than model-transparent.eff, model-combined-transparent.eff or glass.eff (which instruct Rembrandt to not use deferred rendering for the glass) will have grey windows when using Rembrandt.

My screen becomes completely red right after starting FlightGear

The red screen is the visualization of the "Redout" effect. If it occurs right after starting FlightGear, it might be caused by a problem with scenery loading. FlightGear loads scenery on the fly and if scenery cannot be loaded, eg. due to network problems, there might be no ground for the aircraft to be located on. As a result, the aircraft falls through the non existing ground starting to tumble. This in turn causes the readout effect. For verifying the problem you should start your flight in KSFO, whose scenery is already included in the base package.

The FAQ

Who do I contact if I have comments about this FAQ?

Add your comment to this FAQ's discussion page.

How old is this document?

Check its history.

What other important documentation should I read?

Contributing

Content Protection

DRM

  This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.

Every once in a while, the question comes up if it is legal to provide closed source plug-in to FlightGear (more exact OSG file reader plug-in). The only need to keep code close is the prevention of reverse engineering. [1][2][3]


FlightGear in its current form is a product of numerous people working voluntarily on a joint effort to create an open and extensible flight simulator platform. Your very idea of introducing DRM, is against all principles of open source in general.


You're free to create a non-GPL plane for FG - that's data from the perspective of the sim and doesn't trigger the license. You can sell that without ever allowing to re-distribute the source code. You're required to stay clear of a few things (you can't use Generic instruments, Nasal libs,...) but that should be doable. You can charge license fees for such a plane, and nobody may legally re-distribute it.[4]

the data is parsed from the XML into dynamic look up tables (IE. STL). The only resources used beyond that needed to make the FDM function is the overhead of pulling the data out of the XML into memory. That would have to happen no matter what form the data was in. Although there may be better ways to store the data than XML if you are unconcerned about human interaction with the data. I think that making the data human readable/editable is the main point of using XML. It may be overly verbose but it works and there are standard libraries for reading/parsing XML files so this makes using it for data input fairly simple. This benefits both FlightGear and JSBSim in terms of limiting the complexity of handling configuration data. In addition there are a limited number of standardied formats for this type of thing such as JSON and all of those that are human readable/editable have many of the same issues as XML. Full function FDMs are complex and understanding the XML used to configure a complex FDM is a very minor issue and anyone who actually understands a full function FDM will have very few issues with the XML part of this.[5]


FG itself is OpenSource, so whatever protection scheme we may code in, anyone is free to remove (and that's quite legal). It'd be a no-brainer to generate a no-copyright-protection version of FG and distribute it on which your content just runs without the key (or whatever). Given that people usually succeed in cracking DRM schemes in the absence of an open source code, trying to do this with the source code open for anyone seems just a waste of time. Second, whatever format OSG reads, before it arrives at the renderer, it's bound to be an array of vertices. The renderer needs this, there's no decryption at the GLSL stage. So chances are that since we run on *Open*GL, again anyone who really wants can write out an unencrypted format.[6]

as FlightGear is open source, it is incredibly simple to add some code to access the 3D scene graph and extract the full aircraft model (scripts excluded, though they could be reverse engineered). The information is just sitting there, fully visible, and ready to be picked off the OSG branch like a big juicy peach. I could probably write this code in half a day, but converting into AC3D format, PNG textures, etc. to recreate a new copy of the aircraft would take a little longer. If FlightGear was closed source, it would be much harder to write OSG extractor code, but nevertheless still doable.[7]


We have support for catalogs and external hangars for precisely this reason. We obviously want to encourage GPL aircraft, but not every aircraft developer wishes, or is able to, release their work under the GPL. FlightGear both respects and supports that option. [8]

You could certainly run the FDM model externally and use one of the many Network I/O options in FlightGear to pass data back and forth. Quite a few research projects have done this in the past to use FlightGear as a visualiation tool. By extension you could do the same for scripting - have the scripting run externally and interact with FlightGear via one of these protocols.[9]


if you actually try to charge 100$ for a FG plane, you won't find too many customers... because FG is mainly popular in the OpenSource community. If you make it too cumbersome with DRM schemes, maybe someone will try to circumvent it just as a matter of principle (people do this for sport...) - but across multiple platforms, it's actually not easy to make this not an annoyance for the user.[10]

The thing to keep in mind is that no matter what your source format is (dll, encrypted+signed, binary, etc.), ultimately your model mesh and textures and logical structure are read into internal OSG class structures. Once that has process has completed so the model can be rendered on screen, a person could call the appropriate write*File() function to save out your model's subtree into any of the supported formats. The only thing that is needed is access to the FlightGear source code to insert the function call in a strategic location. Ultimately, you can't completely protect your content work if you don't also completely control the situation at the application source code level. And this is a classic copy protection hacking strategy, insert the magic in the code after the distribution format has been authenticated/loaded/decoded and then write it out in a 'decrypted' format. People do it all the time, even with proprietary code. The value of the target usually determines how hard they are willing to work to steal it.[11]


Adding support for DRM to FlightGear is not going to happen - Nasal scripts are provided in plain text format by default (similar to JavaScript), while obfuscation is of course possible - it doesn't make any sense in the context of FlightGear as an open source project.

Also, scripts can be easily shared and run by users just by exchanging or copying them.

Even if you were to dump intermediate Nasal bytecode to an object file and execute this using the Nasal VM, there would be no way of enforcing DRM.

Of course, FlightGear being open source, you could also just add support for DSOs/plugins to a fork of FlightGear and base all your work on this fork - on the other hand, your modifications would still need to be made available.

there's is a way to make legal closed-source add-ons: You can write all your "secret" c++ as an external application, and let that communicate with FlightGear via sockets. This should work reasonably well. But I don't expect that you'll get many customers. First of all, at least on Linux, nobody is keen to run binary blobs, which could easily wipe out your home directory while you are toying around in FlightGear. And then, there's so much Free aircraft development going on, with a lot of momentum, that you'll probably always be behind. And those developers have close ties to the (or are) FlightGear coders, so they have the advantage that they can change the FlightGear code to their liking, at any time. They can change the interface at will, and you have to catch up ... and deal with customer complaints, who suddenly sit on a broken binary blob that doesn't work with the last FlightGear release. And finally, this socket approach works only via property system, and that's open for inspection to anyone (apart from the recently added semi-secret vector property garbage).

FlightGear has no provision to load aircraft from shared libraries. You can distribute your aircraft under a proprietary license, like Vitos does, but not as a shared library. It would take a lot of work to change FlightGear so it can load aircraft from shared libraries. Who would do that work and why would anyone do that when their time could be spent improving free software? And why would the core developers of FlightGear accept such a "contribution"?[12]

Realistically, if you want to sell a commercial aircraft, your customer base is going to be Flight Sim X, X-Plane, Prepar3D. You're simply not going to get any traction in the FlightGear ecosystem. It's not built for it. [13]

Besides, OSG's scripting language support (lua) cannot access all the internals Nasal does, simply because there was no glue code implemented in FlightGear. So no properties for you and no access to internal function call which does Nasal provide. [14]


You own copyright of your work even if you license it GPL, and you may develop your work further and release a more complete version under a commercial license if you like (that's a variant of dual licensing). The only way to not retain copyright of what you do is to transfer it to someone else or to relinquish it by releasing your work into public domain. If you create a 3d model for a FG aircraft and license it GPL, nobody prevents you from adapting and selling it for X-plane. In fact, you can sell it also for FG (but others may re-distribute it as they like once they buy it since it is GPL, so it may not be a too viable business model) [15]


Do other sims offer content encryption or content protection? For instance, I've been able to locate and test a blender plugin that can open up many MSFS aircraft models. How about xplane? It's been a *long* *long* time since I fiddled with their package, but at the time I was paying attention, all their 3d formats were open and well defined. Often the commercial sims will store things in their own binary formats, but in most cases these aren't encrypted and the end users figure these out pretty quickly -- so they can either edit the content or create new content with the same format. I wouldn't consider a binary format much of a content protection scheme ... especially in an open source project where the source to load and store the binary format is readily available. I understand the desire for content creators to not get "ripped off". But also understand that one of the main reasons that FlightGear can be successful is because we make all the source code and content open. If we didn't make everything open, then we wouldn't get nearly the same amount of volunteer contributions and high quality volunteer contributions is the critical reason why FlightGear has been so successful. If we were a closed off commercial outfit, who would want to pitch in and help someone else make money? But with everything open, you know that your contributions can be enjoyed equally by everyone else, just as much as you are enjoying everyone else's contributions. There are some low-lifes out there that try to make a profit on other people's work, and will gladly lie and misrepresent things to swindle as much money as possible from unsuspecting end users. But the truth is that these people have always existed, and will always exist. They are remarkably good and persistent at copying things ... going so far as to break copy protection schemes, reverse engineer hardware designs, copy the exact look of products (even including the logo.) This isn't a problem that is unique to the FlightGear project -- and it's something we would still face no matter how hard we worked to create copy protection schemes. If you designed a binary content format, someone will reverse engineer it. If you design an encryption scheme, someone will just modify the sim code to dump out the decrypted version after it's been loaded into memory by the proprietary decrypting plugin. (If not outright break the encryption scheme or steal your encryption keys.) In all these case, the content can still be easily copied, replicated, sold, etc. The best scheme I've seen is something that has a node-lock key that will only run on a single PC (key'd to mac address, or processor id.) But this implies a more complicated 2 step install where the user must come back to you after installing the product, report their unique id, get a key, and then install that key before they are able to run. And the problem with all of this is that in an open source project, someone could simply compile a new version of the simulator that skips the key check or accepts a trivial key, or any key. I'm just thinking down various avenues here, but hopefully you can see that what seems like a simple request at first is actually quite complex and creates all kinds of down stream issues (both technically and with user support.) And at the end of the day, the bad guys can usually find work arounds anyway and aren't slowed down too much. When farmers grow crops, they have to put up with weeds. We can try reasonable things to minimie the weeds, but if you are too aggressive at killing the weeds and don't tolerate a single one, then you most likely end up killing much of your crop too. So it's my view that this is something we just have to put up with. We can try to take reasonable steps to minimize the problem, but we can't eliminate all the bad guys without harming all the good things about our project.[16]


Once you have distributed source code under the GPL you explicitely declared that it's everyones right to redistribute and modify it - as long as he/she doesn't distribute it under a different license But you, as the copyright holder, can change the license for new versions you haven't yet distributed under the GPL - as long as those modifications weren't made by others, i.e., as long as you are still the sole copyright holder (or you'd have to come to an agreement with the other contributors, but you can only ask nicely). You, as the sole copyright holder, also can distribute it under several licenses at once, e.g. the GPL and some propiratory li- cense (making it worth the money people may pay for it by faster bug fixes, only distributed to the paying customers etc.).[17]


Another thing to consider is that distributing your aircraft as a .dll or .so doesn't hide or obfuscate your code and textures after they have been loaded into the simulator structures for rendering. The rest of FlightGear is open-source so it wouldn't take much effort to insert an OSG function call to save out the aircraft (models and textures) in some other common 3d format. There would be some loss in terms of the organiation of the source files, but even so, it would give someone who's intention is to copy or modify the work a place to start. All the xml config should be there for free in the property tree. The licensing of nasal (I believe) is written in a way that makes it difficult to distribute proprietary nasal code. So there would be some really significant challenges to making a FlightGear aircraft that is secure from modification, not to mention copying.[18]

The key for an open source project is not if you can win a legal argument or not. Rather, it is to avoid any legal argument in the first place, and at all costs. Meaning to stay out of court. To use something like this safely in an open source project, I would suggest something along the following lines:

  • Making your derivative product public, in full (but unlicensed, saying it is copyrighted material),
  • Going to the owners of the original data product, giving them a link to your derivative product,
  • Asking them to make a public statement that the derivative product can be licensed using the "GPLv2 or later version" licence,
  • Make sure to ask them to identify the public derivative product as a link, and identify all its parts (to avoid them saying at a later date that you included bits of the protected material),

Any statement they make on the web can be backed up on the web archive ( http://web.archive.org/ ). To simplify the process, you could draft part of the statement detailing the derivative product in full, with all details. With this, there will no longer be any shades of grey! If they are happy to do this, then it is legally no problem to use (i.e. the grey situation has shifted to white). If they are not happy with your proposal, then they could turn around one day and sue (i.e. the grey situation has shifted to a clear black).[19]


The open-source world depends on license terms and copyrights and cooperation and trust to protect our work. We put up with a small subset of people who willing abuse those terms and hope that larger group peer pressure will keep the bad actors in check. Sometimes there is legal recourse, sometimes it is tough to do anything about it when problems span country boundaries (or when someone just wants to break the rules for their own self serving reasons.) My feeling though is in the long term, most people are honest and do wish to do the right thing, and the small group that is truly there to cause problems or just serve themselves at the expense of others will never endure as long as the larger group of people with good intentions. In the end, you have to make your own determination of how much effort you put into a model, versus how much money you could make selling it, versus the risk of someone copying and distributing it themselves, versus the legal costs to try to stop them.[20]

DRM workarounds

For one of my past projects I had to deal with a proprietary flight dynamics model. I initially used the ethernet interface so it could run as an external stand alone application. Then later I switched to a unix two-way pipe arrangement so I could have tighter synchroniation with the execution order, but still the external program was completely independent and stand alone. I'd love to make everything free and open-source, but this was a case where I didn't have a choice and it was something purchased from a 3rd party company with strict terms. I felt that two independent self sufficient programs (that could talk to each other and exchange information) created sufficient license separation to honor FlightGear's gpl license terms. [21]


For what it's worth, the "ExternalPipe" fdm was setup to cover much of the areas you have touched on. It's probably not exactly what you want but here was some of my logic in how/why I setup it up the way I did.

  • Using a network interface adds some indeterminism ... sometimes network packets are delayed or stack up depending on what is going on with the machine so there isn't a guaranteed lockstep relationship between the simulator the the flight dynamics.
  • Usually the network interface is good, but I observed times when it had extra delays in packets getting where they needed to go.
  • As an alternative, I setup a pair of "named pipes". Pipes are a unix construct, they look like a file to the program, but what you write into them is collected and held for some other application to read out. Unfortunately these are not supported in windows. Pipes are single direction, thus the need for two of them for bi-directional communication. A pipe is really simple: you open it up like any other file, and one process writes into it; the other process reads from it. In between the OS can buffer some amount of information until the reader grabs it. You can use blocking reads (carefully) to ensure FlightGear and your external FDM run in exact lockstep.
  • Pipes imply both processes will run on the same machine, a network interface would allow the processes to live on separate machines.
  • The ExternalPipe interface supports a flexible property interface, so the external FDM process can send any name/value pairs it wishes to send and the interface will dutifully copy them into the FlightGear property tree. The FDM side can also send a list of property names it would like to receive in reply and the interface will dutifully send them over the outgoing pipe every frame. This was a nice addition, and there is plenty of bandwidth through a named pipe to do this in clear text, even with a lot of extra property values.

History: I used this as part of a project I did with ATC flight sim. They had their own proprietary flight dynamics applications that modeled specific aircraft in the code itself. These models had all the necessary source documentation and flight test data to satisfy FAA certification testing requirements of the final simulator. In addition, this external code modelled many of the aircraft systems for one of their high end sims. This required the ability to be flexible in what values were sent back and forth and enabled me to drive some instrument gauges directly from the external code.[22]

  1. Paul Guhl  (Aug 25th, 2011).  [Flightgear-devel] Content protection for modders? .
  2. Soitanen (Aug 28th, 2014). Re: Encrypted aircraft dynamics post on the forum  
  3. Alan Teeder  (Oct 21st, 2015).  [Flightgear-devel] External FDM to protect propriety data in a GPL eviirenment .
  4. Thorsten Renk  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  5. hvengel (Aug 28th, 2014). Re: Encrypted aircraft dynamics post on the forum  
  6. Thorsten Renk  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  7. Edward d'Auvergne  (May 10th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  8. Stuart Buchanan  (May 10th, 2016).  Re: [Flightgear-devel] botom line: if i don't my aircraft to be subject to GPL FGAddon clauses .
  9. Stuart Buchanan  (May 10th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  10. Thorsten Renk  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  11. Curtis Olson  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  12. Ludovic Brenta  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  13. geneb  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  14. Erik Hofman  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  15. Thorsten Renk  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  16. Curtis Olson  (Aug 25th, 2011).  Re: [Flightgear-devel] Content protection for modders? .
  17. Jens Thoms Toerring  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  18. Curtis Olson  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  19. Edward d'Auvergne  (Oct 22nd, 2015).  Re: [Flightgear-devel] External FDM to protect propriety data in a GPL eviirenment .
  20. Curtis Olson  (May 9th, 2016).  Re: [Flightgear-devel] can i distribute my airplane as a shared library, and what legislation issues would that ensue? .
  21. Curtis Olson  (Oct 21st, 2015).  Re: [Flightgear-devel] External FDM to protect propriety data in a GPL eviirenment .
  22. Curtis Olson  (Jan 29th, 2014).  Re: [Flightgear-devel] Feeding FlightGear data through the Protocol Pipe .