FlightGear wiki - User contributions [en]

User:Fgf5

2026-07-20T14:13:59Z

Fgf5: expand

Primarily plays FlightGear 2024.1 on PC, also the free version of X-Plane on mobile.

* 2026-2: Downloaded FG
* 2026-4: Started contributing to the wiki
* 2026-5: Started contributing to the source code repository

My favorite aircraft:
* [[Airbus A320 family]]
* [[Boeing 737-800YV]]
* [[Boeing 777]]
* [[Cessna 172P]] and [[Cessna 182S|182S]]
* [[EC130]]
* [[F-16]]
* [[Follow me e-tron]]
* [[Space Shuttle]]
* [[UFO]]

Favorite add-ons:
* [[Logbook Add-on]]
* [[Which Runway Add-on]]
* [[Nasal Namespace Browser]]
* [[Aerotow Everywhere Add-on]]
* [https://github.com/PlayeRom/flightgear-addon-menu-aggregator Add-ons Menu Aggregator]
* [[AutoEarthView]]

File:2024.2 HDR PBR rendering.png

2026-07-16T21:22:30Z

Fgf5: Fgf5 uploaded a new version of File:2024.2 HDR PBR rendering.png

=={{int:filedesc}}==
{{Information
|description={{en|1=HDR and PBR rendering in 2024.2}}
|date=2026-05-25
|source={{own}}
|author=[[User:Fgf5|Fgf5]]
|permission=
|other versions=
}}

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

Nasal scripting language

2026-07-15T08:24:38Z

Fgf5: /* Fibonacci */ semicolon

{{Nasal Navigation}}
'''Nasal''' is [[FlightGear]]'s built-in scripting language, standing for "not another scripting language". Originally written and developed by Andy Ross for a personal project, it was integrated into FlightGear in November 2003, and has been continuously developed, improved, and refined since then. Over time, it has become probably FlightGear's most powerful, and has been used to create a huge variety of systems, ranging from [[wildfire simulation|wildfires]] to [[Control Display Unit]]s.

Nasal uses some of the concepts of ECMA/JavaScript, Python and Perl and implements a simple but complete way of Object Oriented Programming (OOP). It supports the reading and writing of internal [[Property Tree|properties]], accessing internal data via extension functions, creating GUI dialogs and much more within FlightGear.

Please see the '''right navigation bar''' "Nasal scripting" to get more information and tutorials about Nasal itself.

== Features ==
=== Design ===
* Designed as an extension language, well suited for embedded applications
* Small Interpreter, written in ANSI C, even smaller than lua
* Nasal's VM uses internally a stack machine model and is stackless for interpreted code
* Nasal provides optional bindings for libraries such as gtk, cairo, regex, readline, sqlite or unix, and does not depend on any third party libraries other than the standard C library
* Nasal is threadsafe and does not use a global interpreter lock (i.e. GIL/GVL in Python or Ruby)
* Metaprogramming and Unicode support
* Support for multiple execution contexts and subcontexts

== Examples ==
=== Hello world ===
A [[Nasal Hello World|Hello World]] example:
<syntaxhighlight lang="nasal">
# to be saved in $FG_ROOT/Nasal/hello.nas
print("Hello World!");
</syntaxhighlight>

=== Fibonacci ===
An example of calculating <code>fib(10000000) % 16777216</code>:
<syntaxhighlight lang="nasal">
var fibonacci = func(n) {
if (n == 0) return 0;
if (n == 1) return 1;

var a = 0;
var b = 1;
for (var i = 2; i <= n; i += 1) {
(a, b) = (b, (a + b) & 16777215);
}
return b;
};

var n = 10000000;
var start = systime();
var result = fibonacci(n);
var end = systime();
var elapsed = end - start;

print("Fibonacci(", n, ") mod 16777216 = ", result);
print("Time elapsed: ", elapsed, " seconds");
</syntaxhighlight>

== Tutorials ==
=== Variables and operators ===
See [[Nasal Variables]] and [[Nasal Operators]] for more info.

=== Conditionals and loops ===
See [[Nasal Conditionals]] and [[Nasal Loops]].

=== Functions ===
{{Main article|Using Nasal functions}}

=== Objects ===
{{Main article|Object oriented programming in Nasal}}

=== Namespaces ===
{{Main article|Howto:Understand Namespaces and Methods}}

=== Libraries (and more) ===
See the navigation bar "Nasal scripting" for more info.

== Gallery ==
<gallery mode="packed">
Vim-nasal-syntax-highlighting.png|Syntax highlighting in vim
Highlight parse.png|Nasal support in Notepad++
Nasal syntax hightlighting VSCode.png|Nasal support in VSCode
</gallery>
== Related content ==
=== Wiki ===
* [[Nasal Browser|Nasal namespace browser addon]]

=== Source code ===
* [https://github.com/andyross/nasal Original implementation andyross/nasal]
* [https://gitlab.com/flightgear/simgear/-/tree/next/simgear/nasal Official source of Nasal]
* [https://github.com/ValKmjolnir/Nasal-Interpreter Another implementation of Nasal using C++17] ([https://nasal.fgprc.org.cn/ online interpreter])

[[Category:Nasal]]

HDR Pipeline

2026-07-10T14:20:10Z

Fgf5:

{{forum|47|Effects & Shaders}}

{{infobox subsystem
|image = HDR pipeline c172p over TFFF.png
|name = HDR Pipeline
|started = 04/2021
|description = A modern rendering pipeline that targets relatively powerful systems
|status = In development
|developers = Fernando García Liñán <ref>https://sourceforge.net/u/fgarlin/profile/</ref>
|changelog = https://sourceforge.net/u/fgarlin/profile/feed.rss
|folders =
* {{fgdata file|Compositor/HDR}}
* {{fgdata file|Effects/HDR}}
* {{fgdata file|Shaders/HDR}}
}}

{{Rendering}}

The '''HDR Pipeline''' is a [[Compositor]]-based rendering pipeline that attempts to bring modern rendering techniques to FlightGear, namely {{wikipedia|High dynamic range|high dynamic range (HDR)}} and {{wikipedia|Physically based rendering|physically based rendering (PBR)}}. It is implemented entirely in [[$FG_ROOT]] using XML for the Compositor pipeline definition and [[Effects]], and GLSL for shaders and is only available on 'next' branch or nightly builds (2024.2). The pipeline can be enabled with the command line argument <code>--compositor=Compositor/HDR/hdr</code>.

== Background ==

The [[Classic Pipeline]] relies on legacy [[OpenGL]] features, so rather than improving or reworking it, the idea of creating an entirely separate rendering pipeline from scratch started taking shape. The [[Compositor]] played the biggest role in enabling this effort as it allows the creation of new rendering pipelines entirely in FGData space without any C++ changes whatsoever, greatly reducing the amount of work that had to be done and making the iterative process of testing and debugging much faster.

== Notes for aircraft developers ==

The HDR pipeline handles lighting in a completely different manner compared to [[Atmospheric light scattering|ALS]]. The pipeline will attempt to "translate" classic Effects so they display correctly by making some assumptions. These assumptions are not always correct, so your aircraft might not display correctly under the HDR pipeline. In this section we describe some steps you can follow to leverage all the power of the HDR pipeline.

=== PBR and glTF ===

Physically-based rendering (PBR) refers to the concept of using realistic shading/lighting models along with measured surface values to accurately represent real-world materials. See this [https://marmoset.co/posts/physically-based-rendering-and-you-can-too/ webpage] for an extensive introduction to PBR and how you can create physically-based assets for your aircraft.

This pipeline introduces a PBR Effect ({{fgdata file|Effects/model-pbr.eff}}). However, you don't need to assign this Effect manually. You can export your model from Blender to the [[glTF]] format and use it directly. The Blender exporter will take care of exporting the necessary textures and the FlightGear parser will automatically assign the PBR Effect to your model. Your model XML file would contain something like this:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<path>my-aircraft.gltf</path>
[...]
</PropertyList>
</syntaxhighlight>

Although '''not recommended''', the PBR effect can be assigned as usual by adding an <tt><effect></tt> tag in the model XML and configuring it like you would configure [[Model-combined effect|model-combined]].

=== Lights ===

Lights are defined using the [[Compositor#Lights|Compositor syntax]]. However, since we are dealing with physically-based values, the ambient/diffuse/specular values are ignored and the <tt>color</tt> and <tt>intensity</tt> parameters are used instead. The <tt>attenuation</tt> parameter is also ignored.

It is possible to have a light definition that is compatible with both ALS and HDR by defining all parameters at the same time. This might be troublesome though because the same values might yield different results under each pipeline.

An example light definition is shown below:

<syntaxhighlight lang="xml">
<light>
<name>my-spotlight</name>
<type>spot</type>
<position>
<x-m>-7.7476</x-m>
<y-m>0</y-m>
<z-m>-1.7990</z-m>
</position>
<direction>
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</direction>
<color>
<r>1.0</r>
<g>0.0</g>
<b>0.0</b>
</color>
<intensity>10</intensity>
<spot-exponent>5</spot-exponent>
<spot-cutoff>40</spot-cutoff>
<range-m>50</range-m>
</light>
</syntaxhighlight>

== References ==
{{Appendix}}

== Related content ==
* [[Compositor]]
* [[glTF]]

[[Category:Compositor Pipelines]]

Menubar

2026-07-10T14:13:08Z

Fgf5: /* How to Change the Default Menubar Font Size */

{{Note|The existing menubar is a hard-coded feature implemented using PLIB/PUI which we are hoping to get rid of eventually to help us [[Unifying the 2D rendering backend via canvas]] for better portability and performance.
This feature will be ported to [[Canvas]] in version 2024.2.}}

The in-game '''menubar''' of [[FlightGear]] is located at the top of the screen.

== Menu items ==
''For the list of default menubar items, see [[Menu]].''

=== Add items ===
To add a menu for a specific plane only you have to enhance the planes <tt>-set.xml</tt> file. Add the follow lines (example for the [[Livery over MP|livery selection dialog]] in a [[Boeing 787]]), or any item that you want to show, above the </sim> tag. You can add as many items and menus as you like, but keep the menubar as small as possible, the larger the outside view will be.

<syntaxhighlight lang="xml">
<menubar>
<default>
<menu n="100">
<label>Boeing 787</label>
<enabled type="bool">true</enabled>

<item>
<label>Select Livery</label>
<binding>
<command>nasal</command>
<script>aircraft.livery.dialog.open()</script>
</binding>
</item>

</menu>
</default>
</menubar>
</syntaxhighlight>

* '''menu n="100":''' creates an extra menu item, at the end of the menubar, needs to be start in 100.
* '''aircraft.livery.dialog.open():''' the prefix 'aircraft' is coming from the tagname you choose inside the <nasal> section, eg:
<syntaxhighlight lang="xml">
<nasal>
<aircraft>
<file>Aircraft/MyAircraft/Nasal/script.nas</file>
</aircraft>
</nasal>
</syntaxhighlight>
Use only characters that could be used to name and call a nasal function (eg: the '-' character is not valid).

== Styles ==
The menubar is available in various styles. Currently there are two styles (both are shown below) packaged with FlightGear. The lower one is standard. You can switch between styles by pressing Shift-F10.

[[File:menubar1.jpg|517px]]

[[File:menubar2.jpg|517px]]

=== Creating your own ===
{{main article|Howto:Create a custom GUI style}}

== How to Change the Default Menubar Font Size ==

For those using bigger monitors or higher resolutions it may be necessary to increase the font size of the menubar. The change below can be applied and should be made before launching.

<syntaxhighlight lang="diff">
--- flightgear-data/fgdata/gui/styles/anthrax.xml.orig
+++ flightgear-data/fgdata/gui/styles/anthrax.xml
@@ -11,7 +11,7 @@
<fonts>
<gui>
- <name type="string">HELVETICA_12</name>
+ <name type="string">HELVETICA_18</name>
<baseline-height type="float">21</baseline-height>
</gui>
</syntaxhighlight>

Possible font names are
"default", "FIXED_8x13", "FIXED_9x15", "TIMES_10", "TIMES_24",
"HELVETICA_10", "HELVETICA_12", "HELVETICA_14", "HELVETICA_18",
"SANS_12B",
and all font file names from [[$FG_ROOT|$FG_ROOT]]/Fonts/, such as "helvetica_bold.txf".

<references/>

[[Category:FlightGear feature]]
[[Category:Menubar]]

Menubar

2026-07-10T14:10:36Z

Fgf5: /* Styles */

{{Note|The existing menubar is a hard-coded feature implemented using PLIB/PUI which we are hoping to get rid of eventually to help us [[Unifying the 2D rendering backend via canvas]] for better portability and performance.
This feature will be ported to [[Canvas]] in version 2024.2.}}

The in-game '''menubar''' of [[FlightGear]] is located at the top of the screen.

== Menu items ==
''For the list of default menubar items, see [[Menu]].''

=== Add items ===
To add a menu for a specific plane only you have to enhance the planes <tt>-set.xml</tt> file. Add the follow lines (example for the [[Livery over MP|livery selection dialog]] in a [[Boeing 787]]), or any item that you want to show, above the </sim> tag. You can add as many items and menus as you like, but keep the menubar as small as possible, the larger the outside view will be.

<syntaxhighlight lang="xml">
<menubar>
<default>
<menu n="100">
<label>Boeing 787</label>
<enabled type="bool">true</enabled>

<item>
<label>Select Livery</label>
<binding>
<command>nasal</command>
<script>aircraft.livery.dialog.open()</script>
</binding>
</item>

</menu>
</default>
</menubar>
</syntaxhighlight>

* '''menu n="100":''' creates an extra menu item, at the end of the menubar, needs to be start in 100.
* '''aircraft.livery.dialog.open():''' the prefix 'aircraft' is coming from the tagname you choose inside the <nasal> section, eg:
<syntaxhighlight lang="xml">
<nasal>
<aircraft>
<file>Aircraft/MyAircraft/Nasal/script.nas</file>
</aircraft>
</nasal>
</syntaxhighlight>
Use only characters that could be used to name and call a nasal function (eg: the '-' character is not valid).

== Styles ==
The menubar is available in various styles. Currently there are two styles (both are shown below) packaged with FlightGear. The lower one is standard. You can switch between styles by pressing Shift-F10.

[[File:menubar1.jpg|517px]]

[[File:menubar2.jpg|517px]]

=== Creating your own ===
{{main article|Howto:Create a custom GUI style}}

== How to Change the Default Menubar Font Size ==

For those using bigger monitors or higher resolutions it may be necessary to increase the font size of the menubar. The change below can be applied and should be made before launching.

<syntaxhighlight lang="diff">
--- flightgear-data/fgdata/gui/styles/anthrax.xml.orig 2014-04-24 19:52:04.353028047 -0800
+++ flightgear-data/fgdata/gui/styles/anthrax.xml 2014-04-24 19:57:12.548002672 -0800
@@ -11,7 +11,7 @@
<fonts>
<gui>
- <name type="string">HELVETICA_12</name>
+ <name type="string">HELVETICA_18</name>
<baseline-height type="float">21</baseline-height>
</gui>
</syntaxhighlight>

Possible font names are
"default", "FIXED_8x13", "FIXED_9x15", "TIMES_10", "TIMES_24",
"HELVETICA_10", "HELVETICA_12", "HELVETICA_14", "HELVETICA_18",
"SANS_12B",
and all font file names from [[$FG_ROOT|$FG_ROOT]]/Fonts/, such as "helvetica_bold.txf".

<references/>

[[Category:FlightGear feature]]
[[Category:Menubar]]

Menubar

2026-07-10T14:09:13Z

Fgf5:

{{Note|The existing menubar is a hard-coded feature implemented using PLIB/PUI which we are hoping to get rid of eventually to help us [[Unifying the 2D rendering backend via canvas]] for better portability and performance.
This feature will be ported to [[Canvas]] in version 2024.2.}}

The in-game '''menubar''' of [[FlightGear]] is located at the top of the screen.

== Menu items ==
''For the list of default menubar items, see [[Menu]].''

=== Add items ===
To add a menu for a specific plane only you have to enhance the planes <tt>-set.xml</tt> file. Add the follow lines (example for the [[Livery over MP|livery selection dialog]] in a [[Boeing 787]]), or any item that you want to show, above the </sim> tag. You can add as many items and menus as you like, but keep the menubar as small as possible, the larger the outside view will be.

<syntaxhighlight lang="xml">
<menubar>
<default>
<menu n="100">
<label>Boeing 787</label>
<enabled type="bool">true</enabled>

<item>
<label>Select Livery</label>
<binding>
<command>nasal</command>
<script>aircraft.livery.dialog.open()</script>
</binding>
</item>

</menu>
</default>
</menubar>
</syntaxhighlight>

* '''menu n="100":''' creates an extra menu item, at the end of the menubar, needs to be start in 100.
* '''aircraft.livery.dialog.open():''' the prefix 'aircraft' is coming from the tagname you choose inside the <nasal> section, eg:
<syntaxhighlight lang="xml">
<nasal>
<aircraft>
<file>Aircraft/MyAircraft/Nasal/script.nas</file>
</aircraft>
</nasal>
</syntaxhighlight>
Use only characters that could be used to name and call a nasal function (eg: the '-' character is not valid).

== Styles ==
The menubar is available in various styles. Currently there are two styles (both are shown below) packaged with FlightGear. The lower one is standard, since FlightGear 1.0.0. You can switch between styles by pressing Shift-F10.

[[File:menubar1.jpg|517px]]

[[File:menubar2.jpg|517px]]

=== Creating your own ===
{{main article|Howto:Create a custom GUI style}}

== How to Change the Default Menubar Font Size ==

For those using bigger monitors or higher resolutions it may be necessary to increase the font size of the menubar. The change below can be applied and should be made before launching.

<syntaxhighlight lang="diff">
--- flightgear-data/fgdata/gui/styles/anthrax.xml.orig 2014-04-24 19:52:04.353028047 -0800
+++ flightgear-data/fgdata/gui/styles/anthrax.xml 2014-04-24 19:57:12.548002672 -0800
@@ -11,7 +11,7 @@
<fonts>
<gui>
- <name type="string">HELVETICA_12</name>
+ <name type="string">HELVETICA_18</name>
<baseline-height type="float">21</baseline-height>
</gui>
</syntaxhighlight>

Possible font names are
"default", "FIXED_8x13", "FIXED_9x15", "TIMES_10", "TIMES_24",
"HELVETICA_10", "HELVETICA_12", "HELVETICA_14", "HELVETICA_18",
"SANS_12B",
and all font file names from [[$FG_ROOT|$FG_ROOT]]/Fonts/, such as "helvetica_bold.txf".

<references/>

[[Category:FlightGear feature]]
[[Category:Menubar]]

Menubar

2026-07-10T14:08:31Z

Fgf5:

{{Note|The existing menubar is a hard-coded feature implemented using PLIB/PUI which we are hoping to get rid of eventually to help us [[Unifying the 2D rendering backend via canvas]] for better portability and performance. The PUI menubar can be partially customized by editing PropertyList/XML files for adding entries and styling purposes, but is otherwise fairly inflexible and doesn't support modern widgets like checkboxes, or even just sub-menus.
This feature will be ported to [[Canvas]] in version 2024.2.}}

The in-game '''menubar''' of [[FlightGear]] is located at the top of the screen.

== Menu items ==
''For the list of default menubar items, see [[Menu]].''

=== Add items ===
To add a menu for a specific plane only you have to enhance the planes <tt>-set.xml</tt> file. Add the follow lines (example for the [[Livery over MP|livery selection dialog]] in a [[Boeing 787]]), or any item that you want to show, above the </sim> tag. You can add as many items and menus as you like, but keep the menubar as small as possible, the larger the outside view will be.

<syntaxhighlight lang="xml">
<menubar>
<default>
<menu n="100">
<label>Boeing 787</label>
<enabled type="bool">true</enabled>

<item>
<label>Select Livery</label>
<binding>
<command>nasal</command>
<script>aircraft.livery.dialog.open()</script>
</binding>
</item>

</menu>
</default>
</menubar>
</syntaxhighlight>

* '''menu n="100":''' creates an extra menu item, at the end of the menubar, needs to be start in 100.
* '''aircraft.livery.dialog.open():''' the prefix 'aircraft' is coming from the tagname you choose inside the <nasal> section, eg:
<syntaxhighlight lang="xml">
<nasal>
<aircraft>
<file>Aircraft/MyAircraft/Nasal/script.nas</file>
</aircraft>
</nasal>
</syntaxhighlight>
Use only characters that could be used to name and call a nasal function (eg: the '-' character is not valid).

== Styles ==
The menubar is available in various styles. Currently there are two styles (both are shown below) packaged with FlightGear. The lower one is standard, since FlightGear 1.0.0. You can switch between styles by pressing Shift-F10.

[[File:menubar1.jpg|517px]]

[[File:menubar2.jpg|517px]]

=== Creating your own ===
{{main article|Howto:Create a custom GUI style}}

== Flickering Menubar text under Rembrandt / ALS ==

Due to problems that appear to be related to the internal bitmapped font not being rendering correctly on certain graphics card (e.g. AMD R9 290) it may be necessary to change the GUI style to use the TXF format[http://forum.flightgear.org/viewtopic.php?f=4&t=17536#p166346] fonts.

If there is an option on the Debug menu called *cycle gui* use this, ensure that you are using GUI style 1, i.e. in the preferences, or autosave the gui section should be as followed

<syntaxhighlight lang="xml">
<gui>
<current-style type="int">1</current-style>
<devel-widgets type="bool">false</devel-widgets>
</gui>
</syntaxhighlight>

== How to Change the Default Menubar Font Size ==

For those using bigger monitors or higher resolutions it may be necessary to increase the font size of the menubar. The change below can be applied and should be made before launching.

<syntaxhighlight lang="diff">
--- flightgear-data/fgdata/gui/styles/anthrax.xml.orig 2014-04-24 19:52:04.353028047 -0800
+++ flightgear-data/fgdata/gui/styles/anthrax.xml 2014-04-24 19:57:12.548002672 -0800
@@ -11,7 +11,7 @@
<fonts>
<gui>
- <name type="string">HELVETICA_12</name>
+ <name type="string">HELVETICA_18</name>
<baseline-height type="float">21</baseline-height>
</gui>
</syntaxhighlight>

Possible font names are
"default", "FIXED_8x13", "FIXED_9x15", "TIMES_10", "TIMES_24",
"HELVETICA_10", "HELVETICA_12", "HELVETICA_14", "HELVETICA_18",
"SANS_12B",
and all font file names from [[$FG_ROOT|$FG_ROOT]]/Fonts/, such as "helvetica_bold.txf".

<references/>

[[Category:FlightGear feature]]
[[Category:Menubar]]

Menubar

2026-07-10T14:05:20Z

Fgf5: 2024.2

{{Note|The existing menubar is a hard-coded feature implemented using PLIB/PUI which we are hoping to get rid of eventually to help us [[Unifying the 2D rendering backend via canvas]] for better portability and performance. The PUI menubar can be partially customized by editing PropertyList/XML files for adding entries and styling purposes, but is otherwise fairly inflexible and doesn't support modern widgets like checkboxes, or even just sub-menus.
This feature will be ported to [[Canvas]] in version 2024.2, for details please check out [[Howto:Making a Canvas Menubar]].}}

The in-game '''menubar''' of [[FlightGear]] is located at the top of the screen.

== Menu items ==
''For the list of default menubar items, see [[Menu]].''

=== Add items ===
To add a menu for a specific plane only you have to enhance the planes <tt>-set.xml</tt> file. Add the follow lines (example for the [[Livery over MP|livery selection dialog]] in a [[Boeing 787]]), or any item that you want to show, above the </sim> tag. You can add as many items and menus as you like, but keep the menubar as small as possible, the larger the outside view will be.

<syntaxhighlight lang="xml">
<menubar>
<default>
<menu n="100">
<label>Boeing 787</label>
<enabled type="bool">true</enabled>

<item>
<label>Select Livery</label>
<binding>
<command>nasal</command>
<script>aircraft.livery.dialog.open()</script>
</binding>
</item>

</menu>
</default>
</menubar>
</syntaxhighlight>

* '''menu n="100":''' creates an extra menu item, at the end of the menubar, needs to be start in 100.
* '''aircraft.livery.dialog.open():''' the prefix 'aircraft' is coming from the tagname you choose inside the <nasal> section, eg:
<syntaxhighlight lang="xml">
<nasal>
<aircraft>
<file>Aircraft/MyAircraft/Nasal/script.nas</file>
</aircraft>
</nasal>
</syntaxhighlight>
Use only characters that could be used to name and call a nasal function (eg: the '-' character is not valid).

== Styles ==
The menubar is available in various styles. Currently there are two styles (both are shown below) packaged with FlightGear. The lower one is standard, since FlightGear 1.0.0. You can switch between styles by pressing Shift-F10.

[[File:menubar1.jpg|517px]]

[[File:menubar2.jpg|517px]]

=== Creating your own ===
{{main article|Howto:Create a custom GUI style}}

== Flickering Menubar text under Rembrandt / ALS ==

Due to problems that appear to be related to the internal bitmapped font not being rendering correctly on certain graphics card (e.g. AMD R9 290) it may be necessary to change the GUI style to use the TXF format[http://forum.flightgear.org/viewtopic.php?f=4&t=17536#p166346] fonts.

If there is an option on the Debug menu called *cycle gui* use this, ensure that you are using GUI style 1, i.e. in the preferences, or autosave the gui section should be as followed

<syntaxhighlight lang="xml">
<gui>
<current-style type="int">1</current-style>
<devel-widgets type="bool">false</devel-widgets>
</gui>
</syntaxhighlight>

== How to Change the Default Menubar Font Size ==

For those using bigger monitors or higher resolutions it may be necessary to increase the font size of the menubar. The change below can be applied and should be made before launching.

<syntaxhighlight lang="diff">
--- flightgear-data/fgdata/gui/styles/anthrax.xml.orig 2014-04-24 19:52:04.353028047 -0800
+++ flightgear-data/fgdata/gui/styles/anthrax.xml 2014-04-24 19:57:12.548002672 -0800
@@ -11,7 +11,7 @@
<fonts>
<gui>
- <name type="string">HELVETICA_12</name>
+ <name type="string">HELVETICA_18</name>
<baseline-height type="float">21</baseline-height>
</gui>
</syntaxhighlight>

Possible font names are
"default", "FIXED_8x13", "FIXED_9x15", "TIMES_10", "TIMES_24",
"HELVETICA_10", "HELVETICA_12", "HELVETICA_14", "HELVETICA_18",
"SANS_12B",
and all font file names from [[$FG_ROOT|$FG_ROOT]]/Fonts/, such as "helvetica_bold.txf".

<references/>

[[Category:FlightGear feature]]
[[Category:Menubar]]

TerraSync

2026-07-07T06:18:39Z

Fgf5:

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

'''TerraSync''' is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the main scenery server just in time.
TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the launcher under Settings > Additional Settings (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.eti.pg.gda.pl/o2c/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There are the forum posts: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred] and [https://forum.flightgear.org/viewtopic.php?f=17&t=44466 Terrasync issue]

In addition, you can manually download .txz scenery files from terrasync.eti.pg.gda.pl ([https://terrasync.eti.pg.gda.pl/o2c/ osm2city], [https://terrasync.eti.pg.gda.pl/ws2/ ws2], and [https://terrasync.eti.pg.gda.pl/ws3/ ws3], organized by type) and unpack them into your <code>TerraSync</code> folder correctly.

=== Some scenery objects/buildings do not appear ===
If you've already enabled them in the [[Rendering Options]] dialog, click File > Scenery Download and check whether the status is ready.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

== Internals ==
The TerraSync client first queries NAPTR records for the [[DNS]] name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the <code>.dirindex</code> files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon. The <code>.dirindex</code> files use a text-based structure, and they are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various <code>stat()</code> fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the <code>.dirindex</code> file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the <code>stat()</code> data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered.

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== References ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

TerraSync

2026-07-03T21:33:17Z

Fgf5:

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

'''TerraSync''' is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the main scenery server just in time.
TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the launcher under Settings > Additional Settings (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.b-cdn.net/osm2city/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There is a forum post: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred]

In addition, you can manually download .txz scenery files from [https://terrasync.b-cdn.net/ terrasync.b-cdn.net] and unpack them into your <code>TerraSync</code> folder correctly.

=== Some scenery objects/buildings do not appear ===
If you've already enabled them in the [[Rendering Options]] dialog, click File > Scenery Download and check whether the status is ready.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

== Internals ==
The TerraSync client first queries NAPTR records for the [[DNS]] name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the <code>.dirindex</code> files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon. The <code>.dirindex</code> files use a text-based structure, and they are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various <code>stat()</code> fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the <code>.dirindex</code> file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the <code>stat()</code> data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered.

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== Footnotes ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

DNS

2026-07-03T21:30:52Z

Fgf5:

The {{wikipedia|Domain Name System}} (DNS) is being used within FlightGear to look up resources providing several services. Its use started with version 2016.2 to resolve the location of the [[TerraSync]] servers. This page documents the used services in detail.

== FlightGear systems using DNS ==
These systems in FlightGear use DNS for service discovery:
* The TerraSync client to find a TerraSync server
* The [[Multiplayer|multiplayer]] client to list [[Howto:Set up a multiplayer server|multiplayer servers]] and retrieve information about each server

=== TerraSync ===
The [[TerraSync]] client queries {{Wikipedia|NAPTR record|NAPTR records}} for the DNS name <code>terrasync.flightgear.org</code>. From the command line <code>dig terrasync.flightgear.org ANY</code>.

As of version 2024.1, the configured entries are:
* https://terrasync.eti.pg.gda.pl/ts
* https://terrasync.b-cdn.net/osm2city/
* https://terrasync.eti.pg.gda.pl/o2c
* http://mirrors.ibiblio.org/flightgear/ftp/
* https://download.flightgear.org/
* https://us1mirror.flightgear.org/terrasync/ws2/

(There are also scenery servers not listed above, e.g., https://flightgear.sourceforge.net/scenery/.)

At start, FlightGear sends a query for the DNS name <code>terrasync.flightgear.org</code>. The URL for scenery download is encoded in the regex field between the last two exclamation marks. This string MUST start with <code>!^.*$!</code> and must end with <code>!</code>, the regex itself is not interpreted by the TerraSync client, only the fixed string is taken.
The DNS to query is currently not configurable at system start by setting a property. The version number can be changed by setting property /sim/terrasync/scenery-version to a value other than the default "ws20".

==== Algorithm to pick a Server ====
* At startup, if TerraSync is enabled and if the property /sim/terrasync/http-server is set to "automatic" (the default), a DNS query for terrasync.flightgear.org is sent and the response filtered for entries with the flag field set to "U".
* All entries that have a "order" value higher than the lowest order are discarded. (the terrasync.b-cdn.net entry as of version 2024.1)
* The remaining entries are filtered for those with the lowest preference. (both other entries survive this filter)
* a random entry from the remaining list is picked for the entire session of FlightGear.
This is implemented in <code>SGTerraSync::WorkerThread::run()</code> {{simgear source|simgear/scene/tsync/terrasync.cxx|l=441|t=here}}.

The property /sim/terrasync/http-server can be set to user defined URL pointing to the location of a custom TerraSync server e.g. <code>http://myterrasync.org/custom-scenery</code>.
This will disable the above algorithm.

=== Multiplayer ===
The multiplayer client queries {{Wikipedia|SRV record|SRV records}} for a list of multiplayer servers and {{Wikipedia|TXT record|TXT records}} on each server for detailed information about the server.

The SRV record for a multiplayer server looks like this:
_fgms._udp IN SRV 10 20 5001 mpserver01
All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance (usually 5001). The port number is 0 (zero) for inactive servers.

The TXT record for each referenced multiplayer server looks like this if you enter <code>dig mpserver01.flightgear.org TXT</code>:
mpserver01 IN TXT "flightgear-mpserver=eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo="
with the text data used as in [https://tools.ietf.org/html/rfc1464 RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes]. The attribute name flightgear-mpserver marks this entry as "ours" while it's attribute value is a base64 encoded json string containing additional attributes for the server not available within the SRV record.
For the given example, the base64 string of
eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo=
decodes to
{"name":"mpserver01","location":"Frankfurt,Germany"}

[[Category:Core development projects]]

TerraSync

2026-07-03T21:29:38Z

Fgf5: /* Internals */

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

If you have a steady and reasonably fast internet connection, you can use the built-in '''TerraSync''' instead of manually [[Howto: Install scenery|installing sceneries]]. TerraSync is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the master scenery server "just in time".
For some time now TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the launcher under Settings > Additional Settings (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.b-cdn.net/osm2city/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There is a forum post: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred]

In addition, you can manually download .txz scenery files from [https://terrasync.b-cdn.net/ terrasync.b-cdn.net] and unpack them into your <code>TerraSync</code> folder correctly.

=== Some scenery objects/buildings do not appear ===
If you've already enabled them in the [[Rendering Options]] dialog, click File > Scenery Download and check whether the status is ready.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

== Internals ==
The TerraSync client first queries NAPTR records for the [[DNS]] name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the <code>.dirindex</code> files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon. The <code>.dirindex</code> files use a text-based structure, and they are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various <code>stat()</code> fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the <code>.dirindex</code> file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the <code>stat()</code> data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered.

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== Footnotes ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

TerraSync

2026-07-03T21:29:21Z

Fgf5: /* Internals */

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

If you have a steady and reasonably fast internet connection, you can use the built-in '''TerraSync''' instead of manually [[Howto: Install scenery|installing sceneries]]. TerraSync is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the master scenery server "just in time".
For some time now TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the launcher under Settings > Additional Settings (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.b-cdn.net/osm2city/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There is a forum post: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred]

In addition, you can manually download .txz scenery files from [https://terrasync.b-cdn.net/ terrasync.b-cdn.net] and unpack them into your <code>TerraSync</code> folder correctly.

=== Some scenery objects/buildings do not appear ===
If you've already enabled them in the [[Rendering Options]] dialog, click File > Scenery Download and check whether the status is ready.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

== Internals ==
The TerraSync client first queries NAPTR records for the DNS name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the <code>.dirindex</code> files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon. The <code>.dirindex</code> files use a text-based structure, and they are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various <code>stat()</code> fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the <code>.dirindex</code> file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the <code>stat()</code> data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered.

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== Footnotes ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

Howto:Install scenery

2026-07-03T21:16:51Z

Fgf5: /* Scenery types */

{{installing}}

A default installation of [[FlightGear]] comes with a limited set of [[scenery]] to keep initial download sizes small. It includes the region around the featured airport for each release (Iceland since FlightGear 2020.1), and the area containing the airport used by the [[Cessna 172P]] tutorials (Hawaii, including PHTO). When [[TerraSync]] is enabled by default, additional scenery is automatically downloaded, installed and updated for whichever location around the globe a user visits.

This article explains '''how to manually install scenery''' for people with limited internet access, and how to install [[Howto:Install scenery#Custom scenery|custom sceneries]] that are not available through TerraSync. If you locate yourself at an airport and see nothing but water, you probably did not install that scenery area (correctly).

== Scenery types ==
There are four scenery types, in increasing level of detail:

; TerraSync scenery
: World scenery 2 terrain with constantly updated scenery objects added by fellow FlightGear users to the [[Scenery Objects Database|scenery objects database]], and worldwide [[OSM2City 1st Worldbuild|OpenStreetMap-based buildings]].
; World scenery 2 (old)
: Reasonable level of detail global scenery, with objects such as landmarks and airport buildings. It has not been updated since 2013.
; [[World Scenery 3.0|World scenery 3]]
: Experimental scenery with updated terrain, airports and objects.
; Custom scenery
: Non-official scenery covering all the way from small areas to very large areas, often with a high level of detail and up-to-date terrain and airports.

<gallery mode="packed">
File:SOTM-Sept17.jpg|Hawaii scenery - "weeping wall" waterfalls at Mount Waialeale on the island of Kauai, near PHLI
File:SOTM_2019-06_Ice_and_fire_by_vnts.jpg|Sicily scenery - the [[volcanos|volcano]] Etna snowcapped in winter with a low level eruption, near LICC
File:Bell_412_in_Iceland_(Flightgear_2019.x).jpg|Iceland scenery - having [[:Category:Screenshots_of_overlays|overlays]] enabled shows extremely high 3d detail like small rocks, plants, or individual grass blades
File:SOTM-Mar19.jpg|Madrid scenery with [[Areas_populated_with_osm2city_scenery|OSM2City output]] for Spain
</gallery>

== Obtaining scenery ==
=== TerraSync scenery ===
{{Main article|TerraSync}}

The [[TerraSync]] scenery is automatically downloaded and synchronized as needed while FlightGear is running when the built in TerraSync utility is enabled. As an alternative, especially suited for users with limited internet speeds, scenery can be prefetched before starting a flight via the [[TerraMaster]] tool.

==== Downloading with TerraMaster ====
{{Main article|TerraMaster}}

[[File:TerraMaster r32 - Global view.png|thumb|TerraSync scenery in TerraMaster]]

TerraMaster is a stand alone scenery manager that can download and synchronize TerraSync scenery. It also makes it easier to maintain and get a good overview of downloaded TerraSync scenery. It is a cross platform graphical application written in Java.

TerraMaster allows the FlightGear user to manage scenery tiles easily, selecting which tiles to download, synchronize or delete, and viewing the downloaded/not yet downloaded tiles at a glance. TerraMaster is highly recommended not only for managing scenery tiles easily especially if you are downloading and managing scenery from a computer that does not have FlightGear installed. The downloaded tiles are put into a folder which can then be loaded by FlightGear.

=== World scenery 2 ===
[[File:Worldscenery-text.jpg|thumb|World scenery tiles]]

World scenery 2 is available in tiles of 1 by 1 degree. To find an airport's coordinates and corresponding tile:

# Go to the Wikipedia page for the airport in question (e.g., {{wikipedia|Honolulu International Airport}}, PHNL).
# Find the co-ordinates (often at the top or right and side, marked with a small globe). For PHNL these are 21 N 157 W.
# Round the coordinates to their nearest multiple of 10. Round up for Southern and Western hemisphere coordinates, and round down for Northern and Eastern coordinates, as illustrated by the image. PHNL yields w160n20, while 21 N 157 E would yield e150n20. clarifies this rule.

Terrain tiles can be downloaded from [https://www.flightgear.org/download/mirror/ these mirrors]. You can manually download them from the <tt>Scenery-v2.12</tt> folder and unpack it to your local directory (e.g., TerraSync/Terrain/).

=== World scenery 3 ===
{{Main article|World Scenery 3.0}}

=== Custom scenery ===
Custom scenery is available for certain specific areas. They are distributed separately either due to being only part of a single landmass that has not been re-built completely, being work-in-progress, waiting to be integrated to Terrasync, their license, or because their level of detail is not suitable for low-end machines.

* [[Suggested Airports/Scenery]] for a list of custom scenery projects and an update on state of well developed areas.
* [[Earthview#Installing_and_using_customized_textures|Earthview high resolution]] texture packs. Earthview is FlightGear's orbital renderer. You can select the texture pack that your GPU can handle - [[Earthview#Requirements|depends]] mainly on GPU memory (VRAM).
* [[World Scenery 3.0#Currently Available Scenery|World Scenery 3.0]] for a list of custom scenery for WS3.0.

<gallery mode="packed">
File:Asia.jpg|[[Earthview]] orbital renderer at high sun - with high resolution texture packs installed.
File:SOTM_2019-04_Space_Sauna_by_GinGin.jpg|Earthview orbital renderer at low sun showing light from cities. The [[Space_Shuttle|Space Shuttle]] shows the glow from the heat of hypersonic re-entry.
</gallery>

== Installing world and custom scenery ==

Always install scenery outside the <code>[[$FG_ROOT]]</code> directory. See [[#Technical details]] below for an explanation.

{{caution|'''Do not mix scenery''' types in the '''same directory'''. It may cause problems like custom scenery being overwritten by the TerraSync or TerraMaster utilities, TerraMaster getting locked etc.}}

=== GNU/Linux ===
If you are under a Linux operation system and you are not using a graphical interface to extract the tar archive, you can use one of the two following set of commands in a shell terminal.

<syntaxhighlight lang="shell">
cd SceneryDirectory
tar -xvzf input_file.tgz
</syntaxhighlight>

or

<syntaxhighlight lang="shell">
tar -xvzf 'input_file.tgz' -C SceneryDirectory
</syntaxhighlight>

<code>input_file.tgz</code> should be substituted with the filename of the archive to be extracted (the filename should be completed with the full pathname or any other valid method so that the shell could find the correct archive).

=== Windows ===

Simply unpack the downloaded scenery into a directory of choice, using software like [http://www.winzip.com/ Winzip] or [http://www.7-zip.org 7-zip]. Once done, append this directory to <code>[[$FG_SCENERY]]</code> (in the launcher, this can be done under Add-ons > Additional scenery folders).

=== macOS ===

Unpack the .tgz file either by double-clicking it and moving the resulting <code>wXXXnXX</code> folder to the Scenery folder described in the next line, or on the command line:

<syntaxhighlight lang="shell">
tar -xvzf 'input_file.tgz' -C /Applications/FlightGear.app/Contents/Resources/data/Scenery
</syntaxhighlight>

== Technical details ==
=== Scenery lookup and $FG_SCENERY ===

FlightGear determines what scenery to use by looking at the [[Environment variables|environment variable]] (setting) <code>[[$FG SCENERY]]</code>. There can be more than one scenery path in the variable, for example one path to to TerraSync scenery and one path to custom scenery. Scenery can be overlapping and a tile will be loaded from the first path in <code>$FG SCENERY</code> from which it is available.

Should the paths in <code>$FG_SCENERY</code> not be valid, FlightGear falls back to <code>[[$FG ROOT]]/Scenery</code>.

=== Directories and configuring $FG_SCENERY ===

Mixing scenery types is almost universally a bad idea, and is unsupported. Also note that the scenery packaged with the base package/windows installer may not be the latest scenery.

For this reason it is better to extract downloaded scenery files into a new folder, which we for the sake of this exercise will call <code>$FOOBAR/Scenery</code>.
In this directory, create two subdirectories: <code>/Objects</code> and <code>/Terrain</code>. You should untar individual files into the <code>/Terrain</code> folder.

Then you should set up $FG_SCENERY to use the new path:

* In the [[Qt launcher]]:
*: Add the $FOOBAR/Scenery folder to Add-ons > Additional scenery folders.
* On POSIX Clients
*: <code>set FG_SCENERY="$FOOBAR/Scenery" + FG_SCENERY</code>
* Via a command line option
*: <code>--fg-scenery="$FOOBAR/Scenery"</code>

=== Directory structure ===
==== Terrain ====

The Scenery directory will show the following (scenery is shown for completeness and for easy reference to above):

<tt>
* Scenery/
** Terrain/
*** w130n30/
** Objects/
*** w130n30/</tt>

If you download a scenery module called <code>w90n40.tgz</code> and extract it in <code>Scenery</code>, the result will resemble something like the following:

<tt>
* Scenery/
** Terrain/
*** w09n40/
*** w130n30/
** Objects/
*** w09n40/
*** w130n30/</tt>

Note that the directory structure is already present in the tar archive, starting from the Scenery directory. Note that you have to extract the tar archive in the Scenery directory, not in the <code>$FG_ROOT</code> directory, because the Scenery directory is not present in the archive.

==== Objects ====

Objects and models can be found at the [[FlightGear Scenery Object Database]].

These objects are included in each scenery release, but as the object database is more frequently updated than the terrain, one may want to occasionally update the <code>Object</code> subdirectory from the scenery objects database between scenery releases.

Another option is to download or update the scenery on-demand by using the built in TerraSync utility described above.

Objects are really part of the scenery and can be found in the <code>Scenery</code> directory under <code>$FG ROOT</code>.

<tt>
* Scenery/
** Objects/
*** w130n30/</tt>

Any objects should be installed under the <code>Scenery/Objects</code> directory.

==== Models ====

Replaces the former <code>$FG_ROOT/Models</code>; stores all the shared objects.

<tt>
* Scenery/
** Models/
*** Airport/</tt>

==== Airports ====

{{Main article|About Scenery/Airports}}

This directory is used to extract airport data (like runway usage and parking spots) from.

The directory tree might look somewhat overwhelming, but it simply follows the <code>Airports/[I]/[C]/[A]/</code> style.
<tt>
* Scenery/
** Airports/
*** K/
**** S/
***** F/
</tt>

== Video tutorials (2020.x) ==

{{#ev:youtube|TNN_AZhaHPU|480px||Scenery installation for Flightgear 2020.x by Parnikkapore. Note this is recorded on a non-gaming laptop, and certain settings are not turned up very high.}}
{{#ev:youtube|YxWV4wk_dHw|480px||Terramaster tutorial for Flightgear by FGUK - 2017 but still valid in 2020.}}

== Related content ==
* [[Scenery FAQ]]
* [[Suggested custom scenery]]

[[Category:Scenery]]

[[ar:Howto:Install_scenery]]
[[de:Howto:Install_scenery]]
[[es:Instalación de escenarios]]
[[fr:Installer une scène]]
[[it:Come fare:Installare scenari]]
[[nl:Scenery installeren]]
[[PL:Instalowanie scenerii]]
[[pt:Instalando Cenário]]

Howto:Install scenery

2026-07-03T21:14:28Z

Fgf5: /* World scenery 2 */

{{installing}}

A default installation of [[FlightGear]] comes with a limited set of [[scenery]] to keep initial download sizes small. It includes the region around the featured airport for each release (Iceland since FlightGear 2020.1), and the area containing the airport used by the [[Cessna 172P]] tutorials (Hawaii, including PHTO). When [[TerraSync]] is enabled by default, additional scenery is automatically downloaded, installed and updated for whichever location around the globe a user visits.

This article explains '''how to manually install scenery''' for people with limited internet access, and how to install [[Howto:Install scenery#Custom scenery|custom sceneries]] that are not available through TerraSync. If you locate yourself at an airport and see nothing but water, you probably did not install that scenery area (correctly).

== Scenery types ==
There are four scenery types, in increasing level of detail:

; World scenery 2
: Reasonable level of detail global scenery, with objects such as landmarks and airport buildings. Has not been updated since 2013.
; TerraSync scenery
: World scenery 2 terrain with constantly updated scenery objects added by fellow FlightGear users to the [[Scenery Objects Database|scenery objects database]], and worldwide [[OSM2City 1st Worldbuild|OpenStreetMap-based buildings]]. Most of the terrain and airport layouts have not been updated since 2013.
; [[World Scenery 3.0|World scenery 3]]
: Experimental scenery with updated terrain, airports and objects.
; Custom scenery
: Non-official scenery covering all the way from small areas to very large areas, often with a high level of detail and up-to-date terrain and airports.

<gallery mode="packed">
File:SOTM-Sept17.jpg|Hawaii scenery - "weeping wall" waterfalls at Mount Waialeale on the island of Kauai, near PHLI
File:SOTM_2019-06_Ice_and_fire_by_vnts.jpg|Sicily scenery - the [[volcanos|volcano]] Etna snowcapped in winter with a low level eruption, near LICC
File:Bell_412_in_Iceland_(Flightgear_2019.x).jpg|Iceland scenery - having [[:Category:Screenshots_of_overlays|overlays]] enabled shows extremely high 3d detail like small rocks, plants, or individual grass blades
File:SOTM-Mar19.jpg|Madrid scenery with [[Areas_populated_with_osm2city_scenery|OSM2City output]] for Spain
</gallery>

== Obtaining scenery ==
=== TerraSync scenery ===
{{Main article|TerraSync}}

The [[TerraSync]] scenery is automatically downloaded and synchronized as needed while FlightGear is running when the built in TerraSync utility is enabled. As an alternative, especially suited for users with limited internet speeds, scenery can be prefetched before starting a flight via the [[TerraMaster]] tool.

==== Downloading with TerraMaster ====
{{Main article|TerraMaster}}

[[File:TerraMaster r32 - Global view.png|thumb|TerraSync scenery in TerraMaster]]

TerraMaster is a stand alone scenery manager that can download and synchronize TerraSync scenery. It also makes it easier to maintain and get a good overview of downloaded TerraSync scenery. It is a cross platform graphical application written in Java.

TerraMaster allows the FlightGear user to manage scenery tiles easily, selecting which tiles to download, synchronize or delete, and viewing the downloaded/not yet downloaded tiles at a glance. TerraMaster is highly recommended not only for managing scenery tiles easily especially if you are downloading and managing scenery from a computer that does not have FlightGear installed. The downloaded tiles are put into a folder which can then be loaded by FlightGear.

=== World scenery 2 ===
[[File:Worldscenery-text.jpg|thumb|World scenery tiles]]

World scenery 2 is available in tiles of 1 by 1 degree. To find an airport's coordinates and corresponding tile:

# Go to the Wikipedia page for the airport in question (e.g., {{wikipedia|Honolulu International Airport}}, PHNL).
# Find the co-ordinates (often at the top or right and side, marked with a small globe). For PHNL these are 21 N 157 W.
# Round the coordinates to their nearest multiple of 10. Round up for Southern and Western hemisphere coordinates, and round down for Northern and Eastern coordinates, as illustrated by the image. PHNL yields w160n20, while 21 N 157 E would yield e150n20. clarifies this rule.

Terrain tiles can be downloaded from [https://www.flightgear.org/download/mirror/ these mirrors]. You can manually download them from the <tt>Scenery-v2.12</tt> folder and unpack it to your local directory (e.g., TerraSync/Terrain/).

=== World scenery 3 ===
{{Main article|World Scenery 3.0}}

=== Custom scenery ===
Custom scenery is available for certain specific areas. They are distributed separately either due to being only part of a single landmass that has not been re-built completely, being work-in-progress, waiting to be integrated to Terrasync, their license, or because their level of detail is not suitable for low-end machines.

* [[Suggested Airports/Scenery]] for a list of custom scenery projects and an update on state of well developed areas.
* [[Earthview#Installing_and_using_customized_textures|Earthview high resolution]] texture packs. Earthview is FlightGear's orbital renderer. You can select the texture pack that your GPU can handle - [[Earthview#Requirements|depends]] mainly on GPU memory (VRAM).
* [[World Scenery 3.0#Currently Available Scenery|World Scenery 3.0]] for a list of custom scenery for WS3.0.

<gallery mode="packed">
File:Asia.jpg|[[Earthview]] orbital renderer at high sun - with high resolution texture packs installed.
File:SOTM_2019-04_Space_Sauna_by_GinGin.jpg|Earthview orbital renderer at low sun showing light from cities. The [[Space_Shuttle|Space Shuttle]] shows the glow from the heat of hypersonic re-entry.
</gallery>

== Installing world and custom scenery ==

Always install scenery outside the <code>[[$FG_ROOT]]</code> directory. See [[#Technical details]] below for an explanation.

{{caution|'''Do not mix scenery''' types in the '''same directory'''. It may cause problems like custom scenery being overwritten by the TerraSync or TerraMaster utilities, TerraMaster getting locked etc.}}

=== GNU/Linux ===
If you are under a Linux operation system and you are not using a graphical interface to extract the tar archive, you can use one of the two following set of commands in a shell terminal.

<syntaxhighlight lang="shell">
cd SceneryDirectory
tar -xvzf input_file.tgz
</syntaxhighlight>

or

<syntaxhighlight lang="shell">
tar -xvzf 'input_file.tgz' -C SceneryDirectory
</syntaxhighlight>

<code>input_file.tgz</code> should be substituted with the filename of the archive to be extracted (the filename should be completed with the full pathname or any other valid method so that the shell could find the correct archive).

=== Windows ===

Simply unpack the downloaded scenery into a directory of choice, using software like [http://www.winzip.com/ Winzip] or [http://www.7-zip.org 7-zip]. Once done, append this directory to <code>[[$FG_SCENERY]]</code> (in the launcher, this can be done under Add-ons > Additional scenery folders).

=== macOS ===

Unpack the .tgz file either by double-clicking it and moving the resulting <code>wXXXnXX</code> folder to the Scenery folder described in the next line, or on the command line:

<syntaxhighlight lang="shell">
tar -xvzf 'input_file.tgz' -C /Applications/FlightGear.app/Contents/Resources/data/Scenery
</syntaxhighlight>

== Technical details ==
=== Scenery lookup and $FG_SCENERY ===

FlightGear determines what scenery to use by looking at the [[Environment variables|environment variable]] (setting) <code>[[$FG SCENERY]]</code>. There can be more than one scenery path in the variable, for example one path to to TerraSync scenery and one path to custom scenery. Scenery can be overlapping and a tile will be loaded from the first path in <code>$FG SCENERY</code> from which it is available.

Should the paths in <code>$FG_SCENERY</code> not be valid, FlightGear falls back to <code>[[$FG ROOT]]/Scenery</code>.

=== Directories and configuring $FG_SCENERY ===

Mixing scenery types is almost universally a bad idea, and is unsupported. Also note that the scenery packaged with the base package/windows installer may not be the latest scenery.

For this reason it is better to extract downloaded scenery files into a new folder, which we for the sake of this exercise will call <code>$FOOBAR/Scenery</code>.
In this directory, create two subdirectories: <code>/Objects</code> and <code>/Terrain</code>. You should untar individual files into the <code>/Terrain</code> folder.

Then you should set up $FG_SCENERY to use the new path:

* In the [[Qt launcher]]:
*: Add the $FOOBAR/Scenery folder to Add-ons > Additional scenery folders.
* On POSIX Clients
*: <code>set FG_SCENERY="$FOOBAR/Scenery" + FG_SCENERY</code>
* Via a command line option
*: <code>--fg-scenery="$FOOBAR/Scenery"</code>

=== Directory structure ===
==== Terrain ====

The Scenery directory will show the following (scenery is shown for completeness and for easy reference to above):

<tt>
* Scenery/
** Terrain/
*** w130n30/
** Objects/
*** w130n30/</tt>

If you download a scenery module called <code>w90n40.tgz</code> and extract it in <code>Scenery</code>, the result will resemble something like the following:

<tt>
* Scenery/
** Terrain/
*** w09n40/
*** w130n30/
** Objects/
*** w09n40/
*** w130n30/</tt>

Note that the directory structure is already present in the tar archive, starting from the Scenery directory. Note that you have to extract the tar archive in the Scenery directory, not in the <code>$FG_ROOT</code> directory, because the Scenery directory is not present in the archive.

==== Objects ====

Objects and models can be found at the [[FlightGear Scenery Object Database]].

These objects are included in each scenery release, but as the object database is more frequently updated than the terrain, one may want to occasionally update the <code>Object</code> subdirectory from the scenery objects database between scenery releases.

Another option is to download or update the scenery on-demand by using the built in TerraSync utility described above.

Objects are really part of the scenery and can be found in the <code>Scenery</code> directory under <code>$FG ROOT</code>.

<tt>
* Scenery/
** Objects/
*** w130n30/</tt>

Any objects should be installed under the <code>Scenery/Objects</code> directory.

==== Models ====

Replaces the former <code>$FG_ROOT/Models</code>; stores all the shared objects.

<tt>
* Scenery/
** Models/
*** Airport/</tt>

==== Airports ====

{{Main article|About Scenery/Airports}}

This directory is used to extract airport data (like runway usage and parking spots) from.

The directory tree might look somewhat overwhelming, but it simply follows the <code>Airports/[I]/[C]/[A]/</code> style.
<tt>
* Scenery/
** Airports/
*** K/
**** S/
***** F/
</tt>

== Video tutorials (2020.x) ==

{{#ev:youtube|TNN_AZhaHPU|480px||Scenery installation for Flightgear 2020.x by Parnikkapore. Note this is recorded on a non-gaming laptop, and certain settings are not turned up very high.}}
{{#ev:youtube|YxWV4wk_dHw|480px||Terramaster tutorial for Flightgear by FGUK - 2017 but still valid in 2020.}}

== Related content ==
* [[Scenery FAQ]]
* [[Suggested custom scenery]]

[[Category:Scenery]]

[[ar:Howto:Install_scenery]]
[[de:Howto:Install_scenery]]
[[es:Instalación de escenarios]]
[[fr:Installer une scène]]
[[it:Come fare:Installare scenari]]
[[nl:Scenery installeren]]
[[PL:Instalowanie scenerii]]
[[pt:Instalando Cenário]]

Suggested custom scenery

2026-07-03T21:12:12Z

Fgf5:

Besides the official TerraSync scenery that is automatically synced while FlightGear is running, there are a number of custom sceneries available, created by users for beautifying some specific areas of the scenery. This page is a list of some '''suggested custom scenery''' for downloading and visiting. This list can not be complete as custom sceneries might come and go. It's worth to search the forum for additional custom sceneries.

Since FlightGear 2020.3.7, buildings, roads, pylons, and other objects are ''automatically'' downloaded, based on Open Street Map (OSM) data - see [[OSM2City 1st Worldbuild|OSM2City 1st world build]]. You don't have to download OSM2City custom sceneries for these anymore. However, you need to enable them in the [[Rendering Options]] menu.

* See '''[[Suggested_airports]]''' for a quick list of featured airports situated in well developed regions, with links to OSM2City scenery. It's suitable for newcomers to start at to explore surrounding regions. (March 2020)

* '''OSM2City scenery''' buildings, roads, pylons, and other objects, for the whole planet is now on TerraSync, and ''automatically downloaded'' by FlightGear. The current OSM2City output on TerraSync is from the [[Osm2city_worldbuild|1st world build of OSM2City]] scenery ([https://forum.flightgear.org/viewtopic.php?f=5&t=35581 forum thread]). Custom sceneries for countries and regions are available [[Areas_populated_with_osm2city_scenery|'''here''']]. Note: Old custom sceneries (before March 2021) will contain folders for OSM2City output like Buildings, Roads or Pylons with outdated and obsolete objects. These folders will override the new higher quality and faster rendering objects from TerraSync. Remember to remove these from your custom scenery folder list! If your custom scenery contains sub-folders that are not obsolete, like Terrain, you can leave these alone and only delete OSM2City sub-folders in your custom scenery folder. There are some OSM2City custom sceneries that are not obsolete - these have builds of OSM2City with different options from the 1st worldbuild - for example, custom scenery with auto-generation on in areas without good OSM coverage like the Hawaii custom scenery.

* '''[[:Category:Scenery_enhancement_projects|Custom terrain & region definition projects]]''': There are ongoing scenery enhancement projects to update both regional definitions and terrain in large areas like the [[Australia_Custom_Scenery|Australia]] (regional definitions are planned to be added to FG core). This a partial list, search the '''[https://forum.flightgear.org/viewforum.php?f=5 scenery forum]''' for details. Some of the output of projects like Hawaii terrain has already been integrated into Terrasync.

* Terrasync scenery which is automatically downloaded has high resolution terrain. All of Europe currently has high resolution terrain from CORINE data. A lot of old pre-world scenery 2 may be obsolete.

* Status of terrain in custom sceneries: The page as it stands is missing almost all custom terrain. Some old island custom sceneries have been merged into the automatically downloaded sceneries terrasync. [[User:Wlbragg#Kansas_Custom_Scenery|Kansas/Midwest]] and [[US-Tennessee_Custom_Scenery|Tennessee]] are two examples of custom sceneries that aren't obsolete (March 2020).

:: ''If you are the creator of an island scenery you can add it to [[TerraSync]] by contacting the flightgear-devel [[Mailing_lists|mailing list]]''.

* [[Project3000]] adds a lot of clutter and buildings to airports which do not have models or details. It's a must have. It is planned to be integrated into the FG core eventually. [https://forum.flightgear.org/viewtopic.php?f=5&t=27688 Forum thread]. (March 2020)

== New scenery for the Americas (January 2024) ==

[[File:Cygd-c140-winter.jpg|thumb|New FlightGear Americas scenery, approaching Georgian Bay (Lake Huron) in winter. Note the detail for inland water.]]
New scenery is available for all of the Americas, including islands geographically or politically associated with them (such as Greenland, the Hawaiian Islands, Bermuda, and the Galapagos). This is intended to replace the current default TerraGear scenery as soon as we're ready to rebuild osm2city for it. The scenery includes many more airports (5-10x as many as the default scenery, most with correct taxiways and aprons), detailed inland water, and detailed 30m digital elevations. See [[FlightGear Americas Scenery (custom)]] for download details.

This scenery is suitable for use as a default to fill in the gaps between some of the more-detailed custom-scenery areas listed below.

== Custom scenery (May 2021) ==

''This is only a fraction of available scenery (May 2021). Search the [https://forum.flightgear.org/viewforum.php?f=5 scenery forum] for more.''

''See [[Howto:Install_scenery|How to install custom scenery packages]].''

* '''USA, Tennessee:''' custom scenery for Tennessee by [[User:Scttgs|Scott Giese]](xDraconianx). This is very high resolution scenery created to test potential resolution & performance for the next world scenery build. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=35521 forum thread] for feedback and more info. See the [[US-Tennessee_Custom_Scenery|wiki page]] for downloads. (March 2020)

<gallery mode="packed">
File:US-Tennessee-EastCentral.jpg
File:US-Tennessee-West.jpg
File:US-Tennessee-East.jpg
File:US-Tennessee-WestCentral.jpg
</gallery>

* '''USA, Kansas & Ohio:''' custom scenery for the entire states of Kansas and Ohio created by [[User:Wlbragg|Wlbragg]]. This high resolution scenery includes textures. See the [[User:Wlbragg#Kansas_Custom_Scenery|wiki page]] for downloads and info. (March 2020)

<gallery mode="packed">
File:Kansas_Scenery_Two.jpg
File:KDAY_James_M._Cox_Dayton_International_Airport.jpg
File:Kansas_Scenery_One.jpg
File:Kansas_Scenery_Three.jpg
</gallery>

* '''Scandinavia''': custom scenery covering Scandinavian countries such as Norway, Sweden, and Finland by [[User:D-ECHO|D-ECHO]]. Norway and Sweden have some of the most detailed regional definitions using recent engine features. This custom scenery project further improves it by mainly adding more detailed land type classification, digital elevation data, as well as updated airports. As of March 2020 it updates parts of these countries. See the [[Scandinavia Custom Scenery]] page for download and details.

* '''USA, Pennsylvania, New Jersey, and New York City''': custom scenery for these Eastern US states by montagdude. See [https://forum.flightgear.org/viewtopic.php?f=5&t=38041 forum thread]. Contains custom terrain, OSM2City, and custom materials. (September 2020)

<gallery mode="packed">
File:Ec135-manhattan.jpg
File:Pa28-wilkes-barre.jpg
File:C182s-atlantic-city.jpg
File:Dr400-philadelphia.jpg
</gallery>

* '''USA, Virginia, Maryland, Delaware, and the District of Columbia''': custom scenery for these Mid-Atlantic US states by montagdude. See [https://forum.flightgear.org/viewtopic.php?f=5&t=37322 forum thread]. Contains custom terrain, OSM2City, and custom materials. (April 2020)

* '''USA, Rhode Island and southeastern Massachusetts''': custom scenery for Rhode Island and southeastern parts of the state of Massachusetts by montagdude. See [https://forum.flightgear.org/viewtopic.php?f=5&t=36977 forum thread]. Contains OSM2City. (March 2020)

* '''USA, Champaign, Chicago, Milwaukee and surrounding areas''': custom scenery for Champaign, Bloomington, Chicago, Milwaukee and northern Illinois by pb321. See [https://forum.flightgear.org/viewtopic.php?f=5&t=39209 forum thread] and to report issues. Contains OSM2City and (optional) color corrected USGS orthophotos. (May 2021)
<gallery mode="packed">
File:KPWK-Chicago_Executive.jpg
File:ChicagoAM-OrthoCropped.jpg
File:Approaching KMKE.jpg
</gallery>

* '''USA, Oshkosh, Green Bay, U.P. of Michigan and surrounding areas''': custom scenery for Oshkosh, Appleton, Green Bay and the central Upper Peninsula of Michigan by pb321. See [https://forum.flightgear.org/viewtopic.php?f=5&t=39264 forum thread] and to report issues. Contains OSM2City and (optional) color corrected USGS orthophotos. (May 2021)
<gallery mode="packed">
File:GreenBayNorth.jpg
File:Near Houghton MIa.jpg
File:MarquetteA.jpg
</gallery>

* '''Venezuela: [[Project Venezuela]]:''' custom scenery for Venezuela by [[User:Legoboyvdlp|J. Redpath]], with improved airport layouts, and objects at several airports. Highly improved over TerraSync status. (March 2020)

* '''Canary Islands:''' custom scenery for the Canary Islands by [[User:D-ECHO|D-ECHO]] with improved terrain, objects, vegetation, building, reworked airports, mostly with buildings and furniture. Check out the [[Canary_Islands_Custom_Scenery|wiki page]]. (March 2020)

<gallery mode="packed">
GCLP-1.jpg
GCLP-2.jpg
GCLP-3.jpg
</gallery>

* '''Argentina''': OSM-based custom scenery for Argentina and parts of Chile and Uruguay by Barta.<br/>Updated airports, landcover from OSM polygons, line data and objects using Osm2City. Updated frequently!<br/>Downloads:
:: All output: [http://scenery.bartatech.net/ http://scenery.bartatech.net/] . As of July 2020 these areas are available: Santiago (including Valparaiso), Mendoza, Buenos Aires, complete Rosario area. The other parts only have terrain (no roads, buildings etc). The server will eventually contain all of the sceneries in the southern cone of South America: Argentina, Chile, Uruguay.
::: It's possible to use the [http://scenery.bartatech.net/ scenery.bartatech.net] server directly as a Terrasync server. Just use the following in the [[FlightGear_Qt_launcher|launcher]] or .fgfsrc file:
::: ''--prop:/sim/terrasync/http-server=<nowiki>http://scenery.bartatech.net/</nowiki>''
:: Buenos Aires province: https://github.com/bartacruz/scenery-6040
:: Cuyo Area + Santiago: https://github.com/bartacruz/scenery-cuyo

* '''USA, Florida''': custom scenery for Florida by [[User:Legoboyvdlp|J. Redpath]] with both terrain and OSM2City. It also covers the [[Space Shuttle]] landing site at [[Shuttle_Landing_Facility|KTTS]]. See the [https://github.com/legoboyvdlp/Florida-fg-CustomScenery repository] downloads section for the [https://github.com/legoboyvdlp/Florida-fg-CustomScenery/archive/master.zip zip-file].

* '''London, England''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the London area including an improved Gatwick Airport (ICAO: EGKK). See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37444 forum thread] and [https://github.com/legoboyvdlp/London-fg-CustomScenery repository] downloads section for the [https://github.com/legoboyvdlp/London-fg-CustomScenery/archive/master.zip zip-file].

* '''Moscow area, Russia''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the Moscow area covering 14 tiles. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for the github [https://github.com/legoboyvdlp/Moscow-fg-CustomScenery/archive/master.zip download]. (August 2020)

* '''Valdivostock area, Russia''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the Vadivostock area. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for the github [https://github.com/legoboyvdlp/Vladivostok-fg-CustomScenery/archive/master.zip download]. (August 2020)

* '''Eastern China''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the eastern portion of China covering the area around ZSAM and ZSNJ airports. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for the github [https://github.com/legoboyvdlp/EastChina-fg-CustomScenery/archive/master.zip download]. (August 2020)

* '''Beijing area, China''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the area around Beijing covering 15 tiles. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for the github [https://github.com/legoboyvdlp/Beijing-fg-CustomScenery/archive/master.zip download]. (August 2020)

* '''Sri Lanka''': 2019 custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the island of Sri Lanka in the Indian ocean including rebuilt terrain, OSM2City output, and improved airports. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for github [https://codeload.github.com/legoboyvdlp/SriLanka-fg-CustomScenery/zip/master download].
* '''Dominican Republic:''' 2021 custom scenery by flc972 for [[Gregorio Luperon International Airport]] (MDPP) with detailed modeling of interiors, night lightmaps, ground net and animated jetways as well as some terrain. The airport is located on the Caribbean island of Hispaniola. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=39179 forum thread] for bitbucket [https://bitbucket.org/fableb/flcs-mdpp_airport/downloads/ download] .
* '''Turkey:''' custom scenery including 12 airports. Can be downloaded from https://github.com/Klaudiae/FGCompanion-TurkeyEnhanced
* '''Turkey, Şanlıurfa:''' custom scenery by TheFGFSEagle. Can be downloaded from https://github.com/TheFGFSEagle/LTCS-scenery
* '''Poland:''' custom scenery including 14 airports. Can be downloaded from https://github.com/Klaudiae/FGCompanion-PolandEnhanced

== Custom scenery set to be merged into TerraSync and FGData ==

''These are now in the process of being merged. If you know of custom sceneries of islands or complete landmasses that have not been merged yet, contact the developers. (March 2021).''
* New Zealand scenery ([https://forum.flightgear.org/viewtopic.php?f=5&t=36892 forum thread]). (March 2020)
* [[Australia_Custom_Scenery|Australian custom scenery project]] output - Regional definitions, and textures. See these forum threads for download and details: [https://forum.flightgear.org/viewtopic.php?f=5&t=36145 official thread], demo scenery [https://forum.flightgear.org/viewtopic.php?f=19&t=36956 install details (March 2020)]. A partially completed Sydney airport (YSSY) is also available for download. The terrain in the demo scenery release is likely to be merged when a re-build of Australia is done.
* All Channel Islands (Jersey, Guernsey, Alderney, Sark, etc) ([https://github.com/legoboyvdlp/Jersey-fg-CustomScenery github]). (March 2020).
* Sri Lanka, [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] and [https://github.com/legoboyvdlp/SriLanka-fg-CustomScenery Github]

== Custom scenery which has been merged into TerraSync and FGData ==

''You can remove old scenery folders containing known merged sceneries from your [[Howto:Install_scenery|scenery folder list]].''

* Islands merged recently (2018-2019): Hawaii, Iceland, Island of Jan Mayen (Norway)

== Old and undetermined custom scenery ==

''Some of these may have been obsoleted by the release of the [[FlightGear World Scenery 2.0|new world scenery in November 2013]].''

''Please move sceneries that aren't obsolete into other categories.''

* '''France''': Custom scenery for France with improved landcover information and more detailed elevation information (no improvements on the objects) is under development. See the [[Custom France Scenery|Custom France Scenery page]]. (Pre WS 2.0)

<gallery>
Image:High_textures_transitions3.png|High detail France scenery
Image:High_textures_transitions4_1.png|High detail France scenery
Image:High_textures_transitions6_2.png|High detail France scenery
Image:High_textures_transitions10_1.png|Mont Blanc
Image:High_textures_transitions11_1.png|Aguille du midi?
Image:High_textures_transitions13_1.png|Matterhorn without landclass, just slope transitions
</gallery>

* '''Innsbruck (Austria) area''': The scenery currently covers a 1x1 degree area containing parts of Austria and Germany, and makes use of accurate data from the Corine Land Cover, and Open Street Map projects. See [http://forum.flightgear.org/viewtopic.php?f=5&t=5350 this forum post] and [[FlightGear Newsletter August 2009#Innsbruck Gets A Face Lift|the August 2009 newsletter]] for details. (Pre WS 2.0)

* '''LOWI & Austria Scenery Preview''': This scenery includes the Innsbruck scenario and is much more complete than the previous. It is still experimental, but should try it as having been really good. Info and download can be found [[Innsbruck Airport|here]].

* '''Iberian Peninsula: Spain and Portugal''': custom scenery for Spain and Portugal with improved landcover and additional airports and objects. See the [[Custom Spain and Portugal Scenery|custom Spain and Portugal scenery page]].

* '''EDDK''': Custom scenery for the Cologne/Bonn airport in Germany with very nice and realistic terminal buildings. Available from https://github.com/mherweg/EDDK-fg-CustomScenery.

* '''Argentina''': OSM-based custom scenery for Argentina and parts of Chile and Uruguay.<br/>Updated airports, landcover from OSM polygons, line data and objects using Osm2City. Updated frequently!<br/>Downloads:
** Buenos Aires province: https://github.com/bartacruz/scenery-6040
** Cuyo Area + Santiago: https://github.com/bartacruz/scenery-cuyo

== Related content ==
* [[Howto:Improve scenery in your area, or area of interest]]

{{suggested}}

[[Category:Custom scenery]]

Howto:Install scenery

2026-07-03T21:11:22Z

Fgf5: /* Airports */

{{installing}}

A default installation of [[FlightGear]] comes with a limited set of [[scenery]] to keep initial download sizes small. It includes the region around the featured airport for each release (Iceland since FlightGear 2020.1), and the area containing the airport used by the [[Cessna 172P]] tutorials (Hawaii, including PHTO). When [[TerraSync]] is enabled by default, additional scenery is automatically downloaded, installed and updated for whichever location around the globe a user visits.

This article explains '''how to manually install scenery''' for people with limited internet access, and how to install [[Howto:Install scenery#Custom scenery|custom sceneries]] that are not available through TerraSync. If you locate yourself at an airport and see nothing but water, you probably did not install that scenery area (correctly).

== Scenery types ==
There are four scenery types, in increasing level of detail:

; World scenery 2
: Reasonable level of detail global scenery, with objects such as landmarks and airport buildings. Has not been updated since 2013.
; TerraSync scenery
: World scenery 2 terrain with constantly updated scenery objects added by fellow FlightGear users to the [[Scenery Objects Database|scenery objects database]], and worldwide [[OSM2City 1st Worldbuild|OpenStreetMap-based buildings]]. Most of the terrain and airport layouts have not been updated since 2013.
; [[World Scenery 3.0|World scenery 3]]
: Experimental scenery with updated terrain, airports and objects.
; Custom scenery
: Non-official scenery covering all the way from small areas to very large areas, often with a high level of detail and up-to-date terrain and airports.

<gallery mode="packed">
File:SOTM-Sept17.jpg|Hawaii scenery - "weeping wall" waterfalls at Mount Waialeale on the island of Kauai, near PHLI
File:SOTM_2019-06_Ice_and_fire_by_vnts.jpg|Sicily scenery - the [[volcanos|volcano]] Etna snowcapped in winter with a low level eruption, near LICC
File:Bell_412_in_Iceland_(Flightgear_2019.x).jpg|Iceland scenery - having [[:Category:Screenshots_of_overlays|overlays]] enabled shows extremely high 3d detail like small rocks, plants, or individual grass blades
File:SOTM-Mar19.jpg|Madrid scenery with [[Areas_populated_with_osm2city_scenery|OSM2City output]] for Spain
</gallery>

== Obtaining scenery ==
=== TerraSync scenery ===
{{Main article|TerraSync}}

The [[TerraSync]] scenery is automatically downloaded and synchronized as needed while FlightGear is running when the built in TerraSync utility is enabled. As an alternative, especially suited for users with limited internet speeds, scenery can be prefetched before starting a flight via the [[TerraMaster]] tool.

==== Downloading with TerraMaster ====
{{Main article|TerraMaster}}

[[File:TerraMaster r32 - Global view.png|thumb|TerraSync scenery in TerraMaster]]

TerraMaster is a stand alone scenery manager that can download and synchronize TerraSync scenery. It also makes it easier to maintain and get a good overview of downloaded TerraSync scenery. It is a cross platform graphical application written in Java.

TerraMaster allows the FlightGear user to manage scenery tiles easily, selecting which tiles to download, synchronize or delete, and viewing the downloaded/not yet downloaded tiles at a glance. TerraMaster is highly recommended not only for managing scenery tiles easily especially if you are downloading and managing scenery from a computer that does not have FlightGear installed. The downloaded tiles are put into a folder which can then be loaded by FlightGear.

=== World scenery 2 ===
[[File:Worldscenery-text.jpg|thumb|World scenery tiles]]

World scenery 2 is available in tiles of 1 by 1 degree. To find an airport's coordinates and corresponding tile:

# Go to the Wikipedia page for the airport in question (e.g., {{wikipedia|Honolulu International Airport}}, PHNL).
# Find the co-ordinates (often at the top or right and side, marked with a small globe). For PHNL these are 21 N 157 W.
# Round the coordinates to their nearest multiple of 10. Round up for Southern and Western hemisphere coordinates, and round down for Northern and Eastern coordinates, as illustrated by the image. PHNL yields w160n20, while 21 N 157 E would yield e150n20. clarifies this rule.

Terrain tiles can be downloaded from [https://www.flightgear.org/download/mirror/ these mirrors]. You can manually download them from the <tt>Scenery-v2.12</tt> folder and unpack it to the local TerraSync/Terrain/ directory.

=== World scenery 3 ===
{{Main article|World Scenery 3.0}}

=== Custom scenery ===
Custom scenery is available for certain specific areas. They are distributed separately either due to being only part of a single landmass that has not been re-built completely, being work-in-progress, waiting to be integrated to Terrasync, their license, or because their level of detail is not suitable for low-end machines.

* [[Suggested Airports/Scenery]] for a list of custom scenery projects and an update on state of well developed areas.
* [[Earthview#Installing_and_using_customized_textures|Earthview high resolution]] texture packs. Earthview is FlightGear's orbital renderer. You can select the texture pack that your GPU can handle - [[Earthview#Requirements|depends]] mainly on GPU memory (VRAM).
* [[World Scenery 3.0#Currently Available Scenery|World Scenery 3.0]] for a list of custom scenery for WS3.0.

<gallery mode="packed">
File:Asia.jpg|[[Earthview]] orbital renderer at high sun - with high resolution texture packs installed.
File:SOTM_2019-04_Space_Sauna_by_GinGin.jpg|Earthview orbital renderer at low sun showing light from cities. The [[Space_Shuttle|Space Shuttle]] shows the glow from the heat of hypersonic re-entry.
</gallery>

== Installing world and custom scenery ==

Always install scenery outside the <code>[[$FG_ROOT]]</code> directory. See [[#Technical details]] below for an explanation.

{{caution|'''Do not mix scenery''' types in the '''same directory'''. It may cause problems like custom scenery being overwritten by the TerraSync or TerraMaster utilities, TerraMaster getting locked etc.}}

=== GNU/Linux ===
If you are under a Linux operation system and you are not using a graphical interface to extract the tar archive, you can use one of the two following set of commands in a shell terminal.

<syntaxhighlight lang="shell">
cd SceneryDirectory
tar -xvzf input_file.tgz
</syntaxhighlight>

or

<syntaxhighlight lang="shell">
tar -xvzf 'input_file.tgz' -C SceneryDirectory
</syntaxhighlight>

<code>input_file.tgz</code> should be substituted with the filename of the archive to be extracted (the filename should be completed with the full pathname or any other valid method so that the shell could find the correct archive).

=== Windows ===

Simply unpack the downloaded scenery into a directory of choice, using software like [http://www.winzip.com/ Winzip] or [http://www.7-zip.org 7-zip]. Once done, append this directory to <code>[[$FG_SCENERY]]</code> (in the launcher, this can be done under Add-ons > Additional scenery folders).

=== macOS ===

Unpack the .tgz file either by double-clicking it and moving the resulting <code>wXXXnXX</code> folder to the Scenery folder described in the next line, or on the command line:

<syntaxhighlight lang="shell">
tar -xvzf 'input_file.tgz' -C /Applications/FlightGear.app/Contents/Resources/data/Scenery
</syntaxhighlight>

== Technical details ==
=== Scenery lookup and $FG_SCENERY ===

FlightGear determines what scenery to use by looking at the [[Environment variables|environment variable]] (setting) <code>[[$FG SCENERY]]</code>. There can be more than one scenery path in the variable, for example one path to to TerraSync scenery and one path to custom scenery. Scenery can be overlapping and a tile will be loaded from the first path in <code>$FG SCENERY</code> from which it is available.

Should the paths in <code>$FG_SCENERY</code> not be valid, FlightGear falls back to <code>[[$FG ROOT]]/Scenery</code>.

=== Directories and configuring $FG_SCENERY ===

Mixing scenery types is almost universally a bad idea, and is unsupported. Also note that the scenery packaged with the base package/windows installer may not be the latest scenery.

For this reason it is better to extract downloaded scenery files into a new folder, which we for the sake of this exercise will call <code>$FOOBAR/Scenery</code>.
In this directory, create two subdirectories: <code>/Objects</code> and <code>/Terrain</code>. You should untar individual files into the <code>/Terrain</code> folder.

Then you should set up $FG_SCENERY to use the new path:

* In the [[Qt launcher]]:
*: Add the $FOOBAR/Scenery folder to Add-ons > Additional scenery folders.
* On POSIX Clients
*: <code>set FG_SCENERY="$FOOBAR/Scenery" + FG_SCENERY</code>
* Via a command line option
*: <code>--fg-scenery="$FOOBAR/Scenery"</code>

=== Directory structure ===
==== Terrain ====

The Scenery directory will show the following (scenery is shown for completeness and for easy reference to above):

<tt>
* Scenery/
** Terrain/
*** w130n30/
** Objects/
*** w130n30/</tt>

If you download a scenery module called <code>w90n40.tgz</code> and extract it in <code>Scenery</code>, the result will resemble something like the following:

<tt>
* Scenery/
** Terrain/
*** w09n40/
*** w130n30/
** Objects/
*** w09n40/
*** w130n30/</tt>

Note that the directory structure is already present in the tar archive, starting from the Scenery directory. Note that you have to extract the tar archive in the Scenery directory, not in the <code>$FG_ROOT</code> directory, because the Scenery directory is not present in the archive.

==== Objects ====

Objects and models can be found at the [[FlightGear Scenery Object Database]].

These objects are included in each scenery release, but as the object database is more frequently updated than the terrain, one may want to occasionally update the <code>Object</code> subdirectory from the scenery objects database between scenery releases.

Another option is to download or update the scenery on-demand by using the built in TerraSync utility described above.

Objects are really part of the scenery and can be found in the <code>Scenery</code> directory under <code>$FG ROOT</code>.

<tt>
* Scenery/
** Objects/
*** w130n30/</tt>

Any objects should be installed under the <code>Scenery/Objects</code> directory.

==== Models ====

Replaces the former <code>$FG_ROOT/Models</code>; stores all the shared objects.

<tt>
* Scenery/
** Models/
*** Airport/</tt>

==== Airports ====

{{Main article|About Scenery/Airports}}

This directory is used to extract airport data (like runway usage and parking spots) from.

The directory tree might look somewhat overwhelming, but it simply follows the <code>Airports/[I]/[C]/[A]/</code> style.
<tt>
* Scenery/
** Airports/
*** K/
**** S/
***** F/
</tt>

== Video tutorials (2020.x) ==

{{#ev:youtube|TNN_AZhaHPU|480px||Scenery installation for Flightgear 2020.x by Parnikkapore. Note this is recorded on a non-gaming laptop, and certain settings are not turned up very high.}}
{{#ev:youtube|YxWV4wk_dHw|480px||Terramaster tutorial for Flightgear by FGUK - 2017 but still valid in 2020.}}

== Related content ==
* [[Scenery FAQ]]
* [[Suggested custom scenery]]

[[Category:Scenery]]

[[ar:Howto:Install_scenery]]
[[de:Howto:Install_scenery]]
[[es:Instalación de escenarios]]
[[fr:Installer une scène]]
[[it:Come fare:Installare scenari]]
[[nl:Scenery installeren]]
[[PL:Instalowanie scenerii]]
[[pt:Instalando Cenário]]

Howto:Install scenery

2026-07-03T21:10:55Z

Fgf5: /* Obtaining scenery */

{{installing}}

A default installation of [[FlightGear]] comes with a limited set of [[scenery]] to keep initial download sizes small. It includes the region around the featured airport for each release (Iceland since FlightGear 2020.1), and the area containing the airport used by the [[Cessna 172P]] tutorials (Hawaii, including PHTO). When [[TerraSync]] is enabled by default, additional scenery is automatically downloaded, installed and updated for whichever location around the globe a user visits.

This article explains '''how to manually install scenery''' for people with limited internet access, and how to install [[Howto:Install scenery#Custom scenery|custom sceneries]] that are not available through TerraSync. If you locate yourself at an airport and see nothing but water, you probably did not install that scenery area (correctly).

== Scenery types ==
There are four scenery types, in increasing level of detail:

; World scenery 2
: Reasonable level of detail global scenery, with objects such as landmarks and airport buildings. Has not been updated since 2013.
; TerraSync scenery
: World scenery 2 terrain with constantly updated scenery objects added by fellow FlightGear users to the [[Scenery Objects Database|scenery objects database]], and worldwide [[OSM2City 1st Worldbuild|OpenStreetMap-based buildings]]. Most of the terrain and airport layouts have not been updated since 2013.
; [[World Scenery 3.0|World scenery 3]]
: Experimental scenery with updated terrain, airports and objects.
; Custom scenery
: Non-official scenery covering all the way from small areas to very large areas, often with a high level of detail and up-to-date terrain and airports.

<gallery mode="packed">
File:SOTM-Sept17.jpg|Hawaii scenery - "weeping wall" waterfalls at Mount Waialeale on the island of Kauai, near PHLI
File:SOTM_2019-06_Ice_and_fire_by_vnts.jpg|Sicily scenery - the [[volcanos|volcano]] Etna snowcapped in winter with a low level eruption, near LICC
File:Bell_412_in_Iceland_(Flightgear_2019.x).jpg|Iceland scenery - having [[:Category:Screenshots_of_overlays|overlays]] enabled shows extremely high 3d detail like small rocks, plants, or individual grass blades
File:SOTM-Mar19.jpg|Madrid scenery with [[Areas_populated_with_osm2city_scenery|OSM2City output]] for Spain
</gallery>

== Obtaining scenery ==
=== TerraSync scenery ===
{{Main article|TerraSync}}

The [[TerraSync]] scenery is automatically downloaded and synchronized as needed while FlightGear is running when the built in TerraSync utility is enabled. As an alternative, especially suited for users with limited internet speeds, scenery can be prefetched before starting a flight via the [[TerraMaster]] tool.

==== Downloading with TerraMaster ====
{{Main article|TerraMaster}}

[[File:TerraMaster r32 - Global view.png|thumb|TerraSync scenery in TerraMaster]]

TerraMaster is a stand alone scenery manager that can download and synchronize TerraSync scenery. It also makes it easier to maintain and get a good overview of downloaded TerraSync scenery. It is a cross platform graphical application written in Java.

TerraMaster allows the FlightGear user to manage scenery tiles easily, selecting which tiles to download, synchronize or delete, and viewing the downloaded/not yet downloaded tiles at a glance. TerraMaster is highly recommended not only for managing scenery tiles easily especially if you are downloading and managing scenery from a computer that does not have FlightGear installed. The downloaded tiles are put into a folder which can then be loaded by FlightGear.

=== World scenery 2 ===
[[File:Worldscenery-text.jpg|thumb|World scenery tiles]]

World scenery 2 is available in tiles of 1 by 1 degree. To find an airport's coordinates and corresponding tile:

# Go to the Wikipedia page for the airport in question (e.g., {{wikipedia|Honolulu International Airport}}, PHNL).
# Find the co-ordinates (often at the top or right and side, marked with a small globe). For PHNL these are 21 N 157 W.
# Round the coordinates to their nearest multiple of 10. Round up for Southern and Western hemisphere coordinates, and round down for Northern and Eastern coordinates, as illustrated by the image. PHNL yields w160n20, while 21 N 157 E would yield e150n20. clarifies this rule.

Terrain tiles can be downloaded from [https://www.flightgear.org/download/mirror/ these mirrors]. You can manually download them from the <tt>Scenery-v2.12</tt> folder and unpack it to the local TerraSync/Terrain/ directory.

=== World scenery 3 ===
{{Main article|World Scenery 3.0}}

=== Custom scenery ===
Custom scenery is available for certain specific areas. They are distributed separately either due to being only part of a single landmass that has not been re-built completely, being work-in-progress, waiting to be integrated to Terrasync, their license, or because their level of detail is not suitable for low-end machines.

* [[Suggested Airports/Scenery]] for a list of custom scenery projects and an update on state of well developed areas.
* [[Earthview#Installing_and_using_customized_textures|Earthview high resolution]] texture packs. Earthview is FlightGear's orbital renderer. You can select the texture pack that your GPU can handle - [[Earthview#Requirements|depends]] mainly on GPU memory (VRAM).
* [[World Scenery 3.0#Currently Available Scenery|World Scenery 3.0]] for a list of custom scenery for WS3.0.

<gallery mode="packed">
File:Asia.jpg|[[Earthview]] orbital renderer at high sun - with high resolution texture packs installed.
File:SOTM_2019-04_Space_Sauna_by_GinGin.jpg|Earthview orbital renderer at low sun showing light from cities. The [[Space_Shuttle|Space Shuttle]] shows the glow from the heat of hypersonic re-entry.
</gallery>

== Installing world and custom scenery ==

Always install scenery outside the <code>[[$FG_ROOT]]</code> directory. See [[#Technical details]] below for an explanation.

{{caution|'''Do not mix scenery''' types in the '''same directory'''. It may cause problems like custom scenery being overwritten by the TerraSync or TerraMaster utilities, TerraMaster getting locked etc.}}

=== GNU/Linux ===
If you are under a Linux operation system and you are not using a graphical interface to extract the tar archive, you can use one of the two following set of commands in a shell terminal.

<syntaxhighlight lang="shell">
cd SceneryDirectory
tar -xvzf input_file.tgz
</syntaxhighlight>

or

<syntaxhighlight lang="shell">
tar -xvzf 'input_file.tgz' -C SceneryDirectory
</syntaxhighlight>

<code>input_file.tgz</code> should be substituted with the filename of the archive to be extracted (the filename should be completed with the full pathname or any other valid method so that the shell could find the correct archive).

=== Windows ===

Simply unpack the downloaded scenery into a directory of choice, using software like [http://www.winzip.com/ Winzip] or [http://www.7-zip.org 7-zip]. Once done, append this directory to <code>[[$FG_SCENERY]]</code> (in the launcher, this can be done under Add-ons > Additional scenery folders).

=== macOS ===

Unpack the .tgz file either by double-clicking it and moving the resulting <code>wXXXnXX</code> folder to the Scenery folder described in the next line, or on the command line:

<syntaxhighlight lang="shell">
tar -xvzf 'input_file.tgz' -C /Applications/FlightGear.app/Contents/Resources/data/Scenery
</syntaxhighlight>

== Technical details ==
=== Scenery lookup and $FG_SCENERY ===

FlightGear determines what scenery to use by looking at the [[Environment variables|environment variable]] (setting) <code>[[$FG SCENERY]]</code>. There can be more than one scenery path in the variable, for example one path to to TerraSync scenery and one path to custom scenery. Scenery can be overlapping and a tile will be loaded from the first path in <code>$FG SCENERY</code> from which it is available.

Should the paths in <code>$FG_SCENERY</code> not be valid, FlightGear falls back to <code>[[$FG ROOT]]/Scenery</code>.

=== Directories and configuring $FG_SCENERY ===

Mixing scenery types is almost universally a bad idea, and is unsupported. Also note that the scenery packaged with the base package/windows installer may not be the latest scenery.

For this reason it is better to extract downloaded scenery files into a new folder, which we for the sake of this exercise will call <code>$FOOBAR/Scenery</code>.
In this directory, create two subdirectories: <code>/Objects</code> and <code>/Terrain</code>. You should untar individual files into the <code>/Terrain</code> folder.

Then you should set up $FG_SCENERY to use the new path:

* In the [[Qt launcher]]:
*: Add the $FOOBAR/Scenery folder to Add-ons > Additional scenery folders.
* On POSIX Clients
*: <code>set FG_SCENERY="$FOOBAR/Scenery" + FG_SCENERY</code>
* Via a command line option
*: <code>--fg-scenery="$FOOBAR/Scenery"</code>

=== Directory structure ===
==== Terrain ====

The Scenery directory will show the following (scenery is shown for completeness and for easy reference to above):

<tt>
* Scenery/
** Terrain/
*** w130n30/
** Objects/
*** w130n30/</tt>

If you download a scenery module called <code>w90n40.tgz</code> and extract it in <code>Scenery</code>, the result will resemble something like the following:

<tt>
* Scenery/
** Terrain/
*** w09n40/
*** w130n30/
** Objects/
*** w09n40/
*** w130n30/</tt>

Note that the directory structure is already present in the tar archive, starting from the Scenery directory. Note that you have to extract the tar archive in the Scenery directory, not in the <code>$FG_ROOT</code> directory, because the Scenery directory is not present in the archive.

==== Objects ====

Objects and models can be found at the [[FlightGear Scenery Object Database]].

These objects are included in each scenery release, but as the object database is more frequently updated than the terrain, one may want to occasionally update the <code>Object</code> subdirectory from the scenery objects database between scenery releases.

Another option is to download or update the scenery on-demand by using the built in TerraSync utility described above.

Objects are really part of the scenery and can be found in the <code>Scenery</code> directory under <code>$FG ROOT</code>.

<tt>
* Scenery/
** Objects/
*** w130n30/</tt>

Any objects should be installed under the <code>Scenery/Objects</code> directory.

==== Models ====

Replaces the former <code>$FG_ROOT/Models</code>; stores all the shared objects.

<tt>
* Scenery/
** Models/
*** Airport/</tt>

==== Airports ====

{{Main article|About Scenery/Airports}}

As of FlightGear 2.4.0, this directory is used to extract airport data (like runway usage and parking spots) from.

The directory tree might look somewhat overwhelming, but it simply follows the <code>Airports/[I]/[C]/[A]/</code> style.
<tt>
* Scenery/
** Airports/
*** K/
**** S/
***** F/
</tt>

== Video tutorials (2020.x) ==

{{#ev:youtube|TNN_AZhaHPU|480px||Scenery installation for Flightgear 2020.x by Parnikkapore. Note this is recorded on a non-gaming laptop, and certain settings are not turned up very high.}}
{{#ev:youtube|YxWV4wk_dHw|480px||Terramaster tutorial for Flightgear by FGUK - 2017 but still valid in 2020.}}

== Related content ==
* [[Scenery FAQ]]
* [[Suggested custom scenery]]

[[Category:Scenery]]

[[ar:Howto:Install_scenery]]
[[de:Howto:Install_scenery]]
[[es:Instalación de escenarios]]
[[fr:Installer une scène]]
[[it:Come fare:Installare scenari]]
[[nl:Scenery installeren]]
[[PL:Instalowanie scenerii]]
[[pt:Instalando Cenário]]

Earthview

2026-07-03T21:08:13Z

Fgf5: /* Requirements */

{{See also|Flying on other planets}}

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] or even the [[UFO]], neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

{{Spaceflight}}
== Overview ==
[[File:menubar2.jpg|517px]]

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

[[File:Earthview menu.jpg|thumb|260px]]

The options checkboxes allow to select

* whether a cloud layer should be rendered above the planet
* whether the cloud layer information should be used to render cloud shadows onto the terrain
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution
* whether textures should be rendered with lighting based on a normal map. Parallax effects are also computed if the normal map contains an alpha channel encoding the inverse height of the Earth's relief
* whether clouds should be rendered with lighting and parallax effects. These are computed using the alpha channel of the cloud map as an input information of their vertical extension

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals. If you don't want to start and stop it manually, you can install the [[AutoEarthView]] addon.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if [[Atmospheric light scattering]] (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of [[A local weather system | Advanced Weather]] (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the [http://visibleearth.nasa.gov/ NASA Visible Earth project] - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently, due to size concern, all the textures distributed in FGData are of low resolution (2048p x 2048p per tile) and do not incorporate the alpha channel encoding the height. Parallax mapping for ground textures is therefore disabled. It is however possible to obtain the textures from the NASA website, process them and straightforwardly use them as a replacement. More detailed instructions to do so are given below in the section "Customization".

At highest texture resolution, visuals are generally very compelling:

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

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

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

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]

== Requirements ==

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory. All textures are split into eight tiles, four for the northern hemisphere (N1 to N4), and four for the southern hemisphere (S1 to S4) and each tile is loaded, or unloaded, according to visibility. As such, GPU memory is efficiently used and limited graphic card memory should not be an issue for the default texture size. However, the loading of a texture tile induces some bottleneck and FG may hang for a couple of seconds, or more (depending on tile resolution), while the texture appears.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format, but these can be generated along the lines discussed in the "Customization" section.

For high-end graphic cards, it is possible to actually force the loading of all texture tiles at once when Earthview starts. This is triggered with the command line option:

--prop:/earthview/show-force-all=true

With the maximum resolution textures (16384x16384 pixels for a world tile and 8192x8192 pixels for a cloud and a normalmap tile), expect a minute or more for the loading, around 6GB of GPU memory and 16GB of RAM to be filled. If you can afford it, there will be no other loading bottleneck afterwards. These numbers can accordingly be lowered using lower resolution tiles.

Finally, while it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as [[Project Rembrandt|Rembrandt]] do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues. As such, on old flightgear versions (up to 2018) when using the [[Compositor]] as the rendering pipeline, it is compulsory to default it to ALS with --compositor=Compositor/als.

== Customization ==

To get full advantage of Earthview, and your graphic card, you may install and use your own high resolution tiles as well as normal maps having a alpha channel to trigger parallax mapping.

=== Texture generation ===

There are two ways to obtain these textures:

==== The easy way ====

When our resources allow for it, some users generate these textures and make them available for download. They may be obtained via torrent with this magnet link:

magnet:?xt=urn:btih:6df05a15c863040fd31278dfd1f719523b639cf2&dn=EarthView.World.August-2020.06

and may also be available for download at this url:

[https://curl.irmp.ucl.ac.be/~chris/upload/fg/earthview/ Earthview/]

A bash script to automatically download the full per-month data from above url [http://ix.io/3ogk is available here]. It downloads the dataset for every month, or it symlinks a dataset for a specified month into a specified place, see help of the script (run without arguments or with '-h'). To choose which resolution(s) to download or which image file format(s) to download the variables in the script needs to be edited. Needs an unix environment with bash and wget.

==== The interesting way ====

Most likely the easy way is no longer available, or you are curious. Chris_Blues made a wonderful Bash-script that will download the NASA images and do the texture generation for you, in the correct way. It is available on github, together with the instructions on how to use it:

[https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview]

This program can generate world, clouds and normal maps with height data included in the alpha channel, and at various resolutions ranging from 1024x1024 to 16384x16384 pixels.

==== Remarks ====

Notice that all the input images are provided by NASA and any usage of the textures should be made in accordance with their distribution policy. They are directly accessible for download at [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and search for a texture set of your choice.

NASA provides different seasons for the Earth images, even one set of images per month. [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] allows you to chose the month for which you want to generate your set of tiles.

Graphics cards prefer powers of two in texture sizes, so [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] resizes the tiles to 1024x1024, 2048x2048, 4096x4096, 8192x8192 or 16384x16384 pixels. Be aware of the original image resolution, there is no much gain into using a super-sampled tile. For instance, the current cloud maps provided by NASA have a resolution of typically 10000 pixels. Using 8192x8192 sampling is the best option, the gain of super-sampling it at 16384x16384 is very small. Similar thing holds true for heights and normalmaps (16384x16384 for them is also supersampled, so prefer at most 8192x8192 for them).

=== Installing and using customized textures ===

The texture tiles loaded by Earthview reside in

$FGData/Models/Astro/Textures

where $FGData depends on the installation path of flightgear-fgdata. If you only want to use "png" texture tiles, simply replace all the '''world_*.png''', '''clouds_*.png''' and '''normalmap_earth_*.png''' files by your own.

If you want to use "dds" mipmapped images, then you have to edit a few "ac" files to tell Earthview to use them. These configuration files reside in

$FGData/Models/Astro

and are

earth_*.ac

On Unix systems, the program '''sed''' is your friend (but make a backup before).

* Remarks
It is possible to assign any image you fancy to be used as a tile by Earthview. For this, you can edit the file '''earth_unitscale_rawuv.ac''' to load your images, and edit '''earth.xml''' such that it points to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. You can do the same for '''cloudsphere.xml'''. However, assigning textures in this manner, as they are to the "rawuv" sphere, creates visible seams where the texture sheets end. This is particularly visible if parallax mapping is rendered as the computation requires shifting the textures over the sphere.

The solution is to add margins that encompass a bit of the neighbouring tiles. This is what [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] is doing (as well as the texture set provided). These bordered tiles don't use '''earth_unitscale_rawuv.ac''' but instead '''earth_unitscale_hires.ac''', which is the default (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the original discussion). In other words, if you use [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] to generate your own textures, you do not need to change '''earth.xml''' nor '''earth_unitscale_rawuv.ac'''. Notice that you still need to edit '''earth_unitscale_hires.ac''' (and the rest of the '''earth_*.ac''') if you want to use dds tiles!

=== Open tips ===

* Since there is no limit to customization, and if you can afford 50GB of disk space, you can create a whole set of directories containing Earth textures for each month of the year, as for instance:

EarthView.World.January-2020.06/
EarthView.World.February-2020.06/
...

On linux, a simple "cron" job can automatically link the content of one of these directories to '''$FGData/Models/Astro/Textures/''', like this one:

#!/bin/bash
TEXTUREDIR="/usr/share/games/flightgear-extra/Models/Textures"
TIMESTAMP="2020.06"
MONTH=$(date +%B)
WORLDRES="16384"
echo "Going to: $TEXTUREDIR"
cd $TEXTUREDIR
echo "Linking world textures of: $MONTH"
ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.dds .
ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.png .
echo "done"

And you'll be flying Earth with textures matching the current month!

* You may also fancy textures from other celestial bodies, as for instance the Moon. Textures generator available here [https://github.com/eatdust/LROC2FGearthview LROC2FGearthview] and shaders there [https://github.com/eatdust/moonshaders moonshaders], see the original discussion on the forum [https://forum.flightgear.org/viewtopic.php?f=87&t=15754&start=375#p369043 viewtopic.php?f=87&t=15754&start=375#p369043].

== Implementation ==

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

== Screenshots Gallery ==
{{screenshot cat
| category = Screenshots of Earthview
| subject = the Earthview orbital rendering engine
| image = Shuttle FG01.jpg
}}

A sum up of some nice screenshots, and what is achievable while playing with all the options that Earthview offers us.

Sunset and Diffraction

[[File:Black knight UFO Shuttle sunset.jpg|1024px]]

Black Knight UFO Shuttle

[[File:Black_knight_UFO.jpg|1024px]]

500Nm above the World

[[File:Far_side_of_the_world.jpg|1024px]]

South Pole and Lighting game

[[File:Shuttle_over_South_Pole_500_Nm.jpg|1024px]]

Good night World

[[File:SOTM_2019-09_Firing_at_Dawn_by_GinGin.jpg|1024px]]

California Fly By

[[File:Edwards_RTLS_earthview.jpg|1024px]]

Lonely External Tank

[[File:External_Tank_on_Orbit.jpg|1024px]]

Ready for Orbital Operations Eileen

[[File:Orbital_ops_bay_opened_earthview.jpg|1024px]]

== Related content ==
* [[AutoEarthView]] - an addon that automatically starts/stops Earthview based on the altitude

Suggested custom scenery

2026-07-03T21:05:35Z

Fgf5: update

Besides the official TerraSync scenery that is automatically synced while FlightGear is running, there are a number of custom sceneries available, created by users for beautifying some specific areas of the scenery. This page is a list of some '''suggested custom scenery''' for downloading and visiting. This list can not be complete as custom sceneries might come and go. It's worth to search the forum for additional custom sceneries.

Since FlightGear 2020.3.7, buildings, roads, pylons, and other objects are ''automatically'' downloaded, based on Open Street Map (OSM) data - see [[OSM2City 1st Worldbuild|OSM2City 1st world build]]. You don't have to download OSM2City custom sceneries for these anymore. However, you need to enable then in the [[Rendering Options]] menu.

* See '''[[Suggested_airports]]''' for a quick list of featured airports situated in well developed regions, with links to OSM2City scenery. It's suitable for newcomers to start at to explore surrounding regions. (March 2020)

* '''OSM2City scenery''' buildings, roads, pylons, and other objects, for the whole planet is now on TerraSync, and ''automatically downloaded'' by FlightGear. The current OSM2City output on TerraSync is from the [[Osm2city_worldbuild|1st world build of OSM2City]] scenery ([https://forum.flightgear.org/viewtopic.php?f=5&t=35581 forum thread]). Custom sceneries for countries and regions are available [[Areas_populated_with_osm2city_scenery|'''here''']]. Note: Old custom sceneries (before March 2021) will contain folders for OSM2City output like Buildings, Roads or Pylons with outdated and obsolete objects. These folders will override the new higher quality and faster rendering objects from TerraSync. Remember to remove these from your custom scenery folder list! If your custom scenery contains sub-folders that are not obsolete, like Terrain, you can leave these alone and only delete OSM2City sub-folders in your custom scenery folder. There are some OSM2City custom sceneries that are not obsolete - these have builds of OSM2City with different options from the 1st worldbuild - for example, custom scenery with auto-generation on in areas without good OSM coverage like the Hawaii custom scenery.

* '''[[:Category:Scenery_enhancement_projects|Custom terrain & region definition projects]]''': There are ongoing scenery enhancement projects to update both regional definitions and terrain in large areas like the [[Australia_Custom_Scenery|Australia]] (regional definitions are planned to be added to FG core). This a partial list, search the '''[https://forum.flightgear.org/viewforum.php?f=5 scenery forum]''' for details. Some of the output of projects like Hawaii terrain has already been integrated into Terrasync.

* Terrasync scenery which is automatically downloaded has high resolution terrain. All of Europe currently has high resolution terrain from CORINE data. A lot of old pre-world scenery 2 may be obsolete.

* Status of terrain in custom sceneries: The page as it stands is missing almost all custom terrain. Some old island custom sceneries have been merged into the automatically downloaded sceneries terrasync. [[User:Wlbragg#Kansas_Custom_Scenery|Kansas/Midwest]] and [[US-Tennessee_Custom_Scenery|Tennessee]] are two examples of custom sceneries that aren't obsolete (March 2020).

:: ''If you are the creator of an island scenery you can add it to [[TerraSync]] by contacting the flightgear-devel [[Mailing_lists|mailing list]]''.

* [[Project3000]] adds a lot of clutter and buildings to airports which do not have models or details. It's a must have. It is planned to be integrated into the FG core eventually. [https://forum.flightgear.org/viewtopic.php?f=5&t=27688 Forum thread]. (March 2020)

== New scenery for the Americas (January 2024) ==

[[File:Cygd-c140-winter.jpg|thumb|New FlightGear Americas scenery, approaching Georgian Bay (Lake Huron) in winter. Note the detail for inland water.]]
New scenery is available for all of the Americas, including islands geographically or politically associated with them (such as Greenland, the Hawaiian Islands, Bermuda, and the Galapagos). This is intended to replace the current default TerraGear scenery as soon as we're ready to rebuild osm2city for it. The scenery includes many more airports (5-10x as many as the default scenery, most with correct taxiways and aprons), detailed inland water, and detailed 30m digital elevations. See [[FlightGear Americas Scenery (custom)]] for download details.

This scenery is suitable for use as a default to fill in the gaps between some of the more-detailed custom-scenery areas listed below.

== Custom scenery (May 2021) ==

''This is only a fraction of available scenery (May 2021). Search the [https://forum.flightgear.org/viewforum.php?f=5 scenery forum] for more.''

''See [[Howto:Install_scenery|How to install custom scenery packages]].''

* '''USA, Tennessee:''' custom scenery for Tennessee by [[User:Scttgs|Scott Giese]](xDraconianx). This is very high resolution scenery created to test potential resolution & performance for the next world scenery build. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=35521 forum thread] for feedback and more info. See the [[US-Tennessee_Custom_Scenery|wiki page]] for downloads. (March 2020)

<gallery mode="packed">
File:US-Tennessee-EastCentral.jpg
File:US-Tennessee-West.jpg
File:US-Tennessee-East.jpg
File:US-Tennessee-WestCentral.jpg
</gallery>

* '''USA, Kansas & Ohio:''' custom scenery for the entire states of Kansas and Ohio created by [[User:Wlbragg|Wlbragg]]. This high resolution scenery includes textures. See the [[User:Wlbragg#Kansas_Custom_Scenery|wiki page]] for downloads and info. (March 2020)

<gallery mode="packed">
File:Kansas_Scenery_Two.jpg
File:KDAY_James_M._Cox_Dayton_International_Airport.jpg
File:Kansas_Scenery_One.jpg
File:Kansas_Scenery_Three.jpg
</gallery>

* '''Scandinavia''': custom scenery covering Scandinavian countries such as Norway, Sweden, and Finland by [[User:D-ECHO|D-ECHO]]. Norway and Sweden have some of the most detailed regional definitions using recent engine features. This custom scenery project further improves it by mainly adding more detailed land type classification, digital elevation data, as well as updated airports. As of March 2020 it updates parts of these countries. See the [[Scandinavia Custom Scenery]] page for download and details.

* '''USA, Pennsylvania, New Jersey, and New York City''': custom scenery for these Eastern US states by montagdude. See [https://forum.flightgear.org/viewtopic.php?f=5&t=38041 forum thread]. Contains custom terrain, OSM2City, and custom materials. (September 2020)

<gallery mode="packed">
File:Ec135-manhattan.jpg
File:Pa28-wilkes-barre.jpg
File:C182s-atlantic-city.jpg
File:Dr400-philadelphia.jpg
</gallery>

* '''USA, Virginia, Maryland, Delaware, and the District of Columbia''': custom scenery for these Mid-Atlantic US states by montagdude. See [https://forum.flightgear.org/viewtopic.php?f=5&t=37322 forum thread]. Contains custom terrain, OSM2City, and custom materials. (April 2020)

* '''USA, Rhode Island and southeastern Massachusetts''': custom scenery for Rhode Island and southeastern parts of the state of Massachusetts by montagdude. See [https://forum.flightgear.org/viewtopic.php?f=5&t=36977 forum thread]. Contains OSM2City. (March 2020)

* '''USA, Champaign, Chicago, Milwaukee and surrounding areas''': custom scenery for Champaign, Bloomington, Chicago, Milwaukee and northern Illinois by pb321. See [https://forum.flightgear.org/viewtopic.php?f=5&t=39209 forum thread] and to report issues. Contains OSM2City and (optional) color corrected USGS orthophotos. (May 2021)
<gallery mode="packed">
File:KPWK-Chicago_Executive.jpg
File:ChicagoAM-OrthoCropped.jpg
File:Approaching KMKE.jpg
</gallery>

* '''USA, Oshkosh, Green Bay, U.P. of Michigan and surrounding areas''': custom scenery for Oshkosh, Appleton, Green Bay and the central Upper Peninsula of Michigan by pb321. See [https://forum.flightgear.org/viewtopic.php?f=5&t=39264 forum thread] and to report issues. Contains OSM2City and (optional) color corrected USGS orthophotos. (May 2021)
<gallery mode="packed">
File:GreenBayNorth.jpg
File:Near Houghton MIa.jpg
File:MarquetteA.jpg
</gallery>

* '''Venezuela: [[Project Venezuela]]:''' custom scenery for Venezuela by [[User:Legoboyvdlp|J. Redpath]], with improved airport layouts, and objects at several airports. Highly improved over TerraSync status. (March 2020)

* '''Canary Islands:''' custom scenery for the Canary Islands by [[User:D-ECHO|D-ECHO]] with improved terrain, objects, vegetation, building, reworked airports, mostly with buildings and furniture. Check out the [[Canary_Islands_Custom_Scenery|wiki page]]. (March 2020)

<gallery mode="packed">
GCLP-1.jpg
GCLP-2.jpg
GCLP-3.jpg
</gallery>

* '''Argentina''': OSM-based custom scenery for Argentina and parts of Chile and Uruguay by Barta.<br/>Updated airports, landcover from OSM polygons, line data and objects using Osm2City. Updated frequently!<br/>Downloads:
:: All output: [http://scenery.bartatech.net/ http://scenery.bartatech.net/] . As of July 2020 these areas are available: Santiago (including Valparaiso), Mendoza, Buenos Aires, complete Rosario area. The other parts only have terrain (no roads, buildings etc). The server will eventually contain all of the sceneries in the southern cone of South America: Argentina, Chile, Uruguay.
::: It's possible to use the [http://scenery.bartatech.net/ scenery.bartatech.net] server directly as a Terrasync server. Just use the following in the [[FlightGear_Qt_launcher|launcher]] or .fgfsrc file:
::: ''--prop:/sim/terrasync/http-server=<nowiki>http://scenery.bartatech.net/</nowiki>''
:: Buenos Aires province: https://github.com/bartacruz/scenery-6040
:: Cuyo Area + Santiago: https://github.com/bartacruz/scenery-cuyo

* '''USA, Florida''': custom scenery for Florida by [[User:Legoboyvdlp|J. Redpath]] with both terrain and OSM2City. It also covers the [[Space Shuttle]] landing site at [[Shuttle_Landing_Facility|KTTS]]. See the [https://github.com/legoboyvdlp/Florida-fg-CustomScenery repository] downloads section for the [https://github.com/legoboyvdlp/Florida-fg-CustomScenery/archive/master.zip zip-file].

* '''London, England''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the London area including an improved Gatwick Airport (ICAO: EGKK). See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37444 forum thread] and [https://github.com/legoboyvdlp/London-fg-CustomScenery repository] downloads section for the [https://github.com/legoboyvdlp/London-fg-CustomScenery/archive/master.zip zip-file].

* '''Moscow area, Russia''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the Moscow area covering 14 tiles. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for the github [https://github.com/legoboyvdlp/Moscow-fg-CustomScenery/archive/master.zip download]. (August 2020)

* '''Valdivostock area, Russia''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the Vadivostock area. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for the github [https://github.com/legoboyvdlp/Vladivostok-fg-CustomScenery/archive/master.zip download]. (August 2020)

* '''Eastern China''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the eastern portion of China covering the area around ZSAM and ZSNJ airports. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for the github [https://github.com/legoboyvdlp/EastChina-fg-CustomScenery/archive/master.zip download]. (August 2020)

* '''Beijing area, China''': custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the area around Beijing covering 15 tiles. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for the github [https://github.com/legoboyvdlp/Beijing-fg-CustomScenery/archive/master.zip download]. (August 2020)

* '''Sri Lanka''': 2019 custom scenery by [[User:Legoboyvdlp|J. Redpath]] for the island of Sri Lanka in the Indian ocean including rebuilt terrain, OSM2City output, and improved airports. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] for github [https://codeload.github.com/legoboyvdlp/SriLanka-fg-CustomScenery/zip/master download].
* '''Dominican Republic:''' 2021 custom scenery by flc972 for [[Gregorio Luperon International Airport]] (MDPP) with detailed modeling of interiors, night lightmaps, ground net and animated jetways as well as some terrain. The airport is located on the Caribbean island of Hispaniola. See the [https://forum.flightgear.org/viewtopic.php?f=5&t=39179 forum thread] for bitbucket [https://bitbucket.org/fableb/flcs-mdpp_airport/downloads/ download] .
* '''Turkey:''' custom scenery including 12 airports. Can be downloaded from https://github.com/Klaudiae/FGCompanion-TurkeyEnhanced
* '''Turkey, Şanlıurfa:''' custom scenery by TheFGFSEagle. Can be downloaded from https://github.com/TheFGFSEagle/LTCS-scenery
* '''Poland:''' custom scenery including 14 airports. Can be downloaded from https://github.com/Klaudiae/FGCompanion-PolandEnhanced

== Custom scenery set to be merged into TerraSync and FGData ==

''These are now in the process of being merged. If you know of custom sceneries of islands or complete landmasses that have not been merged yet, contact the developers. (March 2021).''
* New Zealand scenery ([https://forum.flightgear.org/viewtopic.php?f=5&t=36892 forum thread]). (March 2020)
* [[Australia_Custom_Scenery|Australian custom scenery project]] output - Regional definitions, and textures. See these forum threads for download and details: [https://forum.flightgear.org/viewtopic.php?f=5&t=36145 official thread], demo scenery [https://forum.flightgear.org/viewtopic.php?f=19&t=36956 install details (March 2020)]. A partially completed Sydney airport (YSSY) is also available for download. The terrain in the demo scenery release is likely to be merged when a re-build of Australia is done.
* All Channel Islands (Jersey, Guernsey, Alderney, Sark, etc) ([https://github.com/legoboyvdlp/Jersey-fg-CustomScenery github]). (March 2020).
* Sri Lanka, [https://forum.flightgear.org/viewtopic.php?f=5&t=37887 forum thread] and [https://github.com/legoboyvdlp/SriLanka-fg-CustomScenery Github]

== Custom scenery which has been merged into TerraSync and FGData ==

''You can remove old scenery folders containing known merged sceneries from your [[Howto:Install_scenery|scenery folder list]].''

* Islands merged recently (2018-2019): Hawaii, Iceland, Island of Jan Mayen (Norway)

== Old and undetermined custom scenery ==

''Some of these may have been obsoleted by the release of the [[FlightGear World Scenery 2.0|new world scenery in November 2013]].''

''Please move sceneries that aren't obsolete into other categories.''

* '''France''': Custom scenery for France with improved landcover information and more detailed elevation information (no improvements on the objects) is under development. See the [[Custom France Scenery|Custom France Scenery page]]. (Pre WS 2.0)

<gallery>
Image:High_textures_transitions3.png|High detail France scenery
Image:High_textures_transitions4_1.png|High detail France scenery
Image:High_textures_transitions6_2.png|High detail France scenery
Image:High_textures_transitions10_1.png|Mont Blanc
Image:High_textures_transitions11_1.png|Aguille du midi?
Image:High_textures_transitions13_1.png|Matterhorn without landclass, just slope transitions
</gallery>

* '''Innsbruck (Austria) area''': The scenery currently covers a 1x1 degree area containing parts of Austria and Germany, and makes use of accurate data from the Corine Land Cover, and Open Street Map projects. See [http://forum.flightgear.org/viewtopic.php?f=5&t=5350 this forum post] and [[FlightGear Newsletter August 2009#Innsbruck Gets A Face Lift|the August 2009 newsletter]] for details. (Pre WS 2.0)

* '''LOWI & Austria Scenery Preview''': This scenery includes the Innsbruck scenario and is much more complete than the previous. It is still experimental, but should try it as having been really good. Info and download can be found [[Innsbruck Airport|here]].

* '''Iberian Peninsula: Spain and Portugal''': custom scenery for Spain and Portugal with improved landcover and additional airports and objects. See the [[Custom Spain and Portugal Scenery|custom Spain and Portugal scenery page]].

* '''EDDK''': Custom scenery for the Cologne/Bonn airport in Germany with very nice and realistic terminal buildings. Available from https://github.com/mherweg/EDDK-fg-CustomScenery.

* '''Argentina''': OSM-based custom scenery for Argentina and parts of Chile and Uruguay.<br/>Updated airports, landcover from OSM polygons, line data and objects using Osm2City. Updated frequently!<br/>Downloads:
** Buenos Aires province: https://github.com/bartacruz/scenery-6040
** Cuyo Area + Santiago: https://github.com/bartacruz/scenery-cuyo

== Related content ==
* [[Howto:Improve scenery in your area, or area of interest]]

{{suggested}}

[[Category:Custom scenery]]

TerraSync

2026-07-03T20:51:49Z

Fgf5:

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

If you have a steady and reasonably fast internet connection, you can use the built-in '''TerraSync''' instead of manually [[Howto: Install scenery|installing sceneries]]. TerraSync is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the master scenery server "just in time".
For some time now TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the launcher under Settings > Additional Settings (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.b-cdn.net/osm2city/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There is a forum post: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred]

In addition, you can manually download .txz scenery files from [https://terrasync.b-cdn.net/ terrasync.b-cdn.net] and unpack them into your <code>TerraSync</code> folder correctly.

=== Some scenery objects/buildings do not appear ===
If you've already enabled them in the [[Rendering Options]] dialog, click File > Scenery Download and check whether the status is ready.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

== Internals ==
The TerraSync client first queries NAPTR records for the DNS name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the `.dirindex` files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon, in order to maximise the chance of "just working" with different HTTP providers and CDN options in the future. The `.dirindex` files use a text-based structure, which is intended to be straightforward. They are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various `stat()` fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the `.dirindex` file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the `stat()` data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered.

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== Footnotes ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

TerraSync

2026-07-03T20:43:49Z

Fgf5: /* Troubleshooting */

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

If you have a steady and reasonably fast internet connection, you can use the built-in '''TerraSync''' instead of manually [[Howto: Install scenery|installing sceneries]]. TerraSync is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the master scenery server "just in time".
For some time now TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the launcher under Settings > Additional Settings (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.b-cdn.net/osm2city/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There is a forum post: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred]

In addition, you can manually download .txz scenery files from [https://terrasync.b-cdn.net/ terrasync.b-cdn.net] and unpack them into your <code>TerraSync</code> folder correctly.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

== Internals ==
The TerraSync client first queries NAPTR records for the DNS name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the `.dirindex` files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon, in order to maximise the chance of "just working" with different HTTP providers and CDN options in the future. The `.dirindex` files use a text-based structure, which is intended to be straightforward. They are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various `stat()` fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the `.dirindex` file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the `stat()` data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered. Note that there is no provision for keeping modified (dirty) files inside the tree – they will always be overwritten during the next check. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35064470/
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki>
|author = <nowiki>James Turner</nowiki>
|date = May 4th, 2016
|added = May 4th, 2016
|script_version = 0.32
}}
</ref>

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

Enjoy, feedback welcome.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35081518/
|title = <nowiki> [Flightgear-devel] Clone the HTTP scenery data with terrasync.py </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = May 11th, 2016
|added = May 11th, 2016
|script_version = 0.40
}}</ref>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== Footnotes ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

TerraSync

2026-07-03T20:41:38Z

Fgf5: /* Troubleshooting */

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

If you have a steady and reasonably fast internet connection, you can use the built-in '''TerraSync''' instead of manually [[Howto: Install scenery|installing sceneries]]. TerraSync is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the master scenery server "just in time".
For some time now TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the launcher under Settings > Additional Settings (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.b-cdn.net/osm2city/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There is a forum post: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred]

In addition, you can manually download .txz scenery files from [https://terrasync.b-cdn.net/ terrasync.b-cdn.net] and unpack them into your <code>TerraSync</code> folder correctly.

=== Corrupted and unreadable files or directories ===
If you get an error similar to the following in the command line console (black dialog):

Airports/L ... failed:
Can't move 'C:\FlightGear\terrasync\Airports\L\E\.svn\tmp\entries' to 'C:\FlightGear\terrasync\Airports\L\E\.svn\entries': The file or directory is corrupted and unreadable.

and possibly the following popup appears:

[[File:TerraSync Taskbar Error.png]]

==== Solution ====
You can probably fix the error by upgrading to new Windows versions.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

== Internals ==
The TerraSync client first queries NAPTR records for the DNS name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the `.dirindex` files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon, in order to maximise the chance of "just working" with different HTTP providers and CDN options in the future. The `.dirindex` files use a text-based structure, which is intended to be straightforward. They are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various `stat()` fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the `.dirindex` file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the `stat()` data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered. Note that there is no provision for keeping modified (dirty) files inside the tree – they will always be overwritten during the next check. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35064470/
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki>
|author = <nowiki>James Turner</nowiki>
|date = May 4th, 2016
|added = May 4th, 2016
|script_version = 0.32
}}
</ref>

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

Enjoy, feedback welcome.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35081518/
|title = <nowiki> [Flightgear-devel] Clone the HTTP scenery data with terrasync.py </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = May 11th, 2016
|added = May 11th, 2016
|script_version = 0.40
}}</ref>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== Footnotes ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

TerraSync

2026-07-03T20:38:25Z

Fgf5: /* Network or DNS error */

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

If you have a steady and reasonably fast internet connection, you can use the built-in '''TerraSync''' instead of manually [[Howto: Install scenery|installing sceneries]]. TerraSync is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the master scenery server "just in time".
For some time now TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the launcher under Settings > Additional Settings (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.b-cdn.net/osm2city/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There is a forum post: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred]

In addition, you can manually download .txz scenery files from [https://terrasync.b-cdn.net/ terrasync.b-cdn.net] and unpack them into your <code>TerraSync</code> folder correctly.

=== Corrupted and unreadable files or directories ===
If you get an error similar to the following in the command line console (black dialog):

Airports/L ... failed:
Can't move 'C:\FlightGear\terrasync\Airports\L\E\.svn\tmp\entries' to 'C:\FlightGear\terrasync\Airports\L\E\.svn\entries': The file or directory is corrupted and unreadable.

and possibly the following popup appears:

[[File:TerraSync Taskbar Error.png]]

==== Solution ====
You can probably fix the error by upgrading to new Windows versions.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

=== Failure to remove file ===
You get an error indicating that some files can not be removed.

file remove failed: (./.terrasync_cache) reason: Permission denied

TerraSync cache files can not be deleted. You will see errors in console like above. There is not much to do other then delete the <code>.terrasync_cache</code> files manually and then run FlightGear again.

==== Resolution ====
{{caution|Not recommended. Understand the consequences}}

[http://forum.flightgear.org/viewtopic.php?f=17&t=28957&p=278275#p278275 Forum Post w/ PowerShell command is here]

== Internals ==
The TerraSync client first queries NAPTR records for the DNS name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the `.dirindex` files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon, in order to maximise the chance of "just working" with different HTTP providers and CDN options in the future. The `.dirindex` files use a text-based structure, which is intended to be straightforward. They are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various `stat()` fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the `.dirindex` file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the `stat()` data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered. Note that there is no provision for keeping modified (dirty) files inside the tree – they will always be overwritten during the next check. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35064470/
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki>
|author = <nowiki>James Turner</nowiki>
|date = May 4th, 2016
|added = May 4th, 2016
|script_version = 0.32
}}
</ref>

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

Enjoy, feedback welcome.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35081518/
|title = <nowiki> [Flightgear-devel] Clone the HTTP scenery data with terrasync.py </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = May 11th, 2016
|added = May 11th, 2016
|script_version = 0.40
}}</ref>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== Footnotes ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

TerraSync

2026-06-29T20:57:58Z

Fgf5: /* Network or DNS error */

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

If you have a steady and reasonably fast internet connection, you can use the built-in '''TerraSync''' instead of manually [[Howto: Install scenery|installing sceneries]]. TerraSync is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the master scenery server "just in time".
For some time now TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the additional settings in the launcher (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.b-cdn.net/osm2city/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There is a forum post: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred]

In addition, you can manually download .txz scenery files from [https://terrasync.b-cdn.net/ terrasync.b-cdn.net] and unpack them into your <code>TerraSync</code> folder correctly.

=== Corrupted and unreadable files or directories ===
If you get an error similar to the following in the command line console (black dialog):

Airports/L ... failed:
Can't move 'C:\FlightGear\terrasync\Airports\L\E\.svn\tmp\entries' to 'C:\FlightGear\terrasync\Airports\L\E\.svn\entries': The file or directory is corrupted and unreadable.

and possibly the following popup appears:

[[File:TerraSync Taskbar Error.png]]

==== Solution ====
You can probably fix the error by upgrading to new Windows versions.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

=== Failure to remove file ===
You get an error indicating that some files can not be removed.

file remove failed: (./.terrasync_cache) reason: Permission denied

TerraSync cache files can not be deleted. You will see errors in console like above. There is not much to do other then delete the <code>.terrasync_cache</code> files manually and then run FlightGear again.

==== Resolution ====
{{caution|Not recommended. Understand the consequences}}

[http://forum.flightgear.org/viewtopic.php?f=17&t=28957&p=278275#p278275 Forum Post w/ PowerShell command is here]

== Internals ==
The TerraSync client first queries NAPTR records for the DNS name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the `.dirindex` files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon, in order to maximise the chance of "just working" with different HTTP providers and CDN options in the future. The `.dirindex` files use a text-based structure, which is intended to be straightforward. They are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various `stat()` fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the `.dirindex` file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the `stat()` data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered. Note that there is no provision for keeping modified (dirty) files inside the tree – they will always be overwritten during the next check. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35064470/
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki>
|author = <nowiki>James Turner</nowiki>
|date = May 4th, 2016
|added = May 4th, 2016
|script_version = 0.32
}}
</ref>

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

Enjoy, feedback welcome.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35081518/
|title = <nowiki> [Flightgear-devel] Clone the HTTP scenery data with terrasync.py </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = May 11th, 2016
|added = May 11th, 2016
|script_version = 0.40
}}</ref>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== Footnotes ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

TerraSync

2026-06-29T20:56:30Z

Fgf5: /* Network or DNS error */

<div style="padding-left:20px;">''Not to be confused with [[TerraGear]], a toolset to generate scenery.''</div>

If you have a steady and reasonably fast internet connection, you can use the built-in '''TerraSync''' instead of manually [[Howto: Install scenery|installing sceneries]]. TerraSync is a utility that automatically downloads the newest version of the needed [[FlightGear]] scenery while the simulator is running. It runs in the background (optionally as a separate process), monitors your position, and downloads (or updates) the latest scenery from the master scenery server "just in time".
For some time now TerraSync has been integrated into the core FlightGear process, so there is no need to deal with TerraSync for the typical user.

The master repository for TerraSync, i.e. the online resource from which TerraSync downloads its files, is synchronized with the [http://scenemodels.flightgear.org/ FlightGear Scenery Database] once a day. So when using TerraSync, you will always have
# the latest [[File Formats#.2A.stg|.stg-files]], which tell FlightGear where to place an object
# the latest '''static''' models for objects. (Static models define unique objects that exist in one place only, such as famous buildings or landmarks.)
# the latest '''shared''' models for objects. (Generic models used more than once in different places, each can represent many different objects, like generic houses or ships)

== Enabling TerraSync ==

=== In the launcher ===
[[File:Terrasync option.png|400px|thumb|The scenery download options in the settings panel.]]
In the launcher, click <tt>Settings > Download scenery automatically</tt>. If you meet errors related to DNS after starting FG, you may click the "Show more" button on the right and choose a DNS server.

=== Inside FlightGear ===
In the FlightGear [[menu]], click <tt>File > Scenery Download</tt> and then check the "Enable automatic scenery download" option.

=== Command line ===
By default, when enabled with <code>--enable-terrasync</code>, TerraSync now downloads to <i>download_dir</i>/TerraSync, where <i>download_dir</i> is FlightGear's download directory.

FlightGear's download directory may be explicitly set using FlightGear's <code>--download-dir</code> [[Command line options|command line option]], otherwise it defaults to:
*[[$FG_HOME]] on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads</tt> on Windows (which may be located under <tt>C:\Users\<i>username</i>\Documents</tt>, however there are likely several possibilities depending on the Windows version and configuration).

If you neither pass <code>--terrasync-dir</code> nor <code>--download-dir</code> to FlightGear, then the '''default TerraSync directory''' is:
*<tt>[[$FG_HOME]]/TerraSync</tt> on non-Windows systems;
* <tt>%USERPROFILE%\FlightGear\Downloads\TerraSync</tt> on Windows (which is ''possibly'' under <tt>C:\Users\<i>username</i>\Documents</tt> but probably depends on the Windows version and configuration).

==== POSIX compliant [[command line]] shell ====

Start TerraSync:

<code>% nice terrasync -p 5500 -S -d "$HOME/fgfsScenery"</code>

The -S option tells terrasync to use the SVN protocol to fetch data. If you omit it terrasync will use the rsync program instead (which has to be installed on your system).

Start FlightGear:

<code>% fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery="[[$FG_ROOT]]/Scenery/:$HOME/fgfsScenery"</code>

The full documentation and source for TerraSync is located in the FlightGear source distribution (in <code>utils/TerraSync/</code>).

== Troubleshooting ==

=== Network or DNS error ===
{{See also|DNS#TerraSync}}

If network/DNS errors are encountered, you can click the "Show more" button on the right and select a DNS server. If this does not work, enter <code>--prop:/sim/terrasync/http-server= your server</code> in the additional settings in launcher (e.g., <code>--prop:/sim/terrasync/http-server=https://flightgear.sourceforge.net/scenery</code> or <code>--prop:/sim/terrasync/http-server=https://terrasync.b-cdn.net/osm2city/</code>). Note that hardcoding the TerraSync server is inflexible. Remove it once the network returns to normal.

There is a forum post: [https://forum.flightgear.org/viewtopic.php?p=438783 Network errors occurred]

In addition, you can manually download .txz scenery files from [https://terrasync.b-cdn.net/ terrasync.b-cdn.net] and unpack them into your <code>TerraSync</code> folder correctly.

=== Corrupted and unreadable files or directories ===
If you get an error similar to the following in the command line console (black dialog):

Airports/L ... failed:
Can't move 'C:\FlightGear\terrasync\Airports\L\E\.svn\tmp\entries' to 'C:\FlightGear\terrasync\Airports\L\E\.svn\entries': The file or directory is corrupted and unreadable.

and possibly the following popup appears:

[[File:TerraSync Taskbar Error.png]]

==== Solution ====
You can probably fix the error by upgrading to new Windows versions.

=== Locked airport directories ===
You get an error indicating locked airport directories while TerraSync is running.

Working copy '...\FlightGear\terrasync\Airports\K' locked

While those directories often actually ''are'' updated, the error is annoying.

==== Solution ====
Search the TerraSync directory for files named <tt>lock</tt> and delete them. They are supposed to be removed automatically when a TerraSync update is completed, but sometimes that fails.

=== Failure to remove file ===
You get an error indicating that some files can not be removed.

file remove failed: (./.terrasync_cache) reason: Permission denied

TerraSync cache files can not be deleted. You will see errors in console like above. There is not much to do other then delete the <code>.terrasync_cache</code> files manually and then run FlightGear again.

==== Resolution ====
{{caution|Not recommended. Understand the consequences}}

[http://forum.flightgear.org/viewtopic.php?f=17&t=28957&p=278275#p278275 Forum Post w/ PowerShell command is here]

== Internals ==
The TerraSync client first queries NAPTR records for the DNS name terrasync.flightgear.org, then compares the local SHA1 hash with the remote file and downloads tiles from the server.

The SHA1 hashes are what is stored in the `.dirindex` files, both on the server and in the local tree. Time-stamps are not synchronised with the server copies because doing so complicates mirroring on the server side and makes it much less efficient. Hash clashes are not considered an issue (following the same assumption made by the Git developers). No custom or particular HTTP headers are relied upon, in order to maximise the chance of "just working" with different HTTP providers and CDN options in the future. The `.dirindex` files use a text-based structure, which is intended to be straightforward. They are generated on the server side by scripts written by Torsten.

The code uses logic nearly identical to Git to avoid recalculating SHA hashes for the entire repository. If any of various `stat()` fields change (most notably size or modification time), the hash for that file on disk is recomputed. Whenever a file's hash on disk differs from what the `.dirindex` file specifies, the file is downloaded. This provides a complete description of the synchronisation model.

Thus, it is safe to copy or modify files in the tree using any tool; doing so will change the `stat()` data, causing the SHA hash to be recomputed. If the hash no longer matches the server-side copy, a re-download will be triggered. Note that there is no provision for keeping modified (dirty) files inside the tree – they will always be overwritten during the next check. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35064470/
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki>
|author = <nowiki>James Turner</nowiki>
|date = May 4th, 2016
|added = May 4th, 2016
|script_version = 0.32
}}
</ref>

== terrasync.py ==
First of all, the script is now part of the {{fgmeta-python source | text = fgmeta-python}} repository<ref>{{cite web
|url = https://gitlab.com/flightgear/flightgear/-/merge_requests/340
|title = FlightGear merge request 340
|author = Florent Rougon
|date = November 14th, 2025
}}</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/59260673/
|title = <nowiki>[Flightgear-devel] terrasync.py moved to fgmeta-python</nowiki>
|author = Florent Rougon
|date = November 17th, 2025
}}</ref> (this was necessary to share .dirindex processing code with other infrastructure tools, in particular for producing the ''base package''). Installation instructions can be found below the list of files, or more directly in {{fgmeta-python source | path = README.md | text = README.md}}.

The script can provide a complete mirror of the scenery data, also known as TerraSync scenery or just TerraScenery.

{{Caution|If you fully run this script for the first time, it will download more than 90 GB of data and more than 1,800,000 files in 40,000 folders to your hard disk. It will run for hours, probably days (depending on your Internet connection). Since someone has to pay for the bandwidth, please don't let it download large amounts of data unless you have a good reason to do so (like, you maintain a public scenery mirror); otherwise, the service could be discontinued. That being said, if you just want to see the script in action, you can run it for a few seconds and stop it with {{key press|Ctrl|C}}.}}

If you already have at least a partial set of scenery data from the FlightGear built-in TerraSync or even a full TerraScenery, existing and up-to-date files will be reused and won't be downloaded a second time.

=== How it works ===

{{Note|The following is not completely up-to-date. In particular, current terrasync.py has a <code>check</code> mode in addition to the default <code>sync</code> mode. Run <code>terrasync.py --help</code> for up-to-date usage information.}}

The HTTP TerraScenery server holds all the well-know files required for scenery, organized in the also well-known directory structure (/Models, /Objects, /Terrain and /Airports) with all their subdirectories. The content of the /Models folder for example is here: http://flightgear.sourceforge.net/scenery/Models/ Each folder contains a (hidden) file called .dirindex (e.g. http://flightgear.sourceforge.net/scenery/Models/.dirindex) that describes the content of that folder by listing its files, subdirectories and checksums of the files and their subdirectories' .dirindex files. The terrasync.py script does the following (simplified):
* a) download the file at the root of the scenery-url (http://flightgear.sourceforge.net/scenery/.dirindex)
* b) walks into any subdirectory listed within the .dirindex
* c) compares the sha1sum of listed files with the local copy and downloads them on mismatch
* d) for listed subdirectories, calls recursively step b)

Even if all scenery files exist on the server, there are initially still approx. 40,000 .dirindex files missing on your drive and downloading will take hours. To speed up the procedure once you have all .dirindex files locally, try running terrasync.py with the <code>--quick</code> option. This will tell terrasync.py to compare the computed sha1sum of every .dirindex file on your disk with that published in the entry in the parent directory's .dirindex. If you have an up-to-date mirror, this will be ''very'' quick as only the root .dirindex needs to be downloaded. Subsequent updates with the <code>--quick</code> option will also be very fast as only the updated files will be downloaded and also the .dirindex files of the parent folders up to the root directory.

So far, we have just added files to your disk, what about files that have been removed on the server? The script usually does not touch them unless you add <code>--remove-orphan</code> to the command-line. By doing so, you ask terrasync.py to remove all files (not directories) that exist in a subdirectory but are not listed in the corresponding .dirindex file.

If you don't want to download everything into your current working directory, add <code>--target=/some/folder</code> to your command line. This describes pretty much everything terrasync.py does. Here are some examples how to use it:

<syntaxhighlight lang="bash">
# fetch everything from the master repository server into /home/joe/fg/scenery, keep orphan files, (re-)download every .dirindex file
terrasync.py --target=/home/joe/fg/scenery

# just pull in changes, quick and lean for subsequent updates
terrasync.py --target=/home/joe/fg/scenery --quick

# run a mirror, only keep those files listed on the server
terrasync.py --target=/home/joe/fg/scenery --quick --remove-orphan

# use another server to pull the data, not the sourceforge master
terrasync.py --target=/home/joe/fg/scenery --url=http://someserver.org/otherscenery

# restrict the area (must be integers, not decimals)
terrasync.py --target=/home/joe/fg/scenery --top 50 --left 18 --bottom 49 --right 19
</syntaxhighlight>

Enjoy, feedback welcome.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35081518/
|title = <nowiki> [Flightgear-devel] Clone the HTTP scenery data with terrasync.py </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = May 11th, 2016
|added = May 11th, 2016
|script_version = 0.40
}}</ref>

== Related content ==
* [[Howto: Install scenery]]
* [[TerraMaster]]
* [[TerraGear]]

== Footnotes ==
<references/>

[[Category:Scenery software]]
[[Category:FlightGear feature]]

[[de:TerraSync]]
[[es:TerraSync]]
[[fr:TerraSync]]
[[nl:Terrasync]]

AutoEarthView

2026-06-23T12:38:42Z

Fgf5: 0.9.1

{{Infobox Software
| title = AutoEarthView Add-on
| logo = Fgaddonslogo202x89.png |thumb
| image = AutoEarthView.png
| developedby = flyer02@gitlab
| initialrelease = June 21, 2026
| latestrelease = 0.9.1, June 23, 2026
| writtenin = Nasal
| developmentstatus = Stable
| type = Addon
| platform = Min FG version 2024.1
| license = [[GNU General Public License]] v3
| website = https://gitlab.com/flyer02/AutoEarthView
}}

AutoEarthView is a FlightGear [[addon]] that automatically enables/disables [[Earthview|Earthview orbital rendering]] based on the altitude, making it no longer necessary to manually open the EarthView dialog. It automatically starts Earthview when you ascend above a configurable altitude threshold and stops it when you descend below another threshold.

== Features ==

* '''Automatic activation''' – Earthview starts when climbing above the start threshold
* '''Automatic deactivation''' – Earthview stops when descending below the stop threshold
* '''Persistent settings''' – All preferences are saved and restored between sessions
* '''Real-time configuration''' – Adjust thresholds on the fly via a simple dialog
* '''Toggle on/off''' – Enable or disable the automation at any time
* '''Minimal performance impact''' – Altitude checks run every 0.5 seconds

== Installation ==

1. Download the source code from the [https://gitlab.com/flyer02/AutoEarthView/-/releases latest release] and extract it to a directory on your computer. If you want to get the development version, you can run <code>git clone https://gitlab.com/flyer02/AutoEarthView --depth 1</code>.

2. In the launcher, select the Add-ons page from the icon bar on the left, then find the section Add-on Module folders and click the Add(+) button. Select the folder where you put the addon. Once the addon is shown in the list, make sure its check box is selected. The selected folder path should end with "AutoEarthView".

== Usage ==

=== Accessing the Dialog ===

Navigate to the menu bar: '''AutoEarthView → Options'''

=== Configuration Options ===

{| class="wikitable"
|-
! Setting !! Description !! Default
|-
| '''Start threshold''' || Altitude (in feet) at which Earthview automatically starts during climb || 63,000 ft
|-
| '''Stop threshold''' || Altitude (in feet) at which Earthview automatically stops during descent || 30,000 ft
|-
| '''Enabled''' || Master toggle to enable/disable the automation || Enabled
|}

=== Dialog Controls ===

* '''Start threshold''' – Input field for the climb activation altitude
* '''Stop threshold''' – Input field for the descent deactivation altitude
* '''Enabled''' – Checkbox to turn automation on/off
* '''Reset to defaults''' – Restores factory settings

=== Menu Bar ===

The addon adds a new menu: '''AutoEarthView''' with two items:
* '''Options''' – Opens the configuration dialog
* '''About''' – Displays addon information

== How It Works ==

The addon monitors your aircraft's altitude in real-time. When you cross the start threshold during a climb, Earthview is automatically enabled. When you cross the stop threshold during a descent, Earthview is automatically disabled.

Climbing: altitude ≥ 63,000 ft → Earthview starts automatically
Descending: altitude ≤ 30,000 ft → Earthview stops automatically

== Configuration File ==

Settings are stored in <code>~/.fgfs/Export/Addons/org.flightgear.addons.AutoEarthView/save.txt</code>, or <code>C:\Users\your username\AppData\Roaming\flightgear.org\Export\Addons\org.flightgear.addons.AutoEarthView\save.txt</code> on Windows.

[[Category:FlightGear addons]]
[[Category:Spaceflight]]

Addon

2026-06-22T02:23:14Z

Fgf5: /* List of Addons */ Earthview#Customization: not an addon

[[File:Fgaddonslogo202x89.png|right]]
An '''addon''' is a third-party pack for FlightGear containing enhancements.

== Installing an addon ==
Download and copy the add-on to a directory on your computer.

In the launcher, select the Add-ons page from the icon bar on the left, then find the "Add-on Module folders" section and click the Add (+) button. Select the folder where you put the add-on. Make sure the selected folder path ends with the add-on name (such as "Logbook").

Alternatively, use the command line switch <code>--addon=/path/to/some/addon</code> if you are not using the launcher.

Some add-ons (like Aerotow Everywhere) may require additional actions. Please also read the description of the specific add-on.

== List of Addons ==
You can find the official repository at {{fgaddon source|path=Addons}}

# [https://github.com/PlayeRom/flightgear-addon-menu-aggregator Add-ons Menu Aggregator] - this add-on aggregates the menus of all other add-ons into one menu item.
# [[Aerotow Everywhere Add-on]] - AI towing aircraft for gliders at every airport.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=40742
|title = <nowiki> Re: Aerotow Everywhere </nowiki>
|author = <nowiki> Roman Ludwicki (PlayeRom) </nowiki>
|date = Aug 14th, 2022
|added = Aug 14th, 2022
|script_version = 0.40
}}</ref>
# [https://github.com/SP-NTX/AnotherGUI AnotherGUI] - An add-on that adds a new GUI style.
# {{fgaddon source|path=Addons/ATCChatter/|text=ATC Chatter}} (ported by Torsten).
# [[AutoEarthView]] - an addon for spaceflight that automatically starts/stops Earthview based on the altitude
# [[Blacklist add-on]] - Automatically ignore pilots with certain callsigns or multiplayer models.
# [[Bombable]] - military add-on.
# [[Cargo Towing Addon]] <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=36824
|title = <nowiki> Re: Cargo Towing Addon </nowiki>
|author = <nowiki> Wayne Bragg (wlbragg) </nowiki>
|date =
|added =
|script_version = 0.40
}}</ref> - Allow any helicopter to tow, move and place various types of models.
# [[FaceTrackNoIR]] (ported by HHS)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36454826/
|title = <nowiki> Re: </nowiki>
|author = <nowiki> Unknown, HHS</nowiki>
|date = Nov 1th, 2018
}}</ref> - An addon to interface this [[Head tracking|head tracker]] with FlightGear
# [https://forum.flightgear.org/viewtopic.php?f=5&t=24792 Fencemaker] (Eases creating Fence-like scenery objects. Originally by VaLeo, converted to an addon by sfr) - ([https://www.mediafire.com/file/cf0la63v9g352md/fencemaker_addon.zip/file download])<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?f=5&t=24792&start=45#p390066
|title = <nowiki> Re: </nowiki>
|author = <nowiki> Stefan Frank </nowiki>
|maintainer = <nowiki> Stefan Frank </nowiki>
|date = Aug 8th, 2021
}}</ref>
# [https://github.com/PlayeRom/flightgear-addon-fgcamera FGCamera] - ([https://github.com/PlayeRom/flightgear-addon-fgcamera/blob/master/Docs/manual.md manual]) - [[FGCamera | Wiki Page]]
# [[FGPlot]]
# [https://gitlab.com/fg_shfsn/addons/flight-planner Flight Planner] - a flexible tool for manual flight planning and airport briefing.
# [[Ground Services]] (ported by ThomasS)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=316400#p316400
|title = <nowiki> Re: </nowiki>
|author = <nowiki> ThomasS </nowiki>
|date = Aug 12th, 2017
|added = Aug 12th, 2017
|script_version = 0.40
}}</ref>
# [https://gitlab.com/fg_shfsn/addons/hax Hax!]: landing evaluation and aircraft development tools, TerraSync toggler.
# {{fgaddon source|path=Addons/Headtracker/|text=Headtracker addon}} Helps integrate FaceTrackNoIR and opentrack with FlightGear.
# [[HighAirTrader]] An in-sim mini game in which you transport goods to different airports.
# [https://github.com/tdammers/fg-hoppie-acars Hoppie ACARS client] - connect to [http://www.hoppie.nl/acars Hoppie's ACARS], used on VATSIM and other networks.
# [https://github.com/slawekmikula/flightgear-addon-hudheli HUD Heli] - additional Heli HUD's ([https://github.com/slawekmikula/flightgear-addon-hudheli/blob/master/doc/manual.md manual]) - encapsulation of HeliHUD package as an addon.
# [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/Illuminator/ Illuminator] - configure lights attached to 3D models (e.g. taxi light, landing light or a light attached to a scenery model like a light pole) at runtime.
# [https://github.com/slawekmikula/flightgear-addon-protocolkml KML Exporter (Google Earth)] - ([https://github.com/slawekmikula/flightgear-addon-protocolkml/blob/master/doc/manual.md manual])
# [[Landing Rate addon]] [https://forum.flightgear.org/viewtopic.php?f=6&t=33101&p=327787#p327787]
# [https://github.com/slawekmikula/flightgear-addon-linuxtrack LinuxTrack Head Tracker integration] - ([https://github.com/slawekmikula/flightgear-addon-linuxtrack/blob/master/doc/manual.md manual])
# [https://github.com/slawekmikula/flightgear-addon-littlenavmap LittleNavMap integration] - ([https://github.com/slawekmikula/flightgear-addon-littlenavmap/blob/master/doc/manual.md manual])
# [[Logbook Add-on]] - logs all your flights to local file with flight analysis.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=41070
|title = <nowiki> Re: Logbook Add-on </nowiki>
|author = <nowiki> Roman Ludwicki (PlayeRom) </nowiki>
|date = Dec 11th, 2022
|added = Dec 11th, 2022
|script_version = 0.40
}}</ref>
# [[Log time-stamper add-on]] - Will print simulated UTC time, real local time, and/or real UTC time time-stamps at configurable intervals to the console and log.
# [https://gitlab.com/fg_shfsn/addons/mickey Mickey] - Tiny HUD for mouse flying in FlightGear. Visual feedback for mouse flying, to make up for mouse's lack of self-centering.
# [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/MissionGenerator Mission Generator Addon] <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=39774
|title = <nowiki> Re: Announcing Mission Generator Addon </nowiki>
|author = <nowiki> Wayne Bragg (wlbragg) </nowiki>
|date =
|added =
|script_version = 0.40
}}</ref> - Generate various random missions - Search & Rescue, Life Flight, Aerial Intrusion, Wildfire.
# [https://github.com/SP-NTX/MPChatImprovments MPChatImprovments] Multi-key commands for Multiplayer, new features for chat,...
# [https://github.com/PlayeRom/flightgear-addon-nasal-namespace-browser Nasal Namespace Browser] - heir to [[Nasal Browser]]
# [https://github.com/hbeni/fgfs-noGroundDamage noGroundDamage] - Addon to temporarily disable damage after landing and for ground operations for the c172/c182
# [[Oscilloscope addon]] - Allows displaying a property of Nasal function over time
# [[PAR instrument]] - Precision Approach Radar and Ground Controlled Approach
# [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/RainVectorEditor/ Rain Vector Editor] - Utility to allow dynamic editing of the rain vector for the rain effect on glass.
# [[Ramp Marshall]] <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=20572
|title = <nowiki> Re: Nasal based Independant Ramp Marshall </nowiki>
|author = <nowiki> omega95 - Wayne Bragg (wlbragg)</nowiki>
|date =
|added =
|script_version = 0.40
}}{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=42753
|title = <nowiki> Re: Announcing New Ramp Marshall Addon </nowiki>
|author =
|date =
|added =
|script_version = 0.40
}}</ref> - Ramp Marshalling for FlightGear Airports.
# [https://github.com/eatdust/RCView RCView] - Radio Control View<ref>{{cite web
|url = https://github.com/eatdust/RCView
|title = <nowiki> RCView </nowiki>
|author = <nowiki> Chris Ringeval (Eatdirt) </nowiki>
|date = Mar 23rd, 2024
|added = Mar 23rd, 2024
|script_version = 0.0
}}</ref>
# [[Red Griffin ATC]] - Speaking Air Traffic Controller<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?f=6&t=36755
|title = <nowiki> Re: </nowiki>
|author = <nowiki> RedGriffin </nowiki>
|date = Jan 6th, 2020
|added = Jan 6th, 2020
|script_version = 1.0.0 RC2
}}</ref>
# [https://github.com/tdammers/fg-simbrief-addon SimBrief import] - Import flightplans, weights, fuel, and winds alof, from SimBrief.
# [[Spoken ATC]] (ported by Torsten)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=314095#p314095
|title = <nowiki> Re: </nowiki>
|author = <nowiki> Torsten </nowiki>
|date = Jul 10th, 2017
|added = Jul 10th, 2017
|script_version = 0.40
}}</ref>
# [[Spoken GCA]] - An offline ground controlled approach (GCA) addon
# [https://github.com/slawekmikula/flightgear-addon-vfrflight VFRFlight integration] - ([https://github.com/slawekmikula/flightgear-addon-vfrflight/blob/master/doc/manual.md manual])
# [https://github.com/slawekmikula/flightgear-addon-vfrnavigator VFR Flying Helper] - ([https://github.com/slawekmikula/flightgear-addon-vfrnavigator/blob/master/doc/usage.md manual])
# [[Which Runway Add-on]] - dynamically determines and displays the optimal runway for take-off and landing based on current wind and airport preferences, while calculating headwind, crosswind, and tailwind components for each runway.<ref>{{cite web
|url = https://github.com/PlayeRom/flightgear-addon-which-runway
|title = <nowiki> Which Runway GitHub </nowiki>
|author = <nowiki> Roman Ludwicki (PlayeRom) </nowiki>
|date = Sep 10th, 2025
|added = Sep 10th, 2025
|script_version = 0.40
}}</ref>
# [[Wildfire simulation|Wildfire]] <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=39677
|title = <nowiki> Re: Wildfire Addon </nowiki>
|author = <nowiki> AndersG - Wayne Bragg (wlbragg) </nowiki>
|date =
|added =
|script_version = 0.40
}}</ref> - Wildfire simulation.
# [[YASim Development Tools]] (by jsb)

=== Experimental Addons ===

Addons which are in the development stage/unfinished but can be used as a quick view of addon functionality

# [https://github.com/slawekmikula/flightgear-addon-missions FlightGear Missions addon] - Add-on for missions/adventures code
# [[Model Cockpit View]] (abandoned)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?f=30&t=32718&start=45#p430651
|title = <nowiki> Re: </nowiki>
|author = <nowiki> wkitty42 </nowiki>
|date = Mar 24th, 2025
|added = Mar 24th, 2025
|script_version = 0.40
}}</ref>

== Creating an addon ==
There is a very simple Skeleton addon available in FGAddon to be used as a template.<ref name="Forum_announcement">{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35894463/
|title = <nowiki> [Flightgear-devel] Emesary / Multiplayer improvements </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Jun 14th, 2017
|added = Jun 14th, 2017
|script_version = 0.40
}}</ref> See {{fgaddon source|path=Addons/Skeleton}}.

A leading slash (<code>/</code>) in this section indicates the base directory of the directory structure of the addon.

=== Minimum configuration ===
An addon may be installed in a directory anywhere on your hard disk and need at least two files:

* <code>/addon-config.xml</code> - A standard [[PropertyList XML files|PropertyList XML file]] to be used to populate or modify the [[property tree]]. (Same as to be used in <code>--config=foo.xml</code>)
* <code>/addon-main.nas</code> - The Nasal hook for the logic. This file needs a function called <code>main()</code> which will be called from the global addon initializer (<code>addons.nas</code>)

=== Additional common files ===
* <code>/addon-metadata.xml</code> - A PropertyList XML file with metadata about the addon it.
* <code>/addon-menubar-items.xml</code> - A PropertyList XML file describing menus to be added to the FlightGear menu bar.
* <code>/gui/dialogs/<my-foobar-dialog>.xml</code> - PropertyList XML files to create custom dialogs.

=== Good to know ===
The new addon mechanism lets you add a <code>addon-config.xml</code> to override the settings in <code>defaults.xml</code> and other files.

That will allow an addon to:
* override key bindings (as in the spoken ATC addon),
* add or override autopilots and property rules,
* introduce XML state machines.

Unless your really want to add/change/remove those at runtime, this should cater for most use cases.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=314902#p314902
|title = <nowiki> Re: Spoken </nowiki>
|author = <nowiki> Torsten </nowiki>
|date = Jul 23rd, 2017
|added = Jul 23rd, 2017
|script_version = 0.40
}}</ref>

=== Sound Support ===
Sound support is available using fgcommand's.

See also [[Howto:Play sound using Nasal script]].

== Addon initialization ==
On initialization fgfs takes care of:
* Through {{flightgear source|path=src/Main/options.cxx|text=<code>options.cxx</code>}}:<ref name="Forum_announcement"/>
** Creating a property under <code>/addons/addon[n]/path=/path/to/some/addon</code>
** Loading <code>/path/to/some/addon/addon-config.xml</code> into the property tree (same as <code>--config=/path/to/some/addon/addon-config.xml</code>)
** Adding <code>/path/to/some/addon</code> to the list of allowed directories (same as <code>--fg-aircraft=/path/to/some/addon</code>)
* Through {{fgdata source|path=Nasal/addons.nas|text=<code>addons.nas</code>}}:
** Loading <code>/foo/bar/baz/addon-main.nas</code> into namespace <code>__addon[ADDON_ID]__</code>
** Calling <code>main(addonGhost)</code> from <code>/foo/bar/baz/addon-main.nas</code>.

== Aircraft specific config (addon-hints) ==
Some addons need per-aircraft configuration. While addons should strive to be self-contained (ie. the addon should contain means to
detect different aircraft and apply config from whithin the addon) there is also the possibility for the addon to read so called "addon-hints".

For this, a special property tree exists: <code>/sim/addon-hints/<addon>/...</code>
The tree is expected to be populated from the aircraft.xml file. The addon can then read the properties from a common place regardless of loaded aircraft.

<syntaxhighlight lang="xml">
<sim>
<addon-hints>
<my-addon>
...
</my-addon>
</addon-hints>
</sim>
</syntaxhighlight>

== APIs ==
{{hatnote|For more details about these APIs, see the readme file, {{readme file|add-ons}}.}}
=== C++ API ===
There is a C++ API on FlightGear's side that handle some on the add-on related tasks manly through the <code>AddonManager()</code>, <code>Addon()</code> and <code>AddonVersion()</code> classes.

=== Nasal API ===
The Nasal add-on API lives in the 'addons' namespace and can for example do queries to <code>AddonManager()</code> and read data from <code>addons.Addon</code> objects. It can for example compare add-on versions if there is dependencies.

See: {{Repo link|site=gitlab|proj=flightgear|repo=fgdata|branch=next|path=Nasal/addons.nas}}

== References ==
{{Appendix}}

== Related content ==
=== Wiki articles ===
* [[Modules.nas]]
* [[FlightGear configuration via XML]]
* [[FlightGear configuration via XML#preferences.xml]]
* [[Nasal]]
* [[Property tree]]
* [[Properties persistent between sessions]]
* [[PropertyList XML File]]

=== Forum topics ===
* {{forum link|t=32561|title=New Feature: Addon - "API"}}

=== Readme files ===
* {{readme file|add-ons}} - An introduction to add-ons
* {{readme file|gui}} - Details on how to add menus and custom dialogs.

=== Source code ===
==== FGAddon ====
* {{fgaddon source|path=Addons/Skeleton}} - Skeleton addon to be used as a template.

==== FGData ====
* {{fgdata source|path=Nasal/addons.nas}}

==== FlightGear ====
* {{flightgear source|path=src/Main/options.cxx}}
* {{flightgear source|path=src/Add-ons/}}

[[Category:FlightGear addons| ]]

Addon

2026-06-22T02:21:54Z

Fgf5: /* List of Addons */ autoearthview

[[File:Fgaddonslogo202x89.png|right]]
An '''addon''' is a third-party pack for FlightGear containing enhancements.

== Installing an addon ==
Download and copy the add-on to a directory on your computer.

In the launcher, select the Add-ons page from the icon bar on the left, then find the "Add-on Module folders" section and click the Add (+) button. Select the folder where you put the add-on. Make sure the selected folder path ends with the add-on name (such as "Logbook").

Alternatively, use the command line switch <code>--addon=/path/to/some/addon</code> if you are not using the launcher.

Some add-ons (like Aerotow Everywhere) may require additional actions. Please also read the description of the specific add-on.

== List of Addons ==
You can find the official repository at {{fgaddon source|path=Addons}}

# [https://github.com/PlayeRom/flightgear-addon-menu-aggregator Add-ons Menu Aggregator] - this add-on aggregates the menus of all other add-ons into one menu item.
# [[Aerotow Everywhere Add-on]] - AI towing aircraft for gliders at every airport.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=40742
|title = <nowiki> Re: Aerotow Everywhere </nowiki>
|author = <nowiki> Roman Ludwicki (PlayeRom) </nowiki>
|date = Aug 14th, 2022
|added = Aug 14th, 2022
|script_version = 0.40
}}</ref>
# [https://github.com/SP-NTX/AnotherGUI AnotherGUI] - An add-on that adds a new GUI style.
# {{fgaddon source|path=Addons/ATCChatter/|text=ATC Chatter}} (ported by Torsten).
# [[AutoEarthView]] - an addon for spaceflight that automatically starts/stops Earthview based on the altitude
# [[Blacklist add-on]] - Automatically ignore pilots with certain callsigns or multiplayer models.
# [[Bombable]] - military add-on.
# [[Cargo Towing Addon]] <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=36824
|title = <nowiki> Re: Cargo Towing Addon </nowiki>
|author = <nowiki> Wayne Bragg (wlbragg) </nowiki>
|date =
|added =
|script_version = 0.40
}}</ref> - Allow any helicopter to tow, move and place various types of models.
# [[Earthview#Customization]] - High resolution customization
# [[FaceTrackNoIR]] (ported by HHS)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36454826/
|title = <nowiki> Re: </nowiki>
|author = <nowiki> Unknown, HHS</nowiki>
|date = Nov 1th, 2018
}}</ref> - An addon to interface this [[Head tracking|head tracker]] with FlightGear
# [https://forum.flightgear.org/viewtopic.php?f=5&t=24792 Fencemaker] (Eases creating Fence-like scenery objects. Originally by VaLeo, converted to an addon by sfr) - ([https://www.mediafire.com/file/cf0la63v9g352md/fencemaker_addon.zip/file download])<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?f=5&t=24792&start=45#p390066
|title = <nowiki> Re: </nowiki>
|author = <nowiki> Stefan Frank </nowiki>
|maintainer = <nowiki> Stefan Frank </nowiki>
|date = Aug 8th, 2021
}}</ref>
# [https://github.com/PlayeRom/flightgear-addon-fgcamera FGCamera] - ([https://github.com/PlayeRom/flightgear-addon-fgcamera/blob/master/Docs/manual.md manual]) - [[FGCamera | Wiki Page]]
# [[FGPlot]]
# [https://gitlab.com/fg_shfsn/addons/flight-planner Flight Planner] - a flexible tool for manual flight planning and airport briefing.
# [[Ground Services]] (ported by ThomasS)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=316400#p316400
|title = <nowiki> Re: </nowiki>
|author = <nowiki> ThomasS </nowiki>
|date = Aug 12th, 2017
|added = Aug 12th, 2017
|script_version = 0.40
}}</ref>
# [https://gitlab.com/fg_shfsn/addons/hax Hax!]: landing evaluation and aircraft development tools, TerraSync toggler.
# {{fgaddon source|path=Addons/Headtracker/|text=Headtracker addon}} Helps integrate FaceTrackNoIR and opentrack with FlightGear.
# [[HighAirTrader]] An in-sim mini game in which you transport goods to different airports.
# [https://github.com/tdammers/fg-hoppie-acars Hoppie ACARS client] - connect to [http://www.hoppie.nl/acars Hoppie's ACARS], used on VATSIM and other networks.
# [https://github.com/slawekmikula/flightgear-addon-hudheli HUD Heli] - additional Heli HUD's ([https://github.com/slawekmikula/flightgear-addon-hudheli/blob/master/doc/manual.md manual]) - encapsulation of HeliHUD package as an addon.
# [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/Illuminator/ Illuminator] - configure lights attached to 3D models (e.g. taxi light, landing light or a light attached to a scenery model like a light pole) at runtime.
# [https://github.com/slawekmikula/flightgear-addon-protocolkml KML Exporter (Google Earth)] - ([https://github.com/slawekmikula/flightgear-addon-protocolkml/blob/master/doc/manual.md manual])
# [[Landing Rate addon]] [https://forum.flightgear.org/viewtopic.php?f=6&t=33101&p=327787#p327787]
# [https://github.com/slawekmikula/flightgear-addon-linuxtrack LinuxTrack Head Tracker integration] - ([https://github.com/slawekmikula/flightgear-addon-linuxtrack/blob/master/doc/manual.md manual])
# [https://github.com/slawekmikula/flightgear-addon-littlenavmap LittleNavMap integration] - ([https://github.com/slawekmikula/flightgear-addon-littlenavmap/blob/master/doc/manual.md manual])
# [[Logbook Add-on]] - logs all your flights to local file with flight analysis.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=41070
|title = <nowiki> Re: Logbook Add-on </nowiki>
|author = <nowiki> Roman Ludwicki (PlayeRom) </nowiki>
|date = Dec 11th, 2022
|added = Dec 11th, 2022
|script_version = 0.40
}}</ref>
# [[Log time-stamper add-on]] - Will print simulated UTC time, real local time, and/or real UTC time time-stamps at configurable intervals to the console and log.
# [https://gitlab.com/fg_shfsn/addons/mickey Mickey] - Tiny HUD for mouse flying in FlightGear. Visual feedback for mouse flying, to make up for mouse's lack of self-centering.
# [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/MissionGenerator Mission Generator Addon] <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=39774
|title = <nowiki> Re: Announcing Mission Generator Addon </nowiki>
|author = <nowiki> Wayne Bragg (wlbragg) </nowiki>
|date =
|added =
|script_version = 0.40
}}</ref> - Generate various random missions - Search & Rescue, Life Flight, Aerial Intrusion, Wildfire.
# [https://github.com/SP-NTX/MPChatImprovments MPChatImprovments] Multi-key commands for Multiplayer, new features for chat,...
# [https://github.com/PlayeRom/flightgear-addon-nasal-namespace-browser Nasal Namespace Browser] - heir to [[Nasal Browser]]
# [https://github.com/hbeni/fgfs-noGroundDamage noGroundDamage] - Addon to temporarily disable damage after landing and for ground operations for the c172/c182
# [[Oscilloscope addon]] - Allows displaying a property of Nasal function over time
# [[PAR instrument]] - Precision Approach Radar and Ground Controlled Approach
# [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/RainVectorEditor/ Rain Vector Editor] - Utility to allow dynamic editing of the rain vector for the rain effect on glass.
# [[Ramp Marshall]] <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=20572
|title = <nowiki> Re: Nasal based Independant Ramp Marshall </nowiki>
|author = <nowiki> omega95 - Wayne Bragg (wlbragg)</nowiki>
|date =
|added =
|script_version = 0.40
}}{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=42753
|title = <nowiki> Re: Announcing New Ramp Marshall Addon </nowiki>
|author =
|date =
|added =
|script_version = 0.40
}}</ref> - Ramp Marshalling for FlightGear Airports.
# [https://github.com/eatdust/RCView RCView] - Radio Control View<ref>{{cite web
|url = https://github.com/eatdust/RCView
|title = <nowiki> RCView </nowiki>
|author = <nowiki> Chris Ringeval (Eatdirt) </nowiki>
|date = Mar 23rd, 2024
|added = Mar 23rd, 2024
|script_version = 0.0
}}</ref>
# [[Red Griffin ATC]] - Speaking Air Traffic Controller<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?f=6&t=36755
|title = <nowiki> Re: </nowiki>
|author = <nowiki> RedGriffin </nowiki>
|date = Jan 6th, 2020
|added = Jan 6th, 2020
|script_version = 1.0.0 RC2
}}</ref>
# [https://github.com/tdammers/fg-simbrief-addon SimBrief import] - Import flightplans, weights, fuel, and winds alof, from SimBrief.
# [[Spoken ATC]] (ported by Torsten)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=314095#p314095
|title = <nowiki> Re: </nowiki>
|author = <nowiki> Torsten </nowiki>
|date = Jul 10th, 2017
|added = Jul 10th, 2017
|script_version = 0.40
}}</ref>
# [[Spoken GCA]] - An offline ground controlled approach (GCA) addon
# [https://github.com/slawekmikula/flightgear-addon-vfrflight VFRFlight integration] - ([https://github.com/slawekmikula/flightgear-addon-vfrflight/blob/master/doc/manual.md manual])
# [https://github.com/slawekmikula/flightgear-addon-vfrnavigator VFR Flying Helper] - ([https://github.com/slawekmikula/flightgear-addon-vfrnavigator/blob/master/doc/usage.md manual])
# [[Which Runway Add-on]] - dynamically determines and displays the optimal runway for take-off and landing based on current wind and airport preferences, while calculating headwind, crosswind, and tailwind components for each runway.<ref>{{cite web
|url = https://github.com/PlayeRom/flightgear-addon-which-runway
|title = <nowiki> Which Runway GitHub </nowiki>
|author = <nowiki> Roman Ludwicki (PlayeRom) </nowiki>
|date = Sep 10th, 2025
|added = Sep 10th, 2025
|script_version = 0.40
}}</ref>
# [[Wildfire simulation|Wildfire]] <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=39677
|title = <nowiki> Re: Wildfire Addon </nowiki>
|author = <nowiki> AndersG - Wayne Bragg (wlbragg) </nowiki>
|date =
|added =
|script_version = 0.40
}}</ref> - Wildfire simulation.
# [[YASim Development Tools]] (by jsb)

=== Experimental Addons ===

Addons which are in the development stage/unfinished but can be used as a quick view of addon functionality

# [https://github.com/slawekmikula/flightgear-addon-missions FlightGear Missions addon] - Add-on for missions/adventures code
# [[Model Cockpit View]] (abandoned)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?f=30&t=32718&start=45#p430651
|title = <nowiki> Re: </nowiki>
|author = <nowiki> wkitty42 </nowiki>
|date = Mar 24th, 2025
|added = Mar 24th, 2025
|script_version = 0.40
}}</ref>

== Creating an addon ==
There is a very simple Skeleton addon available in FGAddon to be used as a template.<ref name="Forum_announcement">{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35894463/
|title = <nowiki> [Flightgear-devel] Emesary / Multiplayer improvements </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Jun 14th, 2017
|added = Jun 14th, 2017
|script_version = 0.40
}}</ref> See {{fgaddon source|path=Addons/Skeleton}}.

A leading slash (<code>/</code>) in this section indicates the base directory of the directory structure of the addon.

=== Minimum configuration ===
An addon may be installed in a directory anywhere on your hard disk and need at least two files:

* <code>/addon-config.xml</code> - A standard [[PropertyList XML files|PropertyList XML file]] to be used to populate or modify the [[property tree]]. (Same as to be used in <code>--config=foo.xml</code>)
* <code>/addon-main.nas</code> - The Nasal hook for the logic. This file needs a function called <code>main()</code> which will be called from the global addon initializer (<code>addons.nas</code>)

=== Additional common files ===
* <code>/addon-metadata.xml</code> - A PropertyList XML file with metadata about the addon it.
* <code>/addon-menubar-items.xml</code> - A PropertyList XML file describing menus to be added to the FlightGear menu bar.
* <code>/gui/dialogs/<my-foobar-dialog>.xml</code> - PropertyList XML files to create custom dialogs.

=== Good to know ===
The new addon mechanism lets you add a <code>addon-config.xml</code> to override the settings in <code>defaults.xml</code> and other files.

That will allow an addon to:
* override key bindings (as in the spoken ATC addon),
* add or override autopilots and property rules,
* introduce XML state machines.

Unless your really want to add/change/remove those at runtime, this should cater for most use cases.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=314902#p314902
|title = <nowiki> Re: Spoken </nowiki>
|author = <nowiki> Torsten </nowiki>
|date = Jul 23rd, 2017
|added = Jul 23rd, 2017
|script_version = 0.40
}}</ref>

=== Sound Support ===
Sound support is available using fgcommand's.

See also [[Howto:Play sound using Nasal script]].

== Addon initialization ==
On initialization fgfs takes care of:
* Through {{flightgear source|path=src/Main/options.cxx|text=<code>options.cxx</code>}}:<ref name="Forum_announcement"/>
** Creating a property under <code>/addons/addon[n]/path=/path/to/some/addon</code>
** Loading <code>/path/to/some/addon/addon-config.xml</code> into the property tree (same as <code>--config=/path/to/some/addon/addon-config.xml</code>)
** Adding <code>/path/to/some/addon</code> to the list of allowed directories (same as <code>--fg-aircraft=/path/to/some/addon</code>)
* Through {{fgdata source|path=Nasal/addons.nas|text=<code>addons.nas</code>}}:
** Loading <code>/foo/bar/baz/addon-main.nas</code> into namespace <code>__addon[ADDON_ID]__</code>
** Calling <code>main(addonGhost)</code> from <code>/foo/bar/baz/addon-main.nas</code>.

== Aircraft specific config (addon-hints) ==
Some addons need per-aircraft configuration. While addons should strive to be self-contained (ie. the addon should contain means to
detect different aircraft and apply config from whithin the addon) there is also the possibility for the addon to read so called "addon-hints".

For this, a special property tree exists: <code>/sim/addon-hints/<addon>/...</code>
The tree is expected to be populated from the aircraft.xml file. The addon can then read the properties from a common place regardless of loaded aircraft.

<syntaxhighlight lang="xml">
<sim>
<addon-hints>
<my-addon>
...
</my-addon>
</addon-hints>
</sim>
</syntaxhighlight>

== APIs ==
{{hatnote|For more details about these APIs, see the readme file, {{readme file|add-ons}}.}}
=== C++ API ===
There is a C++ API on FlightGear's side that handle some on the add-on related tasks manly through the <code>AddonManager()</code>, <code>Addon()</code> and <code>AddonVersion()</code> classes.

=== Nasal API ===
The Nasal add-on API lives in the 'addons' namespace and can for example do queries to <code>AddonManager()</code> and read data from <code>addons.Addon</code> objects. It can for example compare add-on versions if there is dependencies.

See: {{Repo link|site=gitlab|proj=flightgear|repo=fgdata|branch=next|path=Nasal/addons.nas}}

== References ==
{{Appendix}}

== Related content ==
=== Wiki articles ===
* [[Modules.nas]]
* [[FlightGear configuration via XML]]
* [[FlightGear configuration via XML#preferences.xml]]
* [[Nasal]]
* [[Property tree]]
* [[Properties persistent between sessions]]
* [[PropertyList XML File]]

=== Forum topics ===
* {{forum link|t=32561|title=New Feature: Addon - "API"}}

=== Readme files ===
* {{readme file|add-ons}} - An introduction to add-ons
* {{readme file|gui}} - Details on how to add menus and custom dialogs.

=== Source code ===
==== FGAddon ====
* {{fgaddon source|path=Addons/Skeleton}} - Skeleton addon to be used as a template.

==== FGData ====
* {{fgdata source|path=Nasal/addons.nas}}

==== FlightGear ====
* {{flightgear source|path=src/Main/options.cxx}}
* {{flightgear source|path=src/Add-ons/}}

[[Category:FlightGear addons| ]]

Earthview

2026-06-22T02:21:39Z

Fgf5: /* Related content */

{{See also|Flying on other planets}}

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] or even the [[UFO]], neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

{{Spaceflight}}
== Overview ==
[[File:menubar2.jpg|517px]]

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

[[File:Earthview menu.jpg|thumb|260px]]

The options checkboxes allow to select

* whether a cloud layer should be rendered above the planet
* whether the cloud layer information should be used to render cloud shadows onto the terrain
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution
* whether textures should be rendered with lighting based on a normal map. Parallax effects are also computed if the normal map contains an alpha channel encoding the inverse height of the Earth's relief
* whether clouds should be rendered with lighting and parallax effects. These are computed using the alpha channel of the cloud map as an input information of their vertical extension

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals. If you don't want to start and stop it manually, you can install the [[AutoEarthView]] addon.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if [[Atmospheric light scattering]] (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of [[A local weather system | Advanced Weather]] (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the [http://visibleearth.nasa.gov/ NASA Visible Earth project] - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently, due to size concern, all the textures distributed in FGData are of low resolution (2048p x 2048p per tile) and do not incorporate the alpha channel encoding the height. Parallax mapping for ground textures is therefore disabled. It is however possible to obtain the textures from the NASA website, process them and straightforwardly use them as a replacement. More detailed instructions to do so are given below in the section "Customization".

At highest texture resolution, visuals are generally very compelling:

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

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

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

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]

== Requirements ==

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory. All textures are split into eight tiles, four for the northern hemisphere (N1 to N4), and four for the southern hemisphere (S1 to S4) and each tile is loaded, or unloaded, according to visibility. As such, GPU memory is efficiently used and limited graphic card memory should not be an issue for the default texture size. However, the loading of a texture tile induces some bottleneck and FG may hang for a couple of seconds, or more (depending on tile resolution), while the texture appears.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format, but these can be generated along the lines discussed in the "Customization" section.

For high-end graphic cards, it is possible to actually force the loading of all texture tiles at once when Earthview starts. This is triggered with the command line option:

--prop:/earthview/show-force-all=true

With the maximum resolution textures (16384x16384 pixels for a world tile and 8192x8192 pixels for a cloud and a normalmap tile), expect a minute or more for the loading, around 6GB of GPU memory and 16GB of RAM to be filled. If you can afford it, there will be no other loading bottleneck afterwards. These numbers can accordingly be lowered using lower resolution tiles.

Finally, while it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as [[Project Rembrandt]] do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues. As such, on old flightgear versions (up to 2018) when using the [[Compositor]] as the rendering pipeline, it is compulsory to default it to ALS with --compositor=Compositor/als. Flightgear versions 2020 to 2024 uses the Compositor by default and ALS rendering can be switched on in the Rendering menu.

== Customization ==

To get full advantage of Earthview, and your graphic card, you may install and use your own high resolution tiles as well as normal maps having a alpha channel to trigger parallax mapping.

=== Texture generation ===

There are two ways to obtain these textures:

==== The easy way ====

When our resources allow for it, some users generate these textures and make them available for download. They may be obtained via torrent with this magnet link:

magnet:?xt=urn:btih:6df05a15c863040fd31278dfd1f719523b639cf2&dn=EarthView.World.August-2020.06

and may also be available for download at this url:

[https://curl.irmp.ucl.ac.be/~chris/upload/fg/earthview/ Earthview/]

A bash script to automatically download the full per-month data from above url [http://ix.io/3ogk is available here]. It downloads the dataset for every month, or it symlinks a dataset for a specified month into a specified place, see help of the script (run without arguments or with '-h'). To choose which resolution(s) to download or which image file format(s) to download the variables in the script needs to be edited. Needs an unix environment with bash and wget.

==== The interesting way ====

Most likely the easy way is no longer available, or you are curious. Chris_Blues made a wonderful Bash-script that will download the NASA images and do the texture generation for you, in the correct way. It is available on github, together with the instructions on how to use it:

[https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview]

This program can generate world, clouds and normal maps with height data included in the alpha channel, and at various resolutions ranging from 1024x1024 to 16384x16384 pixels.

==== Remarks ====

Notice that all the input images are provided by NASA and any usage of the textures should be made in accordance with their distribution policy. They are directly accessible for download at [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and search for a texture set of your choice.

NASA provides different seasons for the Earth images, even one set of images per month. [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] allows you to chose the month for which you want to generate your set of tiles.

Graphics cards prefer powers of two in texture sizes, so [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] resizes the tiles to 1024x1024, 2048x2048, 4096x4096, 8192x8192 or 16384x16384 pixels. Be aware of the original image resolution, there is no much gain into using a super-sampled tile. For instance, the current cloud maps provided by NASA have a resolution of typically 10000 pixels. Using 8192x8192 sampling is the best option, the gain of super-sampling it at 16384x16384 is very small. Similar thing holds true for heights and normalmaps (16384x16384 for them is also supersampled, so prefer at most 8192x8192 for them).

=== Installing and using customized textures ===

The texture tiles loaded by Earthview reside in

$FGData/Models/Astro/Textures

where $FGData depends on the installation path of flightgear-fgdata. If you only want to use "png" texture tiles, simply replace all the '''world_*.png''', '''clouds_*.png''' and '''normalmap_earth_*.png''' files by your own.

If you want to use "dds" mipmapped images, then you have to edit a few "ac" files to tell Earthview to use them. These configuration files reside in

$FGData/Models/Astro

and are

earth_*.ac

On Unix systems, the program '''sed''' is your friend (but make a backup before).

* Remarks
It is possible to assign any image you fancy to be used as a tile by Earthview. For this, you can edit the file '''earth_unitscale_rawuv.ac''' to load your images, and edit '''earth.xml''' such that it points to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. You can do the same for '''cloudsphere.xml'''. However, assigning textures in this manner, as they are to the "rawuv" sphere, creates visible seams where the texture sheets end. This is particularly visible if parallax mapping is rendered as the computation requires shifting the textures over the sphere.

The solution is to add margins that encompass a bit of the neighbouring tiles. This is what [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] is doing (as well as the texture set provided). These bordered tiles don't use '''earth_unitscale_rawuv.ac''' but instead '''earth_unitscale_hires.ac''', which is the default (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the original discussion). In other words, if you use [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] to generate your own textures, you do not need to change '''earth.xml''' nor '''earth_unitscale_rawuv.ac'''. Notice that you still need to edit '''earth_unitscale_hires.ac''' (and the rest of the '''earth_*.ac''') if you want to use dds tiles!

=== Open tips ===

* Since there is no limit to customization, and if you can afford 50GB of disk space, you can create a whole set of directories containing Earth textures for each month of the year, as for instance:

EarthView.World.January-2020.06/
EarthView.World.February-2020.06/
...

On linux, a simple "cron" job can automatically link the content of one of these directories to '''$FGData/Models/Astro/Textures/''', like this one:

#!/bin/bash
TEXTUREDIR="/usr/share/games/flightgear-extra/Models/Textures"
TIMESTAMP="2020.06"
MONTH=$(date +%B)
WORLDRES="16384"
echo "Going to: $TEXTUREDIR"
cd $TEXTUREDIR
echo "Linking world textures of: $MONTH"
ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.dds .
ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.png .
echo "done"

And you'll be flying Earth with textures matching the current month!

* You may also fancy textures from other celestial bodies, as for instance the Moon. Textures generator available here [https://github.com/eatdust/LROC2FGearthview LROC2FGearthview] and shaders there [https://github.com/eatdust/moonshaders moonshaders], see the original discussion on the forum [https://forum.flightgear.org/viewtopic.php?f=87&t=15754&start=375#p369043 viewtopic.php?f=87&t=15754&start=375#p369043].

== Implementation ==

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

== Screenshots Gallery ==
{{screenshot cat
| category = Screenshots of Earthview
| subject = the Earthview orbital rendering engine
| image = Shuttle FG01.jpg
}}

A sum up of some nice screenshots, and what is achievable while playing with all the options that Earthview offers us.

Sunset and Diffraction

[[File:Black knight UFO Shuttle sunset.jpg|1024px]]

Black Knight UFO Shuttle

[[File:Black_knight_UFO.jpg|1024px]]

500Nm above the World

[[File:Far_side_of_the_world.jpg|1024px]]

South Pole and Lighting game

[[File:Shuttle_over_South_Pole_500_Nm.jpg|1024px]]

Good night World

[[File:SOTM_2019-09_Firing_at_Dawn_by_GinGin.jpg|1024px]]

California Fly By

[[File:Edwards_RTLS_earthview.jpg|1024px]]

Lonely External Tank

[[File:External_Tank_on_Orbit.jpg|1024px]]

Ready for Orbital Operations Eileen

[[File:Orbital_ops_bay_opened_earthview.jpg|1024px]]

== Related content ==
* [[AutoEarthView]] - an addon that automatically starts/stops Earthview based on the altitude

Earthview

2026-06-22T02:18:27Z

Fgf5: autoearthview

{{See also|Flying on other planets}}

The default FlightGear terrain rendering strategy is designed for visuals from aircraft cruise altitude. While it is [http://www.flightgear.org/tours/pushing-the-boundaries-the-x-15-story/ possible] to use it for altitudes up to some 100 km, the performance impact becomes increasingly prohibitive and the visuals are not overly compelling. In particular for orbiting spacecraft such as [[Vostok-1]] or the [[Space Shuttle]] or even the [[UFO]], neither rendering nor loading the standard terrain mesh is fast enough.

Earthview is an alternative orbital rendering engine for FlightGear designed to get credible visuals in these situations. It is based on projecting a simple textured sphere representing Earth into the scene using ray optics. The quality of the terrain visuals then largely depend on the texture size used. Since there is then only a single object in the field of view, performance is generally very good provided that there is enough texture memory available.

{{Spaceflight}}
== Overview ==
[[File:menubar2.jpg|517px]]

Earthview is started from the menu as View -> Earthview Orbital Rendering. This brings up the configuration dialog.

[[File:Earthview menu.jpg|thumb|260px]]

The options checkboxes allow to select

* whether a cloud layer should be rendered above the planet
* whether the cloud layer information should be used to render cloud shadows onto the terrain
* whether Earthview should take control of the atmosphere visuals and adjust them based on altitude
* whether textures should be procedurally enhanced with overlay textures to provide better apparent texture resolution
* whether textures should be rendered with lighting based on a normal map. Parallax effects are also computed if the normal map contains an alpha channel encoding the inverse height of the Earth's relief
* whether clouds should be rendered with lighting and parallax effects. These are computed using the alpha channel of the cloud map as an input information of their vertical extension

'Start' run Earthview, 'Stop' ends the computations and removes the 3d model. Generally, using Earthview below an altitude of ~30 km / 100.000 ft is not recommended and will almost certainly not give the desired visuals. If you don't want to start and stop it manually, you can install the [[AutoEarthView]] addon.

Sliders further down can be used to adjust details. For instance, if no cloud shadows are rendered, it is possible to rotate the cloud sphere around Earth and give different places different weather (otherwise, the cloud pattern will always be the same, i.e. if a place is obscured by clouds initially, it will always be). Using Rayleigh, Mie and Density, atmosphere visuals (if [[Atmospheric light scattering]] (ALS) is on) can be adjusted. Visibility dials the amount of fogging seen on the planet.

Earthview runs without ALS, but does not provide any credible visuals of the Atmosphere.

If atmosphere visuals are rendered, Earthview interacts with the weather system in that the visibility used by Earthview and by the weather system will be the same. In the case of [[A local weather system | Advanced Weather]] (AW) this is an issue because both systems try to adjust atmosphere visuals. For this reason, AW needs to be ended before Earthview is started. There is no general option to do this automatically, but an automatic transition from default FG rendering and weather to Earthview is easily coded spacecraft side and implemented for the Space Shuttle.

All textures are taken from the [http://visibleearth.nasa.gov/ NASA Visible Earth project] - at the highest resolution level, Earth can be rendered at 32768x65536 pixel (about 500 x 500 m per pixel) and clouds with half of that. Currently, due to size concern, all the textures distributed in FGData are of low resolution (2048p x 2048p per tile) and do not incorporate the alpha channel encoding the height. Parallax mapping for ground textures is therefore disabled. It is however possible to obtain the textures from the NASA website, process them and straightforwardly use them as a replacement. More detailed instructions to do so are given below in the section "Customization".

At highest texture resolution, visuals are generally very compelling:

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

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

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

Earthview can also render Aurora Borealis seen from space.

For comparison, this is the FG native terrain tweaked to render with 600 km visibility from 100 km altitude (bringing a gaming laptop to 10 fps in the process):

[[File:X-15-iceland05.jpg|450px|X-15 over Iceland]] [[File:X-15-iceland03.jpg|450px|X-15 in space]]

== Requirements ==

Since there is no detailed terrain mesh involved and there is essentially just a single textured sphere in the field of view, performance is generally excellent even on low end graphics cards.

The main requirement (especially if custom hires textures are used) is available memory and GPU texture memory. All textures are split into eight tiles, four for the northern hemisphere (N1 to N4), and four for the southern hemisphere (S1 to S4) and each tile is loaded, or unloaded, according to visibility. As such, GPU memory is efficiently used and limited graphic card memory should not be an issue for the default texture size. However, the loading of a texture tile induces some bottleneck and FG may hang for a couple of seconds, or more (depending on tile resolution), while the texture appears.

Where this is feasible and supported by the GPU drivers, pre-compressed and mipmapped dds textures offer the fastest loading times. As such textures can not be used with many OpenSource graphics drivers, the default textures are not in dds format, but these can be generated along the lines discussed in the "Customization" section.

For high-end graphic cards, it is possible to actually force the loading of all texture tiles at once when Earthview starts. This is triggered with the command line option:

--prop:/earthview/show-force-all=true

With the maximum resolution textures (16384x16384 pixels for a world tile and 8192x8192 pixels for a cloud and a normalmap tile), expect a minute or more for the loading, around 6GB of GPU memory and 16GB of RAM to be filled. If you can afford it, there will be no other loading bottleneck afterwards. These numbers can accordingly be lowered using lower resolution tiles.

Finally, while it is possible to use Earthview in rendering schemes other then ALS, this is neither supported nor endorsed. While they work perfectly well for the normal operations envelope of a flightsim, at high altitude the default renderer as well as [[Project Rembrandt]] do not render a realistic horizon line, plausible atmosphere visuals or the hard shadows of outer space and Earthview can not compensate for these issues. As such, on old flightgear versions (up to 2018) when using the [[Compositor]] as the rendering pipeline, it is compulsory to default it to ALS with --compositor=Compositor/als. Flightgear versions 2020 to 2024 uses the Compositor by default and ALS rendering can be switched on in the Rendering menu.

== Customization ==

To get full advantage of Earthview, and your graphic card, you may install and use your own high resolution tiles as well as normal maps having a alpha channel to trigger parallax mapping.

=== Texture generation ===

There are two ways to obtain these textures:

==== The easy way ====

When our resources allow for it, some users generate these textures and make them available for download. They may be obtained via torrent with this magnet link:

magnet:?xt=urn:btih:6df05a15c863040fd31278dfd1f719523b639cf2&dn=EarthView.World.August-2020.06

and may also be available for download at this url:

[https://curl.irmp.ucl.ac.be/~chris/upload/fg/earthview/ Earthview/]

A bash script to automatically download the full per-month data from above url [http://ix.io/3ogk is available here]. It downloads the dataset for every month, or it symlinks a dataset for a specified month into a specified place, see help of the script (run without arguments or with '-h'). To choose which resolution(s) to download or which image file format(s) to download the variables in the script needs to be edited. Needs an unix environment with bash and wget.

==== The interesting way ====

Most likely the easy way is no longer available, or you are curious. Chris_Blues made a wonderful Bash-script that will download the NASA images and do the texture generation for you, in the correct way. It is available on github, together with the instructions on how to use it:

[https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview]

This program can generate world, clouds and normal maps with height data included in the alpha channel, and at various resolutions ranging from 1024x1024 to 16384x16384 pixels.

==== Remarks ====

Notice that all the input images are provided by NASA and any usage of the textures should be made in accordance with their distribution policy. They are directly accessible for download at [http://visibleearth.nasa.gov/ Visible Earth], look into the Blue Marble section and search for a texture set of your choice.

NASA provides different seasons for the Earth images, even one set of images per month. [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] allows you to chose the month for which you want to generate your set of tiles.

Graphics cards prefer powers of two in texture sizes, so [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] resizes the tiles to 1024x1024, 2048x2048, 4096x4096, 8192x8192 or 16384x16384 pixels. Be aware of the original image resolution, there is no much gain into using a super-sampled tile. For instance, the current cloud maps provided by NASA have a resolution of typically 10000 pixels. Using 8192x8192 sampling is the best option, the gain of super-sampling it at 16384x16384 is very small. Similar thing holds true for heights and normalmaps (16384x16384 for them is also supersampled, so prefer at most 8192x8192 for them).

=== Installing and using customized textures ===

The texture tiles loaded by Earthview reside in

$FGData/Models/Astro/Textures

where $FGData depends on the installation path of flightgear-fgdata. If you only want to use "png" texture tiles, simply replace all the '''world_*.png''', '''clouds_*.png''' and '''normalmap_earth_*.png''' files by your own.

If you want to use "dds" mipmapped images, then you have to edit a few "ac" files to tell Earthview to use them. These configuration files reside in

$FGData/Models/Astro

and are

earth_*.ac

On Unix systems, the program '''sed''' is your friend (but make a backup before).

* Remarks
It is possible to assign any image you fancy to be used as a tile by Earthview. For this, you can edit the file '''earth_unitscale_rawuv.ac''' to load your images, and edit '''earth.xml''' such that it points to your just edited 3d model via <path>earth_unitscale_rawuv.ac</path>. You can do the same for '''cloudsphere.xml'''. However, assigning textures in this manner, as they are to the "rawuv" sphere, creates visible seams where the texture sheets end. This is particularly visible if parallax mapping is rendered as the computation requires shifting the textures over the sphere.

The solution is to add margins that encompass a bit of the neighbouring tiles. This is what [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] is doing (as well as the texture set provided). These bordered tiles don't use '''earth_unitscale_rawuv.ac''' but instead '''earth_unitscale_hires.ac''', which is the default (see [https://forum.flightgear.org/viewtopic.php?f=6&t=15754&start=135#p207629 this forum post] for the original discussion). In other words, if you use [https://github.com/chris-blues/Nasa2FGearthview Nasa2FGearthview] to generate your own textures, you do not need to change '''earth.xml''' nor '''earth_unitscale_rawuv.ac'''. Notice that you still need to edit '''earth_unitscale_hires.ac''' (and the rest of the '''earth_*.ac''') if you want to use dds tiles!

=== Open tips ===

* Since there is no limit to customization, and if you can afford 50GB of disk space, you can create a whole set of directories containing Earth textures for each month of the year, as for instance:

EarthView.World.January-2020.06/
EarthView.World.February-2020.06/
...

On linux, a simple "cron" job can automatically link the content of one of these directories to '''$FGData/Models/Astro/Textures/''', like this one:

#!/bin/bash
TEXTUREDIR="/usr/share/games/flightgear-extra/Models/Textures"
TIMESTAMP="2020.06"
MONTH=$(date +%B)
WORLDRES="16384"
echo "Going to: $TEXTUREDIR"
cd $TEXTUREDIR
echo "Linking world textures of: $MONTH"
ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.dds .
ln -s -f ../EarthView.World.${MONTH}-${TIMESTAMP}/${WORLDRES}/world_*.png .
echo "done"

And you'll be flying Earth with textures matching the current month!

* You may also fancy textures from other celestial bodies, as for instance the Moon. Textures generator available here [https://github.com/eatdust/LROC2FGearthview LROC2FGearthview] and shaders there [https://github.com/eatdust/moonshaders moonshaders], see the original discussion on the forum [https://forum.flightgear.org/viewtopic.php?f=87&t=15754&start=375#p369043 viewtopic.php?f=87&t=15754&start=375#p369043].

== Implementation ==

Technically, Earth is rendered as a ~58 km sized sphere positioned 1/100 of the actual altitude away from the spacecraft. It's position is constantly adjusted to give the same visual size using ray optics equations, and its attitude is rotated to place you 'above' the correct latitude and longitude. For 100 km altitude, the camera is thus actually just 1000 m away from the sphere.

Compared to almost anything else, the performance impact of re-positioning the sphere every frame is minimal.

The reason is that graphics cards operate with floating point precision, and a sphere with the real size of Earth would create (potentially architecture dependent) massive numerical problems (the default far plane clipping distance in FG is some 120.000 m). The same is in fact true for the skydome - it's actually a half dome some 20 km away from the camera, made to appear behind everything else by rendering magic. Or, in other words, we can't simply render a 'real earth' and a 'real atmosphere' because that would potentially overtax the GPU - real time rendering is always trickery of some sort.

The implementation has the negative consequence that you may not move the view point too far from the spacecraft (the ray optics illusion works for one object, but not for two simultaneously) - in particular flyby view or tower view will give you odd results with Earthview.

The real terrain engine is not technically switched off, but (assuming normal visibility settings) the terrain mesh is just too far to trigger either tile loading or rendering - as you get back from orbit, the terrain will load underneath Earthview, and if you end it at a reasonable altitude (say between 80.000 and 120.000 ft) you can go right back to the native FG terrain with minimum fuss.

== Screenshots Gallery ==
{{screenshot cat
| category = Screenshots of Earthview
| subject = the Earthview orbital rendering engine
| image = Shuttle FG01.jpg
}}

A sum up of some nice screenshots, and what is achievable while playing with all the options that Earthview offers us.

Sunset and Diffraction

[[File:Black knight UFO Shuttle sunset.jpg|1024px]]

Black Knight UFO Shuttle

[[File:Black_knight_UFO.jpg|1024px]]

500Nm above the World

[[File:Far_side_of_the_world.jpg|1024px]]

South Pole and Lighting game

[[File:Shuttle_over_South_Pole_500_Nm.jpg|1024px]]

Good night World

[[File:SOTM_2019-09_Firing_at_Dawn_by_GinGin.jpg|1024px]]

California Fly By

[[File:Edwards_RTLS_earthview.jpg|1024px]]

Lonely External Tank

[[File:External_Tank_on_Orbit.jpg|1024px]]

Ready for Orbital Operations Eileen

[[File:Orbital_ops_bay_opened_earthview.jpg|1024px]]

== Related content ==
* [[AutoEarthView]] - An addon that automatically starts/stops Earthview based on the altitude

AutoEarthView

2026-06-22T02:17:42Z

Fgf5:

{{Infobox Software
| title = AutoEarthView Add-on
| logo = Fgaddonslogo202x89.png |thumb
| image = AutoEarthView.png
| developedby = flyer02@gitlab
| initialrelease = June 21, 2026
| latestrelease = 0.9.0, June 21, 2026
| writtenin = Nasal
| developmentstatus = Stable
| type = Addon
| platform = Min FG version 2024.1
| license = [[GNU General Public License]] v3
| website = https://gitlab.com/flyer02/AutoEarthView
}}

AutoEarthView is a FlightGear [[addon]] that automatically enables/disables [[Earthview|Earthview orbital rendering]] based on the altitude, making it no longer necessary to manually open the EarthView dialog. It automatically starts Earthview when you ascend above a configurable altitude threshold and stops it when you descend below another threshold.

== Features ==

* '''Automatic activation''' – Earthview starts when climbing above the start threshold
* '''Automatic deactivation''' – Earthview stops when descending below the stop threshold
* '''Persistent settings''' – All preferences are saved and restored between sessions
* '''Real-time configuration''' – Adjust thresholds on the fly via a simple dialog
* '''Toggle on/off''' – Enable or disable the automation at any time
* '''Minimal performance impact''' – Altitude checks run every 0.5 seconds

== Installation ==

1. Download the source code from the [https://gitlab.com/flyer02/AutoEarthView/-/releases latest release] and extract it to a directory on your computer. If you want to get the development version, you can run <code>git clone https://gitlab.com/flyer02/AutoEarthView --depth 1</code>.

2. In the launcher, select the Add-ons page from the icon bar on the left, then find the section Add-on Module folders and click the Add(+) button. Select the folder where you put the addon. Once the addon is shown in the list, make sure its check box is selected. The selected folder path should end with "AutoEarthView".

== Usage ==

=== Accessing the Dialog ===

Navigate to the menu bar: '''AutoEarthView → Options'''

=== Configuration Options ===

{| class="wikitable"
|-
! Setting !! Description !! Default
|-
| '''Start threshold''' || Altitude (in feet) at which Earthview automatically starts during climb || 63,000 ft
|-
| '''Stop threshold''' || Altitude (in feet) at which Earthview automatically stops during descent || 30,000 ft
|-
| '''Enabled''' || Master toggle to enable/disable the automation || Enabled
|}

=== Dialog Controls ===

* '''Start threshold''' – Input field for the climb activation altitude
* '''Stop threshold''' – Input field for the descent deactivation altitude
* '''Enabled''' – Checkbox to turn automation on/off
* '''Reset to defaults''' – Restores factory settings

=== Menu Bar ===

The addon adds a new menu: '''AutoEarthView''' with two items:
* '''Options''' – Opens the configuration dialog
* '''About''' – Displays addon information

== How It Works ==

The addon monitors your aircraft's altitude in real-time. When you cross the start threshold during a climb, Earthview is automatically enabled. When you cross the stop threshold during a descent, Earthview is automatically disabled.

Climbing: altitude ≥ 63,000 ft → Earthview starts automatically
Descending: altitude ≤ 30,000 ft → Earthview stops automatically

== Configuration File ==

Settings are stored in <code>~/.fgfs/Export/Addons/org.flightgear.addons.AutoEarthView/save.txt</code>, or <code>C:\Users\your username\AppData\Roaming\flightgear.org\Export\Addons\org.flightgear.addons.AutoEarthView\save.txt</code> on Windows.

[[Category:FlightGear addons]]
[[Category:Spaceflight]]

AutoEarthView

2026-06-22T02:11:47Z

Fgf5:

{{Infobox Software
| title = AutoEarthView Add-on
| logo = Fgaddonslogo202x89.png |thumb
| image = AutoEarthView.png
| developedby = flyer02@gitlab
| initialrelease = June 21, 2026
| latestrelease = 0.9.0, June 21, 2026
| writtenin = Nasal
| developmentstatus = Stable
| type = Addon
| platform = Min FG version 2024.1
| license = [[GNU General Public License]] v3
| website = https://gitlab.com/flyer02/AutoEarthView
}}

AutoEarthView is a FlightGear [[addon]] that automatically enables/disables [[Earthview|Earthview orbital rendering]] based on aircraft altitude, making it no longer necessary to manually open the EarthView dialog. It automatically starts Earthview when you ascend above a configurable altitude threshold and stops it when you descend below another threshold.

== Features ==

* '''Automatic activation''' – Earthview starts when climbing above the start threshold
* '''Automatic deactivation''' – Earthview stops when descending below the stop threshold
* '''Persistent settings''' – All preferences are saved and restored between sessions
* '''Real-time configuration''' – Adjust thresholds on the fly via a simple dialog
* '''Toggle on/off''' – Enable or disable the automation at any time
* '''Minimal performance impact''' – Altitude checks run every 0.5 seconds

== Installation ==

1. Download the source code from the [https://gitlab.com/flyer02/AutoEarthView/-/releases latest release] and extract it to a directory on your computer. If you want to get the development version, you can run <code>git clone https://gitlab.com/flyer02/AutoEarthView --depth 1</code>.

2. In the launcher, select the Add-ons page from the icon bar on the left, then find the section Add-on Module folders and click the Add(+) button. Select the folder where you put the addon. Once the addon is shown in the list, make sure its check box is selected. The selected folder path should end with "AutoEarthView".

== Usage ==

=== Accessing the Dialog ===

Navigate to the menu bar: '''AutoEarthView → Options'''

=== Configuration Options ===

{| class="wikitable"
|-
! Setting !! Description !! Default
|-
| '''Start threshold''' || Altitude (in feet) at which Earthview automatically starts during climb || 63,000 ft
|-
| '''Stop threshold''' || Altitude (in feet) at which Earthview automatically stops during descent || 30,000 ft
|-
| '''Enabled''' || Master toggle to enable/disable the automation || Enabled
|}

=== Dialog Controls ===

* '''Start threshold''' – Input field for the climb activation altitude
* '''Stop threshold''' – Input field for the descent deactivation altitude
* '''Enabled''' – Checkbox to turn automation on/off
* '''Reset to defaults''' – Restores factory settings

=== Menu Bar ===

The addon adds a new menu: '''AutoEarthView''' with two items:
* '''Options''' – Opens the configuration dialog
* '''About''' – Displays addon information

== How It Works ==

The addon monitors your aircraft's altitude in real-time. When you cross the start threshold during a climb, Earthview is automatically enabled. When you cross the stop threshold during a descent, Earthview is automatically disabled.

Climbing: altitude ≥ 63,000 ft → Earthview starts automatically
Descending: altitude ≤ 30,000 ft → Earthview stops automatically

== Configuration File ==

Settings are stored in <code>~/.fgfs/Export/Addons/org.flightgear.addons.AutoEarthView/save.txt</code>, or <code>C:\Users\your username\AppData\Roaming\flightgear.org\Export\Addons\org.flightgear.addons.AutoEarthView\save.txt</code> on Windows.

[[Category:FlightGear addons]]
[[Category:Spaceflight]]

AutoEarthView

2026-06-22T02:11:22Z

Fgf5: Created page with "{{Infobox Software | title = AutoEarthView Add-on | logo = Fgaddonslogo202x89.png |thumb | image = AutoEarthView.png | developedby = flyer02@gitlab | initialrelease = June 21, 2026 | latestrelease = 0.9.0, June 21, 2026 | writtenin = Nasal | developmentstatus = Stable | type = Addon | platform = Min FG version 2024.1 | license =..."

{{Infobox Software
| title = AutoEarthView Add-on
| logo = Fgaddonslogo202x89.png |thumb
| image = AutoEarthView.png
| developedby = flyer02@gitlab
| initialrelease = June 21, 2026
| latestrelease = 0.9.0, June 21, 2026
| writtenin = Nasal
| developmentstatus = Stable
| type = Addon
| platform = Min FG version 2024.1
| license = [[GNU General Public License]] v3
| website = https://gitlab.com/flyer02/AutoEarthView
}}

AutoEarthView is a FlightGear [[addon]] that automatically enables/disables [[Earthview|Earthview orbital rendering]] based on aircraft altitude, making it no longer necessary to manually open the EarthView dialog. It automatically starts Earthview when you ascend above a configurable altitude threshold and stops it when you descend below another threshold.

== Features ==

* '''Automatic activation''' – Earthview starts when climbing above the start threshold
* '''Automatic deactivation''' – Earthview stops when descending below the stop threshold
* '''Persistent settings''' – All preferences are saved and restored between sessions
* '''Real-time configuration''' – Adjust thresholds on the fly via a simple dialog
* '''Toggle on/off''' – Enable or disable the automation at any time
* '''Minimal performance impact''' – Altitude checks run every 0.5 seconds

== Installation ==

1. Download the source code from the [latest release](https://gitlab.com/flyer02/AutoEarthView/-/releases) and extract it to a directory on your computer. If you want to get the development version, you can run <code>git clone https://gitlab.com/flyer02/AutoEarthView --depth 1</code>.

2. In the launcher, select the Add-ons page from the icon bar on the left, then find the section Add-on Module folders and click the Add(+) button. Select the folder where you put the addon. Once the addon is shown in the list, make sure its check box is selected. The selected folder path should end with "AutoEarthView".

== Usage ==

=== Accessing the Dialog ===

Navigate to the menu bar: '''AutoEarthView → Options'''

=== Configuration Options ===

{| class="wikitable"
|-
! Setting !! Description !! Default
|-
| '''Start threshold''' || Altitude (in feet) at which Earthview automatically starts during climb || 63,000 ft
|-
| '''Stop threshold''' || Altitude (in feet) at which Earthview automatically stops during descent || 30,000 ft
|-
| '''Enabled''' || Master toggle to enable/disable the automation || Enabled
|}

=== Dialog Controls ===

* '''Start threshold''' – Input field for the climb activation altitude
* '''Stop threshold''' – Input field for the descent deactivation altitude
* '''Enabled''' – Checkbox to turn automation on/off
* '''Reset to defaults''' – Restores factory settings

=== Menu Bar ===

The addon adds a new menu: '''AutoEarthView''' with two items:
* '''Options''' – Opens the configuration dialog
* '''About''' – Displays addon information

== How It Works ==

The addon monitors your aircraft's altitude in real-time. When you cross the start threshold during a climb, Earthview is automatically enabled. When you cross the stop threshold during a descent, Earthview is automatically disabled.

Climbing: altitude ≥ 63,000 ft → Earthview starts automatically
Descending: altitude ≤ 30,000 ft → Earthview stops automatically

== Configuration File ==

Settings are stored in <code>~/.fgfs/Export/Addons/org.flightgear.addons.AutoEarthView/save.txt</code>, or <code>C:\Users\your username\AppData\Roaming\flightgear.org\Export\Addons\org.flightgear.addons.AutoEarthView\save.txt</code> on Windows.

[[Category:FlightGear addons]]
[[Category:Spaceflight]]

File:AutoEarthView.png

2026-06-22T02:00:31Z

Fgf5: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=AutoEarthView dialog}}
|date=2026-06-22
|source={{own}}
|author=[[User:Fgf5|Fgf5]]
|permission=
|other versions=
}}

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

Aerotow Everywhere Add-on

2026-06-22T01:58:17Z

Fgf5: typo

{{Infobox Software
| title = Aerotow Everywhere Add-on
| logo = Fgaddonslogo202x89.png |thumb
| image = Aerotow add-on 1.png
| alt = Aerotow Everywhere Add-on - the tow plane taxis in front of the glider.
| developedby = Roman Ludwicki (PlayeRom, SP-ROM)
| initialrelease = August 14, 2022
| latestrelease = 1.9.3, September 25, 2025
| writtenin = Nasal
| developmentstatus = Stable (2023)
| type = Addon
| platform = Min FG version 2024.1.1
| license = [[GNU General Public License]] v3
| website = https://github.com/PlayeRom/flightgear-addon-aerotow-everywhere
}}

This is an add-on designed to include an AI aircraft that will be able to tow a glider. The main idea is to be able to do this at any airport and with any glider. Technically, this add-on adds the aerotow-dragger AI scenario dynamically, so you won't have to create XML with the scenario manually anymore.

== Installation ==

This add-on creates a flight plan in real-time based on the airport you are at. Unfortunately this causes a problem which you will have to solve manually by following the instructions below.
Namely, the flight plan for AI aircraft, by default, must be stored in the <code>[[$FG_ROOT]]/AI/FlightPlans/</code> directory. But for security reasons, Nasal scripts cannot save files to that directory, but can save e.g. to <code>[[$FG_HOME]]/Export/</code>. Therefore, the run-time created flight plan will just be saved to <code>[[$FG_HOME]]/Export/Addons/org.flightgear.addons.Aerotow/AI/FlightPlans/</code>. The problem is that FlightGear does not know that it is supposed to look for the flight plan file in this location as well, so you have to tell it manually by using the <code>--data</code> [[Command_line_options|command line option]].

<code>[[$FG_HOME]]</code> is the FlightGear home path. It differs depending on the operating system.
Under Linux/macOS <code>[[$FG_HOME]]</code> is <code>/home/{username}/.fgfs/</code>.
Under Windows <code>[[$FG_HOME]]</code> is <code>C:\Users\{username}\AppData\Roaming\flightgear.org\</code>.
Where <code>{username}</code> is the name of the user logged into the operating system.

# {{repo link
| site = gh
| user = PlayeRom
| repo = flightgear-addon-aerotow-everywhere/releases
| text = Download "Aerotow Everywhere" add-on
}} and unzip it.
# In Launcher go to "Add-ons" tab. Click "Add" button by "Add-on Module folders" section and select folder with unzipped "Aerotow Everywhere" add-on directory (or add command line options: <code>--addon=path</code>), and click "Fly!". After loading the simulator, a <code>$FG_HOME/Export/Addons/org.flightgear.addons.Aerotow</code> directory should be created.
# Close FlightGear for now.
# In the file explorer of your operating system, find the directory <code>$FG_HOME/Export/Addons/org.flightgear.addons.Aerotow</code>. This path must be added by the <code>--data</code> command line option, so it will be treated as an additional FGData directory. In Launcher go to "Settings" tab and in "Additionnal Setting" type for example on the Linux system: <code>--data=/home/{username}/.fgfs/Export/Addons/org.flightgear.addons.Aerotow</code> or on the Windows: <code>--data=C:\Users\{username}\AppData\Roaming\flightgear.org\Export\Addons\org.flightgear.addons.Aerotow</code>.
# Run simulator again, now everything should be working.

== How to start? ==

Start FlightGear at any airport with your aircraft as a glider, such as ASK 21.

From the top menu, select "Aerotow Everywhere" -> "Call for Piper J3 Cub aircraft", "Robin DR400", "Cessna 182" or "Douglas C-47". (Yes, you can choose from many aircrafts). The AI aircraft will appear to your right and align to the centerline of the runway in front of you. At this time you should hook up to the aircraft, most often by pressing the {{key press|Ctrl|o}} key (check help of your glider). The AI aircraft will begin to accelerate and take off.

You can also take off in the bush. Then the tow plane will position itself in front of you (glider's course), so what heading you have is important. If you move away from the runway threshold further than 100 m, then the take-off of the tow plane will be as in the bush, i.e. according to the glider heading and not the runway.

== How does the AI tow aircraft fly by default? ==

[[File:Aerotow add-on 1.png|thumb|Aerotow Everywhere Addo-on - the tow plane taxis in front of the glider.]]

The tow plane always takes off in front of your runway and flies along the runway for 5 km, then turns back and flies downwind for 6 km, then turns back again and flies another 6 km. During this flight it is constantly gaining altitude. Then, after having flown the entire given route, it lands at the airport from which it took off or when start in the bush turns in an unknown direction and flies at a constant altitude. If the aircraft lands at the airport, the scenario starts again, i.e. the aircraft respawn to take-off again.

You can disconnect from the aircraft at any time, most often by pressing the {{key press|o}} key (check help of your glider).

Default route:
^ - airport with heading direction to north
1 - 1st waypoint
2 - 2nd waypoint, etc.

2 . . 1 5
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. ^ .
. .
. .
3 . . . . 4

== Menu of add-on ==

This add-on add a new item to main menu named "Aerotow Everywhere" with following items:

# <code>Aerotow Route</code> - display the dialog for change aerotow route.
# <code>Towrope Configuration</code> - display the dialog for change towrope parameters.
# <code>Call for Piper J3 Cub aircraft</code> - load AI tow scenario with Piper J3 Cub.
# <code>Call for Robin DR400 aircraft</code> - load AI tow scenario with Robin DR400. This aircraft has better performance and can take you higher then Piper Cub.
# <code>Call for Cessna 182 aircraft</code> - load AI tow scenario with Cessna 182. This aircraft has little bit better performance than Robin.
# <code>Call for Douglas C-47 aircraft</code> - load AI tow scenario with Douglas C-47. Dedicated mainly to the "Horsa Assault Glider".
# <code>Call for Handley Page Halifax</code> - load AI tow scenario with Handley Page Halifax. Dedicated mainly to the "Horsa Assault Glider".
# <code>Disable tow aircraft</code> - unload AI tow scenario.
# <code>Add thermal</code> - display the dialog for configuring and adding thermal.
# <code>Help</code> - display help dialog.
# <code>About</code> - display about dialog with add-on information.

== Aerotow Route ==

You can change the AI aircraft's default route, for this go to menu "Aerotow Everywhere" -> "Aerotow Route".

=== Aerotow aircraft ===

On the top of the "Aerotow Route" dialog you have selector to change aircraft type. It's only for calculate performance and display how the altitude will change.

=== Max alt (AGL) ===

Here you can set limit of AGL altitude. 0 means without limits - the plane will always increase its altitude during its flight. AGL is always in terms of the place you are starting from.

=== Route ===

Next you have initial heading, distance and altitude change. "Initial heading" depend of the runway where you are located. The aircraft will always take-off along the runway, a distance of 100 m, where it will gain 20 ft in altitude above the terrain. These parameters you cannot change unless you change the airport/runway.

Next you can see a table with fields where you can change values. Each row represents a single waypoint of flight plan of AI aircraft. For each waypoint you have following columns:

# <code>Heading change (deg)</code> - information on how the heading of the aircraft should change in relation to the previous one. A value of <code>0</code> means no change, so continue with the same heading. And e.g. <code>-90</code> means a left turn of 90 degrees, <code>60</code> means a right turn of 60 degrees, etc.
# <code>Distance (m)</code> - distance in meters from the previous waypoint to the present one.
# <code>Alt change (AGL ft)</code> - information on how much the altitude on this leg of the route will increase (in feet above ground.) This information depend of selected airplane. AGL is always in terms of the place you are starting from (not the waypoint place).

If you enter a value less than or equal to <code>0</code> for <code>Distance (m)</code> field this means that here the route is end and the next rows will not be included to the flight plan.

You have a maximum of 10 waypoints to use, hope that's enough.

On the below of the dialog you can see a total amount of distance (in meters) and total altitude in feet above ground level.

=== Buttons ===

# <code>OK</code> - close the route dialog.
# <code>Default</code> - set default waypoints (your changes will be lost.)

== Adding thermals ==

An additional feature of this add-on is the possibility of placing the thermals just in front of the glider. To do this, go to menu "Aerotow Everywhere" -> "Add thermal" where you can configure the following parameters:

# <code>Distance</code> - the distance in metres at which the thermals will be placed in front of the gliders.
# <code>Strength</code> - thermal strength in feet per second.
# <code>Diameter</code> - diameter of thermal in feet.
# <code>Height</code> - height of thermal in feet above mean sea level.

Click <code>Add thermal</code> button for add the thermal.

Many thanks to the FG forum user "wlbragg" for proposing and presenting a solution to this feature.

== Limitations ==

# This add-on doesn't check if there are any obstacles in the AI aircraft's path, e.g. terrain, buildings, power lines, etc. Keep this in mind when choosing an airport or planning your route.
# Minimum FlightGear version: 2024.1. Because only 2024 version is able to search for flight plans in additional FGData folders added by <code>--data</code> command line option.

== Troubleshooting ==

=== When I select "Aerotow Everywhere" -> "Call for Piper J3 Cub aircraft" or other plane from menu, I see "Let's fly!" message but nothing happened. The tow plane does not appear. ===

Probably you didn't include the <code>--data</code> command line option with the path where FlightGear should look for additional flight plan files for AI. Unfortunately, the simulator does not inform us that there was a problem with finding the flight plan file, so everything looks like it should work but does not.

For fix it, in the file explorer of your operating system, find the directory <code>[[$FG_HOME]]/Export/Addons/org.flightgear.addons.Aerotow</code>. This path must be added by the <code>--data</code> command line option, so it will be treated as an additional FGData directory where FlightGear will find the flight plan. In Launcher go to "Settings" tab and in "Additionnal Setting" type (on the Linux system):

--data=/home/{username}/.fgfs/Export/Addons/org.flightgear.addons.Aerotow

or on the Windows:

--data=C:\Users\{username}\AppData\Roaming\flightgear.org\Export\Addons\org.flightgear.addons.Aerotow

Run simulator again, now everything should be working.

== What is the difference with "Drag robot"? ==

Some gliders have a "Drag robot" function implemented, which basically, you could say, does the same thing, tows our glider. "Drag robot" uses the trick of positioning the model of the plane. The "drag robot" always spins semicircles in a random way from left to right.

This add-on can be independent of the glider and available to anyone where "Drag robot" is unavailable. This add-on applies a flight plan AI scenario for an AI aircraft which means that the aircraft "really flies" (we have rotating propeller, adjusting the landing gear, etc.) You can also set the route in which the plane should fly. In addition, we have the sound of the AI aircraft engine.

"Drag robot" has "Advanced Configuration" dialog to adjust plane parameters, what is not available in Aerotow Everywhere Add-on.

[[Category:FlightGear addons]]
[[Category:Nasal software]]
[[Category:Glider tugs]]

World Scenery

2026-06-10T18:08:17Z

Fgf5:

'''World Scenery''' is the name of the corresponding Terrain and [[Scenery]] data for [[FlightGear]].
The latest published release is [[FlightGear_World_Scenery_2.0|World Scenery 2.0]].

== World Scenery releases ==
* [[World Scenery 3.0]] - currently experimental
* [[World Scenery 2.0]] - November, 2013
* World Scenery 1.0.1 - October 27, 2008
* [[World Scenery v1.0.0]] - March 4, 2008
* World Scenery v0.9.10 - January 17, 2006

== Version Notes ==
=== World Scenery 3.0 ===
A new, LoD-based approach to scenery using landclass textures over a regular elevation mesh. For more information see [[World Scenery 3.0]].

=== World Scenery 2.0 ===
3D models on the terrain such as landmarks and airports are contributed and maintained under the Scenery Object database, with new World Scenery releases including updates to models since the last release. However, new models can usually be updated using the site before the next WS release.
=== World Scenery 1.0.1 ===
Released October 27, 2008, it works with [[FlightGear 1.9.0]] and [[FlightGear 1.0]], and probably some older releases although not all scenery objects may be fully supported. Elevation data for 1.0.1 uses SRTM3 version 2, SRTM30/GTOPO30 version 2 from ftp://e0srp01u.ecs.nasa.gov/srtm/version2/ .
=== World Scenery v1.0.0 ===
=== World Scenery v0.9.10 ===
Released 17th January 2006.

== Related content ==
* [[FlightGear Scenery Database]]

[[Category:Scenery]]

World Scenery

2026-06-10T18:07:24Z

Fgf5: remove link

'''World Scenery''' is the name of the corresponding Terrain and [[Scenery]] data for [[FlightGear]].
The latest published release is [[FlightGear_World_Scenery_2.0|World Scenery 2.0]] released in November 2013.

== World Scenery releases ==
* [[World Scenery 3.0]] - currently in Alpha testing
* [[World Scenery 2.0]] - November, 2013
* World Scenery 1.0.1 - October 27, 2008
* [[World Scenery v1.0.0]] - March 4, 2008
* World Scenery v0.9.10 - January 17, 2006

== Version Notes ==

=== World Scenery 3.0 ===
A new, LoD-based approach to scenery using landclass textures over a regular elevation mesh. For more information see [[World Scenery 3.0]].

=== World Scenery 2.0 ===
3D models on the terrain such as landmarks and airports are contributed and maintained under the Scenery Object database, with new World Scenery releases including updates to models since the last release. However, new models can usually be updated using the site before the next WS release.
=== World Scenery 1.0.1 ===
Released October 27, 2008, it works with [[FlightGear 1.9.0]] and [[FlightGear 1.0]], and probably some older releases although not all scenery objects may be fully supported. Elevation data for 1.0.1 uses SRTM3 version 2, SRTM30/GTOPO30 version 2 from ftp://e0srp01u.ecs.nasa.gov/srtm/version2/ .
=== World Scenery v1.0.0 ===
=== World Scenery v0.9.10 ===
Released 17th January 2006.

== Related content ==
* [[FlightGear Scenery Database]]

[[Category:Scenery]]

Links

2026-06-10T17:59:26Z

Fgf5:

== FlightGear ==
=== Source code ===
{{Main article|FlightGear Git}}

=== Mirrors ===
See [https://www.flightgear.org/download/mirrors flightgear.org/download/mirrors] for more info.

=== Hangar ===
{{Main article|FlightGear hangars}}

=== Multiplayer ===
{{Main article|Howto:Multiplayer#Servers}}

=== Scenery ===
* [https://scenery.flightgear.org/ scenery.flightgear.org] — the database of [[scenery]] objects

=== Liveries ===
See [https://liveries.flightgear.org/ liveries.flightgear.org].

=== Support ===
* [https://www.flightgear.org/support/manual/ flightgear.org/support/manual/] - the manual
* [[Main Page|wiki.flightgear.org]] — this wiki

== Community ==
=== Forums ===
[https://forum.flightgear.org/ The official forum]

* [https://fr.flightgear.org/forums/ French 1]
* [https://equipe-flightgear.forumactif.com/ French 2]
* [https://forum.fguk.me/ FGUK]

=== Discord servers ===
{{Main article|Discord}}

=== YouTube channels ===
{{Main article|YouTube channels}}

== Related projects ==
{{Main article|FlightGear related projects}}

[[Category:FlightGear]]

Links

2026-06-10T17:54:39Z

Fgf5: rewritten

== FlightGear ==
=== Source code ===
{{Main article|FlightGear Git}}

=== Mirrors ===
See [https://www.flightgear.org/download/mirrors flightgear.org/download/mirrors] for more info.

=== Hangar ===
{{Main article|FlightGear hangars}}

=== Multiplayer ===
{{Main article|Howto:Multiplayer#Servers}}

=== Scenery ===
* [https://scenery.flightgear.org/ scenery.flightgear.org] — the database of [[scenery]] objects

=== Liveries ===
See [https://liveries.flightgear.org/ liveries.flightgear.org].

== Support ==
* [[Main Page|wiki.flightgear.org]] — this wiki

== Community ==
=== Forums ===
[https://forum.flightgear.org/ The official forum]

* [https://fr.flightgear.org/forums/ French 1]
* [https://equipe-flightgear.forumactif.com/ French 2]
* [https://forum.fguk.me/ FGUK]

=== Discord servers ===
{{Main article|Discord}}

=== YouTube channels ===
{{Main article|YouTube channels}}

== Related projects ==
{{Main article|FlightGear related projects}}

[[Category:FlightGear]]

Volunteer

2026-06-10T17:32:28Z

Fgf5: /* Tell us about your own ideas and feature requests for improving FlightGear */

{{Volunteer Intro}}

== Media ==
=== Screenshots ===
Another easy way for getting started contributing is to create nice FlightGear screenshots. You can upload these to the wiki where they can then be used to illustrate articles and to highlight articles via the [[:Category:Picture of the week|picture of the week]] on the main page.

[[Howto: Make nice screenshots]] provides some tips on how to create stunning shots, while [[Help:Upload]] discusses how to upload screenshots to the wiki.

=== Videos ===
Many users like to capture their flights in FlightGear as a video, [[YouTube channels|YouTube]] for example is an excellent way for sharing such videos with fellow FlightGear users. YouTube videos can also be directly embedded in forum postings and wiki articles.

=== Screencasts (video tutorials) ===
Creating FlightGear related video tutorials is another excellent way for getting started contributing.

== Documentation ==
{{forum|72|FlightGear Documentation}}

=== FAQ-Maintainers ===
The FlightGear project is looking for people who are willing to help maintain the FAQ which, given the constant development of the project, is chronically out of date. If you you would like to get involved, follow the {{forum link|text=forum}} to stay current on the latest news, problems, and of course on what questions are asked more frequently, and simply start editing the [[FAQ|wiki FAQ]].

=== Maintaining the wiki ===
You can easily [[Special:UserLogin|register an account]] and help [[Portal:Wiki|improve the wiki]], and provide your help in reviewing articles, fixing their look and readability, updating them and adding what you think is missing, for example many articles could be greatly improved just by adding a handful of relevant screenshots for illustration purposes. Proof reading of existing articles is also greatly appreciated.

Registering takes less than a minute. After registration, you'll have to confirm your registration by clicking on the link sent to you by email.

=== Translating the wiki and FlightGear ===
You can also help localize the wiki by [[Help:Translate|translating]] important articles into different languages. Please see the [[translation requests]].

Also, FlightGear itself can be easily translated by updating the files in [[$FG_ROOT]]/Translations. For details please see [[Howto: Translate FlightGear|Translating FlightGear]].

=== Wiki article writers ===
Various aspects of FlightGear are currently not yet sufficiently documented, and available documentation is often not really suitable to be used by non-developers. This results in users being unaware of the wide range of features and possibilities that FlightGear supports already.

As an "article writer" you should be able to document your own experiences with FlightGear in a clear and concise [[FlightGear wiki:Manual of Style|style]], so that others can easily follow your instructions in order to make use of the less known features of FlightGear. These articles don't need to be very comprehensive, they shall only provide users with easy to follow instructions on how to achieve something, and possibly some caveats and hints.

* [[:Category:Volunteer: Writing]]

=== Contributing to the manual ===
The wiki is not the only documentation here, of course. FlightGear comes with a set of illustrated documentation, notably [[FlightGear Manual|"The Manual"]]. If you are skilled and a little bit familiar with LaTex, your help would be really welcome. More on this at the [[manual]] wiki page. You'll find the source code in the {{getstart source|text=Getstart repository}}.

=== Documentation Editors/Reviewers ===
{{Main article|Howto:Write a FlightGear Review}}
The documentation that comes with FlightGear base package might be inaccurate (outdated) due to the advances in FlightGear's code. You can check the current documentation and identify areas for improvement, by directly making corresponding suggestions for augmentations, or even writing new help documents altogether, while staying current with the mailing list.

Smaller corrections shall be sent by email to the developer mailing list, preferably in unified diff format (for patch to work). Alternatively, small text files can also be sent directly to the mailing list, more complex modifications should be only made available by uploading them to a webpage and linking to the corresponding files from your emails.

If you intend to redo a major part of the current documentation, first discuss this with the developers, to avoid documenting code that may also be under development or deprecation.

== Development ==
=== Creating interactive tutorials ===
FlightGear has a built-in [[Tutorials|tutorial]] system that is based on its scripting language [[Nasal]], this system is very flexible and can be used for creating interactive tutorials (or even missions) for use in FlightGear itself, in other words these tutorials run directly in the simulator.

Creating new tutorials, or updating and improving existing ones, is another great way for getting more familiar with FlightGear. For details please see [[Tutorials]].

=== Providing patches for aircraft's -set.xml status fields ===
One way you could easily contribute would be to submit patches to HEAD setting the "status" flag on each aircraft accurately. While it will require learning a bit about SCM, and XML, that would be a fine contribution. For a details on how the status should be arrived at see [[Aircraft status indication]].

=== Creating Scenery Models ===
The FlightGear project maintains a steadily growing repository of [http://scenemodels.flightgear.org 3D models] for adding some eye-candy to the scenery. The world has always enough room left for your [http://scenemodels.flightgear.org/contribute.php contribution]. Please take the time to investigate what is already there and enjoy populating your favourite area.

Note that you don't have to create any models yourself. You can simply [[Howto: Place 3D objects with the UFO|place existing models using the UFO]]. For example, placing objects in the scenery with the [[UFO]] and submitting them to the database is pretty straightforward and takes very little time. Even an hour spent doing this makes a difference.

If anyway you'd like to [[Modeling - Getting Started|test your modeling skills]], here some suggestions:
* We need people to go out and take good pictures of all the buildings at their local airports, build models, and create textures (that could be different people for each task).
* We need people to start modelling identifiable human-made landmarks like bridges, stadiums, and major buildings. Around the San Francisco Bay area, bridges are especially important. Once you have identified some buildings or objects you would like to have (Aircraft carriers, fuel bowsers, cars, towers, ...) you will need to check out the tools for creating and placing these objects.

It would be helpful if people would model the area they are interested in. Generally contributions are going to be from FlightGear users who find scenery lacking in some area and choose to improve it. You are encouraged to research your own area for airport, navaid and scenery information, to contribute the data or dive right in to airport and scenery design.

=== Making airports ===
Sometimes you'd like to populate your favourite airport with objects, but you find it has a wrong layout or that it doesn't exist at all! So, you'll want to [[Howto:Make an airport|make or improve that layout]], which can be done with [[WED]]. Remember that we're maintaining an open (GPL) airport database in common with X-Plane simulator.

Other than just fix the look, you might want to add interactive details like [[AI Traffic]] and maybe update navaids and comm frequencies. We need people to go over paper lists and airport diagrams for countries that don't publish air navigation data free online (i.e. almost everyone but the U.S.) and fill in the blanks in our navaid and airport databases.

To be sure the airport you're interested in is not already being worked on, check the [[Airports under construction]] article. Also, note that since we switched to a newer format for the airport database, there are many airports that need to be converted from the older (810) format to the newer (850). All the info is in [[Howto:Make an airport]].

=== Contributing to the scenery terrain ===
We need people to collect geodata to give us more accurate roads, rivers, etc., especially outside the U.S. and Europe. Note that since we're now allowed to use OpenStreetMap data for this, you might consider contributing to that project too. With time, more and more features will be imported from OSM, beginning with roads and rails, and going on with power lines and antennas and whatnot.

The first step into this is learning how to [[Using TerraGear|use TerraGear]]. Remember that all the data you plan to use must be GPL compatible. You might also consider editing some of that source data and contribute it to the Scenery Project that would make good use of it!

=== Core development ===
{{Main article|Howto:Start core development}}
If you know Git, consider contributing to the [[Howto:Start core development|core development]] at [https://gitlab.com/flightgear gitlab.com/flightgear]. Apart from the three core repositories (simgear, flightgear and terragear), you don't need to have an in-depth understanding of C++.

== Other ==
=== Submitting bugs to the Bug Tracker ===
Bugs can be reported to {{tickets|the issue tracker}} (select the respective project, or <code>flightgear</code> if unsure). Reporting bugs accurately helps make bug fixing significantly easier for the developers. Another thing that is very helpful, is reviewing posted bug reports and see if you can reproduce/confirm them on your system.

=== Artwork Creators/Contributors ===
FlightGear itself would not be possible without the contribution of various types of artwork:
* Aircraft developers need photographs, images and sounds to realistically model a particular aircraft.
* The splash screen displayed when loading the simulator can be personalized, and you can [[Howto: Create custom splash screens|create one for your favourite aircraft]].
* Sound recordings of aircraft are also very valuable - particularly engine sounds for unusual aircraft.

In general, you can find requests and post your offers of this kind in the Developers forum, but you can also browse [[:Category:Aircraft by status|existing aircraft projects]] and see if there's anything you'd like to improve.

=== Pre-Release Testers ===
Prior to a release, release candidates are provided to the community. By directly providing feedback about your experiences with FlightGear's development code, you will become a crucial part of the development process and you will basically serve as quality control for FlightGear, your experiences will determine whether FlightGear's development code is ready for a next official release or not. See the [[Release plan]] to find out when release candidates will be distributed.

Note: If you are interested in actually doing development for FlightGear, make sure to check out the [[Portal:Developer|Developer section]].

=== Hosting a multiplayer server ===
If you have access to an Unix based server, another good opportunity for contributing would be to set up a multiplayer server for use with FlightGear, for details please check out [[Howto: Set up a multiplayer server]].

=== Tell us if FlightGear works with your hardware ===
You can help fellow FlightGear users by telling us if FlightGear works with your hardware. Please see [[Hardware Recommendations]].

=== Participate in the FlightGear Forums ===
If you haven't done so already, please consider registering at the {{forum link|text=FlightGear forum}}, this is a very simple thing to do, but it makes it very easy to obtain and provide help and other support within the FlightGear community.

Taking extra care in your posting to avoid requiring the attention of the moderators is in some ways also a contribution. Doing so helps self-police the forums so that the moderators can spend their time doing constructive development.

=== Check out the Discord server ===
{{Main article|Discord}}
To talk to fellow FlightGear users in realtime, you may want to check out our [[Discord]] server (and other unofficial servers). This is also an excellent way for getting and providing community help.

=== Tell us about your own ideas and feature requests for improving FlightGear ===
If you think you have a good idea or feature request for improving FlightGear, the FlightGear forum and the [[Discord]] server are also excellent ways to get feedback.

=== Help us write the FlightGear Newsletter ===
The FlightGear newsletter is a community driven newsletter that is created and edited using the wiki. All FlightGear users are invited to contribute to the newsletter. The only thing that is required is a wiki account, which is free and easy to register.

Please feel free to add news about your own FlightGear related projects, or projects started by others to the newsletter.

You can find the draft of next month's newsletter at: [[Next newsletter]]

Just tracking the forums, mailing lists or the IRC channel should provide you with plenty of opportunities for things that could be added to the newsletter. One simple thing for getting started - even without writing anything - is uploading screen shots showing recent FlightGear developments for use in the FlightGear newsletter.

=== Reviews ===
Another thing that can be easily done is reviewing FlightGear (or just certain parts of it, like for example scenery and/or aircraft) and submit your reviews to some of the flight simulation portals. Of course, you can also directly write your reviews using the FlightGear wiki, see: [[FlightGear Reviews]].

[[Category:Contribution requests]]
[[Category:Community]]

[[es:Tener a bien]]
[[fr:Volontaires]]

New to FlightGear

2026-06-10T17:13:30Z

Fgf5: /* Starting FlightGear */

'''Welcome to [[FlightGear]]!''' Here we will try to get you up in the virtual air in the shortest time possible. We will also introduce you to some of the features of this flight simulator and also a few information on its community.

== Installation and setup ==
=== Hardware requirements ===
For FlightGear to run smoothly, it requires a video card with OpenGL drivers 4.0 or higher. This is usually not a problem, but take a look at the [[hardware recommendations]] to have a better idea.

=== Getting FlightGear ===
You may download the latest files from the [https://www.flightgear.org/download/ FlightGear download] page. Choose the source or binary files appropriate for your particular system. {{Wikipedia|AppImage|AppImage}} binary files for Linux are also available with 2020.3 LTS and later. Most Linux users will find that most distributions have a packaged version of FlightGear (the package name could be <code>fgfs</code> or <code>flightgear</code>.)

Depending on your technical expertise you may choose the [[Git]] development version of FlightGear, which typically has more features and can be required by some of the latest developmental aircraft, but can be unstable and is more complicated to get for non-Windows users. In general, the development version is not advised to the average user, but if you are willing to do some testing there is a nightly build available for [https://www.flightgear.org/download/nightly/ download]. If you are using a Git version controlled copy of FlightGear, you may choose to synchronise your aircraft using the version controlled [[FGAddon|FGAddon aircraft development repository]].

=== Installing on Windows ===
After you downloaded the installer, run it and follow its instructions to install FlightGear.

Defender SmartScreen on Windows may block the installation simply because the binary file is not signed with a key that Microsoft respects. Of course, the key is paid. In this case, we need to click on the inconspicuous "More info" link. Only then will the "Run anyway" button appear. You can safely trust that this is not a dangerous application, as long as you have actually downloaded it from official sources.

If you're using third-party antivirus software for some reason, it may be blocking FlightGear from installing. This isn't something we can control, so it's entirely up to you how you want to handle it.

With the Windows installer, you may choose where to install FlightGear. The [[$FG_ROOT]] directory would be <code><your chosen directory>/data</code>.

=== Installing on macOS ===
Installing FlightGear on macOS is very simple. Just drag and drop the FlightGear icon to the <code>/Applications</code> folder. That is it.

The first time you launch FlightGear, its icon on the Dock bounces for several seconds while loading aircraft and airport info. When the GUI launcher appears, select the aircraft and airport, then click "Fly!" to launch the simulator. You can configure more options using the GUI launcher. See the [http://flightgear.sourceforge.net/manual/next/en/getstart-ench4.html#takeoff-how-to-start-the-program official manual] for more details.

If you would like to launch FlightGear using command-line, launch the Terminal app and type the following.

cd /Applications/FlightGear.app/Contents/MacOS
./fgfs --options.....

The [[$FG_ROOT]] and [[$FG_SCENERY]] are not set on macOS. If you want to specify these variables yourself for command-line use, run the followings on the Terminal app:

FG_ROOT=/Applications/FlightGear.app/Contents/Resources/data
FG_SCENERY=[[$FG_ROOT]]/Scenery

After launching the GUI launcher, you will have the alias to [[$FG_ROOT]] at <code>$HOME/Documents/FlightGear/<version></code> so you can browse the data folder using Finder.

Note: Once you have installed FlightGear, Mac users can locate their [[$FG_ROOT]] folder by opening their applications folder in Finder, right clicking on FlightGear, and clicking "Show Package Contents". This will take you inside the FlightGear folder. You are now able to access all files including Data/Aircraft to [[Howto: Install aircraft#Macintosh OS X|install new aircraft]].

=== Installing from source ===
Main article: [[Building FlightGear]]

=== Getting scenery ===
A limited set of [[scenery]] comes installed with FlightGear. For FlightGear 2024.1 this consists of
* The area surrounding the featured airport for the release which is [[Keflavik_Airport|Keflavik International Airport]] (BIKF)
* The tutorial airport for the [[Cessna_172P|Cessna 172P]] which is [[Hilo_International_Airport|Hilo International Airport]] (PHTO)

In FlightGear, scenery is generally stored in you [[$FG_ROOT]] directory, and is divided into three kinds of data:
* '''Airports''' holds airport data, like runway usage and parking spots.
* '''Objects''' and '''Models''' are the buildings, bridges and radio towers, etc. that represent three-dimensional structures.
* '''Terrain''' represents the contours, elevations and type of ground you fly/taxi over.

The current way of "installing" new scenery is enabling [[TerraSync]], which will automatically download and update any place you visit - even on the fly! If you have a slow Internet connection and/or computer you could instead use a scenery manager, for example [[TerraMaster]]. In addition you can also manually download and install new scenery parts, either the official [[World Scenery]] or custom scenery.

The scenery is also available on the [https://www.flightgear.org/download/mirrors/ mirrors page] of the FlightGear website, and can be installed following [[Howto: Install scenery]]. '''This is recommended for users with weak internet connections or weak computers!'''

Custom scenery is available in many places. For example, on the {{forum link|f=5|text=FlightGear forum}} or within repositories. An internet search should be able to find them. See [[Suggested_custom_scenery|suggested custom scenery]] page for a few recent releases.

FlightGear 2020.3.7 LTS and later added an experimental rollout of 3 dimensional buildings, roads, and objects based on OpenStreetMap data for the entire world to automatically downloaded TerraSync data - see [[OSM2City 1st Worldbuild|1st OSM2City world-build]] notes (March 2021). Some manual downloads of 3d structures for regions or entire countries is available on the [[Areas populated with osm2city scenery|osm2City downloads]] wiki page.

=== Getting aircraft ===
Additional [[aircraft]] can be downloaded and installed through the [[Qt-launcher|launcher]]. Alternatively, you can go to the FlightGear website and navigate to the [http://www.flightgear.org/download/ download page], then choose the aircraft download link that fits your FlightGear version. In addition there are many third party [[hangars]]. For the installation, see [[Howto: Install aircraft]].

== Running FlightGear ==
=== Starting FlightGear ===
The easiest way to start FlightGear is to use the desktop icon. This starts the graphical interface [[FlightGear Qt launcher]] where you can choose aircraft, start position etc. Remember the Qt launcher only has basic options to get you started. A lot of options for graphics, scenery, [[Weather|weather]], [https://www.flightgear.org/tours/simulating-the-ever-changing-scenery/ environment], [[Input_device|input devices]] etc. are available from the [[menu]] inside the simulator.

Many users choose however to start FlightGear directly from the command line. The executable name is <code>fgfs</code> and can be run without options. If it is "not found", it is likely not in your [https://en.wikipedia.org/wiki/PATH_(variable) path]. The location depends on your particular system and choices you made during compile and installation. There is a list of [[Command Line Parameters]] which must be used to change many options, like the aircraft you want. The most important:

fgfs --launcher # opens the FlightGear Qt launcher
fgfs --show-aircraft # displays a list of installed aircraft
fgfs --aircraft=c172p # start FG with the aircraft "c172p" (from the list)

The Qt launcher also lets users add command line parameters for options that are normally changed from the menu inside the simulator, as well as quite advanced options that are only available from the command line.

=== Configuring rendering and UI ===
[[File:Rendering options 2024.1.png|thumb|View > Rendering Options dialog.]]
If your render quality or framerate is too low, click "View > Rendering Options" to adjust the graphic settings. For newer hardware, it's recommended to set "graphics quality" to high and check "use disk space for faster loading", "animated jetways" and "satellite photoscenery".

If the menu text appears too small on high DPI or large screens, you can manually [[Menubar#How to Change the Default Menubar Font Size|change the menubar font size]] by editing the data file, or simply click "Debug > Cycle GUI Style".

=== Using the keyboard and/or mouse ===
Users with limited access to a [[joystick]] or other controllers sometimes use the keyboard or mouse to control their aircraft. Using the keyboard to fly can be difficult and the mouse is recommended over the keyboard for flying, yet even a cheap joystick would improve the experience so much.

To get help with keyboard commands, with FlightGear running, go to the ''Help'' menu, look under ''Basic Keys'' (for simulator related commands) and ''Common Aircraft Keys'' (for commands universal to all aircraft) and ''Aircraft Help'' (for key commands specific to your aircraft). If the main menu is hidden, press {{key press|F10}}. If you come from other simulators, check [[key commands compared to other simulators]] for an overview of the difference between the key commands of that sim and FlightGear.

To use the mouse to fly the aircraft, press {{key press|Tab}} (the cursor should change to a cross) and move the mouse to direct the aircraft. Press {{key press|Tab}} again to look around (cursor should show a two sided arrow), and press {{key press|Tab}} again to return to normal mode, used to click stuff in the cockpit. You can click "File > Input Devices > Mouse Config" to adjust the mouse sensitivity.

For most users lacking a rudder axis control, it’s difficult to manually coordinate [[aileron]] and [[rudder]] movements during a turn. To enable auto-coordination and make flight easier, you may click "Settings", then click the "Show more" button on the right of "General", and finally click "Enable auto-coordination" in the launcher.

=== First time in the cockpit ===
Finding your way around the cockpit may be challenging the first time.

You can use {{key press|Ctrl|V}} to switch to the cockpit view. If the text on the panel are too small, you can use the view mode of the mouse (press Tab until you get a cursor shaped like a double arrow) to pan and the mouse wheel to zoom, or pan with the joystick hat and zoom with {{key press|X}} and {{key press|Shift|X}}.

One of the first steps that many take on entering an unfamiliar cockpit is to press {{key press|Ctrl|C}} to highlight all the "hotspots", that is instrument controls, buttons, knobs, etc. Many aircraft also offer a specific help menu.

Some functions, such as starter or magneto, may be difficult to use or simply lack clickable "hotspots", especially in aircraft models which are in development. In most cases you can use the keyboard. The keyboard always work according to the assignments listed on the "Help > Aircraft help" or "Help > Common aircraft keys" menu, but sometimes some keys are reassigned by an aircraft or configuration. Again, remember to check all the help dialogs.

=== Starting the engine ===
You are eager to fly, but the engine is off. Well, turning on the engines is not always easy. Most aircraft have an ''autostart'' entry in their custom menu, but here is a general procedure that should work in many cases:

In general to start the engine on a piston-engine type aircraft, you need (after making sure the game is not paused {{key press|p}}):
# Fuel: Some aircraft start the simulation with no fuel. You can add it in ''Equipment'' > ''Fuel and Payload''.
# Correct fuel mixture: This is generally ''rich'', so push the red knob all the way in, or use the key {{key press|m}} to enrich ({{key press|Shift|m}} leans.)
# Magnetos set on ''both'': Turn the key or press {{key press|}}} ''three times'' to move through ''R'', ''L'', ''Both''.
# Throttle: Some engines start better with a little gas.
# Run the starter: Click the ''Start'' position of the key on the panel, or press {{key press|s}}. Hold the starter for sufficient time, even 10 seconds.

Starting all engines in a multi-engine aircraft is similar to the single engine - except you must follow the same start sequence for each and every engine. FlightGear provides a convenient way to do this for all engines at once: Press {{key press|~}} and all the procedure above will work for all the engines. Note though that the default 2D panel is connected to ''only one engine'' and the {{key press|~}} trick might not work. Also, give some gas to be sure that all the engines are on.

These instructions may not work for jet aircraft, helicopters, or other types of aircraft with complex start procedures. Check the instructions in the aircraft help menu (press {{key press|?}}) and/or look at [[Aircraft|the aircraft's article on this wiki]]. In general to start the engine on a jet engine type aircraft, you need to:
# Set cutoff ''ON''
# Engage the starter
# Once the engines spools up to approximately 5% N1, set cutoff ''OFF''
# Disengage the starter once the engine has reached operational speed

== Learning to fly ==
=== FlightGear's Manual ===
FlightGear has an official [https://www.flightgear.org/support/manual/ manual] that covers the basics of flight. As a beginner, you may want to start with [https://flightgear.gitlab.io/getstart/release-{{current release|cr}}/en/HTML/getstart-ench8.html Chapter 8: A Basic Flight Simulator Tutorial].

=== Tutorials ===
Many aircraft have their own interactive [[tutorials|tutorial]]. With tutorials, you can learn to operate particular aircraft but also learn to fly. You can access tutorials by going to ''Help'' > ''Tutorial''. A great place to start is the tutorial for the [[Cessna 172P]] aircraft, commonly used in real life to learn to fly fixed-winged aircraft.

If the tutorial starts without a runway and surrounded by water, your setup of FlightGear is missing the scenery for the airport at which the tutorial was supposed to run. To get scenery see the [[#Getting scenery]] section above.

== Making your first flight ==
=== Realism ===
One of the most frequent questions novice pilots ask about any flight simulator, but more so to FlightGear, is "Why is my aircraft turning left all the time?" Although it could be due to wind gusts crossing the runway, it is more likely due to the [[Understanding Propeller Torque and P-Factor|propeller torque and p-factor]].

In certain other flight simulators, despite marketing slogans to the contrary, some settings are turned down to make the aircraft easier to fly. This reduces effects such as the above. The realism is always turned up in FlightGear.

Here are some of the FlightGear realism points, which may be confusing to first time pilots:
* "Left turning syndrome" for the previously mentioned reasons.
* Compass turning error: A compass, when subjected to the forces of flight, tends to turn in the opposite direction for a brief period before settling on the correct heading. This is not a malfunction (see also the Wikipedia article {{wikipedia|Aircraft compass turns}}).
* The Vertical Speed Indicator (VSI) is also subject to error.
* The [[Horizontal Situation Indicator]] (HSI) is driven by a gyroscope (that is why it is sometimes called a Directional Gyroscope), which is subject to ''gyro drift''. The indicator will drift from its current heading and must be periodically (every ~15 minutes) calibrated to agree with the magnetic compass heading.
* You cannot just cancel a turn or climb by centering the yoke or stick. You must turn or push the stick the other way to get to level and level flight. But even then, the plane will not maintain its altitude or heading by itself. A common mistake is trying to find a hands off yoke position. While with trimming one could leave the plane for a couple of seconds, one must use autopilot or constantly adjust the yoke.

Many forces act on an aircraft in flight as well as on the [[avionics and instruments]] used for control and navigation, and may be counter-intuitive. Pilots must learn to recognize these phenomena and compensate for their effects. ''FlightGear models instrument errors that exist in the real world''. If you don't want it, press {{key press|h}} to enable the HUD.

=== Airports and navigation aids ===
When you first start FlightGear, whether from the command line or the graphical interface of the launchers, you may wonder how to determine what airports are available. The launcher displays a list of airports, but you will not see details such as tower or [[ILS]] frequencies. You will not find a map showing [[VOR]]s and their frequencies. What can you do? See [[Getting aeronautical charts]].

In-sim, there is a map you can use in ''Main Menu'' > ''Equipment'' > ''Map'', which will allow you to see navigation data and the position of airports and aids. For more help with navigation see [[Understanding navigation]].

=== Flying using the autopilot ===
A generic [[autopilot]] is available from the ''Autopilot > Autopilot Settings'' menu, while many aircraft come with their own ''specific'' autopilot, frequently a model of the real life one.

For aircraft that provide their own autopilot, you should use the autopilot controls available in the virtual cockpit. This means clicking on the instrument panel in the virtual cockpit. The Autopilot menu may be grayed out and unavailable when the aircraft supplies its own autopilot in some aircraft, including the Airbuses and the [[Cessna 172P|C172P]].

The Cessna 172 comes with a [[Bendix/King KAP140 Autopilot]] in its virtual cockpit. You can use both the autopilot device in the cockpit and the [[Autopilot#Autopilot Settings|autopilot settings]] from the menu.

== Advanced ==
=== Flying ===
{{Main article|Aircraft}}

* If you continue to fly light civilian aircraft, [[Cessna 182S]] which is more complex than C172P and [[Piper PA28 Warrior II|PA28]] are good choices.
* If you are interested in flying airlines, [[Airbus A320 family]], Boeing [[Boeing 777|777]]/[[Boeing 787-8 Dreamliner|787]], [[MD-11]] and [[MD-80]] are suggested.
* If you are fascinated by fighter aircrafts, choose a highly rated military aircraft (such as [[General Dynamics F-16 Fighting Falcon|F-16]]/[[F-15]]) from [[Aircraft#Modern military aircraft|here]], and enable multiplayer damage or install [[Bombable]].
* If you switch to helicopters, it is recommended to fly [[Eurocopter EC130 B4]].

Besides common aircraft, there are also detailed [[Space Shuttle|space shuttles]] available.

=== Scenery ===
It is fascinating to explore the [[scenery]] (or just test the graphics/frame rate) with [[UFO]]. First of all, [[#Configuring rendering and UI|increase your graphics quality]]. If you don't see buildings initially, keep FG open and wait for a while for [[TerraSync]] to finish downloading and for the buildings to appear.
There are plenty of [[Suggested airports|well-developed airports]] and scenery areas. You can also explore the scenery objects on the [https://scenery.flightgear.org/map model map].

=== Multiplayer ===
FlightGear has some multiplayer servers that will let you fly in more lively skies, see [[Howto: Multiplayer]]. There are also [[OpenRadar]] and [[ATC-pie]], standalone programs that will let you be an [[Air traffic control|air traffic controller]].

There is also a [[MPMap|multiplayer map]] that lets you see who is online right now, and even what [[navaids]] are nearby.

=== Menu items ===
For a quick reference about the usage of each menu item in FlightGear, see [[menu]].

=== Addons ===
FlightGear has a lot of third-party [[Addon|addons]] containing enhancements. For beginners, [[Logbook Add-on|Logbook]] and [[Which Runway Add-on|Which Runway]] may be the most useful addons.

== The FlightGear community ==
=== Getting help ===
This page is designed to give the user the essential things they need to know about using FlightGear for the first time. Besides the [[Portal:User|User portal]] of this wiki, there are other pages you may want to read:
*[[Troubleshooting problems]] to help you with the most common issues;
*[[Frequently asked questions]];
...and communication channels that can be used to obtain information or request help:
*The [[FlightGear Manual]], a ''must read'' for beginners;
*{{forum link|text=FlightGear Forum}} and its subforums;
*[[Discord|FlightGear's Discord server]], the quickest way to get help;
*[[FlightGear IRC channel]];
*[[Mailing list|FlightGear users mailing list]], biggest chance to get in contact with core developers;
*Documents bundled with the release package.

=== Customizing FlightGear without compiling it ===
[https://www.flightgear.org/download/ Our website] offers precompiled binaries for download and install on Windows, macOS and Linux. In addition, most Linux distributions provide a packaged version in their repositories.

Although the install is binary, most of FlightGear's systems are open to configuration through [[XML]] files and [[NASAL scripting]]. You are free ''and encouraged'' to make changes to aircraft flight models, scenery, textures, OpenGL [[shader]]s and any other feature you wish to change for your personal satisfaction or to share with other FlightGear users. If this is what you intend to do, take a look at the [[Portal:Developer|Developer portal]].

=== How you can help ===
{{Main article|Volunteer}}
FlightGear is an open source, volunteer based project. That means that whatever you find here comes from passion, spare time and nothing else. This includes the simulator, the scenery, the aircraft, the wiki, the {{forum link|text=forum}} and everything else. Volunteers, in essence ''people that do things'', are fundamental to this project. Without them, it would not make a single step forward. So it is essential that contributors have fun in what they do.

If you plan to contribute to this project, you should take a look at some articles that will give you some hints:
*[[Howto:Understand the FlightGear development process]]
*[[Implementing new features for FlightGear]]
*[[How the FlightGear project works]]

The fields where their help would be appreciated are many:
;Testing:
*[[Building FlightGear|Build]] the latest Git code
*[https://gitlab.com/flightgear/flightgear/-/issues File bug reports]
*Running FlightGear via valgrind to track down memory leaks

;Support:
*Help new users with downloading, compiling, installing and running FlightGear ({{forum link|text=on the forum}} or on [[Discord]])
*Provide ideas & suggestions, see: [[Feature Requests / Proposals / Ideas]]
*Help [[Portal:Wiki|clean up this wiki]]
*Help provide new contents for missing wiki pages

;Development:
*Core codebase:
**Provide [[Howto:Start core development|source code / data / documentation contributions]]
**Provide [[Bugs|bug fixes]] or new features
*Aircraft development (3D modeling, textures, FDMs, scripting)
*Scenery development (terrain, model, weather)
*Get involved in any of the other FlightGear-affiliated projects

[[Category:FlightGear]]

[[ca:Nou a FlightGear]]
[[de:Neu bei FlightGear]]
[[es:Nuevo en FlightGear]]
[[fi:Uusi_käyttäjä]]
[[fr:Nouveau sur flightgear]]
[[it:Nuovo per FlightGear]]
[[ja:FlightGear入門]]
[[nl:Nieuw bij FlightGear]]
[[pl:Nowy w FlightGear]]
[[pt:Novo no FlightGear]]
[[sr:Novi u FlightGear-u]]
[[th:New to FlightGear]]
[[zh:FlightGear入门]]

Zh/FlightGear入门

2026-06-10T17:13:10Z

Fgf5: /* 运行FlightGear */

'''欢迎来到[[FlightGear]]！''' 在这里，我们将尝试让你在最短的时间内升入虚拟天空。并将向你介绍这款飞行模拟器的一些功能，以及其社区的一些信息。

== 安装与设置 ==
=== 硬件要求 ===
为了让FlightGear流畅运行，它需要一块支持OpenGL 4.0或更高版本驱动的显卡。这通常不是问题，但你可以查看[[hardware recommendations|硬件推荐]]以获得更清晰的了解。

=== 获取FlightGear ===
{| class=toccolours align="center" style="text-align: center; width: 80%; font-size: 85%; clear:both; margin-top:1em; margin-bottom:-0.5em; border-left: 15px solid orange;"
| '''强烈建议中国内地用户从[https://mirrors.tuna.tsinghua.edu.cn/flightgear/ftp/ TUNA镜像站]下载FlightGear，以保证下载速度。'''
安装文件位于其中的<code>release-<大版本号></code>文件夹下，Windows用户请选择下载该文件夹下的<code>FlightGear-<小版本号>.exe</code>。该镜像站也提供部分机模与地景下载。
'''此外，[[FlightGear China|FlightGear中国飞友会（或FGPRC）]][https://www.fgprc.org.cn 官网]也可下载macOS和Windows平台最新LTS版本的FlightGear。'''
|}
你可以从 [https://www.flightgear.org/download/ FlightGear下载] 页面下载最新文件。选择适合你特定系统的源代码或二进制文件。Linux系统的{{Wikipedia|AppImage|AppImage}}二进制文件也可用于2020.3 LTS及更高版本。大多数Linux用户会发现，大多数发行版都有一个打包版本的FlightGear（包名可能是<code>fgfs</code>或<code>flightgear</code>）。

根据你的技术专长，你可以选择FlightGear的[[Git]]开发版本，该版本通常具有更多功能，并且是一些最新开发中的飞机所必需的，但可能不稳定，并且对非Windows用户来说更复杂。一般来说，不建议普通用户使用开发版本，但如果你愿意进行一些测试，可以下载[https://www.flightgear.org/download/nightly/ 夜间构建版本]。如果你使用的是Git版本控制的FlightGear副本，你可以选择使用版本控制的[[FGAddon|FGAddon飞机开发仓库]]来同步你的飞机。

=== 在Windows上安装 ===
下载安装程序后，运行它并按照其说明安装FlightGear。

Windows上的Defender SmartScreen可能会阻止安装，仅仅是因为二进制文件没有使用微软认可的密钥进行签名。当然，这个密钥是收费的。在这种情况下，我们需要点击不起眼的“更多信息”链接。只有这样，“仍要运行”按钮才会出现。只要你确实是从官方来源下载的，就可以放心地相信这不是一个危险的应用程序。

如果你出于某种原因使用了第三方防病毒软件，它可能会阻止FlightGear安装。这不是我们能控制的，所以完全由你自己决定如何处理。

使用Windows安装程序时，你可以选择安装FlightGear的位置。[[$FG_ROOT]]目录将是<code><你选择的目录>/data</code>。

=== 在macOS上安装 ===
在macOS上安装FlightGear非常简单。只需将FlightGear图标拖放到<code>/Applications</code>文件夹中即可。就是这样。

第一次启动FlightGear时，它在加载飞机和机场信息时，Dock上的图标会跳动几秒钟。当GUI启动器出现时，选择飞机和机场，然后点击“Fly!”启动模拟器。你可以使用GUI启动器配置更多选项。有关更多详细信息，请参阅[官方手册](http://flightgear.sourceforge.net/manual/next/en/getstart-ench4.html#takeoff-how-to-start-the-program)。

如果你想使用命令行启动FlightGear，请启动终端应用程序并输入以下内容。

cd /Applications/FlightGear.app/Contents/MacOS
./fgfs --options.....

在macOS上未设置[[$FG_ROOT]]和[[$FG_SCENERY]]。如果你想自己为命令行使用指定这些变量，请在终端应用程序中运行以下命令：

FG_ROOT=/Applications/FlightGear.app/Contents/Resources/data
FG_SCENERY=[[$FG_ROOT]]/Scenery

启动GUI启动器后，你将在<code>$HOME/Documents/FlightGear/<版本></code>处拥有指向[[$FG_ROOT]]的别名，因此你可以使用Finder浏览数据文件夹。

注意：安装FlightGear后，Mac用户可以通过在Finder中打开应用程序文件夹，右键单击FlightGear，然后单击“显示包内容”来找到他们的[[$FG_ROOT]]文件夹。这将带你进入FlightGear文件夹内部。你现在可以访问所有文件，包括Data/Aircraft，以[[Howto: Install aircraft#Macintosh OS X|安装新飞机]]。

=== 从源代码安装 ===
主条目：[[Building FlightGear]]

=== 获取地景 ===
FlightGear安装时附带有限的一组[[scenery|地景]]。对于FlightGear 2024.1，这包括：
* 发布版特色机场[[Keflavik_Airport|凯夫拉维克国际机场]] (BIKF) 周围的区域
* [[Cessna_172P|塞斯纳172P]]的教程机场[[Hilo_International_Airport|希洛国际机场]] (PHTO)

在FlightGear中，地景通常存储在你的[[$FG_ROOT]]目录中，并分为三种数据：
* '''机场''' 包含机场数据，如跑道使用和停机位。
* '''物体''' 和 '''模型''' 是建筑物、桥梁和无线电塔等，代表三维结构。
* '''地形''' 代表你飞行/滑行经过的地面的轮廓、高程和类型。

当前“安装”新地景的方法是启用[[TerraSync]]，它将自动下载并更新你访问的任何地方——甚至在飞行过程中！如果你网络连接和/或电脑较慢，你可以改用风景管理器，例如[[TerraMaster]]。此外，你也可以手动下载并安装新的地景部分，无论是官方的[[World Scenery|世界地景]]还是自定义地景。

地景也可在FlightGear网站的[https://www.flightgear.org/download/mirrors/ 镜像页面]上获得，并可以按照[[Howto: Install scenery|如何安装地景]]进行安装。'''建议网络连接或电脑较弱的用户使用此方法！'''

自定义地景在很多地方都有。例如，在{{forum link|f=5|text=FlightGear论坛}}或代码仓库中。互联网搜索应该能够找到它们。有关最近的一些发布，请参阅[[Suggested_custom_scenery|建议的自定义地景]]页面。

FlightGear 2020.3.7 LTS及更高版本增加了基于OpenStreetMap数据的全球三维建筑、道路和物体的实验性推出，用于自动下载的TerraSync数据——请参阅[[OSM2City 1st Worldbuild|首次OSM2City世界构建]]说明（2021年3月）。在[[Areas populated with osm2city scenery|osm2City下载]]维基页面上，提供了一些针对地区或整个国家的三维结构的手动下载。

=== 获取飞机 ===
可以通过[[Qt-launcher|启动器]]下载并安装额外的[[aircraft|飞机]]。或者，你可以访问FlightGear网站并导航到[http://www.flightgear.org/download/ 下载页面]，然后选择适合你FlightGear版本的飞机下载链接。此外，还有许多第三方[[hangars|机库]]。有关安装，请参阅[[Howto: Install aircraft|如何安装飞机]]。

== 运行FlightGear ==
=== 启动FlightGear ===
启动FlightGear最简单的方法是使用桌面图标。这将启动图形界面的[[FlightGear Qt launcher|FlightGear Qt启动器]]，你可以在其中选择飞机、起始位置等。Qt启动器仅提供基本选项帮你入门。更多图形、地景、[[Weather|天气]]、[https://www.flightgear.org/tours/simulating-the-ever-changing-scenery/ 环境]、[[Input_device|输入设备]]等选项，可通过模拟器内的[[menu|菜单]]调整。

不过，许多用户也直接从命令行启动FlightGear。可执行文件名为<code>fgfs</code>，不带参数即可运行。若提示“未找到”，则可能不在你的[https://en.wikipedia.org/wiki/PATH_(variable) PATH]中。路径取决于你的系统以及编译安装时的选择。通过[[Command Line Parameters|命令行参数]]可修改诸多选项，例如指定飞机。最常用的有：

fgfs --launcher # 打开FlightGear Qt启动器
fgfs --show-aircraft # 列出已安装的飞机
fgfs --aircraft=c172p # 启动飞机c172p

Qt启动器也支持添加命令行参数，用于调整通常由模拟器内菜单控制的选项，以及一些仅命令行可用的高级选项。

=== 配置渲染和UI ===
[[File:Rendering options 2024.1.png|thumb|View > Rendering Options 对话框]]
如果渲染质量或帧率过低，点击 "View > Rendering Options" 调整图形设置。对于较新硬件，建议将 "graphics quality" 设为 high，并勾选 "use disk space for faster loading"、"animated jetways" 和 "satellite photoscenery"。

若菜单文字在高DPI或大屏幕上显示过小，可手动编辑数据文件[[Menubar#How to Change the Default Menubar Font Size|修改菜单栏字体大小]]，或直接点击 "Debug > Cycle GUI Style"。

=== 使用键盘与/或鼠标 ===
缺少摇杆或其他控制器的用户有时会用键盘或鼠标来驾驶飞机。键盘飞行较难，推荐用鼠标代替键盘，但即使一个廉价摇杆也能大幅提升体验。

获取键盘命令帮助：在FlightGear运行时，打开 "Help" 菜单，查看 "Basic Keys"（模拟器相关命令）、"Common Aircraft Keys"（所有飞机通用命令）和 "Aircraft Help"（当前飞机特有命令）。若主菜单隐藏，按 {{key press|F10}}。若你从其他模拟器转来，可参考[[key commands compared to other simulators|键位对比]]了解差异。

用鼠标飞行：按 {{key press|Tab}}（光标变为十字），移动鼠标即可操控飞机。再按一次 {{key press|Tab}} 可环顾四周（光标变为双箭头），第三次按 {{key press|Tab}} 返回正常模式（用于点击驾驶舱控件）。可在 "File > Input Devices > Mouse Config" 中调整鼠标灵敏度。

多数用户没有方向舵轴，转弯时手动协调[[aileron|副翼]]与[[rudder|方向舵]]较困难。要启用自动协调，可在启动器中依次点击 "设置" → "通用" 右侧的 "显示更多" → 勾选 "启用自动协调"。

=== 首次进入驾驶舱 ===
初次进入驾驶舱可能找不到北。

按 {{key press|Ctrl|V}} 可切换到驾驶舱视角。若面板文字太小，可用鼠标视图模式（按 Tab 直到光标变为双箭头）平移，用滚轮缩放；或用摇杆苦力帽平移，{{key press|X}} / {{key press|Shift|X}} 缩放。

许多人进入陌生驾驶舱后的第一件事是按下 {{key press|Ctrl|C}} 高亮所有 "hotspots"（仪表、按钮、旋钮等）。许多飞机也提供专门的帮助菜单。

某些功能（如启动器、磁电机）可能难以点击或干脆没有 "hotspots"，尤其在开发中的飞机模型上。多数情况下可用键盘操作。键位分配始终列在 "Help > Aircraft Help" 或 "Help > Common Aircraft Keys" 菜单中，但有时会被飞机或配置重新定义。别忘了查看所有帮助对话框。

=== 启动发动机 ===
你急着要飞，但发动机没转。打开发动机并不总是那么容易。大多数飞机在自定义菜单中有 "autostart" 项，但以下通用步骤通常有效：

启动活塞式发动机（先确认游戏未暂停，按 {{key press|p}} 检查）：
# 燃油：某些飞机启动时无燃油。可在 "Equipment" > "Fuel and Payload" 中添加。
# 混合比：通常应为 "rich"，将红色旋钮完全推入，或按 {{key press|m}} 加浓（{{key press|Shift|m}} 减稀）。
# 磁电机设为 "both"：转动钥匙或按 {{key press|}}} ''三次''，依次经过 "R"、"L"、"Both"。
# 油门：少许油门有助于启动。
# 启动：点击面板上钥匙的 "Start" 位置，或按 {{key press|s}}。按住启动器足够长时间（甚至10秒）。

启动多引擎飞机的所有引擎：与单引擎类似，但需对每台引擎执行相同步骤。FlightGear 提供了一键操作：按 {{key press|~}}，上述所有步骤将同时作用于所有引擎。注意默认的2D面板仅连接 ''一台引擎''，{{key press|~}} 可能无效。另外，稍给一些油门确保所有引擎都启动。

上述步骤不适用于喷气机、直升机或其他复杂启动流程的机型。请查看飞机帮助菜单（按 {{key press|?}}）或本维基上[[Aircraft|该飞机的条目]]。通常，启动喷气发动机的步骤为：
# 将切断（cutoff）设为开（ON）
# 启动启动器（starter）
# 发动机转速提升到大约5% N1时，将切断设为关（OFF）
# 达到工作转速后，断开启动器

== 学习飞行 ==
=== FlightGear 手册 ===
FlightGear 有涵盖飞行基础的[https://www.flightgear.org/support/manual/ 官方手册]。初学者可从[https://flightgear.gitlab.io/getstart/release-{{current release|cr}}/en/HTML/getstart-ench8.html 第8章：基础飞行模拟器教程]开始。

=== 教程 ===
许多飞机自带交互式[[tutorials|教程]]。通过教程，你不仅能学习特定机型的操作，也能学习飞行。进入 "Help" > "Tutorial" 即可。[[Cessna 172P|塞斯纳172P]] 的教程是个不错的起点，这款飞机在现实中常用于固定翼飞行训练。

如果教程开始时没有跑道，周围全是水，说明你的 FlightGear 缺少教程所需机场的地景。请参照上文 [[#Getting scenery|获取地景]] 一节。

== 第一次飞行 ==
=== 真实感 ===
新手常问的一个问题是：“为什么我的飞机总向左转？” 这虽然可能是跑道侧风所致，但更常见的原因是[[Understanding Propeller Torque and P-Factor|螺旋桨扭矩和P因子]]。

其他某些模拟器为了降低难度，会调低这类效应。而 FlightGear 始终将真实度拉满。

以下是一些可能让新手困惑的真实感特性：
* 前述的“左转问题”
* 罗盘转弯误差：罗盘受飞行力影响，会在稳定到正确航向之前短暂反向偏转。这不是故障（参见维基百科 {{wikipedia|Aircraft compass turns|Aircraft compass turns}}）。
* 垂直速度指示器（VSI）也存在误差。
* [[Horizontal Situation Indicator|HSI]] 由陀螺仪驱动（因此也称 Directional Gyroscope），存在“陀螺漂移”。需要定期（约每15分钟）按磁罗盘航向校准。
* 无法通过回中驾驶杆来取消转弯或爬升。必须向相反方向压杆才能恢复水平直线飞行。即便如此，飞机也不会保持高度和航向。常见错误是试图找到一个“放手”位置。通过配平可让飞机自行稳定几秒，但仍需使用自动驾驶仪或不断调整驾驶杆。

飞机飞行中以及用于控制和导航的[[avionics and instruments|航电与仪表]]会受到多种力的作用，有些反直觉。飞行员必须学会识别并补偿这些效应。''FlightGear 模拟了现实世界中存在的仪表误差''。如果你不需要，按{{key press|h}}显示HUD.

=== 机场与导航设备 ===
首次启动 FlightGear 时，你可能想知道哪些机场可用。启动器显示机场列表，但不会提供塔台或[[ILS]]频率等细节，也没有显示[[VOR]]及其频率的地图。怎么办？请参阅[[Getting aeronautical charts|获取航图]]。

模拟器内可通过 "Main Menu" > "Equipment" > "Map" 打开地图，查看导航数据、机场及导航设备的位置。更多导航帮助请见[[Understanding navigation|理解导航]]。

=== 使用自动驾驶仪 ===
从 "Autopilot > Autopilot Settings" 菜单可获得通用[[autopilot|自动驾驶仪]]，而许多飞机自带“特定”自动驾驶仪，通常仿自真实型号。

对于自带自动驾驶仪的飞机，应使用虚拟驾驶舱中的自动驾驶控件（即点击仪表板）。在某些飞机（如空客和[[Cessna 172P|C172P]]）中，当飞机提供自己的自动驾驶仪时，"Autopilot" 菜单可能会变灰不可用。

塞斯纳172的驾驶舱内置了[[Kap140|KAP140]]自动驾驶仪。你可以同时使用驾驶舱中的自动驾驶设备和菜单中的[[Autopilot#Autopilot Settings|autopilot settings]]。

== 进阶 ==
=== 飞行 ===
{{Main article|Aircraft}}

* 若继续飞通航机，推荐 [[Cessna 182S]]（比 c172p 更复杂）和 [[Piper PA28 Warrior II|PA28]]。
* 若对航线飞行感兴趣，可尝试 [[Airbus A320 family]]、波音 [[Boeing 777|777]]/[[Boeing 787-8 Dreamliner|787]]、[[MD-11]] 和 [[MD-80]]。
* 若迷恋战斗机，请从 [[Aircraft#Modern military aircraft|这里]] 选择高评分军用机（如 [[General Dynamics F-16 Fighting Falcon|F-16]]/[[F-15]]），并启用多人模式伤害或安装 [[Bombable]]。
* 若转向直升机，建议从 [[Eurocopter EC130 B4]] 开始。

除了常规飞机以外，还有精细的 [[Space Shuttle|航天飞机]] 机模。

=== 地景 ===
用 [[UFO]] 探索[[scenery|地景]]（或测试图形/帧率）很有意思。首先，[[#Configuring rendering and UI|提高图形质量]]。若一开始看不到建筑，保持 FG 运行，等待 [[TerraSync]] 下载完成，建筑便会显现。
有许多[[Suggested airports|高质量机场]]和地景区域。你也可以在 [https://scenery.flightgear.org/model 模型地图] 上浏览地景物。

=== 多人模式 ===
FlightGear 有多人服务器，可让你在更热闹的天空中飞行，见 [[Howto: Multiplayer]]。另有第三方程序 [[OpenRadar]] 和 [[ATC-pie]]，可让你扮演 [[Air traffic control|空中交通管制员]]。

还有一张[[MPMap|多人地图]]，可查看当前在线玩家及其附近的 [[navaids]]。

=== 菜单项 ===
关于 FlightGear 每个菜单项的快速参考，见 [[menu]]。

=== 附加模组 ===
FlightGear 有许多第三方 [[Addon|模组]] 提供增强。对初学者来说，[[Logbook Add-on|Logbook]] 和 [[Which Runway Add-on|Which Runway]] 可能是最实用的两个模组。

== FlightGear社区 ==
=== 获取帮助 ===
本页面旨在为用户提供首次使用FlightGear时需要了解的基本信息。除了本维基的[[Portal:User|用户门户]]，你可能还想阅读其他页面：
*[[Troubleshooting problems|问题排查]]帮助你解决最常见的问题；
*[[Frequently asked questions|常见问题解答]]；
...以及可用于获取信息或请求帮助的沟通渠道：
*[[FlightGear Manual|FlightGear手册]]，初学者''必读''；
*{{forum link|text=FlightGear论坛}}及其子论坛；
*[[Discord|Discord服务器]]，获取帮助的最快方式；
*[[FlightGear IRC channel|IRC频道]]；
*[[Mailing list|FlightGear用户邮件列表]]，与核心开发人员联系；
*安装包附带的文档。

=== 无需编译即可自定义FlightGear ===
[https://www.flightgear.org/download/ 我们的网站]提供了预编译的二进制文件，供Windows、macOS和Linux下载和安装。此外，大多数Linux发行版在其仓库中提供了一个打包版本。

尽管安装是二进制的，但FlightGear的大部分系统都可以通过[[XML]]文件和[[Nasal|NASAL脚本]]进行配置。欢迎并鼓励你根据自己的喜好或与其他FlightGear用户分享，对飞机飞行模型、地景、纹理、OpenGL[[shader|着色器]]以及任何你想要更改的功能进行修改。如果你打算这样做，请查看[[Portal:Developer|开发者门户]]。

=== 你如何提供帮助 ===
{{Main article|Volunteer}}
FlightGear是一个开源、基于志愿者的项目。这意味着你在这里找到的一切都源于热情、业余时间，别无其他。这包括模拟器、地景、飞机、维基、{{forum link|text=论坛}}以及所有其他东西。志愿者，本质上就是''做事的人''，对这个项目至关重要。没有他们，项目将无法前进一步。因此，贡献者能够享受他们所做的事情的乐趣至关重要。

如果你计划为这个项目做出贡献，你应该看看一些会给你一些提示的文章：
*[[Howto:Understand the FlightGear development process|理解FlightGear开发流程]]
*[[Implementing new features for FlightGear|为FlightGear实现新功能]]
*[[How the FlightGear project works|FlightGear项目如何运作]]

需要他们帮助的领域有很多：
;测试:
*[[Building FlightGear|构建]]最新的Git代码
*[https://gitlab.com/flightgear/flightgear/-/issues 提交错误报告]
*用Valgrind运行FlightGear以追踪内存泄漏

;支持:
*帮助新用户下载、编译、安装和运行FlightGear（{{forum link|text=在论坛上}}或在[[Discord]]上）
*提供想法与建议，请参阅：[[Feature Requests / Proposals / Ideas|功能请求/提案/想法]]
*帮助[[Portal:Wiki|清理此维基]]
*帮助为缺失的维基页面提供新内容

;开发:
*核心代码库：
**提供[[Howto:Start core development|源代码/数据/文档贡献]]
**提供[[Bugs|故障修复]]或新功能
*飞机开发（3D建模、纹理、飞行动力学模型、脚本）
*地景开发（地形、模型、天气）
*参与任何其他FlightGear附属项目

[[Category:FlightGear]]

[[ca:Nou a FlightGear]]
[[de:Neu bei FlightGear]]
[[es:Nuevo en FlightGear]]
[[en:New to FlightGear]]
[[fi:Uusi_käyttäjä]]
[[fr:Nouveau sur flightgear]]
[[it:Nuovo per FlightGear]]
[[ja:FlightGear入門]]
[[nl:Nieuw bij FlightGear]]
[[pl:Nowy w FlightGear]]
[[pt:Novo no FlightGear]]
[[sr:Novi u FlightGear-u]]
[[th:New to FlightGear]]

Space Shuttle

2026-06-04T22:22:44Z

Fgf5: /* Educational Links / Shuttle technical files */ format

{{:{{PAGENAME}}/info}}
{{hatnote|See also [[Space Shuttle (FG Space Program)]] for the other Space Shuttle.}}
[[File:Spacetripready.png]][[File:Checklistready.png]]

{{Space Shuttle navigation}}

The NASA '''Space Shuttle''' was the world's first operational space plane capable of reaching orbit. It was operated from 1981 to 2011 on a total of 135 missions during which two orbiters, Challenger and Columbia, were lost in accidents.

The Shuttle launch system components include the Orbiter Vehicle (OV), a pair of solid rocket boosters (SRBs) and the external tank (ET) containing the liquid hydrogen and oxygen fuel for the engines of the orbiter. Of these, only the external tank is expendable; the SRBs splash into the sea shortly after launch and are recovered, and the orbiter itself returns to a landing site where it lands like an airplane.

The mixture of a rocket-like launch, a spacecraft-like near ballistic early atmospheric phase and an airplane like approach and landing makes the Space Shuttle a truly unique flying experience.

== Project Aim ==

The aim of the Shuttle Project is to create a highly realistic simulation of the capabilities of the Space Shuttle in FlightGear. While most of the time the real Shuttle is under the control of automatic guidance systems, there are fallback modes to control the spacecraft manually, the so-called CSS (control stick steering) modes, and it is these modes we primarily try to implement.

In addition to the real avionics and control modes, the idea is also to provide various 'educational' modes and instruments in order to explore and appreciate certain aspects of a Shuttle mission more.

The [http://ntrs.nasa.gov NASA technical reports server] supplies a large base of wind tunnel and in-situ performance data of both the mated launch vehicle and the orbiter, and the aerodynamics of the simulated shuttle is based on these documents. The authoritative source for procedures for trajectory management, instrumentation, limits and emergency procedures is the [https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf Space Shuttle Crew Operations Manual] and currently a normal mission, i.e. ascent, orbital insertion, de-orbit, entry, terminal area energy management and landing can be flown largely 'by the book', i.e. following the real procedure for CSS.

In the following, descriptions refer to the development version - the last stable or the release version may not have all features described.

=== Limit and failure modeling ===

The project contains code to simulate the various structural and aerodynamical limits as well as component failures based on sections 4 and 6 of the Space Shuttle crew manual.

The general philosophy on limit modeling is that they can be treated dependent on a user setting as 'soft', 'hard' and 'realistic'. Where applicable, warnings when the state of the orbiter is getting dangerously close to a limit are called out in addition to a recommendation how to deal with the situation. Dependent on the trajectory of the orbiter, there may or may not be sufficient time to redeem the situation.

; soft
: Limit violations are called out, but their violation has no consequences for aerodynamics or component failures.

; hard
: Any limit violation immediately ends the simulation.

; realistic
: In reality, components do not necessarily fail immediately if used outside their design specs. This option applies a probabilistic failure model in which the chance for a component to fail grows with the degree of limit violation. The failure may or may not be immediately visible, e.g. too much qbar upon ascent may damage the heat shield, but this may not be apparent (unless specifically checked) until the heat shield fails upon atmospheric entry.

Component failure is modeled gradually where applicable - while a tire can only blow or not blow, an airfoil or a thruster for instance may lose a certain percentage of its efficiency.

In addition to failures induced by limit violations, the simulation also supports failure scenarios designed to model typical failure modes which could be expected to occur during operations, such as for instance engine failures or lock-up on ascent, coolant loop failures or leaks or similar. Rather complex chains of failures are modeled, for instance a failure of a coolant water spray boiler will lead to subsequent overheating of an APU unit - if this is not realized and proper action taken, the APU will fail subsequently, causing in turn a failure of one hydraulic system which potentially causes downstream failures of airfoil actuators or main engine gimbal capability.

== The mated launch vehicle ==

At liftoff, thrust for the shuttle is provided by its three main engines (SSMEs) and the two SRBs. The assembled launch configuration has a height of 184.2 ft (56.1 m) and a mass of about 4,470,000 lb or 2.030 tons (in addition to payload), over 90% of this being propellant. The main engines would at this point be incapable of lifting the launch stack.

The SRBs burn an ammonium perchlorate composite fuel with a relatively low ISP of 268 s in vacuum, supplying 2,800,000 lbf of liftoff thrust each, this is supplemented by the SSME burning liquid hydrogen/oxygen with an ISP of 455 s, supplying an additional total liftoff thrust of 1,180,000 lbf. At liftoff, the shuttle hence reaches a thrust/weight ratio over 1.6, i.e. it leaves the launch pad rapidly.

Control during ascent is provided by thrust vectoring of both the SRB and SSME nozzles. The real-world CSS scheme is a 'stick controls rates' scheme which for stick to neutral does 'attitude hold' which makes it possible to control the launch trajectory very precisely.

=== The Solid Rocket Boosters ===

Each SRB weighs about 1,300,000 lb, out of which 1,100,000 is propellant weight. The propellant of the SRBs is shaped to provide a high liftoff thrust, followed by a thrust reduction during the phase of the highest dynamical pressure (max. qbar). The actual thrust as a function of time is fairly complicated:

[[File:SRB thrust.png|400px|thumb|none|Thrust characteristics of the Space Shuttle Solid Rocket Boosters]]

The distribution is faithfully modeled in FG and the definitions to match the real thrust characteristics is taken from the [http://jsbsim.sourceforge.net/download.html JSBSim code repository]

The SRBs can not be throttled, once ignited, they provide thrust as explained above. SRB ignition takes place some three seconds after main engine ignition, and once they ramp up to full thrust, the shuttle has no choice but to leave the launch pad. For thrust vectoring, SRB nozzles can be gimbaled up to 8 deg in both pitch and yaw axes, a roll moment is created by gimbaling the two SRBs in opposite directions.

[[File:SRB 2.jpg|800px|thumbnail|none|Early ascent on combined SRB and SSME thrust]]
[[File:Sonic boom.webp|800px|thumbnail|none|Sonic boom and max dynamical pressure]]

As of May 2015, SRB separation happens automatically once the thrust drops below some threshold to avoid having to drag dead weight, but there is no provision to manually separate. The SRBs are pushed away from the remaining launch vehicle by separation motor burns. These (including the separation animation with still burning SRBs) are modeled in FG, however due to technical issues with the submodel code at high velocities, thrust of the separation motors in the sim is set larger than in reality to provide the same visual separation dynamics.

The SRBs are implemented as ballistic submodels, i.e. they follow a correct trajectory and ascent with the shuttle, however since (unlike the shuttle) they are not accelerating, they visually fall behind quite quickly.

=== The Main Engines ===

The three main engines (SSMEs) are used during ascent and burn propellant from the ET. They are mounted in a triangular configuration at the stern, tilted by 13 degrees with respect to the spacecraft main axis and can be gimbaled by 10.5 degrees in the pitch and by 8.5 degrees in the yaw axis. The reason for the tilted arrangement is to have a sensible CoG of the OV together with the ET during the later ascent stages. The heavy oxygen is stored forward in the ET, leading to a fairly forward CoG for the mated vehicle such that the SSMEs can be vectored through the CoG. This assembly is faithfully modeled in FG.

[[File:SSME.jpg|800px|thumbnail|none|Late ascent phase on SSME thrust]]

The engines can be throttled between 67 and 109% of rated power, this is necessary to keep the launch vehicle within structural limits during the high qbar phase in the atmosphere and later close to MECO as the propellant in the ET is almost depleted. Thrust increases during ascent as the exhaust gases do no longer have to push against an atmosphere. Both liftoff and vacuum thrust of the modeled engines are in agreement with published values.

Since the SSME's are mounted much closer to each other than the SRBs, the Shuttle loses significant yaw and roll maneuverability after SRB separation. However as the spacecraft is nearly out of the atmosphere by then, no such maneuverability reserves are actually needed.

In FG, the throttle controls all three SSMEs during ascent. Engines ignite once throttle is moved above 67%, this triggers the SRB ignition. If the throttle is moved below 67%, the engines will stop, however they will restart once throttle is moved again up as long as fuel is available in the ET.

The engine numbering by NASA has the center engine as number 1, the left engine as number 2 and the right engine as number 3 and these numbers are used in in-sim callouts of engine failures. For some failure modes, engines will not respond to throttle any more, in this case the cutoff switches have to be used. These are {{Key press|Control|q}} for engine 1, {{Key press|Control|w}} for engine 2 and {{Key press|Control|e}} for engine 3. An engine that has been shut down by the cutoff switch will not re-ignite.

The propellant for the SSMEs is carried in the ET. The tank has a liftoff weight of approximately 1,680,000 lb (760 tons) and a dry weight of about 66,000 lb (dependent on version - the Space Shuttle menu offers an option to fly older and heavier tanks). The ET is the only expendable component of the launch stack, it is dropped after MECO upon almost reaching orbit and then the shuttle uses the OMS to attain orbit while the tank re-enters the atmosphere half an orbit later and breaks up during entry.

[[File:Et_sep.jpg|800px|thumbnail|none|External tank separation]]

In FG, the tank is normally separated using {{Key press|d}}. This is vetoed if the Shuttle has unsafe yaw, pitch or roll motion in which case the RCS should be used to stabilize the orbiter before ET separation. If an emergency separation needs to be performed, {{Key press|Control|d}} overrides the veto. At separation, a translational RCS burn will automatically push the shuttle away from the tank.

After separation, the ET will approximately co-orbit with the OV, i.e. unless the Shuttle ignites the OMS engines, the tank will be visible for a long time, slowly drifting off, and it is quite possible to use the Shuttle's RCS engines to do a visual inspection of the tank.

[[File:ET_sep_2.jpg|800px|thumbnail|none|The ET seen from the Shuttle]]

=== A note on aerodynamics of the mated vehicle ===

With the ET and SRBs attached, the launch stack has quite different aerodynamical characteristics than the OV alone, for instance the stack is more yaw-stable than the orbiter and its pitching moment as function of alpha and rolling moment as function of beta are very different. Where such data could be obtained from wind tunnel tests with the mated stack, it has been used in the simulation.

As in reality, the simulated shuttle has an automated downward elevon deflection schedule with Mach number upon ascent to provide further load relief for the wings (with corresponding aerodynamical forces acting).

In general though, aerodynamical effects are subleading, the ascent dynamics is dominated by the thruster forces and the flight control systems have a large margin to compensate for them.

=== The Ascent Performances ===

Space Shuttle Main Engine thrust, [https://en.wikipedia.org/wiki/Specific_impulse ISP], and consumption is now within a percent of the real datas (Dev version of December 2020)
The mixture ratio in real was around 6, and it is what we observe in the sim (6 times more liquid Oxygen burnt than liquid Hydrogen). Hence, Main Engine Cut Off (MECO) time is matching real one. Plus, the propellant remaining at MECO, called the Final Performance Reserve (FPR) is now within a percent (15000 pounds). It makes launch with high payload into a high inclination Orbit (towards ISS typically) really interesting and limitating performance wise, like in real.

An interesting read about that FPR, written by a former Shuttle Flight Controller: [https://waynehale.wordpress.com/2014/10/08/understanding-sts-93-the-key-is-mixture-ratio/ Wayne Hale: The key is Mixture Ratio]

You can find below some in sim datas compared to real one coming from the Shuttle Crew Operations Manual (SCOM).

[[File:Stage_1_in_sim.png|600px|thumbnail|none|Stage 1 Velocity Vs Time in Sim]][[File:Stage_1_scom.jpg|600px|thumbnail|none|Stage 1 Velocity Vs Time in real]]
[[File:Stage_2_in_sim.png|600px|thumbnail|none|Stage 2 Velocity Vs Time in Sim]][[File:Stage_2_scom.jpg|600px|thumbnail|none|Stage 2 Velocity Vs Time in real]]

=== CSS DAP schemes for ascent ===

During ascent, the stick controls thrust vectoring for both SSMEs and SRBs. The following two DAP schemes are available:

; Thrust vectoring
: This is the real CSS ascent mode for the shuttle in which stick motion controls rate, stick to neutral commands an attitude hold. Internally a PID controller vectors the thrusters and uses the stick input as a bias for the error. This is a very stable scheme and can be easily used to achieve high precision in controlling ascent speed or orbital inclination.

; Thrust vectoring (gimbal)
: This is an educational scheme in which the stick motion directly controls the engine gimbal, i.e. the pilot needs to do the task of the PID controller himself. To make things somewhat easier, the engines are automatically vectored through the stack's CoG, i.e. outside the atmosphere stick neutral corresponds to zero moments acting on the stack. In the atmosphere, the control input hence needs to compensate for aerodynamical forces. Launch in this scheme is fairly rough and it is not possible to reach high precision, but it is possible to fly into orbit and gain a first-hand experience of the forces acting on the stack.

{{Key press|m}} switches between the ascent DAPs. {{Key press|Control|m}} switches from the ascent to the orbital DAP modes (do not use an orbital DAP for ascent control unless you know very well what you're doing).

=== Ascent structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during ascent:

* Dynamical pressure qbar < 819 lb/sqf (modeled)

This is a structural limit for the orbiter and mated stack, in actual operations the orbiter should be kept below 650 lb/sqf.

* Wing bending moment coefficient CBW between -0.019 and 0.019 at max. qbar (modeled)

At max qbar, the wing bending moment is a function of Mach number and AoA. Since Mach number is close to 1.4 in this phase of the flight, this limit basically translates into alpha between -8 degrees and 2 degrees. This can only be achieved if the orbiter is in inverted flight.

* Translational accelerations Nx between 0 and 3.11 g (modeled), Ny between -0.18 and 0.18 g (not modeled) and Nz between -0.06 and 0.73 g (not modeled).

These are structural limits of the mated stack to acceleration rather than aerodynamical forces. Especially the Nx (acceleration along the orbiter axis, i.e. main engine thrust) is important and requires to throttle down the SSMEs towards the end of the burn time.

* Late ascent trajectory may not drop below 265.000 ft (modeled)

This is a heat load limit for the external tank insulation, if the thermal protection of the ET fails, it will explode.

== The Shuttle in orbit ==

For maneuvering in orbit, the OV is equipped with three RCS thruster clusters and the two OMS engines. The propellant for these systems is monomethylhydrazine (MMH) oxydized with dinitrogen tetroxide, resulting in a specific impulse of 312 s. This is an hypergolic fuel combination (i.e. ignites automatically). OMS and RCS tanks have an interconnect valve, however only the RCS can be fired from the OMS propellant reserves, not vice versa (currently not modeled).

The OMS engines are located at the rear of the spacecraft in pods attached to the fuselage. Two of the RCS clusters are attached to the OMS pods, one is located at the spacecraft nose.

=== The Orbital Maneuvering System engines ===

The two OMS engines provide a thrust of 6,000 lb and, using the propellant reserves of 7,773 lb of nitrogen tetrozide and 4,718 lb of MMH can induce a total velocity change of about 1000 ft/sec if all propellant is spent. Typically half of this is used to push the OV into a proper orbit after ET separation and for the de-orbit burn, the rest is available for orbital maneuvers such as inclination adjustments.

Once in orbit, in FG throttle control is transferred to both OMS engines. They can be throttled from zero to 100% of nominal thrust and are automatically vectored by the flight controls through the CoG of the orbiter. The real shuttle has a DAP for thrust vectoring of the OMS engines as well as the option of using a single engine with partial thrust vectoring, only the first option is currently modeled.

[[File:OMS_burn.jpg|800px|thumbnail|none|OMS burn for orbital insertion]]
[[File:MS cockpit view Orbit.webp|800px|thumbnail|none|Orbit cockpit configuration]]

=== OMS DAP schemes ===

In orbit, the throttle controls OMS engine thrust. The following DAP schemes are available:

; OMS TVC
: This is a stick-controls-rates scheme which utilizes thrust vectoring for the OMS engines. It resembles in principle the ascent thrust vectoring, except for the fact that the OMS engines are far less powerful and hence rates and the transition to the set rate are a lot slower. Note that this DAP will only control the Shuttle if the OMS is firing.

If TVC for the OMS is not feasible (for instance because the OMS engine gimbal actuators are damaged), the OMS engines can also be fired with an RCS attitude-holding rotational DAP active (for example '''RCS DAP-A'''. In this case, attitude control is provided by the RCS thrusters and thrust by the OMS engines.

=== The Reaction Control System ===

The RCS system consists of three modules, one forward at the nose and two at the OMS pods. The forward module contains 14 primary and 2 secondary thrusters, each aft module carries 12 primary and two secondary thrusters. Propellant reserves in each module are 1,477 lb of oxidizer and 928 lb of MMH. Each primary thruster has 870 lb of thrust with an ISP of 289 s, the secondary Vernier thrusters produce a mere 24 lb each with an ISP of 228 s. Due to geometric constraints, the thrusters are not aligned with the main spacecraft axes or in the same plane (for instance, there is no purely downward firing nose thruster, as its nozzle would have to fire through the heat shield). The layout of the whole system is shown below:

[[File:RCS Jet IDs.gif|600px|Space Shuttle RCS layout]]

Not all thrusters point orthogonal, and not all thrusters have the same nominal thrust - the complete list is as follows

[[File:RCS Break Down Table.gif|600px|List of Space Shuttle RCS thrusters and orientation]]

All of these thrusters are faithfully modeled in FG with their actual orientation and nominal thrust values, including the system of Vernier thrusters, equipping the Space Shuttle with a grand total of 51 distinct engines.

=== RCS DAP schemes ===

The real Space Shuttle has a multitude of (partially mission-specific) DAP schemes, each with different gains and deadbands, which control the thruster firing pattern in response to the controllers. A fair selection of these is implemented in FG. In the real Shuttle cockpit, there is both a rotational hand controller (RHC) and a translational hand controller (THC) to initiate either rotations of the shuttle or translational accelerations (e.g. for approach and docking). In FG, {{Key press|m}} corresponds to switching from THC to RHC to OMS control and back, {{Key press|Shift|m}} switches between the different DAPs and {{Key press|Control|m}} is the override switch to aerodynamical controls. The HUD will display the currently selected mode for clarity.

Due to the geometry of the thruster arrangement, there is significant mode mixing. For instance, a lateral translation firing nose and right pod thruster with the same thrust would also induce a yaw motion (since the modules do not have the same distance to the CoG) and a roll (since they are not in the CoG plane and in fact not even in the same plane). In most implemented modes, the FCS logic takes care of most of these effects by firing additional thruster to cancel the unwanted motion, however in some modes this is not easily possible and mode mixing has to be anticipated and accounted for manually. This is in fact the same as in the real Shuttle.

The Shuttle has four different control pushbuttons (implemented in the menu) to control the basic way the orbital DAP works. These are AUTO, INRTL, LVLH and FREE.

If AUTO is selected, the RCS is controlled by the on-board flight software (specifically either the pointing and tracking routines available on the UNIV PTG display or the automatic burn attitude maneuvering routines available on the MNVR display). In this mode, stick control input is not used. Note that if an automatic maneuver program is selected, the controls need to be switched to AUTO prior to the start of the program. If this is not done, a SEL AUTO warning message is created.

In INRTL (inertial), the stick controls roll rates and the Shuttle holds inertial altitude for stick to neutral. The orbiting Shuttle in this mode thus has an apparent slow attitude drift with respect to the horizon.

In contrast, LVLH (local vertical, local horizon) commands an attitude hold with respect to the local horizon, i.e. the Shuttle appears not to change attitude relative to Earth. Again in this scheme, the stick controls rates.

The following DAPs are available for INRTL and LVLH:

; RCS DAP-A
: A precision 'stick controls rate' scheme in which stick to neutral commands an attitude hold. The mode has fairly strict deadbands and steep gains and hence uses comparatively much propellant to stabilize attitude.

; RCS DAP-B
: As DAP-A, but more permissive in terms of deadbands, trades less strictly stabilized attitude against reduced propellant consumption.

; RCS DAP-A VERNIER
: A 'stick controls rate' scheme in which the Vernier thrusters are used to maneuver the Shuttle. The Verniers are not very powerful and moreover fire in an awkward geometry, so there is significant mode mixing into translations when using them and the response of the Shuttle is very slow - the mode should mainly be used for automatic attitude hold as it is very propellant-friendly.

; RCS TRANS ATT HLD
: A translational DAP in which 'attitude hold' is commanded for all rotation channels. This makes this mode very stable and controllable at the expense of an increased propellant consumption - use e.g. for a precision approach to a docking.

; RCS TRANS LOW-Z ATT HLD
: No upward-firing thrusters are used in this mode to avoid plume impingement on a satellite or docking target. For this reason, forward and backward firing jets are used simultaneously which are both angled slightly upward. For -Z-translations, this causes a 12 times higher fuel consumption. For weak thrust attitude control works well, for strong thrust the controller is, without using upward-pointing thrusters, unable to completely control the pitching motion.

Finally, FREE puts the orbiter into free drift. Stick to neutral then commands all RCS jets off, and stick movements control angular acceleration. The following DAPs are available for this control:

; RCS rotation
: This is a simple scheme in which the stick motion controls thrust, i.e. angular acceleration. Stick to neutral commands no thrust, i.e. the Shuttle will continue its current rotation.

; RCS ROT TAIL ONLY
: A 'stick controls thrust' scheme in which the nose module is not used. This causes significant mode mixing.

; RCS ROT NOSE ONLY
: A 'stick controls thrust' scheme in which the OMS pod modules are not used. This causes significant mode mixing and has very limited roll control (the roll moment only comes from the position difference between left-mounted and right-mounted upward and downward firing thrusters)

; RCS translation
: A translational DAP in which the stick controls translational thrust along the spacecraft x, y and z axes. Stick to idle commands no thrust, but the Shuttle will of course retain its relative velocity to a fix point until counter-thrust is used. RCS translation can be used for emergency de-orbit burns if the OMS is not available. Limited compensation is done for cross-coupling to rotational modes.

; RCS TRANS LOW-Z
: To prevent thruster plume impingement on a docking target, say the ISS, in this mode all upward-firing thrusters are inhibited. To provide the deceleration force for a docking (which is needed in -Z direction), foreward and backward firing thrusters are used simultaneously - since they point about 10 degrees upward, this provides a downward acceleration without upward plume at the expense of 12 times higher than normal propellant consumption. There is strong cross-coupling to a pitching motion.

The following DAPs are available for re-entry (OPS 304):

; RCS ROT ENTRY
: A 'stick controls rates' DAP designed for entering the atmosphere which enforces a 'no sideslip' attitude in which the nose module is not used. This has very strict deadbands and aggressive gains to combat the yaw instability of the Shuttle upon entry, significant mode mixing and is very propellant-consuming. Do not use in orbit and only activate at the entry interface once the shuttle has the correct attitude! During entry, the DAP will gradually transfer control to the 'Aerodynamical' DAP - at qbar of 10 lb/sqft the roll axis, at 40 lb/sqft the pitch axis and at around Mach 3.5 the yaw axis.

; Aerojet
: The Aerojet DAP is close to the real entry DAP used by the Shuttle. Its RCS part works similar to RCS ROT ENTRY, but control is not transferred to to the Aerodynamical DAP but to the atmosphere part of Aerojet (see below) which employs the same rate control routines as the RCS part. The scheme also supports an automatic AoA control scheme in which the pilot only has to manage the roll axis during entry, which makes this the most easy to fly DAP for entry and atmospheric flight.

For precision control, the keyboard is a more suitable input device than a joystick or a mouse since exact nulling of rates is somewhat easier with keystrokes.

==== Orbital DAP configuration ====

As of November 2015, the Shuttle's orbital DAPs are configurable using the SPEC 20 utility. This allows to set characteristics such as the roll rates achieved for a given controller movement, deadbands for attitude and rate holding as well as to switch the nose / aft RCS pods selectively off to conserve propellant.

[[File:Dap_config_spec_20.jpg|600px|thumb|none|DAP utility display of the Space Shuttle]]

Note that the DAP characteristics configuration allows to specify unstable or ineffective use of the RCS, thus changes should be entered with care.

==== Key mapping for RCS rotation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Roll left
|-
|{{Key press|6}}
|Roll right
|-
|{{Key press|2}}
|Pitch up
|-
|{{Key press|8}}
|Pitch down
|-
|{{Key press|[}}
|Yaw left
|-
|{{Key press|]}}
|Yaw right
|-
|{{Key press|5}}
|Cut thrust
|}

==== Key mapping for RCS translation DAP ====

{| class="keytable"
! Key
! Function
|-
|{{Key press|4}}
|Left
|-
|{{Key press|6}}
|Right
|-
|{{Key press|2}}
|Down
|-
|{{Key press|8}}
|Up
|-
|{{Key press|[}}
|Backward
|-
|{{Key press|]}}
|Forward
|-
|{{Key press|5}}
|Cut thrust
|}
.

=== Spacewalk ===

The Shuttle version as of May 2015 contains a 'proof of concept' spacewalk view designated 'EVA'. This is intended to simulate the view of an astronaut using a MMU. In the EVA view, use {{Key press|Shift|E}} to initiate spacewalk. The stick then controls the MMU thrusters and {{Key press|m}} is used to switch between the translational and rotational modes of the MMU.

Before spacewalk is initiated, the yaw, pitch and roll rates of the Shuttle need to be nulled (since control inputs during spacewalk refer to the MMU, the Shuttle also can't be controlled from this view).

Once outside, the MMU can be used to float around the Shuttle, or to inspect co-orbiting objects. However, note that it is impossible to leave the EVA view unless the astronaut maneuvers back to the airlock. Currently it is not possible to see spacewalk from outside, nor can the view direction be adjusted - in a future implementation, spacewalk will be improved using the FG walker functionality.

== Aerodynamics of the Space Shuttle Orbiter ==

The conditions encountered by the Space Shuttle span a wide range from a thin, rarefied atmosphere at Mach 27 to a sea level atmosphere flown at about Mach 0.6. Over this range of conditions, the handling characteristics change quite dramatically.

Somewhat simplified, one can divide the atmospheric entry in three phases - an initial near-ballistic entry phase in which airfoils are essentially useless, an aerodynamical entry phase in which the Shuttle is controlled by airfoils and aerodynamical forces are very noticeable on the trajectory, but in which the flight dynamics is completely different from that of an airplane and the final approach and landing phase during which the Shuttle is flown like an aircraft.

[[File:Shuttle-landing04.jpg|800px|thumbnail|none|Early near-ballistic entry phase]]<br />
<br />
[[File:Glowing red 2.jpg|800px]]

During these phases, control is passed from RCS jets to the airfoils - the inboard and outboard elevons at the trailing wing edges and the rudder/speedbrake at the tail stabilizer fin. The elevons can be deflected from -40 to 25 degrees, the rudder from -25 to +25 degrees. At a qbar of 10 lb/sqf roll control is taken over by the airfoils, at 40 lb/sqf pitch control is managed by airfoils and below Mach 3.5 finally yaw control is transferred, at which point the airplane-like phase of the entry starts. In addition to the primary airfoils, the Shuttle is equipped with a body flap which can be used to adjust trim.

During the first two phases, the Shuttle is flown with a high AoA (initially 40 degrees) to create a detatched bow shockwave which keeps the heat of atmospheric entry away from the fuselage. The characteristic hallmark of this attitude is that the stabilizer fin is shadowed by the wings - this renders the rudder ineffective above Mach 6 and makes the Shuttle yaw unstable against sideslip above Mach 2, i.e. any sideslip must be very accurately controlled by the FCS during entry or the Shuttle will tumble uncontrolled. This can not be done by the rudder, thus yaw jets remain crucial for controlling the Shuttle down to Mach 3.5.

Another effect is that the elevons deflected upward are in the lee of the wings, significantly reducing their effectivity as compared to downward deflections. However, in the entry regime, operating the elevons upward is more advantageous due to heating constraints.

=== Lift / Drag ===

Despite being designed for a gliding approach and landing, the Shuttle is not actually a very good glider - even close to approach, the glide ratio (i.e. L/D) reaches about 4.5, much less than most normal planes would have.

[[File:L-D-mach.gif|‎500px|thumbnail|none|Lift to drag as a function of AoA for different Mach numbers]]

The maximum of L/D varies somewhat with Mach number, however for hypersonic flight thermal constraints force a high AoA and aerodynamical efficiency is a secondary concern. Only in the supersonic to subsonic phase is the Shuttle flown close to its optimum glide ratio.

Due to the Delta-wing design, L/D has no pronounced stall even at high AoA in any region. However, the need to have sufficient lift despite the relatively poor aerodynamics forces a high touchdown speed of about 200 kt.

=== Longitudinal Dynamics ===

In the near-ballistic entry phase, pitch is controlled by an attitude-hold mode of the RCS, however elevons are automatically trimmed by the FCS to negative (upward) deflections to take some of the load early on to conserve propellant.

The pitching moment induced by the control surface varies dramatically as function of Mach number.

[[File:Control response.gif|500px|thumbnail|none|Pitching CM moment]]

As seen from the figure, at high Mach numbers the response is fairly flat (i.e. large elevon deflections are needed to control the Shuttle) and also non-linear (upward deflections cause much less pitching moment than downward deflection). In contrast, at low Mach numbers small elevon deflections already cause large moments and the response is almost linear. In all regimes, the pitching moment is normal force (i.e. AoA) dependent.

Since the elevons supply both pitching and roll control, at high hypersonic Mach numbers roll controls are close to being saturated with elevons deflected near full up. To open up better roll control, below Mach 10 the speedbrake is opened to provide a pitching moment relieving the elevons, and the Shuttle's body flap can also be trimmed upward.

=== Lateral stability ===

As mentioned above, during most of the entry phase, the Space Shuttle has no rudder action and the yawing moment as a function of sideslip angle beta is negative, indicating instability. This means that the FCS has to manage yaw stability by commanding yaw thrusters to maintain near zero beta, which is increasingly more challenging as the Shuttle penetrates deeper into the atmosphere and aerodynamical forces grow while thrust is reduced as compared to nominal vacuum values. This implies that a sizable amount of RCS propellant (about 1/3 of the capacity to be on the safe side) needs to be available before atmospheric entry.

Below approximately Mach 6, the rudder starts to contribute to yaw stability and from Mach 3.5 down to Mach 2 where the yawing moment finally becomes positive only the rudder is used. The roll behavior of the orbiter before any FCS is somewhat skittish as the roll moment as a function of roll rate is not a large damping term over most of the Mach range. The FCS of the Shuttle in FG therefore does not place yaw and roll axis directly under pilot control. The rudder is always commanded to minimize beta and no pilot input for the rudder should be needed or used unless sideslip is explicitly desired. The elevons are commanded to provide a simple roll damper to make control smoother.

The real Shuttle has in addition a '''NO Y JET''' mode to stabilize the orbiter during entry in which the elevons are used to control yaw. This leads to significantly reduced roll control since roll then needs to be driven by adverse yaw till the rudder picks up sufficient airflow. This mode has been implemented since dev version of july 2017.

=== A note on thruster efficiency in the atmosphere ===

Thrusters used in the hypersonic rarefied airflow of the upper atmosphere do not only cause the yaw, pitch and roll moment by the thrust acting at a certain distance to the CoG, but also are subject to plume impingement on the orbiter fuselage and interactions with the air flow field.

While impingement generically degrades the effectivity, the interaction moment can somewhat counter-intuitively act both directions. In particular the yaw moment is increased by the airflow, helping to stabilize the Shuttle.

As of May 2015, none of these effects is modeled in Flightgear.

=== Control cross couplings ===

The Shuttle has significant cross couplings between the elevon deflection in pitch and roll mode and the rudder as a function of Mach number, all of which are faithfully modeled in FG. One of the main effects is that upward elevon deflection alters the airflow at the aft fuselage, creating additional suction effects which alter aerodynamical forces.

In particular, at supersonic speeds yaw stability is somewhat improved at high upward elevon deflection while the effect reverses at subsonic speeds. At the same time, roll control is significantly reduced at full elevon deflection, with the effect being more pronounced at low than at high Mach numbers.

Control surface effectiveness in general drops with increasing Mach number, however the speed at which this happens is different for elevons and rudder.

=== Aerodynamical DAP schemes ===

There are two different control schemes available for the aerodynamical part of the Shuttle's flight - one of them based on the real Shuttle DAP, the other educational.

; Aerojet
: The Aerojet DAP is closest to what the real Shuttle uses. It is a scheme in which the stick commands pitch and roll rates and stick in neutral position commands attitude hold. Above Mach 3.5, in addition an automatic pitch control mode can be activated which maintains the scheduled safe entry AoA. Flying the Shuttle is very easy in this mode - there is no operational need to use trim or rudder and response to control input is crisp and precise. During entry, Aerojet can manage even agressive roll reversals inside the stable region.

; Aerodynamical
: This is an educational mode in which the Shuttle is flown similar to an airplane, i.e. the stick basically controls the airfoil positions, and in order to achieve level flight with stick neutral, trim has to be used. Since the Shuttle is yaw-unstable at high Mach numbers, this mode still has automatic stability augmentation, i.e. rudder and ailerons are commanded automatically to minimize sideslip. Entry can be flown with this mode starting in-orbit with '''RCS ROT ENTRY''' and illustrates the amount of work the rate controller has to do as well as gives a hands-on feeling for hypersonic aerodynamics. This however is somewhat challenging and it is possible to maneuver the Shuttle outside its stability envelope using too agressive maneuvers. Once below Mach 5, the Shuttle responds well and stable to direct aerodynamical control.

=== Entry and touchdown structural and aerodynamical limits ===

The following structural and aerodynamical limits need to be observed during entry and landing:

* Dynamical pressure qbar < 375 lb/sqf (modeled)

This is a structural limit for the orbiter and the airfoils, beyond this the actuators can no longer move the airfoils, leading to a loss of control. In nominal operations the orbiter should be kept below 250 lb/sqf.

* Peak temperature < 2900 F (modeled)

This is the approximate limit beyond which the thermal protection system fails, with subsequent structural failure of the overheated airframe and loss of the orbiter.

* gear extension speed < 312 KEAS (modeled)

Structural limit of the gear against aerodynamical forces.

* vertical speed upon touchdown < 9 ft/sec (modeled)

This is the structural limit of the main gear struts, and their destruction is fully modeled in 'realistic' mode.

* airspeed upon drag chute deployment < 230 kt (modeled)

The drag chute has a safety pin which disconnects the chute if the airspeed is higher than the stability limit. This is fully modeled.

* roll speed of tires < 230 kt (not modeled)

This is the certified maximal speed at which the tires don't blow.

* derotation speed < 2 deg/s (modeled)

This is the structural limit for the nose gear strut, and nose gear breakage is fully modeled.

* AoA < 15 deg on touchdown (modeled)

Beyond this angle, the body flap and tail structure of the orbiter touch the ground before the main gear does.

[[File:Fin.jpg|800px|thumbnail|none|Touchdown and drag chute deployed]]

== Systems ==

Most of the Shuttle's systems are designed around the philosophy that failure of any one component should allow the mission to continue and failure of two components should still allow a safe return to Earth. As a result, most systems exist triple, and the loss of one subsystem is not normally felt when operating the Shuttle, only a loss of two subsystems requires to take special action and compromises the maneuverability of the vehicle.

In the real Shuttle, many system switches have a 'GPC' (general purpose computer) setting in which the computer controls a system automatically and an 'on' setting in which the system is manually controlled. In FG, the system control is a bit simplified as no GPC or mission control is simulated and not all existing sensor readings are simulated which would be necessary for manual control. Often 'GPC' and 'on' are merged into one setting for which, dependent on system, either the user has to always control a system manually or a control routine is activated and no manual control is possible.

=== Electric Power Generation ===

Electricity aboard the Shuttle is generated by three fuel cells (FCs) which produce electricity utilizing the reaction of cryogenic hydrogen and oxygen into water (which is then used in the environment system). Each fuel cell can supply about 12 kW of power, which means plenty of redundancy given the normal power consumption of the orbiter is about 14 kW.

The fuel cells normally circulate hydrogen and oxygen in a closed loop to avoid losses, however they have to be periodically purged (reaction products vented into space) to avoid their effectivity to decrease by contamination.

As of June 2015, the power generation as well as the coarse power balance of the orbiter is modeled (i.e. switching components on which use electricity will have to be supplied by the running FCs), however not all the details of the electrical distribution system or the reactant feed lines are done. In normal operation, the electrical power system should require very little crew intervention.

=== Auxiliary Power Unit and Hydraulics System ===

Thrust vector control of the SSMEs during ascent, movement of the various aerosurfaces, deployment of the landing gear and brakes/nose wheel steering all rely on hydraulic pressure to operate.

The Space Shuttle is equipped with three independent hydraulics systems, each of them powered by an Auxiliary Power Unit (APU), a turbine utilizing hydrazine as propellant. Under normal load conditions, each APU utilized about 3 - 3.5 lb of propellant per minute. With a hydrazine load of 332 lb, this means the system can be operated for about 90 minutes under nominal conditions or be run in a power-saving mode for 110 minutes during an once around abort. This means that the APUs have to be switched off when not used - they are powered down as part of the post-MECO operations and powered up as part of the atmospheric entry preparations.

As compared to the rest of the Shuttle's systems, the APU turbines with with 180 kW power each generate a lot of waste heat which ends up warming the hydraulic fluid and the lube oil. The APUs are operated at a temperature of over 390 K (250 F) though, so for an APU cold start it takes a bit more than 10 minutes to reach that temperature. Afterwards, the water spray boiler systems have to be used to cool hydraulic fluid and lube oil - they are supplied by three water tanks containing 142 lb of water each and can spray up to 10 lb / minute for cooling purpose. Overheating APUs can not be run for more than 2-3 minutes before they fail.

When not in use, electrically powered hydraulic circulation pumps keep the hydraulic fluid moving such as to equalize temperatures in the components.

In case of a hydraulic failure, Priority Rate Limiting (PRL) for the airfoils is used to allocate the remaining power as efficiently as possible. Usually the elevons move with 20 deg/s and the rudder with 14 deg/s, however in the case of multiple hydraulic failures, these numbers are reduced to 13.9 deg/s for elevons and 7 deg/s for the rudder. The orbiter is still fully controllable in this case, but not as responsive to agressive maneuvers.

As of June 2015, the APU and hydraulic system is modeled with a fair amount of detail and operated from a dedicated menu. APUs need to be started as part of the pre-launch checklist - refer to Help/Aircraft Checklists for the detailed procedure. '''If the hydraulic system is not available during ascent, this will result in loss of the vehicle after SRB separation as there is no control over the Shuttle if the SSMEs can not be gimbaled.''' Also PRL for all airfoils is fully supported.

Operation of the water spray boilers is realistically integrated into the heat transfer model of the Shuttle (see below), including the failure of overheating APUs.

=== Active Thermal Control System ===

In orbit, the Shuttle's systems use on average about 14 kW of power, which eventually ends up heating the interior of the pressure vessel. Active cooling systems carry the heat load away and radiate it into space. A water coolant loop system takes care of the avionics bays and the cabin and exchanges heat with a two loop freon coolant system which also cools systems elsewhere in the Shuttle. The freon is circulated through the radiator panels located on the inside of the payload bay doors and dumps a maximum of about 18.000 W of heat into space.

If the payload bay doors are closed (such as during ascent or entry), the freon loop can be cooled by flash evaporators which utilize quickly evaporating water sprayed on the freon tubes as coolant. To provide the cooling performance of the radiator, this system uses about 66 lb of water per hour, i.e. can only be a temporary measure as the water storage aboard would be quickly depleted otherwise.

The heat balance in space is also influenced by the orientation of the Shuttle relative to the Sun and Earth - sunward facing surfaces tend to heat up to 350 K whereas shaded surfaces may cool down to 150 K. To ensure ice-free thruster and other exhausts, electrical heating elements may therefore be needed.

Orbiter heat management often combines cooling systems and attitude - for instance placing the OV into a tail to Sun inertial attitude minimizes incident heat and allows to cool the freon down so that it can act as a heat sink for about 15 minutes even without the radiator deployed, a technique known as 'cold soak'. Similarly, orienting the payload bay towards Earth ensures that even during the night, temperatures don't drop too much so that EVA work is possible. Temperatures can be equalized across the Shuttle by slowly rotating the spacecraft.

As of June 2015, the FG Shuttle includes a fairly sophisticated simulation of the heat balance, including incident heat flux from Sun and Earth dependent on surface normal and albedo, internally generated heat in the avionics bays, heat transport via conduction and via the cooling loops, radiated heat from the surfaces the action of the flash evaporators and the radiator. Most real heat-management techniques, including cold soak and slow rotations, are fully supported.

[[File:Shuttle coldsoak.jpg|600px|thumbnail|none|Cold-soaking the Shuttle's freon loops in preparation for de-orbit.]]

Thermal inertia of the Orbiter is generically high - temperatures adjust at timescales of hours rather than minutes to their equilibrium values. For educational purposes, it is possible to choose simulation options which speed up the approach to thermal equilibrium by a factor or 10 or 100 respectively - this will result in an almost immediate response of the temperature distribution to e.g. changes in attitude. These options should be used with care.

=== Main Propulsion System ===

Under the name Main Propulsion System (MPS), the various subsystems operating the SSMEs are summarized. This includes the SSME controllers (two per engine for redundancy), the propellant feeding system supplying liquid hydrogen and oxygen to the engines and the various hydraulically operated valves, a helium system to supply purge gas flows and emergency hydraulics power and finally the engines themselves.

The SSME's feed high-pressure propellants into the combustion chamber. Power for the turbo pumps is provided by partial pre-combustion of the propellant, and ullage pressure in the external tank is maintained by branching off a small fraction of vaporized propellant back into the tank. The precise opening of the propellant feeding valves which throttles the engines is governed by the controllers which in turn receive throttle commands from the Shuttle's guidance computers.

For the most part, the MPS settings are controlled on the ground prior to launch and not changed during ascent, however after MECO there are about 5,200 lb of propellant trapped in the feeding manifolds which need to be dumped. During this propellant dump, high-pressure helium is used to vent liquid oxygen through the thruster exhausts while hydrogen is allowed to boil off through the fill/drain valves.

In case of a hydraulic failure, the SSMEs can neither be gimbaled nor can their valves be changed. Each of the three hydraulic systems operated the valves of one engine, and each engine gimbal is supported by two hydraulic systems (i.e. it takes two failures to disable gimbal on one engine, but each hydraulic failure will disable valves on one engine).

If the valve settings can no longer be changed, the engine can still continue to run, but it can't be throttled any more, a condition known as 'hydraulic lockup'. It is still possible to shut down such an engine using pressure from the helium system though. Similarly, if sensors monitoring combustion chamber conditions or the command path from guidance computer to engine controllers fail, the engine is in a condition called 'electric lockup' - the controller will continue to operate it with the last known settings. Locked-up engines usually need to be shut down manually using the cutoff switches about 30 seconds prior to nominal MECO.

As of June 2015, the MPS is modeled in a good amount of detail, including most of the relevant valve settings, hydraulic and electric lockup, power failures on the engine controllers and the propellant dump sequence. The in-sim checklists provide instructions on how to execute the propellant dump and how to safe the engines for orbital operations.

=== Mechanical Systems ===

The Shuttle uses electromechanical actuators to move components which do not require hydraulic power. This includes the ET umbilical doors and the payload bay door. Each actuator contains two separate motors for redundancy, and transition time for any motion doubles if a motor is non-functional. The movement of these components is not time-critical, and hence usually slow - the complete payload bay door opening sequence takes about four minutes at normal speed to execute, twice that for actuator failures.

The ET umbilical doors are open at launch to allow the oxidizer and fuel feedlines to enter the orbiter, and they need to be closed after reaching orbit for the thermal protection during entry to be efficient. The payload bay doors are closed during ascent and entry and only opened in orbit. This is crucial, as the freon cooling loop radiators are located on the inside of the payload bay doors, i.e. the Shuttle can not remain indefinitely in orbit without opening the payload bay.

Opening or closing mechanical components usually involves unlatching, moving and possibly re-latching the components.

As of June 2015, the normal operation of ET umbilical door and payload bay door is implemented, but no actuator failures. The sequences can be driven from the GUI in automatic mode, but there is in principle support to drive them in manual mode as well as described in the Shuttle Crew Operations Manual.

Note that there's cross talk between mechanical systems and thermal modeling - tension building in the Shuttle due to uneven heating of the left and right fuselage can prevent the payload bay doors from opening or closing for instance.

== Guidance systems ==

=== Automated flight ===

Automated flight is available for all nominal mission phases except for the final approach and touchdown (for which in reality no AP is available either) as well as all single engine loss intact ascent aborts and all two engine out contingency aborts ending in either emergency landing or crew bailout.

Unlike an airplane which is usually in or close to a steady-state equilibrium (level flight at cruise altitude) when under AP control, this is almost never the case for the Shuttle. Thus, the AP requires a context to work properly - whether a current state vector is good or bad depends on what one wants to achieve. Usually this context is a guidance target (i.e. a desired orbit, a landing site, an abort MECO condition,...) and if no such target is provided, the AP will not engage.

If there is a valid guidance target, the PFD will display error needles even if the AP is disengaged which reflect what the AP would try to do in the current situation which can be used for manual piloting. The AP can be used separately in the pitch and yaw/roll axis and independently for throttle/speedbrake control.

Once disengaged, it is as a rule not wise to re-engage the AP if the Shuttle has deviated too much from the intended state. Many AP stages are based on closed loop guidance and will try to steer back to the desired solution, however this may not be possible.

Also, automated flight does not mean the pilot can lean back and the Shuttle will handle all aborts on its own - some AP modes specifically need to be engaged or augmented by DPS options to properly work - see the Crew Operations Manual for detailed instructions. In particular, if in an emergency the wrong AP mode is engaged, the Shuttle may try to solve a kinematically impossible maneuver which usually results in loss of control.

Finally, do not expect miracles from the AP. It will usually save the orbiter even after the loss of two engines, but it may not always on its own find a viable solution to a landing site in an abort scenario. In general, automated flight is much better at manging the instantaneous state (holding an alpha schedule, aiming at a waypoint) than at longer-term planning (managing gliding range after an abort,...).

Different from the powered and gliding phase, the orbital DAP contains automatic routines for attitude management - pointing the Shuttle, tracking a location or a celestial object or automated OMS burn maneuvers.

Operating the Shuttle AP properly is very different from operating airplane APs and requires a profound knowledge of OPS sequences and major mode transitions as well as strict adherence to the published procedures.

=== Ascent guidance Powered Explicit Guidance (PEG) ===

{{note|Full explanations about the Ascent guidance might be found there: [[Shuttle guidance - Ascent guidance Powered Explicit Guidance (PEG)]]}}

The purpose of this section is to present and discuss about the second stage ascent guidance (post SRB sep) for Nominal Orbital Insertion, and some Intact Aborts (TAL / AOA / ATO).
The guidance is based on the real closed loop used in the Shuttle, known as Power Explicit Guidance https://www.orbiterwiki.org/wiki/Powered_Explicit_Guidance.

'''Documentations'''

*A very detailled and complete topic about the guidance by Noiredd who implemented it in Matlab and KSP: https://github.com/Noiredd/PEGAS-MATLAB/blob/master/docs/upfg.md
*A deeper document with nice schematic drawings: Ascent Guidance Navigation and Control Shuttle Workbook (page 111) https://www.google.com/search?client=firefox-b-d&q=ascent+guidance+workbook+shuttle
*Original formulation of the Unified Power Explicit Guidance with equations and algorithms: ''ntrs.nasa.gov/citations/19740004402''
*A paper about enhancements made over the years to the original ascent guidance: ''ntrs.nasa.gov/citations/20180002035''

'''Overview'''

Second stage guidance functions very differently from first stage guidance in that second stage guidance is closed loop. Second stage guidance computes the control variables (essentially commanded attitude and attitude rates) and burn time to go (TGO) in such a way that the vehicle flies from the current state to the prescribed target conditions (altitude, velocity, flight path angle, and orbit plane) within trajectory constraints. It solves this two point boundary value problem each cycle (every 1.92 seconds). One limitation of second stage guidance is that it doesn't calculate if there is enough propellant to reach the desired MECO conditions.
[[File:PEG Meco target.webp|400px|thumbnail|none]]

The powered explicit guidance (PEG) scheme used by second stage guidance nominally operates in two phases. The first phase computes throttle and attitude commands based on three SSMEs and a constant thrust requirement until an acceleration of 3g is reached. At that time, the second phase, which uses variable throttle to maintain a constant acceleration, is entered. If an engine failure is detected, a third phase of PEG, which computes the necessary guidance commands using constant thrust to aim for the desired targets using two SSMEs, is entered (assuming no RTLS or TAL abort).

During current shuttle operations, only two phases of PEG are used, constant thrust through 3g and then variable thrust through main engine cutoff (MECO). STS-1 and STS-26, in order to prevent or reduce abort gaps, flew higher than normal trajectories, called lofted or abort shaped. This method required the third PEG phase, which ran from SRB sep to T_FAIL (I-loaded MET) and achieved lofting by assuming that an engine would fail causing loss of performance at the time T_FAIL. When T_FAIL occurred, PEG stopped assuming that an engine would fail. A drawback with this method was discovered later, however. The lofted trajectories caused “black zones,” or regions where an unsurvivable entry/pullout condition would be created if two engines actually did fail (CA). For this reason and the fact that abort shaping costs thousands of pounds of nominal ascent performance (payload), the I-load, T_FAIL is now set to zero, and lofted trajectories are not currently planned.
[[File:PEG step.webp|600px|thumbnail|none]]

Second stage guidance performs yaw steering to achieve the desired orbit plane. The desired orbit plane is defined by the unitized negative angular momentum vector (I-loads), commonly referred to as the '''IY vector'''. The x and y components of the IY vector define the nodal crossing, while the z component defines the inclination. For missions which do not involve rendezvous with a vehicle already in orbit (referred to as the “target”), the IYs are defined during the flight design process approximately 6 months prior to launch. These missions employ “earth fixed” yaw steering since the trajectory relative to the earth remains the same regardless of launch time. In order to successfully launch into orbit and rendezvous with another vehicle already in space, the orbiter must end up in the same orbital plane and altitude as the other vehicle.
[[File:PEG insertion.webp|600px|thumbnail|none]]

Forty seconds prior to MECO, guidance no longer seeks to achieve the altitude and orbital plane position targets. Common terminology is, “at MECO minus 40 seconds, the position constraints are released.” Without this constraint release, when TGO becomes small, a small change in position error would produce large changes in the thrust turning rate vector and over controlling would result. Note also that the cutoff time (TGO) calculation includes the predicted velocity change from the time minimum throttle is commanded to burnout. This corresponds to the predicted tailoff impulse from each active SSME and is known as fine count. Fine count occurs 10 seconds prior to MECO for nominal ascent, ATO, and TAL and 6 seconds prior to powered pitchdown for RTLS. It is at fine count where second stage, closed loop guidance is terminated and the SSMEs are commanded to a lower power level, usually 67% for three engines running or 91% for one or two engines running (note that the SSMEs aren't throttled back until powered pitchdown during an RTLS). Thereafter, the flight path angle constraint is released, such that TGO is computed solely on the desired velocity change (VGO). When guidance sees the shuttle at the correct inertial velocity (VI), all SSMEs are commanded to shut down.

=== Entry guidance algorithm ===

{{note|Full explanations about Entry shuttle guidance might be found there: [[Shuttle guidance - Entry guidance algorithm]]}}

A topic speaking about the entry guidance algorithm.

'''Documentations'''

I didnt use hyperlinks to avoid NASA ntrs server spam from forum robots

*A quick overview of the Descent guidance from the Space Shuttle Technical Conference: ''ntrs.nasa.gov/citations/19850008593''
*A deeper look into the Entry equations formalism with that paper that you might find under: ''Shuttle Entry Guidance JSC-14694 ''
*Entry guidance formulation requirements (code): ''ntrs.nasa.gov/citations/19800016873''

All the documentations linked in the Entry/TAEM rework are even more useful now, as almost all the parts of Entry guidance are simulated and displayed parameters fed with consistent datas.
https://forum.flightgear.org/viewtopic.php?f=87&t=38777

=== TAEM/Approach guidance algorithm ===

{{note|Full explanations about TAEM and Approach/Autoland guidance might be found there: [[Shuttle guidance - TAEM/Approach and Autoland guidance]]}}

This section speaks about TAEM and Autoland guidance.

'''Documentations'''

*Space Shuttle TAEM guidance code sum up: [https://ntrs.nasa.gov/citations/19920010688]
*TAEM/Approach Handbooks there: [https://forum.flightgear.org/viewtopic.php?f=87&t=38777]

'''Overview'''

The last link mentionned above is pretty interesting to see the evolution of TAEM guidance and how it was handled.
The main document I used include the Optional TAEM Targeting (OTT) logic that has been used since STS-5 (before the HAC was a circle with less Energy options for test flights).

After STS-5, HAC could be flown with the different options we are used to see .
Overhead or Straight-In HAC; and Nominal Entry Point (7Nm in final) or Minimal Entry Point (4Nm in final)
[[File:OTT option.webp|600px|thumbnail|none]]

Another option called - final radius shrinking - is included in that TAEM guidance version.
It allows the final HAC radius (2.3 Nm) to decrease up to 0.8 Nm if we are low during the HAC.
[[File:Spiral hac.webp|600px|thumbnail|none]]

The whole logic is organized through several functions that are called during all the TAEM phase at a rate between 160 and 980ms.
It ends at 10000 feet (Approach and Landing interface) where the Auto Land logic kicks in (quite the same logic with tighter gains).
[[File:TAEM flow logic.webp|600px|thumbnail|none]]

Let's go briefly through each functions.
The first function that is not mentionned is a frame coordinate converter from a Greenwhich frame into a runway centered frame.
[[File:TAEM runway coordinate system.webp|600px|thumbnail|none]]

== Avionics and DPS ==

The avionics of the Space Shuttle is fairly faithfully reproduced by the simulation, see the dedicated article on [[Space Shuttle Avionics]] for an overview. The implemented screens include routines to monitor the various systems as well as guidance navigation and control for all mission stages.

[[File:GNC_sys_summ_up_2.jpg|600px|thumbnail|none|GNC SYS SUMM 2 display of the Space Shuttle]]

All nine MDUs of the forward panel are usable and display the DPS and MEDS screens of the Shuttle - this includes launch and entry guidance routines, TAEM guidancs as well as orbital tracking and pointing management. In addition, HUDs for Commander and Pilot are provided.

[[File:Shuttle_cockpit_OPS_2_day.jpg|1000px|thumbnail|none|Space Shuttle cockpit Day]] [[File:Shuttle_cockpit_before_launch.jpg|1000px|thumbnail|none|Space Shuttle cockpit Night]]

An alternative display for all phases of flight is provided by the FG-native the HUD. This has four different modes - ascent, orbit, entry and approach, and dependent on the HUD mode, different information relevant for the mission phase is displayed. In all cases, the current CSS DAP is identified in the upper left.

There is a calculator for orbital elements available, determining perigee and apogee, orbital inclination and longitude of the ascending node (the latter is currently not so useful as it is obtained in an inertial coordinate system). Based on these orbital elements, the groundtrack map displays current position of the Space Shuttle, selected landing site, ground track history and a prediction of the future orbit - if the perigee is below the surface of Earth, the prediction ends at the estimated ballistic impact point (note that due to the aerodynamical capabilities of the Shuttle, the actual landing site can be within a cross range of about 1000 miles around that point dependent on how the trajectory is managed during the entry phase).

== Payload handling ==

The Space Shuttle is equipped with the capability to release payload from the bay into space, or to catch a payload from space and deposit and secure it in the bay. For this, the Remote Manipulator System (RMS) arm in combination with the payload retention system is used.

[[File:Hubble docked.jpg|600px|thumbnail|none|Handling a payload with the RMS arm]]
[[File:Hubble COAS.jpg|600px|thumbnail|none|Hubble through COAS system]]
[[File:Hubble_grapple.png|600px|thumbnail|none|Handling Hubble with the RMS arm]]

=== RMS arm operation ===

The RMS arm is a fairly complicated device with six different joints, each allowing rotation along one specific axis, which is formed after the human arm. The nomenclature is borrowed from this analogy, so there is a shoulder yaw, a shoulder pitch, an elbow pitch, a wrist pitch and wrist yaw and roll joints. Each of the joints can only be moved a certain angular range. At the end of the RMS arm is the end effector which is the device which can attach to a payload.

The RMS arm can be driven in various modes. The simplest of these are the single joint or the direct mode in which each joint angle is controlled separately, i.e. the arm is extended by first selecting a joint, then commanding it to either increase or decrease angle, before the next joint is selected.

Since this is cumbersome, the more natural control modes allow to use the stick (or whatever control device is attached) to directly move a reference point. In the ORB UL x/y/z mode (UL stands for 'unloaded') the reference point is the tip of the end effector, i.e. using the stick just moves the joint angles such that the end effector moves along the x, y, or z-axis and otherwise keeps its attitude. The ORB UL yaw/pitch/roll mode in contrast keeps the end effector's position and just changes its attitude.

The real Shuttle has additional modes in which the reference point is in the center of the payload, or in which the reference coordinate system is changed from the Shuttle's coordinate system to a system co-moving with the end effector camera - these are as of August 2015 not implemented in FG.

All modes except single and direct joint driving have software safety stops when the joints approach their limit extensions. Since in its stowed position, two of the joints are in the software stop region, it is necessary to directly drive shoulder pitch and elbow pitch out of their soft stop region to be able to use the more sophisticated control modes - see the diagram below for the reach angles of each joint.

[[File:Joints.gif|600px|thumbnail|none|RMS arm reference coordinate system and joint reach angles]]

Finally, the RMS arm is secured by a shoulder brace to make it cope with launch acceleration. This brace needs to be removed before the arm can be operated, and the arm itself needs to be powered, deployed and unlatched.

=== Payload retention system ===

The payload retention system is a series of latches which hold a payload in the bay. Before a payload can be lifted out of the bay, these latches need to be released. Similarly, if a payload is returned into the bay, ready-to-latch indicators show when it has reached the correct stowing position and it can only be safely released from the RMS arm once the latches are closed.

The real Shuttle has three different payload positions with corresponding latch controls, as of August 2015 only one payload position is supported in FG. Likewise, currently only a simple demo satellite with no proper folding/unfolding animation is available as visual payload (note that a payload mass affecting the FDM can also be chosen in the 'Fuel and Payload' dropdown menu).

== Mission phases ==

The various phases of a Shuttle mission are generically subdivided into launch, orbit, entry, TAEM and approach. These can directly be accessed by appending the mission phase to the command line. This will automatically start the Shuttle in the correct configuration and the correct state for the mission selected. For instance, --aircraft=SpaceShuttle-TAEM --airport=KVBG will initialize a TAEM approach into Vandenberg, --aircraft=SpaceShuttle-orbit --lat=30.0 --lon=0.0 --heading=90.0 will initialize the Shuttle in a 30 deg inclination orbit.

Note that --aircraft=SpaceShuttle-entry combined with an airport as location will ''not'' initialize you on an entry trajectory to that airport since the entry interface is several thousand miles away from the landing site and moreover the trajectory needed is not unique but depends on what you fly - you need to initialize the entry interface location by hand using latitude and longitude.

Specific information on the mission phases can be found in the following articles:

=== Documentations ===

[[Flying the Shuttle - Space Shuttle Checklists]]

=== Nominal Operations ===

[[Flying the Shuttle - Launch]]

[[Flying the Shuttle - Orbital Operations]]

[[Flying the Shuttle - Entry]]

[[Flying the Shuttle - Final Approach]]

=== Nominal Operations Advanced Tutorial ===

[[Flying the Shuttle - Launch And Post Insertion Advanced]]

[[Flying the Shuttle - Deorbit Preparation Advanced]]

[[Flying the Shuttle - Deorbit Burn and Final Entry Preparation Advanced]]

[[Flying the Shuttle - Entry TAEM and Landing Advanced]]

=== Intact Aborts ===

[[Flying the Shuttle - Intact Abort Procedures Overview]]

[[Flying the Shuttle - Return To Launch Site RTLS]]

[[Flying the Shuttle - Transoceanic Abort Landing TAL]]

== Glossary of acronyms ==
{|
| '''AoA''' || Angle of Attack
|-
| '''APU''' || Auxiliary Power Unit
|-
| '''CoG''' || Center of Gravity
|-
| '''CSS''' || Control stick steering
|-
| '''DAP''' || Digital autopilot
|-
| '''ET''' || External tank
|-
| '''EVA''' || Extravehicular Activity (spacewalk)
|-
| '''FC''' || Fuel cell
|-
| '''FCS''' || Flight Control System
|-
| '''ISP''' || Specific impulse
|-
| '''MECO''' || Main Engine Cutoff
|-
| '''MMH''' || monomethylhydrazine (a propellant)
|-
| '''MMU''' || Manned Maneuvering Unit
|-
| '''MPS''' || Main Propulsion System
|-
| '''OV''' || Orbiter vehicle
|-
| '''OMS''' || Orbital Maneuvering System
|-
| '''PRL''' || Priority Rate Limiting
|-
| '''RCS''' || Reaction Control System
|-
| '''RHC''' || Rotational Hand Controller
|-
| '''RMS''' || Remote Manipulator System
|-
| '''SRB''' || Solid rocket booster
|-
| '''SSME''' || Space Shuttle main engine
|-
| '''TAEM''' || Terminal Area Energy Management
|-
| '''THC''' || Translational Hand Controller
|-
| '''TVC''' || Thrust Vector Control
|}

== Latest development snapshot ==
The latest development version (possibly unstable) is found in a dedicated [https://sourceforge.net/projects/fgspaceshuttledev/ repository] on SourceForge. You can download the latest snapshot from http://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tarball. Stable updates are pushed to FGAddon periodically.

== Documentation ==

In addition to the original NASA Shuttle Crew Operations Manual and the DPS dictionary which are found in the Documentation/ folder of the spacecraft, a Flight Manual specifically for the operation of the Flightgear simulation is available (standard edition free of charge for Flightgear users):

[[File:Flight manual standard.png|400px|link=http://www.science-and-fiction.org/bookstore.html|alt=Shuttle flight manual|Title Flight Manual]]

(click picture to download, or use this [https://web.archive.org/web/20250915000000*/http://www.science-and-fiction.org/downloads/flight_manual_basic.pdf.gz archived copy] if the original link is dead)

== Educational Links / Shuttle technical files ==

=== General Space knowledge and tutorials ===
''Basic of Space Flight Book''
https://er.jsc.nasa.gov/seh/spaceflt.pdf

''Thorsten LEO Tools''
https://forum.flightgear.org/viewtopic.php?f=87&t=35213

''Orbiter Space Sim Beginners tutorial''
https://www.youtube.com/watch?v=bOxpvqrqLAo

''FAA Space Basics ( Must read)''
https://web.archive.org/web/20210530202242/https://www.faa.gov/about/office_org/headquarters_offices/avs/offices/aam/cami/library/online_libraries/aerospace_medicine/tutorial/section3/spacecraft_design/

''Rendez Vous Theory''

https://www.baen.com/rendezvous and https://www.baen.com/rendezvous-part2

'''Educative links'''

Why the wings of the Shuttle Stay on it during Maximal Aerodynamical pressure phase
https://www.aiaa.org/docs/default-source/uploadedfiles/about-aiaa/history-and-heritage/why_the_wings_stay_on-ehrlich.pdf?sfvrsn=801c62b5_0

Space Shuttle Aerodynamics and Flight Dynamics Overview
https://web.archive.org/web/20210127120052/https://www.nasa.gov/centers/johnson/pdf/584730main_Wings-ch4d-pgs226-241.pdf

=== Space Shuttle Systems ===

'''Space Shuttle Systems in depth'''

''Nasa Space Shuttle systems Exhaustive Manual: SCOM''
https://web.archive.org/web/20200602210929/https://www.nasa.gov/centers/johnson/pdf/390651main_shuttle_crew_operations_manual.pdf

''Nasa Data processing system dictionnary, or "What does that page of my shuttle computer"''
https://web.archive.org/web/20210226022241/https://www.nasa.gov/centers/johnson/pdf/359895main_DPS_G_K_7.pdf

''Crew Software Interface ( Nice introduction to Shuttle Computer and handling)''
https://web.archive.org/web/20210226022249/https://www.nasa.gov/centers/johnson/pdf/383444main_crew_software_interface_21002.pdf

'''Workbooks ( Detailled part on some Shuttle systems and procedures, SCOM complement)'''

''APU (How Hydraulic is provided to Shuttle systems''
https://web.archive.org/web/20210226022251/https://www.nasa.gov/centers/johnson/pdf/383439main_apu_hyd_wsb_21002.pdf

''Air Data Systems (What are the equivalent of Pitot Tubes in the Shuttle)''
https://web.archive.org/web/20210226021921/https://www.nasa.gov/centers/johnson/pdf/383438main_air_data_system_workbook_21002.pdf

''Environmental Control and Life Support System ( How is cooled the Shuttle )''
https://web.archive.org/web/20210226004654/https://www.nasa.gov/centers/johnson/pdf/383445main_eclss_21002.pdf

''Navigation Aids ( or how the Shuttle find precisely the runway during entry)''
https://web.archive.org/web/20210226022247/https://www.nasa.gov/centers/johnson/pdf/383450main_navigation_aids_workbook%2021002.pdf

''Intact Ascent Aborts ( Procedures after ONE engine failure)''
https://web.archive.org/web/20210226022307/https://www.nasa.gov/centers/johnson/pdf/383447main_intact_ascent_aborts_workbook_21002.pdf

''Contigency Aborts Procedures after more than ONE engine failure/degradation''
https://web.archive.org/web/20210226011554/https://www.nasa.gov/centers/johnson/pdf/383441main_contingency_aborts_21007_31007.pdf

''And much more that are not publicly available but findable here after a subscription ( A true Space Gold Mine)''
https://www.nasaspaceflight.com/l2/

=== Space Shuttle Checklists ===
''Flight Data Files Bible Site''
https://web.archive.org/web/20211020173004/https://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html

''Annotated and condensed one''
[[Flying the Shuttle - Space Shuttle Checklists]]

A bit more organized:
More informations about Flight Data Files in SCOM part 3

'''Normal situation Checklists'''

''Ascent''
https://web.archive.org/web/20210406234707/https://www.nasa.gov/centers/johnson/pdf/567068main_ASC_135_F_1.pdf

''Post Insertion''
https://web.archive.org/web/20210417211853/https://www.nasa.gov/centers/johnson/pdf/567074main_PI_135_F.pdf

''On Orbit''
https://web.archive.org/web/20210417205430/https://www.nasa.gov/centers/johnson/pdf/567072main_ORB_OPS_135_F_1.pdf

''Rendez Vous''
https://web.archive.org/web/20210417202323/https://www.nasa.gov/centers/johnson/pdf/567076main_RNDZ_135_F.pdf

''Deorbit Preparation''
https://web.archive.org/web/20210424062634/https://www.nasa.gov/centers/johnson/pdf/492871main_D-O_G_Q_5.pdf

''Entry''

https://web.archive.org/web/20210424062633/https://www.nasa.gov/centers/johnson/pdf/381558main_ENT_G_H_8.pdf
https://web.archive.org/web/20210417204127/https://www.nasa.gov/centers/johnson/pdf/567069main_ENT_135_F.pdf

'''Non Normal situation Checklists'''
In the Normal situation Checks above, there are off nominal sections to deal with non critical procedures.

For time critical procedures that must be performed within 5 minutes, there are the so called Pocket checklists ( Ascent, Orbit and Entry).
They are almost the same.

''Ascent''
The Ascent PCL contains procedures that safe systems for continued flight. It also contains orbiter systems powerdown procedures.
https://web.archive.org/web/20210407003811/https://www.nasa.gov/centers/johnson/pdf/366508main_APCL_G_O_1.pdf

''Orbit''
At the initiation of the post insertion phase, the Orbit PCL is utilized. This PCL contains critical orbiter systems malfunction responses and powerdown procedures. The orbit PCL often refers to the orbiter Malfunction Procedures (MAL) Book for detailed troubleshooting.

https://web.archive.org/web/20210907221523/https://www.nasa.gov/centers/johnson/pdf/359853main_OPCL_G_M_10.pdf

Contigency Deorbit in case of Severe malfunctions in Orbit ( Loss of cooling systems, or massive elec failure,..) that would lead to a fast deorbit.

https://web.archive.org/web/20210417212721/https://www.nasa.gov/centers/johnson/pdf/359894main_C-DO_G_L_8_P%26I.pdf

''Entry''

The Entry PCL contains critical contingency systems malfunction responses that allow safe continuation of the pre-deorbit through early entry phases along with orbiter systems powerdown procedures.

https://web.archive.org/web/20210424062636/https://www.nasa.gov/centers/johnson/pdf/366509main_EPCL_G_M_11.pdf

=== Space Shuttle Books ===

''To Orbit and Back Again''

Like a SCOM, less cryptic, full of anecdotes.
https://www.springer.com/gp/book/9781461409823

''Into to the Black''

Book about STS 1, it reads like a Thriller
https://www.thespacereview.com/article/2982/

''Shuttle Down''

Book about an hypothetical scenario. What if the Shuttle was launched from vandenberg and would have diverted to Easter Island :)
[url]https://www.goodreads.com/book/show/549127.Shuttle_Down[/url]

== Videos ==

A compilation of in FG Sim videos about the Space Shuttle

[https://www.youtube.com/watch?v=LOpKt2gXQoE Space Shuttle Launch Flight Gear with STS 133 Real Voices]

[https://www.youtube.com/watch?v=bDGIZj4GGxg Space Shuttle RTLS Abort with OPS 6 real guidance]

[https://www.youtube.com/watch?v=ECJjC-i_3l8 Space Shuttle TAEM KSC Runway 33:HAC and Final Approach]

[https://www.youtube.com/watch?v=fbTFKBWYGbE Space Shuttle TAL]

[https://www.youtube.com/watch?v=62ylBBeO-z4 Space Shuttle Autoland in fog]

On orbit timelapse
[https://forum.flightgear.org/viewtopic.php?f=19&t=35234]

== Mission reports ==

A compilation of Space Shuttle stories / mission reports.

''Shuttle approaches contest''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32790]

''The Van Allen Mission''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35011]

''STS 62 Polar Mission''
[https://forum.flightgear.org/viewtopic.php?f=87&t=38916]

''Meeting ISS''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35276]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35316]
[https://forum.flightgear.org/viewtopic.php?f=19&t=35535]

''Meeting Hubble''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36311]

''From Ground to Orbit''
[https://forum.flightgear.org/viewtopic.php?f=19&t=32851]

''From Orbit to Ground''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33167]

''Return to Launch Site''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33030]

''Transoceanic Abort Landing in Zaragoza''
[https://forum.flightgear.org/viewtopic.php?f=19&t=33368]

''Abort Once Around''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34315]

''Contingency Abort: Landing in Bermuda''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34254]

''Contigency Abort: East Coast Abort Landing''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34969]

''Electrical failure and TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34810]

''Impending Loss of Hydraulics and AOA''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35048]

''Fictionnal Mission into Polar Orbit from Vandenberg''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34700]

''Deorbit and Landing in Easter Island''
[https://forum.flightgear.org/viewtopic.php?f=19&t=34229]

''Triple Engine Failure TAL''
[https://forum.flightgear.org/viewtopic.php?f=19&t=35763]

''Massive electrical failures and Contigency Deorbit // Off Nominal Checklist walkthrough''
[https://forum.flightgear.org/viewtopic.php?f=87&t=36862]

''Single Engine TAL after Droop''
[https://forum.flightgear.org/viewtopic.php?f=87&t=40479]

== Gallery ==
{{screenshot cat
| category = Space Shuttle screenshots
| subject = the Space Shuttle
| image = Shuttle FG03.jpg
}}{{-}}
<gallery mode="packed">
KSC_launch_photorealism.webp|KSC launch photorealism
KSC_launch_2_photorealism.webp|KSC launch photorealism
Vandenberg_photorealism.webp|Vandenberg site photorealism
White_sands_photorealism.webp|White Sands site photorealism
Edwards_photorealism.webp|Edwards site photorealism
Bermuda_photorealism.webp|Bermuda site photorealism
Pad_view_inside.jpg|View on the Pad Pilot Side
Rainy_Pad.jpg|Rainy Pad
On_the_pad.jpg|Shuttle Launch
Shuttle_Launch.jpg|Shuttle Launch
Shuttle FG04.jpg|Shuttle Launch
Farewell.jpg|Launch smoke trail
SRB_sep.jpg|SRB separation
Orbital_Speed.jpg|Accelerating to orbital speed
SSME.jpg|Improved visuals of the exhaust flame
The_desk.jpg|Shuttle 3d cockpit
MECO_sep.jpg|External tank separation
On_orbit_view.jpg|A view of Earth after reaching orbit
ET_sep_2.jpg|The ET seen from the Shuttle
Shuttle OMS full.jpg|Full OMS thrust
Light_effect.jpg|Lightings game in Orbit
Shadow_3.jpg|Shadows and lights on the L2 Commander panel
Over_Africa.jpg|The orbiter high over Africa
Payload ops03.jpg|Handling payload with the RMS arm
Payload_lighting.jpg|Payload Lightings
Space Shuttle sunrise.jpg|Sunrise over Antarctica
Over_Antartica.jpg|Sunrise over Antarctica 2
Sunset.jpg|The OV in orbit at Sunset
Sunset_2.jpg|The OV in orbit at Sunset 2
Sunset_rtls.jpg|RTLS Abort
OMS_burn.jpg|Orbital insertion burn at night
Shuttle-landing04.jpg|Atmospheric entry
Glowing_red_2.jpg|Tiles Glowing Red
Roll_reversal.jpg|High bank angle maneuver to control vertical speed
Mach_down.jpg|During TAEM the Space Shuttle goes subsonic
Eastern_Island_approach.jpg|On final approach into Eastern Island Emergency Landing Site
Final_approach_trondheim.jpg|Final in Trondheim
Pre_flare_KSC.jpg|Pre-flare
Flare_KSC.jpg|Flare
Touch_KSC.jpg|Touchdown in KSC
Fin.jpg|Wheels stop in KSC
</gallery>

[[Category:Space Shuttle documentation]]

File:2024.2 PBR-rendered cockpit.png

2026-05-25T04:39:37Z

Fgf5: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=PBR-rendered cockpit of c172 in 2024.2}}
|date=2026-05-25
|source={{own}}
|author=[[User:Fgf5|Fgf5]]
|permission=
|other versions=
}}

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

Main Page

2026-05-25T04:29:25Z

Fgf5: format

{{Main page/Header
|title = Welcome to the [[FlightGear wiki]]
|subtitle = ''Fly free!''
|rightbox = {{Main page/Languages}}
|introduction =
[[Help:Your first article|Get involved]] by starting, improving, or extending articles.

|rightcolumn1 = [[File:Portal user.png|40px]]</div>
<span style="font-size: 105%; font-weight: bold">[[Portal:User|Using]]</span><br/>
<span style="font-style: italic">'''[[New to FlightGear]]'''<br/>
[[Frequently asked questions]] • [[Troubleshooting problems|Troubleshooting]]<br/>
[[Howto: Install scenery|Installing scenery]] • [[Howto: Install aircraft|Installing aircraft]]<br/>
[[Aircraft|Aircraft list]] • [[Howto: Fly a helicopter|Helicopter flying]]</span>
|rightcolumn2 = [[File:Portal developer.png|40px]]</div>
<span style="font-size: 105%; font-weight: bold">[[Portal:Developer|Developing]]</span><br/>
<span style="font-style: italic">
[[Portal:Developer/Aircraft|Aircraft]] • [[Portal:Developer/Scenery|Scenery]] • [[Portal:Embedded|Embedded]]<br/>
[[Howto: Place 3D objects with the UFO|Placing objects]] • [[Howto: Create custom terrain|Editing terrain]]<br/>[[Howto:Improve scenery in your area, or area of interest|Scenery: Improving your area]]<br/>
[[How the FlightGear project works]]</span>
|rightcolumn3 = [[File:Portal wiki.png|40px]]</div>
<span style="font-size: 105%; font-weight: bold"> [[Portal:Wiki|Wiki]]</span><br/>
<span style="font-style: italic">
[[FlightGear Wiki|About the wiki]] • [[Help:Contents|Help]]<br/>
[[Help:Your first article|Your first article]] • [[Help:Translate|Translate]]<br/>
[[Special:Categories|Categories]]</span>

|sections =
{{Main page/Leftbox
|title = About FlightGear
|logo = FlightGear logo.png
|contents = '''[[FlightGear]]''' is a flight-simulator created by an international group of volunteers, and released as free, open-source [[GNU General Public License|GPL]] software. It has been used for [[Professional and educational FlightGear users|academic research, education]], and for fun.

FlightGear comes with a set of illustrated documentation, notably "[https://flightgear.org/support/manual The Manual]," which is included in the installation package. This wiki provides additional documentation on both user and development topics.

=== I am looking for … ===
* [[Portal:User|Help on using FlightGear]]
* [[Portal:Developer|How to contribute something to FlightGear]]
* [[table of models|Information about aircraft developed for FlightGear]]
}}
{{Main page/Leftbox
|title = News
|logo = Nuvola apps knewsticker.png
|contents = {{News}}
}}
{{Main page/Leftbox
|title = Did you know …
|logo = Nuvola apps ktip.png
|contents = {{Did you know}}
}}

}}

{{Main page/Rightcolumn
|title = Highlight
|contents = <center style="padding-top: 0.9em">[[File:2024.2 HDR PBR rendering.png|frameless]]</center>
|padding-right = 23px
}}Coming HDR/PBR rendering in version 2024.2 (nightly).
{{Main page/Rightcolumn
|title = [[:Category:Screenshot of the month|Screenshot of the month]]
|contents = <center style="padding-top: 0.9em">{{POTM/{{#ifexpr: {{#time: m}} = 01 | {{#expr: {{#time: Y}} - 1 }}-12 | {{#time: Y }}-{{padleft: {{#expr: {{#time: m}} - 1}} | 2 | 0}}}}}}</center>
|padding-right = 23px
}}
{{Main page/Rightcolumn end
|title = [[FlightGear and Git|Development repository status]]
|contents = <center style="padding-top: 0.9em">{{GitStatus}}</center>
|padding-right = 23px
}}

[[Category:FlightGear wiki]]

Main Page

2026-05-25T04:28:22Z

Fgf5: changed the highlight picture (admins can revert it if dissatisfied)

{{Main page/Header
|title = Welcome to the [[FlightGear wiki]]
|subtitle = ''Fly free!''
|rightbox = {{Main page/Languages}}
|introduction =
[[Help:Your first article|Get involved]] by starting, improving, or extending articles.

|rightcolumn1 = [[File:Portal user.png|40px]]</div>
<span style="font-size: 105%; font-weight: bold">[[Portal:User|Using]]</span><br/>
<span style="font-style: italic">'''[[New to FlightGear]]'''<br/>
[[Frequently asked questions]] • [[Troubleshooting problems|Troubleshooting]]<br/>
[[Howto: Install scenery|Installing scenery]] • [[Howto: Install aircraft|Installing aircraft]]<br/>
[[Aircraft|Aircraft list]] • [[Howto: Fly a helicopter|Helicopter flying]]</span>
|rightcolumn2 = [[File:Portal developer.png|40px]]</div>
<span style="font-size: 105%; font-weight: bold">[[Portal:Developer|Developing]]</span><br/>
<span style="font-style: italic">
[[Portal:Developer/Aircraft|Aircraft]] • [[Portal:Developer/Scenery|Scenery]] • [[Portal:Embedded|Embedded]]<br/>
[[Howto: Place 3D objects with the UFO|Placing objects]] • [[Howto: Create custom terrain|Editing terrain]]<br/>[[Howto:Improve scenery in your area, or area of interest|Scenery: Improving your area]]<br/>
[[How the FlightGear project works]]</span>
|rightcolumn3 = [[File:Portal wiki.png|40px]]</div>
<span style="font-size: 105%; font-weight: bold"> [[Portal:Wiki|Wiki]]</span><br/>
<span style="font-style: italic">
[[FlightGear Wiki|About the wiki]] • [[Help:Contents|Help]]<br/>
[[Help:Your first article|Your first article]] • [[Help:Translate|Translate]]<br/>
[[Special:Categories|Categories]]</span>

|sections =
{{Main page/Leftbox
|title = About FlightGear
|logo = FlightGear logo.png
|contents = '''[[FlightGear]]''' is a flight-simulator created by an international group of volunteers, and released as free, open-source [[GNU General Public License|GPL]] software. It has been used for [[Professional and educational FlightGear users|academic research, education]], and for fun.

FlightGear comes with a set of illustrated documentation, notably "[https://flightgear.org/support/manual The Manual]," which is included in the installation package. This wiki provides additional documentation on both user and development topics.

=== I am looking for … ===
* [[Portal:User|Help on using FlightGear]]
* [[Portal:Developer|How to contribute something to FlightGear]]
* [[table of models|Information about aircraft developed for FlightGear]]
}}
{{Main page/Leftbox
|title = News
|logo = Nuvola apps knewsticker.png
|contents = {{News}}
}}
{{Main page/Leftbox
|title = Did you know …
|logo = Nuvola apps ktip.png
|contents = {{Did you know}}
}}

}}

{{Main page/Rightcolumn
|title = Highlight
|contents = <center style="padding-top: 0.9em">[[File:2024.2 HDR PBR rendering.png|frameless]]</center>
|padding-right = 23px
}}.
{{Main page/Rightcolumn
|title = [[:Category:Screenshot of the month|Screenshot of the month]]
|contents = <center style="padding-top: 0.9em">{{POTM/{{#ifexpr: {{#time: m}} = 01 | {{#expr: {{#time: Y}} - 1 }}-12 | {{#time: Y }}-{{padleft: {{#expr: {{#time: m}} - 1}} | 2 | 0}}}}}}</center>
|padding-right = 23px
}}Coming HDR/PBR rendering in version 2024.2 (nightly).
{{Main page/Rightcolumn end
|title = [[FlightGear and Git|Development repository status]]
|contents = <center style="padding-top: 0.9em">{{GitStatus}}</center>
|padding-right = 23px
}}

[[Category:FlightGear wiki]]

File:Canvas menu 2024.2+.png

2026-05-25T04:22:14Z

Fgf5: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=The menu in the canvas UI in 2024.2+}}
|date=2026-05-25
|source={{own}}
|author=[[User:Fgf5|Fgf5]]
|permission=
|other versions=
}}

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

File:2024.2 HDR PBR rendering.png

2026-05-25T04:20:38Z

Fgf5: Uploaded own work with UploadWizard