FlightGear wiki - User contributions [en]

Animated jetways

2024-11-01T22:24:54Z

Wkitty42: /* Animated jetways type 1 */ add date they were fixed in FGDate

[[File:Animated-jetways-KSFO.jpg|thumb|Animated jetways at [[San Francisco International Airport|KSFO]]]]
'''Animated jetways''' can be set in motion by pilots arriving at terminals of airports in FlightGear that have had them added.

Jetways are the "tubes" that passengers use when entering or leaving aircraft docked to the passenger terminals.

== Different types of jetways ==
There are at least two types of animated jetways in FlightGear, here called type 1 and type 2. Type 1 is more advanced than type 2.

; Type 1
: They can connect to your aircraft and also to AI or multiplayer aircraft, (almost) no matter where you stand and in which orientation, as long as you are near enough.

; Type 2
: You have to park very precisely, they do not connect to AI aircraft and they are not visible to other in multiplayer, etc.

== Animated jetways type 1 ==
{{main article|Howto:Animated jetways}}

=== Known issues ===
* They only exist in [[San Francisco International Airport|KSFO]]. But <code>jetways.xml</code> files for more airports are available here: http://media.lug-marl.de/flightgear/jetways/ and here: {{github source|user=mherweg|repo=Airports}}
* <code>generic.xml</code> in FGData is broken. <code>generic.xml</code> in [[TerraSync]] is repaired. See this forum post: {{forum link|p=257608|title=Re: jetways at KSFO}}
* The elevations in the output file of the Jetway editor has to be corrected manually. '''A version of <code>jetways.nas</code> without the elevation problem can be found here''': http://media.lug-marl.de/flightgear/jetways/
* The stg converter of the Jetway editor has a bug in the file-selection dialog. '''A fixed version of <code>jetways_edit.nas</code> can be found here: ''' http://media.lug-marl.de/flightgear/jetways/

As of Oct 2015, the last 2 bugs (<code>jetways.nas</code> & <code>jetways_edit.nas</code>) are fixed in the git version of FGData {{fgdata source|commit=dd3390b3afee955ba23dfd9334baf438bc7ae989}}

Here's another improved version of <code>jetways.nas</code> & <code>jetways_edit.nas</code>:
{{forum link|p=306013|title=Re: The animated jetway project}}

=== Adding type 1 jetways to an airport ===
If you use them at your airport, try to find someone (Torsten D.) with commit rights to FGData or TerraSysnc's <code>Airports/</code> folder and/or use them in your custom scenery.

=== Type 1 Jetways at KDEN ===
recommended:
* Rename <code>Models/Airport/Jetway/jetway-movable.xml</code> to <code>jetway-movable.xml.bak</code>
alternative:
* remove all <model> entries from <code>Objects/w110n30/w105n39/KDEN_Concourse_C.xml</code>

=== Type 1 Jetways at KLAS ===
recommended:
* Rename <code>Models/Airport/Jetway/jetway-movable.xml</code> to <code>jetway-movable.xml.bak</code>
alternative:
* remove all lines with <code>OBJECT_SHARED Models/Airport/Jetway/jetway-movable.xml</code> from <code>Objects/w120n30/w116n36/1056643.stg</code>

=== Type 1 Jetways at PANC ===
recommended:
* Rename <code>Models/Airport/Jetway/jetway-movable.xml</code> to <code>jetway-movable.xml.bak</code>
alternative:
* remove all lines with <code>OBJECT_SHARED Models/Airport/Jetway/jetway-movable.xml</code> from <code>Objects/w150n60/w150n61/501192.stg</code>

=== Type 1 Jetways at EGKK ===
* create a folder <code>Models/Airport/Jetway/backup and move jetway.xml</code>, <code>jetway-747-ba.xml</code>, <code>jetway-737-ba.xml</code>, <code>jetway-a320-ba.xml</code> into that folder.
alternative:
* remove all lines with <code>OBJECT_SHARED Models/Airport/Jetway/...</code> from <code>Objects/w010n50/w001n51/2941771.stg</code>

=== Type 1 Jetways at EHAM ===
That is a tough one! The static jetways are part of the .ac file of the terminals e.g. <code>Schiphol_Gate_E.ac.</code> If you really want animated jetways there, you have to edit those terminal buildings in a 3D software like blender or sketchup. <code>EHAM_gate.xml</code> and <code>EHAM_gate_2.xml</code> also need to be fixed but that is easy: you can download them here:
http://media.lug-marl.de/flightgear/jetways/

=== Type 1 Jetways at EDDF ===
EDDF has no other jetways except for Type1-Jetways at Terminal A+. So just put <code>EDDF.jetways.xml</code> into the <code>Airports/E/D/D/</code> folder

== Animated jetways type 2 ==
You can find type 2 at EDDH, EDDK, EDDG and some other airports, They exist in three versions for aircraft with one, two or three doors:

* <code>jetway-movable.xml</code>
* <code>jetway-movable-2.xml</code>
* <code>jetway-movable-3.xml</code>

=== Known issues ===
* You click one of them and all others also move
* Your aircraft has to park exactly aligned on the yellow line with the front wheel on the mark.
* They only fit when the terminal building in front of the aircraft, you can not use them when the terminal building is on the side of the aircraft.
* Movement is not visible via multiplayer

=== Adding type 2 jetways to an airport ===
Place them as a shared object with the ufo and submit the locations to to http://scenemodels.flightgear.org/. See [[Placing 3D Objects with the UFO]].

=== Adding type 2 jetways to an aircraft ===
Add the following to your aircraft-set.xml, see the A380 as an example. You can find the right values by parking your aircraft at a type 2 jetway and setting the properties in <code>/scenery/airport/jetway</code>. In that way you don't have to restart FlightGear every time to check if your settings are right.

<syntaxhighlight language="xml">
<aircraft>
<jetway-pos>
<x-tra>-2</x-tra>
<y-rot>2</y-rot>
<z-rot>18</z-rot>
<hood-rot>0</hood-rot>
</jetway-pos>
<jetway2-pos>
<x-tra>2.5</x-tra>
<y-rot>2.5</y-rot>
<z-rot>45</z-rot>
<hood-rot>0</hood-rot>
</jetway2-pos>
<jetway3-pos>
<x-tra>4</x-tra>
<y-rot>5</y-rot>
<z-rot>47</z-rot>
<hood-rot>3</hood-rot>
</jetway3-pos>
</aircraft>
</syntaxhighlight>

== Related content ==
* [[AI Jetway Objects]]
* [[Howto:Animated jetways]]
* [[List of .stg files with non-AI jetway scenery objects]]
* [[Ramp Marshall]]

[[Category:Scenery enhancement]]
[[Category:AI Traffic]]

Canvas Maps

2022-01-18T13:23:15Z

Wkitty42: /* Geo-referencing */ remove link to osggis.org... apparently someone bought the domain and turned it into a XXX site

{{Template:Canvas Navigation}}

== Status: The Map/NavDisplay backend ==
* '''TheTom''': " [[ATC-FS]] is definitely an interesting application which can benefit from the Canvas very much. Maybe we can do some ATC programs which look like the real ones... "
* '''Hooray''': " It would be great to have 2-3 "real" applications, so that the canvas/map API becomes more powerful."
* '''TheTom''': "vertical projection seems not too complicated as its basically just calculating segment lenghts on a sphere, or maybe just direct distance calculations. I think the error in comparison to the real sphere can be neglected while using typical distances (eg. at a distance of 300 miles the error is about 2.8 miles, which is ~0.9%)." {{Pending}} (see [[Canvas Maps]])

== Shared Requirements (MFDs and GUI maps) ==
It would make sense to introduce another wrapper here, something like "mfd.nas" which transparently handles the low level details and which uses canvas.nas as its workhorse.

Like you say, the API requirements for canvas and the mfd module will become clearer once existing dialogs and gauges are getting ported. I would however be careful not to put too much special stuff into the generic canvas module.

We need to keep in mind that once the hard coded Map dialog is getting ported, there will be lots of overlapping functionality with similar "displays", like the NavDisplay, agradar, wxradar - all of these are basically about mapping a geo-position to 2D screen space (horizontal currently).

The Canvas system's mapping mode loosely follows the ideas from ARINC 661.
The current hard coded NavDisplay is really an ARINC 661 display - it takes a list of symbols, a list of items and combines then using a projection to create a final display. The only additional code is to deal with special things that can't easily be described by a simply symbol, especially the flight-plan/route path.

The Map widget will be special in that it will be a shared component that can be used for both, GUI dialogs, as well as MFD-style avionics. The idea is to create a generic system that can be easily parametrized and customized as required, so that it can be used by people to create all sorts of mapping/charting displays in FlighGear, either as conventional MFD gauges, or as GUI dialogs (for example ATC radar screens).

A display like the current navdisplay could be rendered as an instrument, but also as a GUI widget.
In any case, there would be a fixed set of "inputs" and "outputs", i.e. the "interface" of the system.

In FlightGear, this would usually mean that there are input and output properties. For cockpit instruments, these would be mapped to hot spots, i.e. clickable panel actions.

So, what could be done is adding a new Nasal class to make these relationships explicit: input properties and output properties.
When a canvas system is being loaded as an instrument, these "generic" properties would be mapped to instrument-specific properties. And when it is loaded as a GUI widget, these could be exposed as GUI hooks, i.e. mapped to checkboxes, buttons etc.

In its simplest form, developers would use different hashes or vectors to specify the properties supported for input/output, in each different mode:

* Instrument mode
* HUD mode
* GUI (widget) mode
* scenery mode

There could be other more specific modes, for MFDs (or CDUs).

For example, let's consider the MFD example, i.e. the map dialog, which has a single "control property" (input) to select if the runways shall be rendered or not. The GUI widget would simply map this property to a checkbox, while the cockpit panel would map it to a cockpit hotspot to show/hide this layer.

Obviously, it would be important to support multiple instances, so that an aircraft may have multiple MFDs, CDUs - and so that the cockpit settings don't override the settings in the canvas-driven map dialog, but that can be accomplished by using different canvases. At some point it might make sense to see how this can be optimized, so that a single canvas may be partially shared, ie. by having cascades of canvases (like we talked about), so that there are no redundant canvases being drawn. Basically, something like a shared canvas instance, which is evaluated for each instance of the instrument/widget, i.e. drawn multiple times per frame for the control properties of each canvas system (PFD, ND, EICAS).

That would make it possible to share multiple instances, with different settings, while sharing most of the rendering logic and data, i.e. a single canvas RTT context could be largely shared. That may be a worthwhile thing to support, because it would help improve the performance for complex glass cockpits, with many identical instruments (layers/groups) - which may still have different "modes" selected, so that they require their own rendering pass, while sharings lots of data/GL state otherwise.

That being said, I would consider changing the canvas class such that it is possible to link properties to certain usage modes/scenarios. That would make it possible for people to easily use the same code for different purposes.

Overall, I feel that the design would evolve automatically once we actually try to port the map dialog to become a generic canvas module, usable for both, cockpit instruments - but also as a GUI widget. In other words: how would the design ideally look, if we could create generic canvas systems for such purposes?

That shouldn't involve any C++ changes - just creating abstract interface classes for people to use - so that their subclasses automatically satisfy everything that's needed.

And it would actually make sense to support the same thing for GUI widgets, too - i.e. allow them to be rendered as part of fully functioning cockpit instruments, that may seem like over-engineering now - but all modern airliners use A661 meanwhile, and they all support "real GUIs" as part of the MFD/CDU - i.e. control boxes, dialog boxes, check boxes, buttons etc.
So it would be great to support the FG canvas widget here, too - we could get it for free like this.

== Moving Maps ==
Basically, a moving map terrain view would require support for accessing the FG tile manager, so that a orthographic view of the scenery can be rendered.
It might be easier to use OSG's GeoTIFF support instead and require people to add GeoTIFF images for the region of interest?
Overall, I feel that would be better implemeneted as a separate mode (implemented in C++)?
I think it would be better to use the same elevation data that is used for rendering, so that you don't have to create and provide the same data two times. Rendering an orthographic view would come for free if we implement support for multiple cameras. If we don't want to do it with rendering we can use a cached list of terrain intersections. I have seen such an implementation in one of the aircrafts in the forum (I think it was the 787).
Yes, that's true - that's been discussed previously, but there was talk about using a dedicated scene graph for such moving map displays on the devel list, see [[CompositeViewer Support]].

Also see: [[Howto:Use a Camera View in an Instrument]]

Related:
* http://forum.flightgear.org/viewtopic.php?f=4&t=15722&p=154788&hilit=synthetic#p153941
* http://forum.flightgear.org/viewtopic.php?f=71&t=17105&p=163120&hilit=synthetic#p163119
* http://forum.flightgear.org/viewtopic.php?f=71&p=164340#p163475

== Vector data ==
{{Main article|Canvas Tile Element}}

Looking at the [[Map]] dialog docs, James was planning to add a bunch of other features which are not currently supported by the map widget, but which would probably be worth keeping in mind for the canvas system as such, for example:
* "use terrain height intersections to compute a EGPWS / G1000-style terrain clearance overlay"

Also, he mentions "national borders & coastlines rendering" under planned improvements.

That would probably be best accomplished by rendering vector data from shapefiles (esri), OSG already has support for ESRI using the ESRIShape plugin: http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.2/src/osgPlugins/shp/ESRIShape.cpp

Yeah, it seems like osgGIS is really focused too much on OSG. But instead of using shapelib for ESRI support I'd rather use gdal or ogr which is already used in TerraGear and is not limited to a single format. But I think this is something to consider later. For a first version of the map it should be enough to expose the data that is already available in the core.

== Misc ==
This is copied from various articles that have become obsolete now and which are considered for deletion - so none of this is currently planned, it's just kept here to help us assess whether all the required building blocks are in place, or if we should look into adding other building blocks.

=== Geo-referencing ===
* ability to load maps/charts in standard formats, i.e. as ESRI shapefile layers (There are some plugins for OSG to deal with ESRI/GIS data)
* access to terrain via terrain API to query terrain properties
* access to airspace via airspace API to query surrounding airspace
* access to navigation databases (airports, navaids, waypoints, airways)
* render to texture

FlightGear history

2021-08-05T11:31:09Z

Wkitty42: /* Release timeline */ fix 2020.2.1 date... used date of branch cut from commit logs mailing list since archive was removed as too buggy and 2020.3 was cut a week or two later...

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
| Jul 17, 1997 || First major code release
|-
| Sep 23, 1997 || 0.12
|-
| Dec 9, 1997 || 0.15
|-
| Dec 17, 1997 || 0.18
|-
| Dec 30, 1997 || 0.19 (first binaries)
|-
| Jan 6, 1998 || 0.22
|-
| Mar 11 98 || 0.37
|-
| Apr 8, 1998 || 0.41
|-
| Apr 14, 1998 || 0.42
|-
| Apr 23, 1998 || 0.43
|-
| Apr 28, 1998 || 0.44
|-
| May 7, 1998 || 0.45
|-
| May 11, 1998 || 0.46
|-
| May 18, 1998 || 0.47
|-
| Jun 9, 1998 || 0.48
|-
| Jun 27, 1998 || 0.49
|-
| Jul 13, 1998 || 0.50
|-
| Jul 21, 1998 || 0.51
|-
| Aug 15, 1998 || 0.52
|-
| Sep 2, 1998 || 0.53
|-
| Sep 25, 1998 || 0.54
|-
| Oct 23, 1998 || 0.55
|-
| Nov 23, 1998 || 0.56
|-
| Jan 21, 1999 || 0.57
|-
| Feb 10, 1999 || 0.58
|-
| Mar 31, 1999 || 0.59
|-
| May 26, 1999 || 0.6.0
|-
| Jun 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | Sep 11, 1999 || 0.7.0 (Development)
|-
| 0.6.2 (Stable)
|-
| Oct 22, 1999 || 0.7.1 (Development)
|-
| Feb 17, 2000 || 0.7.2 (Development)
|-
| May 18, 2000 || 0.7.3 (Development)
|-
| Jul 20, 2000 || 0.7.4
|-
| Sep 18, 2000 || 0.7.5
|-
| Dec 19, 2000 || 0.7.6
|-
| Jun 20, 2001 || 0.7.7
|-
| Jul 13, 2001 || 0.7.8
|-
| Feb 16, 2002 || 0.7.9
|-
| Apr 20, 2002 || 0.7.10
|-
| Sep 7, 2002 || 0.8.0
|-
| Dec 3, 2002 || 0.9.0
|-
| Dec 5, 2002 || 0.9.1
|-
| Jun 4, 2003 || 0.9.2
|-
| Oct 24, 2003 || 0.9.3
|-
| Mar 26, 2004 || 0.9.4
|-
| Jul 29, 2004 || 0.9.5
|-
| Oct 12, 2004 || 0.9.6
|-
| Jan 18, 2005 || 0.9.8
|-
| Nov 17, 2005 || 0.9.9
|-
| Apr 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| Dec 17, 2007 || 1.0.0
|-
| Dec 22, 2008 || 1.9.0
|-
| Jan 25, 2009 || 1.9.1
|-
| Feb 25, 2010 || 2.0.0
|-
| Aug 17, 2011 || 2.4.0
|-
| Feb 17, 2012 || 2.6.0
|-
| Aug 17, 2012 || 2.8.0
|-
| Feb 17, 2013 || 2.10
|-
| Sep 21, 2013 || 2.12
|-
| Feb 17, 2014 || 3.0
|-
| Oct 15, 2014 || 3.2
|-
| Feb 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| Feb 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2
|-
| May 17, 2016 || 2016.2.1
|-
| Sep 12, 2016 || 2016.3.1
|-
| Nov 19, 2016 || 2016.4.1
|-
| Nov 23, 2016 || 2016.4.2
|-
| Dec 5, 2016 || 2016.4.3
|-
| Dec 28, 2016 || 2016.4.4
|-
| Feb 23, 2017 || 2017.1.1
|-
| Mar 1, 2017 || 2017.1.2
|-
| Apr 4, 2017 || 2017.1.3
|-
| May 22, 2017 || 2017.2.1
|-
| Sep 20, 2017 || 2017.3.1
|-
| Apr 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4
|-
| Apr 20, 2020 || 2018.3.5
|-
| Aug 9, 2020 || 2018.3.6
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2
|-
| Jun 26, 2020 || 2020.1.3
|-
| Oct 13, 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2
|-
| Nov 23, 2020 || 2020.3.3
|-
| Dec 1, 2020 || 2020.3.4
|-
| Dec 19, 2020 || 2020.3.5
|-
| Jan 24, 2021 || 2020.3.6
|-
| Mar 21, 2021 || 2020.3.7
|-
| Mar 25, 2021 || 2020.3.8
|-
| Jun 14, 2021 || 2020.3.9
|-
| Jul 26, 2021 || 2020.3.10
|-
| Jul 29, 2021 || 2020.3.11
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released. Since 2018.1, the selection of a new default airport has been changed so that a new airport is selected for each new major version release instead of for each minor version release.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="3" | [[BIKF]] || rowspan="3" | Keflavik
|-
| 2020.2
|-
| 2020.3
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2021-08-04T10:35:04Z

Wkitty42: /* Release timeline */ add sub versions 2020.3.10 and 2020.3.11... i should note the dates i'm using are the dates of the files on SF in the release-YYYY.V directory... in case anyone was wondering...

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
| Jul 17, 1997 || First major code release
|-
| Sep 23, 1997 || 0.12
|-
| Dec 9, 1997 || 0.15
|-
| Dec 17, 1997 || 0.18
|-
| Dec 30, 1997 || 0.19 (first binaries)
|-
| Jan 6, 1998 || 0.22
|-
| Mar 11 98 || 0.37
|-
| Apr 8, 1998 || 0.41
|-
| Apr 14, 1998 || 0.42
|-
| Apr 23, 1998 || 0.43
|-
| Apr 28, 1998 || 0.44
|-
| May 7, 1998 || 0.45
|-
| May 11, 1998 || 0.46
|-
| May 18, 1998 || 0.47
|-
| Jun 9, 1998 || 0.48
|-
| Jun 27, 1998 || 0.49
|-
| Jul 13, 1998 || 0.50
|-
| Jul 21, 1998 || 0.51
|-
| Aug 15, 1998 || 0.52
|-
| Sep 2, 1998 || 0.53
|-
| Sep 25, 1998 || 0.54
|-
| Oct 23, 1998 || 0.55
|-
| Nov 23, 1998 || 0.56
|-
| Jan 21, 1999 || 0.57
|-
| Feb 10, 1999 || 0.58
|-
| Mar 31, 1999 || 0.59
|-
| May 26, 1999 || 0.6.0
|-
| Jun 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | Sep 11, 1999 || 0.7.0 (Development)
|-
| 0.6.2 (Stable)
|-
| Oct 22, 1999 || 0.7.1 (Development)
|-
| Feb 17, 2000 || 0.7.2 (Development)
|-
| May 18, 2000 || 0.7.3 (Development)
|-
| Jul 20, 2000 || 0.7.4
|-
| Sep 18, 2000 || 0.7.5
|-
| Dec 19, 2000 || 0.7.6
|-
| Jun 20, 2001 || 0.7.7
|-
| Jul 13, 2001 || 0.7.8
|-
| Feb 16, 2002 || 0.7.9
|-
| Apr 20, 2002 || 0.7.10
|-
| Sep 7, 2002 || 0.8.0
|-
| Dec 3, 2002 || 0.9.0
|-
| Dec 5, 2002 || 0.9.1
|-
| Jun 4, 2003 || 0.9.2
|-
| Oct 24, 2003 || 0.9.3
|-
| Mar 26, 2004 || 0.9.4
|-
| Jul 29, 2004 || 0.9.5
|-
| Oct 12, 2004 || 0.9.6
|-
| Jan 18, 2005 || 0.9.8
|-
| Nov 17, 2005 || 0.9.9
|-
| Apr 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| Dec 17, 2007 || 1.0.0
|-
| Dec 22, 2008 || 1.9.0
|-
| Jan 25, 2009 || 1.9.1
|-
| Feb 25, 2010 || 2.0.0
|-
| Aug 17, 2011 || 2.4.0
|-
| Feb 17, 2012 || 2.6.0
|-
| Aug 17, 2012 || 2.8.0
|-
| Feb 17, 2013 || 2.10
|-
| Sep 21, 2013 || 2.12
|-
| Feb 17, 2014 || 3.0
|-
| Oct 15, 2014 || 3.2
|-
| Feb 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| Feb 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2
|-
| May 17, 2016 || 2016.2.1
|-
| Sep 12, 2016 || 2016.3.1
|-
| Nov 19, 2016 || 2016.4.1
|-
| Nov 23, 2016 || 2016.4.2
|-
| Dec 5, 2016 || 2016.4.3
|-
| Dec 28, 2016 || 2016.4.4
|-
| Feb 23, 2017 || 2017.1.1
|-
| Mar 1, 2017 || 2017.1.2
|-
| Apr 4, 2017 || 2017.1.3
|-
| May 22, 2017 || 2017.2.1
|-
| Sep 20, 2017 || 2017.3.1
|-
| Apr 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4
|-
| Apr 20, 2020 || 2018.3.5
|-
| Aug 9, 2020 || 2018.3.6
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2
|-
| Jun 26, 2020 || 2020.1.3
|-
| 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2
|-
| Nov 23, 2020 || 2020.3.3
|-
| Dec 1, 2020 || 2020.3.4
|-
| Dec 19, 2020 || 2020.3.5
|-
| Jan 24, 2021 || 2020.3.6
|-
| Mar 21, 2021 || 2020.3.7
|-
| Mar 25, 2021 || 2020.3.8
|-
| Jun 14, 2021 || 2020.3.9
|-
| Jul 26, 2021 || 2020.3.10
|-
| Jul 29, 2021 || 2020.3.11
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released. Since 2018.1, the selection of a new default airport has been changed so that a new airport is selected for each new major version release instead of for each minor version release.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="3" | [[BIKF]] || rowspan="3" | Keflavik
|-
| 2020.2
|-
| 2020.3
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2021-06-12T10:37:01Z

Wkitty42: /* Release timeline */ remove "(bugfix release)" from entries because all minor releases are bug fixes...

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
| Jul 17, 1997 || First major code release
|-
| Sep 23, 1997 || 0.12
|-
| Dec 9, 1997 || 0.15
|-
| Dec 17, 1997 || 0.18
|-
| Dec 30, 1997 || 0.19 (first binaries)
|-
| Jan 6, 1998 || 0.22
|-
| Mar 11 98 || 0.37
|-
| Apr 8, 1998 || 0.41
|-
| Apr 14, 1998 || 0.42
|-
| Apr 23, 1998 || 0.43
|-
| Apr 28, 1998 || 0.44
|-
| May 7, 1998 || 0.45
|-
| May 11, 1998 || 0.46
|-
| May 18, 1998 || 0.47
|-
| Jun 9, 1998 || 0.48
|-
| Jun 27, 1998 || 0.49
|-
| Jul 13, 1998 || 0.50
|-
| Jul 21, 1998 || 0.51
|-
| Aug 15, 1998 || 0.52
|-
| Sep 2, 1998 || 0.53
|-
| Sep 25, 1998 || 0.54
|-
| Oct 23, 1998 || 0.55
|-
| Nov 23, 1998 || 0.56
|-
| Jan 21, 1999 || 0.57
|-
| Feb 10, 1999 || 0.58
|-
| Mar 31, 1999 || 0.59
|-
| May 26, 1999 || 0.6.0
|-
| Jun 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | Sep 11, 1999 || 0.7.0 (Development)
|-
| 0.6.2 (Stable)
|-
| Oct 22, 1999 || 0.7.1 (Development)
|-
| Feb 17, 2000 || 0.7.2 (Development)
|-
| May 18, 2000 || 0.7.3 (Development)
|-
| Jul 20, 2000 || 0.7.4
|-
| Sep 18, 2000 || 0.7.5
|-
| Dec 19, 2000 || 0.7.6
|-
| Jun 20, 2001 || 0.7.7
|-
| Jul 13, 2001 || 0.7.8
|-
| Feb 16, 2002 || 0.7.9
|-
| Apr 20, 2002 || 0.7.10
|-
| Sep 7, 2002 || 0.8.0
|-
| Dec 3, 2002 || 0.9.0
|-
| Dec 5, 2002 || 0.9.1
|-
| Jun 4, 2003 || 0.9.2
|-
| Oct 24, 2003 || 0.9.3
|-
| Mar 26, 2004 || 0.9.4
|-
| Jul 29, 2004 || 0.9.5
|-
| Oct 12, 2004 || 0.9.6
|-
| Jan 18, 2005 || 0.9.8
|-
| Nov 17, 2005 || 0.9.9
|-
| Apr 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| Dec 17, 2007 || 1.0.0
|-
| Dec 22, 2008 || 1.9.0
|-
| Jan 25, 2009 || 1.9.1
|-
| Feb 25, 2010 || 2.0.0
|-
| Aug 17, 2011 || 2.4.0
|-
| Feb 17, 2012 || 2.6.0
|-
| Aug 17, 2012 || 2.8.0
|-
| Feb 17, 2013 || 2.10
|-
| Sep 21, 2013 || 2.12
|-
| Feb 17, 2014 || 3.0
|-
| Oct 15, 2014 || 3.2
|-
| Feb 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| Feb 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2
|-
| May 17, 2016 || 2016.2.1
|-
| Sep 12, 2016 || 2016.3.1
|-
| Nov 19, 2016 || 2016.4.1
|-
| Nov 23, 2016 || 2016.4.2
|-
| Dec 5, 2016 || 2016.4.3
|-
| Dec 28, 2016 || 2016.4.4
|-
| Feb 23, 2017 || 2017.1.1
|-
| Mar 1, 2017 || 2017.1.2
|-
| Apr 4, 2017 || 2017.1.3
|-
| May 22, 2017 || 2017.2.1
|-
| Sep 20, 2017 || 2017.3.1
|-
| Apr 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4
|-
| Apr 20, 2020 || 2018.3.5
|-
| Aug 9, 2020 || 2018.3.6
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2
|-
| Jun 26, 2020 || 2020.1.3
|-
| 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2
|-
| Nov 23, 2020 || 2020.3.3
|-
| Dec 1, 2020 || 2020.3.4
|-
| Dec 19, 2020 || 2020.3.5
|-
| Jan 24, 2021 || 2020.3.6
|-
| Mar 21, 2021 || 2020.3.7
|-
| Mar 25, 2021 || 2020.3.8
|-
| Jun 14, 2021 || 2020.3.9
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released. Since 2018.1, the selection of a new default airport has been changed so that a new airport is selected for each new major version release instead of for each minor version release.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="3" | [[BIKF]] || rowspan="3" | Keflavik
|-
| 2020.2
|-
| 2020.3
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2021-06-12T10:24:00Z

Wkitty42: /* Release timeline */ anticipated official release of 2020.3.9...

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
| Jul 17, 1997 || First major code release
|-
| Sep 23, 1997 || 0.12
|-
| Dec 9, 1997 || 0.15
|-
| Dec 17, 1997 || 0.18
|-
| Dec 30, 1997 || 0.19 (first binaries)
|-
| Jan 6, 1998 || 0.22
|-
| Mar 11 98 || 0.37
|-
| Apr 8, 1998 || 0.41
|-
| Apr 14, 1998 || 0.42
|-
| Apr 23, 1998 || 0.43
|-
| Apr 28, 1998 || 0.44
|-
| May 7, 1998 || 0.45
|-
| May 11, 1998 || 0.46
|-
| May 18, 1998 || 0.47
|-
| Jun 9, 1998 || 0.48
|-
| Jun 27, 1998 || 0.49
|-
| Jul 13, 1998 || 0.50
|-
| Jul 21, 1998 || 0.51
|-
| Aug 15, 1998 || 0.52
|-
| Sep 2, 1998 || 0.53
|-
| Sep 25, 1998 || 0.54
|-
| Oct 23, 1998 || 0.55
|-
| Nov 23, 1998 || 0.56
|-
| Jan 21, 1999 || 0.57
|-
| Feb 10, 1999 || 0.58
|-
| Mar 31, 1999 || 0.59
|-
| May 26, 1999 || 0.6.0
|-
| Jun 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | Sep 11, 1999 || 0.7.0 (Development)
|-
| 0.6.2 (Stable)
|-
| Oct 22, 1999 || 0.7.1 (Development)
|-
| Feb 17, 2000 || 0.7.2 (Development)
|-
| May 18, 2000 || 0.7.3 (Development)
|-
| Jul 20, 2000 || 0.7.4
|-
| Sep 18, 2000 || 0.7.5
|-
| Dec 19, 2000 || 0.7.6
|-
| Jun 20, 2001 || 0.7.7
|-
| Jul 13, 2001 || 0.7.8
|-
| Feb 16, 2002 || 0.7.9
|-
| Apr 20, 2002 || 0.7.10
|-
| Sep 7, 2002 || 0.8.0
|-
| Dec 3, 2002 || 0.9.0
|-
| Dec 5, 2002 || 0.9.1
|-
| Jun 4, 2003 || 0.9.2
|-
| Oct 24, 2003 || 0.9.3
|-
| Mar 26, 2004 || 0.9.4
|-
| Jul 29, 2004 || 0.9.5
|-
| Oct 12, 2004 || 0.9.6
|-
| Jan 18, 2005 || 0.9.8
|-
| Nov 17, 2005 || 0.9.9
|-
| Apr 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| Dec 17, 2007 || 1.0.0
|-
| Dec 22, 2008 || 1.9.0
|-
| Jan 25, 2009 || 1.9.1
|-
| Feb 25, 2010 || 2.0.0
|-
| Aug 17, 2011 || 2.4.0
|-
| Feb 17, 2012 || 2.6.0
|-
| Aug 17, 2012 || 2.8.0
|-
| Feb 17, 2013 || 2.10
|-
| Sep 21, 2013 || 2.12
|-
| Feb 17, 2014 || 3.0
|-
| Oct 15, 2014 || 3.2
|-
| Feb 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| Feb 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2 (bugfix release)
|-
| May 17, 2016 || 2016.2.1
|-
| Sep 12, 2016 || 2016.3.1
|-
| Nov 19, 2016 || 2016.4.1
|-
| Nov 23, 2016 || 2016.4.2 (bugfix release)
|-
| Dec 5, 2016 || 2016.4.3 (bugfix release)
|-
| Dec 28, 2016 || 2016.4.4 (bugfix release)
|-
| Feb 23, 2017 || 2017.1.1
|-
| Mar 1, 2017 || 2017.1.2 (bugfix release)
|-
| Apr 4, 2017 || 2017.1.3 (bugfix release)
|-
| May 22, 2017 || 2017.2.1 (bugfix release)
|-
| Sep 20, 2017 || 2017.3.1
|-
| Apr 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2 (bugfix release)
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4 (bugfix release)
|-
| Apr 20, 2020 || 2018.3.5 (bugfix release)
|-
| Aug 9, 2020 || 2018.3.6 (bugfix release)
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2 (bugfix release)
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2 (bugfix release)
|-
| Jun 26, 2020 || 2020.1.3 (bugfix release)
|-
| 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2 (bugfix release)
|-
| Nov 23, 2020 || 2020.3.3 (bugfix release)
|-
| Dec 1, 2020 || 2020.3.4 (bugfix release)
|-
| Dec 19, 2020 || 2020.3.5 (bugfix release)
|-
| Jan 24, 2021 || 2020.3.6 (bugfix release)
|-
| Mar 21, 2021 || 2020.3.7 (bugfix release)
|-
| Mar 25, 2021 || 2020.3.8 (bugfix release)
|-
| Jun 14, 2021 || 2020.3.9 (bugfix release)
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released. Since 2018.1, the selection of a new default airport has been changed so that a new airport is selected for each new major version release instead of for each minor version release.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="3" | [[BIKF]] || rowspan="3" | Keflavik
|-
| 2020.2
|-
| 2020.3
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2021-06-04T11:21:12Z

Wkitty42: /* Cycled default airports */ add statement about new default airport selection being changed to each major version release instead of each minor version release...

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
| Jul 17, 1997 || First major code release
|-
| Sep 23, 1997 || 0.12
|-
| Dec 9, 1997 || 0.15
|-
| Dec 17, 1997 || 0.18
|-
| Dec 30, 1997 || 0.19 (first binaries)
|-
| Jan 6, 1998 || 0.22
|-
| Mar 11 98 || 0.37
|-
| Apr 8, 1998 || 0.41
|-
| Apr 14, 1998 || 0.42
|-
| Apr 23, 1998 || 0.43
|-
| Apr 28, 1998 || 0.44
|-
| May 7, 1998 || 0.45
|-
| May 11, 1998 || 0.46
|-
| May 18, 1998 || 0.47
|-
| Jun 9, 1998 || 0.48
|-
| Jun 27, 1998 || 0.49
|-
| Jul 13, 1998 || 0.50
|-
| Jul 21, 1998 || 0.51
|-
| Aug 15, 1998 || 0.52
|-
| Sep 2, 1998 || 0.53
|-
| Sep 25, 1998 || 0.54
|-
| Oct 23, 1998 || 0.55
|-
| Nov 23, 1998 || 0.56
|-
| Jan 21, 1999 || 0.57
|-
| Feb 10, 1999 || 0.58
|-
| Mar 31, 1999 || 0.59
|-
| May 26, 1999 || 0.6.0
|-
| Jun 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | Sep 11, 1999 || 0.7.0 (Development)
|-
| 0.6.2 (Stable)
|-
| Oct 22, 1999 || 0.7.1 (Development)
|-
| Feb 17, 2000 || 0.7.2 (Development)
|-
| May 18, 2000 || 0.7.3 (Development)
|-
| Jul 20, 2000 || 0.7.4
|-
| Sep 18, 2000 || 0.7.5
|-
| Dec 19, 2000 || 0.7.6
|-
| Jun 20, 2001 || 0.7.7
|-
| Jul 13, 2001 || 0.7.8
|-
| Feb 16, 2002 || 0.7.9
|-
| Apr 20, 2002 || 0.7.10
|-
| Sep 7, 2002 || 0.8.0
|-
| Dec 3, 2002 || 0.9.0
|-
| Dec 5, 2002 || 0.9.1
|-
| Jun 4, 2003 || 0.9.2
|-
| Oct 24, 2003 || 0.9.3
|-
| Mar 26, 2004 || 0.9.4
|-
| Jul 29, 2004 || 0.9.5
|-
| Oct 12, 2004 || 0.9.6
|-
| Jan 18, 2005 || 0.9.8
|-
| Nov 17, 2005 || 0.9.9
|-
| Apr 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| Dec 17, 2007 || 1.0.0
|-
| Dec 22, 2008 || 1.9.0
|-
| Jan 25, 2009 || 1.9.1
|-
| Feb 25, 2010 || 2.0.0
|-
| Aug 17, 2011 || 2.4.0
|-
| Feb 17, 2012 || 2.6.0
|-
| Aug 17, 2012 || 2.8.0
|-
| Feb 17, 2013 || 2.10
|-
| Sep 21, 2013 || 2.12
|-
| Feb 17, 2014 || 3.0
|-
| Oct 15, 2014 || 3.2
|-
| Feb 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| Feb 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2 (bugfix release)
|-
| May 17, 2016 || 2016.2.1
|-
| Sep 12, 2016 || 2016.3.1
|-
| Nov 19, 2016 || 2016.4.1
|-
| Nov 23, 2016 || 2016.4.2 (bugfix release)
|-
| Dec 5, 2016 || 2016.4.3 (bugfix release)
|-
| Dec 28, 2016 || 2016.4.4 (bugfix release)
|-
| Feb 23, 2017 || 2017.1.1
|-
| Mar 1, 2017 || 2017.1.2 (bugfix release)
|-
| Apr 4, 2017 || 2017.1.3 (bugfix release)
|-
| May 22, 2017 || 2017.2.1 (bugfix release)
|-
| Sep 20, 2017 || 2017.3.1
|-
| Apr 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2 (bugfix release)
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4 (bugfix release)
|-
| Apr 20, 2020 || 2018.3.5 (bugfix release)
|-
| Aug 9, 2020 || 2018.3.6 (bugfix release)
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2 (bugfix release)
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2 (bugfix release)
|-
| Jun 26, 2020 || 2020.1.3 (bugfix release)
|-
| 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2 (bugfix release)
|-
| Nov 23, 2020 || 2020.3.3 (bugfix release)
|-
| Dec 1, 2020 || 2020.3.4 (bugfix release)
|-
| Dec 19, 2020 || 2020.3.5 (bugfix release)
|-
| Jan 24, 2021 || 2020.3.6 (bugfix release)
|-
| Mar 21, 2021 || 2020.3.7 (bugfix release)
|-
| Mar 25, 2021 || 2020.3.8 (bugfix release)
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released. Since 2018.1, the selection of a new default airport has been changed so that a new airport is selected for each new major version release instead of for each minor version release.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="3" | [[BIKF]] || rowspan="3" | Keflavik
|-
| 2020.2
|-
| 2020.3
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2021-05-04T14:58:54Z

Wkitty42: /* Release timeline */ consistent three-letter month names and leading spaces

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
| Jul 17, 1997 || First major code release
|-
| Sep 23, 1997 || 0.12
|-
| Dec 9, 1997 || 0.15
|-
| Dec 17, 1997 || 0.18
|-
| Dec 30, 1997 || 0.19 (first binaries)
|-
| Jan 6, 1998 || 0.22
|-
| Mar 11 98 || 0.37
|-
| Apr 8, 1998 || 0.41
|-
| Apr 14, 1998 || 0.42
|-
| Apr 23, 1998 || 0.43
|-
| Apr 28, 1998 || 0.44
|-
| May 7, 1998 || 0.45
|-
| May 11, 1998 || 0.46
|-
| May 18, 1998 || 0.47
|-
| Jun 9, 1998 || 0.48
|-
| Jun 27, 1998 || 0.49
|-
| Jul 13, 1998 || 0.50
|-
| Jul 21, 1998 || 0.51
|-
| Aug 15, 1998 || 0.52
|-
| Sep 2, 1998 || 0.53
|-
| Sep 25, 1998 || 0.54
|-
| Oct 23, 1998 || 0.55
|-
| Nov 23, 1998 || 0.56
|-
| Jan 21, 1999 || 0.57
|-
| Feb 10, 1999 || 0.58
|-
| Mar 31, 1999 || 0.59
|-
| May 26, 1999 || 0.6.0
|-
| Jun 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | Sep 11, 1999 || 0.7.0 (Development)
|-
| 0.6.2 (Stable)
|-
| Oct 22, 1999 || 0.7.1 (Development)
|-
| Feb 17, 2000 || 0.7.2 (Development)
|-
| May 18, 2000 || 0.7.3 (Development)
|-
| Jul 20, 2000 || 0.7.4
|-
| Sep 18, 2000 || 0.7.5
|-
| Dec 19, 2000 || 0.7.6
|-
| Jun 20, 2001 || 0.7.7
|-
| Jul 13, 2001 || 0.7.8
|-
| Feb 16, 2002 || 0.7.9
|-
| Apr 20, 2002 || 0.7.10
|-
| Sep 7, 2002 || 0.8.0
|-
| Dec 3, 2002 || 0.9.0
|-
| Dec 5, 2002 || 0.9.1
|-
| Jun 4, 2003 || 0.9.2
|-
| Oct 24, 2003 || 0.9.3
|-
| Mar 26, 2004 || 0.9.4
|-
| Jul 29, 2004 || 0.9.5
|-
| Oct 12, 2004 || 0.9.6
|-
| Jan 18, 2005 || 0.9.8
|-
| Nov 17, 2005 || 0.9.9
|-
| Apr 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| Dec 17, 2007 || 1.0.0
|-
| Dec 22, 2008 || 1.9.0
|-
| Jan 25, 2009 || 1.9.1
|-
| Feb 25, 2010 || 2.0.0
|-
| Aug 17, 2011 || 2.4.0
|-
| Feb 17, 2012 || 2.6.0
|-
| Aug 17, 2012 || 2.8.0
|-
| Feb 17, 2013 || 2.10
|-
| Sep 21, 2013 || 2.12
|-
| Feb 17, 2014 || 3.0
|-
| Oct 15, 2014 || 3.2
|-
| Feb 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| Feb 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2 (bugfix release)
|-
| May 17, 2016 || 2016.2.1
|-
| Sep 12, 2016 || 2016.3.1
|-
| Nov 19, 2016 || 2016.4.1
|-
| Nov 23, 2016 || 2016.4.2 (bugfix release)
|-
| Dec 5, 2016 || 2016.4.3 (bugfix release)
|-
| Dec 28, 2016 || 2016.4.4 (bugfix release)
|-
| Feb 23, 2017 || 2017.1.1
|-
| Mar 1, 2017 || 2017.1.2 (bugfix release)
|-
| Apr 4, 2017 || 2017.1.3 (bugfix release)
|-
| May 22, 2017 || 2017.2.1 (bugfix release)
|-
| Sep 20, 2017 || 2017.3.1
|-
| Apr 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2 (bugfix release)
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4 (bugfix release)
|-
| Apr 20, 2020 || 2018.3.5 (bugfix release)
|-
| Aug 9, 2020 || 2018.3.6 (bugfix release)
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2 (bugfix release)
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2 (bugfix release)
|-
| Jun 26, 2020 || 2020.1.3 (bugfix release)
|-
| 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2 (bugfix release)
|-
| Nov 23, 2020 || 2020.3.3 (bugfix release)
|-
| Dec 1, 2020 || 2020.3.4 (bugfix release)
|-
| Dec 19, 2020 || 2020.3.5 (bugfix release)
|-
| Jan 24, 2021 || 2020.3.6 (bugfix release)
|-
| Mar 21, 2021 || 2020.3.7 (bugfix release)
|-
| Mar 25, 2021 || 2020.3.8 (bugfix release)
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="3" | [[BIKF]] || rowspan="3" | Keflavik
|-
| 2020.2
|-
| 2020.3
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2021-04-25T11:58:06Z

Wkitty42: /* Release timeline */ update released versions and dates

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the [[LaRCsim]] flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an OpenGL based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, although only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of existing features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
|July 17, 1997 || First major code release
|-
|September 23, 1997 || 0.12
|-
|December 9, 1997 || 0.15
|-
|December 17, 1997 || 0.18
|-
|December 30, 1997 || 0.19 (first binaries)
|-
|January 6, 1998 || 0.22
|-
|Mar 11 98 || 0.37
|-
|April 8, 1998 || 0.41
|-
|April 14, 1998 || 0.42
|-
|April 23, 1998 || 0.43
|-
|Apr 28, 1998 || 0.44
|-
|May 7, 1998 || 0.45
|-
|May 11, 1998 || 0.46
|-
|May 18, 1998 || 0.47
|-
|June 9, 1998 || 0.48
|-
|June 27, 1998 || 0.49
|-
|July 13, 1998 || 0.50
|-
|July 21, 1998 || 0.51
|-
|August 15, 1998 || 0.52
|-
|September 2, 1998 || 0.53
|-
|September 25, 1998 || 0.54
|-
|October 23, 1998 || 0.55
|-
|November 23, 1998 || 0.56
|-
|January 21, 1999 || 0.57
|-
|February 10, 1999 || 0.58
|-
|March 31, 1999 || 0.59
|-
|May 26, 1999 || 0.6.0
|-
| June 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | September 11, 1999 || 0.7.0 (Development)
|-
|0.6.2 (Stable)
|-
|October 22, 1999 || 0.7.1 (Development)
|-
|February 17, 2000 || 0.7.2 (Development)
|-
|May 18, 2000 || 0.7.3 (Development)
|-
|July 20, 2000 || 0.7.4
|-
|September 18, 2000 || 0.7.5
|-
|December 19, 2000 || 0.7.6
|-
|June 20, 2001 || 0.7.7
|-
|July 13, 2001 || 0.7.8
|-
| February 16, 2002 || 0.7.9
|-
| April 20, 2002 || 0.7.10
|-
| September 7, 2002 || 0.8.0
|-
| December 3, 2002 || 0.9.0
|-
| December 5, 2002 || 0.9.1
|-
| June 4, 2003 || 0.9.2
|-
| October 24, 2003 || 0.9.3
|-
| March 26, 2004 || 0.9.4
|-
| July 29, 2004 || 0.9.5
|-
| October 12, 2004 || 0.9.6
|-
| January 18, 2005 || 0.9.8
|-
| November 17, 2005 || 0.9.9
|-
| April 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| December 17, 2007 || 1.0.0
|-
| December 22, 2008 || 1.9.0
|-
| January 25, 2009 || 1.9.1
|-
| February 25, 2010 || 2.0.0
|-
| August 17, 2011 || 2.4.0
|-
| February 17, 2012 || 2.6.0
|-
| August 17, 2012 || 2.8.0
|-
| February 17, 2013 || 2.10
|-
| September 21, 2013 || 2.12
|-
| February 17, 2014 || 3.0
|-
| October 15, 2014 || 3.2
|-
| February 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| February 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2 (bugfix release)
|-
| May 17, 2016 || 2016.2.1
|-
| September 12, 2016 || 2016.3.1
|-
| November 19, 2016 || 2016.4.1
|-
| November 23, 2016 || 2016.4.2 (bugfix release)
|-
| December 5, 2016 || 2016.4.3 (bugfix release)
|-
| December 28, 2016 || 2016.4.4 (bugfix release)
|-
| February 23, 2017 || 2017.1.1
|-
| March 1, 2017 || 2017.1.2 (bugfix release)
|-
| April 4, 2017 || 2017.1.3 (bugfix release)
|-
| May 22, 2017 || 2017.2.1 (bugfix release)
|-
| September 20, 2017 || 2017.3.1
|-
| April 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2 (bugfix release)
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4 (bugfix release)
|-
| Apr 20, 2020 || 2018.3.5 (bugfix release)
|-
| Aug 9, 2020 || 2018.3.6 (bugfix release)
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2 (bugfix release)
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2 (bugfix release)
|-
| Jun 26, 2020 || 2020.1.3 (bugfix release)
|-
| 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2 (bugfix release)
|-
| Nov 23, 2020 || 2020.3.3 (bugfix release)
|-
| Dec 1, 2020 || 2020.3.4 (bugfix release)
|-
| Dec 19, 2020 || 2020.3.5 (bugfix release)
|-
| Jan 24, 2021 || 2020.3.6 (bugfix release)
|-
| Mar 21, 2021 || 2020.3.7 (bugfix release)
|-
| Mar 25, 2021 || 2020.3.8 (bugfix release)
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || rowspan="4" | [[PHNL]] || rowspan="4" | Honolulu
|-
| 2018.2
|-
| 2018.3
|-
| 2019.1
|-
| 2020.1 || rowspan="3" | [[BIKF]] || rowspan="3" | Keflavik
|-
| 2020.2
|-
| 2020.3
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

TerraMaster

2021-03-28T22:11:59Z

Wkitty42: after 6 years, i don't think we need the note about the old google code hosted scenery site any more...

{{Infobox Software
|title = TerraMaster
|logo =
|image = TerraMaster r32 - Global view.png
|developedby = reeed, portree kid
|initialrelease = July 18, 2011
|latestrelease = January 30, 2019 (v2.03)
|writtenin = Java
|os =
|platform = Cross-platform
|developmentstatus =
|type = Scenery manager
|license = [[GNU GPL]] v2
|website = https://portree-kid.github.io/terramaster/
}}

'''TerraMaster''' is a graphical [[scenery]] manager that gives you a quick overview of your scenery and makes it easier to maintain that scenery. TerraMaster is a cross platform stand alone application written in Java that synchronises [[TerraSync]] scenery tiles you select with the FlightGear Scenery Database. You can delete scenery tiles if the TerraSync scenery directory takes too much space, and you can also search for airports.

== Overview ==
=== Map ===
When TerraMaster starts it will show a map of the Earth. The map can be zoomed and one or more 1x1 degree tiles can be selected before they are synced or deleted. All the airports within a tile can be shown, and airports can be searched for and be shown.

=== Icons ===
The top row contains a status field, two groups of icon buttons, a search field and a sync progress bar. The icons will be grayed out when they can not be used. For more detailed directions, see the section [[#Using|Using]] below. From left to right:
* ''Status field''. Shows the name of the tile that was last selected.

* ''Sync icon''. Syncs the tiles currently selected.
* ''Clock icon''. Syncs old tiles.
* ''Flight icon''. Opens a dialog to help selecting a route.
* ''Trash can icon''. Deletes the currently selected tiles.
* ''Eye icon''. Shows all airports in the first selected tile of the currently selected tiles.
* ''Stop button''. Currently does not work.

* ''Empty paper''. Hides all shown airports.
* ''Globe icon''. Zooms out to the global view.
* ''Gear icon''. Opens a dialogue to select the location of the TerraSync scenery directory.

* ''Search field''. Used to search for airports.

* ''Sync progress bar''. Only visible during syncing.

=== Tile border colours ===
The tiles are colour coded to represent the state of the tiles:

* '''Green''' tiles have both terrain and objects.
* '''Amber/Yellow''' tiles has terrain but no objects. (And are possibly unsyncable - see "Bug", below.)
* '''Red''' tiles are currently selected for synchronisation.
* '''Blue''' tiles are currently being synchronised.

The blue tiles that are being synced will change colour to green or amber/yellow as they are synced. Tiles that get no border after they have been synced don't contain terrain or objects and are usually located in open seas.

== Using ==
[[File:TerraMaster r32 - Mouse hint.png|thumb|Tile information pop-up when holding the mouse pointer over a tile.]]
[[File:TerraMaster r32 - Airports in selected tile.png|thumb|Showing all airports in a selected tile using the "eye" button.]]
[[File:TerraMaster r32 - Searching for an airport.png|thumb|Searching for an airport.]]

=== Zooming and panning ===
TerraMaster with the global view. Left-clicking will zoom you in on an area.

'''Zoom''' using the scroll wheel.

'''Pan''' around by dragging the map while pressing the right mouse button.

Get '''back to global view''' by clicking the "globe" icon.

=== Showing tile information ===
To get some information about a downloaded tile, hold the mouse pointer over it.

A pop-up box will show the name of that tile, if there are terrain and objects in it and what airports it contains. This only works if a tile has been synced, either with Terrasync or TerraMaster.

=== Syncing tiles ===
To '''select just one tile''' left-click it. The scenery for download is available in 1x1 degree tiles.

To '''select more tiles''' press the Ctrl key while left-clicking or left-dragging over the wanted tiles. If you accidentally selected a tile to many, '''deselect tiles''' using it Ctrl+left-click. You can also deselect several tiles using Ctrl+left-click and dragging.

'''Start the update and/or download''' clicking the "sync" icon. The tiles will be downloaded starting from the first tile you selected and proceed in order of distance from it. If you are downloading tiles for a long flight you should then begin by selecting a tile close to the departure airport.

=== Syncing old tiles ===

'''Start the update and/or download''' clicking the 2nd "sync" icon. All previously downloaded tiles that are older than the age given in the settings, will be downloaded.

=== Deleting tiles ===
You can delete files from the TerraSync scenery by selecting the tiles you want to delete and click the "trash can" icon.

=== Showing all airports in a tile ===
To show all airports in a tile, select it and click on the "eye" icon. To hide the airports again, click the "empty paper" icon.

=== Searching for an airport ===
You can search for airports using the search field and pressing enter. The airports location an ICAO code will be shown in white on the map. If you don't see it, zoom out. ICAO airport codes works best, but sometimes the airport's name also work. To hide the airports again, click the "empty paper" icon.

Be warned that the search function is rather slow as it uses a web query to mpmap.flightgear.org and that it also doesn't tell if there was no airports found.

== Video tutorial ==
Here is a short video tutorial:
{{#ev:youtube|YxWV4wk_dHw}}

== Tips ==
* '''Before [[multiplayer]] events''' it might be an idea to sync the related tiles, even more so if you know that someone has crated new buildings etc. and got them into the [[FlightGear Scenery Database|scenery database]].
* If you have very little hard drive space left you can delete tiles you rarely or never fly within.
* Starting TerraMaster in a console window will let you see the sync process, which can be useful if the sync stalls for unknown reasons.
* If you already have a synchronisation running and want to add more tiles to be synced, just mark more tiles as above with Ctrl + leftclick and drag to mark more tiles and press the sync button again.

== Installing ==
Before installing, make sure you have Java 6 or higher, as it is needed.

# Download the newest version of TerraMaster from the [https://github.com/Portree-Kid/terramaster/releases releases page].
# Create a shortcut or script that runs <code>java -jar terramaster.jar</code>.
# When running TerraMaster the first time, click the "gear" icon and select the folder where your TerraSync scenery is located. On some machines you might have to manually edit the property file to have it pointing to the TerraSync directory.
# Done!

== Models ==
<strike>Don't forget that the contents of <tt>''TerraSync/Models''</tt> will have to be copied to <tt>''[[$FG_ROOT]]/Models''</tt> for them to be visible.</strike>

{{note|Since at least FG v3.4, it is no longer necessary to move or copy the <tt>''TerraSync/Models''</tt> folder. FlightGear will find and use the models in the <tt>''TerraSync/Models''</tt> directory with no problems.}}

== Related content ==
* [[FlightGear Admin Wizard]]

== External link ==
* {{forum link|title=TerraMaster: a new scenery manager|t=12050}}

[[Category:Scenery software]]

Command line options

2021-03-25T13:29:00Z

Wkitty42: /* General Options */ add --texture-cache-dir option to the list

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--fg-aircraft=path Specify additional aircraft directory path(s)
(alternatively, you can use --aircraft-dir to
target a specific aircraft in a given
directory)
--texture-cache-dir=path Set the DDS texture cache directory to be different
than the default location
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:foo=bar Set property named "foo" to value "bar"
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry/resolution (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign=name Assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
See also [[Commonly used debugging tools#fgfs.log]]
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:FlightGear]]
[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]
[[pl:Opcje wiersza poleceń]]

FlightGear history

2021-01-25T22:25:04Z

Wkitty42: /* Release timeline */ added 2020.3.5 and 2020.3.6...

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the LaRCsim flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an [[OpenGL]] based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, altough only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of exsisting features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
|July 17, 1997 || First major code release
|-
|September 23, 1997 || 0.12
|-
|December 9, 1997 || 0.15
|-
|December 17, 1997 || 0.18
|-
|December 30, 1997 || 0.19 (first binaries)
|-
|January 6, 1998 || 0.22
|-
|Mar 11 98 || 0.37
|-
|April 8, 1998 || 0.41
|-
|April 14, 1998 || 0.42
|-
|April 23, 1998 || 0.43
|-
|Apr 28, 1998 || 0.44
|-
|May 7, 1998 || 0.45
|-
|May 11, 1998 || 0.46
|-
|May 18, 1998 || 0.47
|-
|June 9, 1998 || 0.48
|-
|June 27, 1998 || 0.49
|-
|July 13, 1998 || 0.50
|-
|July 21, 1998 || 0.51
|-
|August 15, 1998 || 0.52
|-
|September 2, 1998 || 0.53
|-
|September 25, 1998 || 0.54
|-
|October 23, 1998 || 0.55
|-
|November 23, 1998 || 0.56
|-
|January 21, 1999 || 0.57
|-
|February 10, 1999 || 0.58
|-
|March 31, 1999 || 0.59
|-
|May 26, 1999 || 0.6.0
|-
| June 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | September 11, 1999 || 0.7.0 (Development)
|-
|0.6.2 (Stable)
|-
|October 22, 1999 || 0.7.1 (Development)
|-
|February 17, 2000 || 0.7.2 (Development)
|-
|May 18, 2000 || 0.7.3 (Development)
|-
|July 20, 2000 || 0.7.4
|-
|September 18, 2000 || 0.7.5
|-
|December 19, 2000 || 0.7.6
|-
|June 20, 2001 || 0.7.7
|-
|July 13, 2001 || 0.7.8
|-
| February 16, 2002 || 0.7.9
|-
| April 20, 2002 || 0.7.10
|-
| September 7, 2002 || 0.8.0
|-
| December 3, 2002 || 0.9.0
|-
| December 5, 2002 || 0.9.1
|-
| June 4, 2003 || 0.9.2
|-
| October 24, 2003 || 0.9.3
|-
| March 26, 2004 || 0.9.4
|-
| July 29, 2004 || 0.9.5
|-
| October 12, 2004 || 0.9.6
|-
| January 18, 2005 || 0.9.8
|-
| November 17, 2005 || 0.9.9
|-
| April 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| December 17, 2007 || 1.0.0
|-
| December 22, 2008 || 1.9.0
|-
| January 25, 2009 || 1.9.1
|-
| February 25, 2010 || 2.0.0
|-
| August 17, 2011 || 2.4.0
|-
| February 17, 2012 || 2.6.0
|-
| August 17, 2012 || 2.8.0
|-
| February 17, 2013 || 2.10
|-
| September 21, 2013 || 2.12
|-
| February 17, 2014 || 3.0
|-
| October 15, 2014 || 3.2
|-
| February 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| February 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2 (bugfix release)
|-
| May 17, 2016 || 2016.2.1
|-
| September 12, 2016 || 2016.3.1
|-
| November 19, 2016 || 2016.4.1
|-
| November 23, 2016 || 2016.4.2 (bugfix release)
|-
| December 5, 2016 || 2016.4.3 (bugfix release)
|-
| December 28, 2016 || 2016.4.4 (bugfix release)
|-
| February 23, 2017 || 2017.1.1
|-
| March 1, 2017 || 2017.1.2 (bugfix release)
|-
| April 4, 2017 || 2017.1.3 (bugfix release)
|-
| May 22, 2017 || 2017.2.1 (bugfix release)
|-
| September 20, 2017 || 2017.3.1
|-
| April 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2 (bugfix release)
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4 (bugfix release)
|-
| Apr 20, 2020 || 2018.3.5 (bugfix release)
|-
| Aug 9, 2020 || 2018.3.6 (bugfix release)
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2 (bugfix release)
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2 (bugfix release)
|-
| Jun 26, 2020 || 2020.1.3 (bugfix release)
|-
| 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2 (bugfix release)
|-
| Nov 23, 2020 || 2020.3.3 (bugfix release)
|-
| Dec 1, 2020 || 2020.3.4 (bugfix release)
|-
| Dec 19, 2020 || 2020.3.5 (bugfix release)
|-
| Jan 24, 2021 || 2020.3.6 (bugfix release)
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || [[PHNL]] || Honolulu
|-
| 2018.2 || [[PHNL]] || Honolulu
|-
| 2018.3 || [[PHNL]] || Honolulu
|-
| 2019.1 || [[PHNL]] || Honolulu
|-
| 2020.1 || [[BIKF]] || Keflavik
|-
| 2020.2 || [[BIKF]] || Keflavik
|-
| 2020.3 || [[BIKF]] || Keflavik
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2020-12-14T16:46:26Z

Wkitty42: /* Release timeline */ fix 2020.3.3 entry

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the LaRCsim flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an [[OpenGL]] based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, altough only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of exsisting features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
|July 17, 1997 || First major code release
|-
|September 23, 1997 || 0.12
|-
|December 9, 1997 || 0.15
|-
|December 17, 1997 || 0.18
|-
|December 30, 1997 || 0.19 (first binaries)
|-
|January 6, 1998 || 0.22
|-
|Mar 11 98 || 0.37
|-
|April 8, 1998 || 0.41
|-
|April 14, 1998 || 0.42
|-
|April 23, 1998 || 0.43
|-
|Apr 28, 1998 || 0.44
|-
|May 7, 1998 || 0.45
|-
|May 11, 1998 || 0.46
|-
|May 18, 1998 || 0.47
|-
|June 9, 1998 || 0.48
|-
|June 27, 1998 || 0.49
|-
|July 13, 1998 || 0.50
|-
|July 21, 1998 || 0.51
|-
|August 15, 1998 || 0.52
|-
|September 2, 1998 || 0.53
|-
|September 25, 1998 || 0.54
|-
|October 23, 1998 || 0.55
|-
|November 23, 1998 || 0.56
|-
|January 21, 1999 || 0.57
|-
|February 10, 1999 || 0.58
|-
|March 31, 1999 || 0.59
|-
|May 26, 1999 || 0.6.0
|-
| June 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | September 11, 1999 || 0.7.0 (Development)
|-
|0.6.2 (Stable)
|-
|October 22, 1999 || 0.7.1 (Development)
|-
|February 17, 2000 || 0.7.2 (Development)
|-
|May 18, 2000 || 0.7.3 (Development)
|-
|July 20, 2000 || 0.7.4
|-
|September 18, 2000 || 0.7.5
|-
|December 19, 2000 || 0.7.6
|-
|June 20, 2001 || 0.7.7
|-
|July 13, 2001 || 0.7.8
|-
| February 16, 2002 || 0.7.9
|-
| April 20, 2002 || 0.7.10
|-
| September 7, 2002 || 0.8.0
|-
| December 3, 2002 || 0.9.0
|-
| December 5, 2002 || 0.9.1
|-
| June 4, 2003 || 0.9.2
|-
| October 24, 2003 || 0.9.3
|-
| March 26, 2004 || 0.9.4
|-
| July 29, 2004 || 0.9.5
|-
| October 12, 2004 || 0.9.6
|-
| January 18, 2005 || 0.9.8
|-
| November 17, 2005 || 0.9.9
|-
| April 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| December 17, 2007 || 1.0.0
|-
| December 22, 2008 || 1.9.0
|-
| January 25, 2009 || 1.9.1
|-
| February 25, 2010 || 2.0.0
|-
| August 17, 2011 || 2.4.0
|-
| February 17, 2012 || 2.6.0
|-
| August 17, 2012 || 2.8.0
|-
| February 17, 2013 || 2.10
|-
| September 21, 2013 || 2.12
|-
| February 17, 2014 || 3.0
|-
| October 15, 2014 || 3.2
|-
| February 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| February 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2 (bugfix release)
|-
| May 17, 2016 || 2016.2.1
|-
| September 12, 2016 || 2016.3.1
|-
| November 19, 2016 || 2016.4.1
|-
| November 23, 2016 || 2016.4.2 (bugfix release)
|-
| December 5, 2016 || 2016.4.3 (bugfix release)
|-
| December 28, 2016 || 2016.4.4 (bugfix release)
|-
| February 23, 2017 || 2017.1.1
|-
| March 1, 2017 || 2017.1.2 (bugfix release)
|-
| April 4, 2017 || 2017.1.3 (bugfix release)
|-
| May 22, 2017 || 2017.2.1 (bugfix release)
|-
| September 20, 2017 || 2017.3.1
|-
| April 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2 (bugfix release)
|-
| {{N/a}} || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4 (bugfix release)
|-
| Apr 20, 2020 || 2018.3.5 (bugfix release)
|-
| Aug 9, 2020 || 2018.3.6 (bugfix release)
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2 (bugfix release)
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2 (bugfix release)
|-
| Jun 26, 2020 || 2020.1.3 (bugfix release)
|-
| 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2 (bugfix release)
|-
| Nov 23, 2020 || 2020.3.3 (bugfix release)
|-
| Dec 1, 2020 || 2020.3.4 (bugfix release)
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || [[PHNL]] || Honolulu
|-
| 2018.2 || [[PHNL]] || Honolulu
|-
| 2018.3 || [[PHNL]] || Honolulu
|-
| 2019.1 || [[PHNL]] || Honolulu
|-
| 2020.1 || [[BIKF]] || Keflavik
|-
| 2020.2 || [[BIKF]] || Keflavik
|-
| 2020.3 || [[BIKF]] || Keflavik
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2020-12-14T16:43:50Z

Wkitty42: /* Release timeline */ added dates from earlier

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the LaRCsim flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an [[OpenGL]] based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, altough only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of exsisting features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
|July 17, 1997 || First major code release
|-
|September 23, 1997 || 0.12
|-
|December 9, 1997 || 0.15
|-
|December 17, 1997 || 0.18
|-
|December 30, 1997 || 0.19 (first binaries)
|-
|January 6, 1998 || 0.22
|-
|Mar 11 98 || 0.37
|-
|April 8, 1998 || 0.41
|-
|April 14, 1998 || 0.42
|-
|April 23, 1998 || 0.43
|-
|Apr 28, 1998 || 0.44
|-
|May 7, 1998 || 0.45
|-
|May 11, 1998 || 0.46
|-
|May 18, 1998 || 0.47
|-
|June 9, 1998 || 0.48
|-
|June 27, 1998 || 0.49
|-
|July 13, 1998 || 0.50
|-
|July 21, 1998 || 0.51
|-
|August 15, 1998 || 0.52
|-
|September 2, 1998 || 0.53
|-
|September 25, 1998 || 0.54
|-
|October 23, 1998 || 0.55
|-
|November 23, 1998 || 0.56
|-
|January 21, 1999 || 0.57
|-
|February 10, 1999 || 0.58
|-
|March 31, 1999 || 0.59
|-
|May 26, 1999 || 0.6.0
|-
| June 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | September 11, 1999 || 0.7.0 (Development)
|-
|0.6.2 (Stable)
|-
|October 22, 1999 || 0.7.1 (Development)
|-
|February 17, 2000 || 0.7.2 (Development)
|-
|May 18, 2000 || 0.7.3 (Development)
|-
|July 20, 2000 || 0.7.4
|-
|September 18, 2000 || 0.7.5
|-
|December 19, 2000 || 0.7.6
|-
|June 20, 2001 || 0.7.7
|-
|July 13, 2001 || 0.7.8
|-
| February 16, 2002 || 0.7.9
|-
| April 20, 2002 || 0.7.10
|-
| September 7, 2002 || 0.8.0
|-
| December 3, 2002 || 0.9.0
|-
| December 5, 2002 || 0.9.1
|-
| June 4, 2003 || 0.9.2
|-
| October 24, 2003 || 0.9.3
|-
| March 26, 2004 || 0.9.4
|-
| July 29, 2004 || 0.9.5
|-
| October 12, 2004 || 0.9.6
|-
| January 18, 2005 || 0.9.8
|-
| November 17, 2005 || 0.9.9
|-
| April 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| December 17, 2007 || 1.0.0
|-
| December 22, 2008 || 1.9.0
|-
| January 25, 2009 || 1.9.1
|-
| February 25, 2010 || 2.0.0
|-
| August 17, 2011 || 2.4.0
|-
| February 17, 2012 || 2.6.0
|-
| August 17, 2012 || 2.8.0
|-
| February 17, 2013 || 2.10
|-
| September 21, 2013 || 2.12
|-
| February 17, 2014 || 3.0
|-
| October 15, 2014 || 3.2
|-
| February 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| February 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2 (bugfix release)
|-
| May 17, 2016 || 2016.2.1
|-
| September 12, 2016 || 2016.3.1
|-
| November 19, 2016 || 2016.4.1
|-
| November 23, 2016 || 2016.4.2 (bugfix release)
|-
| December 5, 2016 || 2016.4.3 (bugfix release)
|-
| December 28, 2016 || 2016.4.4 (bugfix release)
|-
| February 23, 2017 || 2017.1.1
|-
| March 1, 2017 || 2017.1.2 (bugfix release)
|-
| April 4, 2017 || 2017.1.3 (bugfix release)
|-
| May 22, 2017 || 2017.2.1 (bugfix release)
|-
| September 20, 2017 || 2017.3.1
|-
| April 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| Dec 3, 2018 || 2018.3.1
|-
| Jan 29, 2019 || 2018.3.2 (bugfix release)
|-
| || 2018.3.3 (not released)
|-
| Aug 9, 2019 || 2018.3.4 (bugfix release)
|-
| Apr 20, 2020 || 2018.3.5 (bugfix release)
|-
| Aug 9, 2020 || 2018.3.6 (bugfix release)
|-
| Mar 14, 2019 || 2019.1.1
|-
| Sep 1, 2019 || 2019.1.2 (bugfix release)
|-
| May 11, 2020 || 2020.1.1
|-
| May 25, 2020 || 2020.1.2 (bugfix release)
|-
| Jun 26, 2020 || 2020.1.3 (bugfix release)
|-
| 2020 || 2020.2.1
|-
| Oct 29, 2020 || 2020.3.1
|-
| Nov 6, 2020 || 2020.3.2 (bugfix release)
|-
| Nov 23, 2020 || 2020.3.3 (bugfix release)
|-
| Dec 1, 2020 || 2020.3.4 (bugfix release)
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || [[PHNL]] || Honolulu
|-
| 2018.2 || [[PHNL]] || Honolulu
|-
| 2018.3 || [[PHNL]] || Honolulu
|-
| 2019.1 || [[PHNL]] || Honolulu
|-
| 2020.1 || [[BIKF]] || Keflavik
|-
| 2020.2 || [[BIKF]] || Keflavik
|-
| 2020.3 || [[BIKF]] || Keflavik
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2020-12-14T12:03:47Z

Wkitty42: /* Cycled default airports */ adding new releases since 2018.2

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the LaRCsim flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an [[OpenGL]] based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, altough only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of exsisting features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
|July 17, 1997 || First major code release
|-
|September 23, 1997 || 0.12
|-
|December 9, 1997 || 0.15
|-
|December 17, 1997 || 0.18
|-
|December 30, 1997 || 0.19 (first binaries)
|-
|January 6, 1998 || 0.22
|-
|Mar 11 98 || 0.37
|-
|April 8, 1998 || 0.41
|-
|April 14, 1998 || 0.42
|-
|April 23, 1998 || 0.43
|-
|Apr 28, 1998 || 0.44
|-
|May 7, 1998 || 0.45
|-
|May 11, 1998 || 0.46
|-
|May 18, 1998 || 0.47
|-
|June 9, 1998 || 0.48
|-
|June 27, 1998 || 0.49
|-
|July 13, 1998 || 0.50
|-
|July 21, 1998 || 0.51
|-
|August 15, 1998 || 0.52
|-
|September 2, 1998 || 0.53
|-
|September 25, 1998 || 0.54
|-
|October 23, 1998 || 0.55
|-
|November 23, 1998 || 0.56
|-
|January 21, 1999 || 0.57
|-
|February 10, 1999 || 0.58
|-
|March 31, 1999 || 0.59
|-
|May 26, 1999 || 0.6.0
|-
| June 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | September 11, 1999 || 0.7.0 (Development)
|-
|0.6.2 (Stable)
|-
|October 22, 1999 || 0.7.1 (Development)
|-
|February 17, 2000 || 0.7.2 (Development)
|-
|May 18, 2000 || 0.7.3 (Development)
|-
|July 20, 2000 || 0.7.4
|-
|September 18, 2000 || 0.7.5
|-
|December 19, 2000 || 0.7.6
|-
|June 20, 2001 || 0.7.7
|-
|July 13, 2001 || 0.7.8
|-
| February 16, 2002 || 0.7.9
|-
| April 20, 2002 || 0.7.10
|-
| September 7, 2002 || 0.8.0
|-
| December 3, 2002 || 0.9.0
|-
| December 5, 2002 || 0.9.1
|-
| June 4, 2003 || 0.9.2
|-
| October 24, 2003 || 0.9.3
|-
| March 26, 2004 || 0.9.4
|-
| July 29, 2004 || 0.9.5
|-
| October 12, 2004 || 0.9.6
|-
| January 18, 2005 || 0.9.8
|-
| November 17, 2005 || 0.9.9
|-
| April 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| December 17, 2007 || 1.0.0
|-
| December 22, 2008 || 1.9.0
|-
| January 25, 2009 || 1.9.1
|-
| February 25, 2010 || 2.0.0
|-
| August 17, 2011 || 2.4.0
|-
| February 17, 2012 || 2.6.0
|-
| August 17, 2012 || 2.8.0
|-
| February 17, 2013 || 2.10
|-
| September 21, 2013 || 2.12
|-
| February 17, 2014 || 3.0
|-
| October 15, 2014 || 3.2
|-
| February 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| February 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2 (bugfix release)
|-
| May 17, 2016 || 2016.2.1
|-
| September 12, 2016 || 2016.3.1
|-
| November 19, 2016 || 2016.4.1
|-
| November 23, 2016 || 2016.4.2 (bugfix release)
|-
| December 5, 2016 || 2016.4.3 (bugfix release)
|-
| December 28, 2016 || 2016.4.4 (bugfix release)
|-
| February 23, 2017 || 2017.1.1
|-
| March 1, 2017 || 2017.1.2 (bugfix release)
|-
| April 4, 2017 || 2017.1.3 (bugfix release)
|-
| May 22, 2017 || 2017.2.1 (bugfix release)
|-
| September 20, 2017 || 2017.3.1
|-
| April 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| 2018 || 2018.3.1
|-
| 2018 || 2018.3.2 (bugfix release)
|-
| 2018 || 2018.3.3 (bugfix release)
|-
| 2018 || 2018.3.4 (bugfix release)
|-
| 2018 || 2018.3.5 (bugfix release)
|-
| 2018 || 2018.3.6 (bugfix release)
|-
| 2019 || 2019.1.1
|-
| 2020 || 2020.1.1
|-
| 2020 || 2020.1.2 (bugfix release)
|-
| 2020 || 2020.1.3 (bugfix release)
|-
| 2020 || 2020.1.4 (bugfix release)
|-
| 2020 || 2020.2.1
|-
| 2020 || 2020.3.1
|-
| 2020 || 2020.3.2 (bugfix release)
|-
| 2020 || 2020.3.3 (bugfix release)
|-
| 2020 || 2020.3.4 (bugfix release)
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || [[PHNL]] || Honolulu
|-
| 2018.2 || [[PHNL]] || Honolulu
|-
| 2018.3 || [[PHNL]] || Honolulu
|-
| 2019.1 || [[PHNL]] || Honolulu
|-
| 2020.1 || [[BIKF]] || Keflavik
|-
| 2020.2 || [[BIKF]] || Keflavik
|-
| 2020.3 || [[BIKF]] || Keflavik
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FlightGear history

2020-12-14T11:56:24Z

Wkitty42: /* Release timeline */ add missing releases since 2018.1.2 - still need to research release dates and update the table with them

[[FlightGear]] development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.

FlightGear incorporated other open-source resources, including the LaRCsim flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.

In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.

== Beginnings (1996-1997) ==
[[File:FG SUNHALO.JPG|thumb|270px|March 18, 1999: one of the oldest surviving screenshots of FlightGear. Back then, FlightGear was the only PC based flight simulator rendering the [[Moon|sun, moon, and celestial]] objects at the correct position, and under the correct lighting conditions, in the sky. ]]
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis.
 
Development of an [[OpenGL]] based version was spearheaded by Curtis Olsen starting in 1997, after the initial start in 1996. A large community response lead to many contributing to the project from its start in late '90s up to the present.
 
"''I was working at the University of Minnesota at the time, and had access to Sun and SGI graphical work stations which offered OpenGL for 3d graphics. OpenGl was just starting to become available on PC hardware with things like the 3dfx voodoo card. Somewhere at this point it occurred to me that a far better path would be to leverage an existing multi-platform 3d graphics system (like OpenGL) to build our flight simulator upon.''

''So I proceeded to rough together a basic scenery system, pasted on the larcsim flight model, and in a relatively short time was able to show actual flight over real 3d terrain. Good, realistic 3d terrain was something the other existing flight sims at the time were pretty far behind on ... and I think my work was enough of a breakthrough that it got a lot of people excited about the possibilities.''"~Curt Olson <ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>
 
Rather than start entirely from scratch, FlightGear developers made use of the LaRCsim flight model from NASA, with OpenGL for 3D graphic code, and freely available elevation data. First working binaries came out in 1997, with an intense updating of newer versions for several years resulting in progressively more stable and advanced programs.

== Versions 0.7–0.9 (2001–2003) ==
By 2001, the team was releasing new beta versions regularly (0.7.x, 0.8.0, over 2001-2003) and with 0.9.xx (2003-2006). Later in the decade, the rate of final public releases slowed, but had larger amounts of content (0.9.10, 1.0.0 etc.). The maturity of software by 2005 lead to more widespread reviews, and increased popularity.

== Version 0.9.0-0.9.11 (2002-2007) ==
The use of version numbers slowed dramatically after the late 2002 release of version 0.9.0. Versions 0.9.9 (2005) and 0.9.10 (2006) had about 8 all-new or redone [[aircraft]] adding to a total of 70-90 aircraft. [[Nasal]] was also integrated into FlightGear in version 0.9.4. FlightGear 0.9.10 won Softpedia's "Pick" award (5 out of 5 stars) on June 3, 2006 as well as the "100% CLEAN" Softpedia award.

Behind the scenes there was a 0.9.11-pre1 released in 2007 that ended up being superseded by FlightGear 1.0. The pre-version had about 33 new or redone aircraft.

[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]

== Version 1.0 (2008) ==
The version number marked a formal transition out of beta development since the software's first release in 1997, ten years prior.

== Version 1.9.0 (2008) ==
At the time version 1.9.0 was released FlightGear switched from [[PLIB]] to [[OSG]], which caused the temporary loss of some of the features like 3D clouds and shadows. On the contrary new features such as particles add another degree of realism to the simulation. Most aircraft developed for OSG do not work with older versions. The user is able to choose from 230 aircraft provided with 1.9.0, altough only a few are included in the base package.
Version 1.9.1, released shortly afterwards, was a bug fix release.

== Version 2.0.0 (2010) ==
FlightGear 2.0.0 reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0 marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of exsisting features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models.

== Version 2.4.0 (2011) ==
Starting with version 2.4.0, the FlightGear team adopted a [[release plan]]. From then on, a new version is released every February and August.

==Version 3.8.0/2016.1.0==
{{Main article|Release plan#Detailed time schedule and checklist}}
Following the cancellation of 3.6, the modern FlightGear team revised the release plan and process. New releases are essentially selected and tuned "nightlies" instead of special compilations.

Also, in this release the concept of rotating default airports first started. All FlightGear releases after 2016.1 have unique default airports and 'codenames'.

{{Main article|Release plan/Lessons learned#2016.1}}

== Release timeline ==
Final build code release dates by year.

{| class="mw-collapsible mw-collapsed wikitable" style="width:40%; margin:auto"
! Date !! Version
|-
|July 17, 1997 || First major code release
|-
|September 23, 1997 || 0.12
|-
|December 9, 1997 || 0.15
|-
|December 17, 1997 || 0.18
|-
|December 30, 1997 || 0.19 (first binaries)
|-
|January 6, 1998 || 0.22
|-
|Mar 11 98 || 0.37
|-
|April 8, 1998 || 0.41
|-
|April 14, 1998 || 0.42
|-
|April 23, 1998 || 0.43
|-
|Apr 28, 1998 || 0.44
|-
|May 7, 1998 || 0.45
|-
|May 11, 1998 || 0.46
|-
|May 18, 1998 || 0.47
|-
|June 9, 1998 || 0.48
|-
|June 27, 1998 || 0.49
|-
|July 13, 1998 || 0.50
|-
|July 21, 1998 || 0.51
|-
|August 15, 1998 || 0.52
|-
|September 2, 1998 || 0.53
|-
|September 25, 1998 || 0.54
|-
|October 23, 1998 || 0.55
|-
|November 23, 1998 || 0.56
|-
|January 21, 1999 || 0.57
|-
|February 10, 1999 || 0.58
|-
|March 31, 1999 || 0.59
|-
|May 26, 1999 || 0.6.0
|-
| June 21, 1999 || 0.6.1 (Stable)
|-
|rowspan=2 | September 11, 1999 || 0.7.0 (Development)
|-
|0.6.2 (Stable)
|-
|October 22, 1999 || 0.7.1 (Development)
|-
|February 17, 2000 || 0.7.2 (Development)
|-
|May 18, 2000 || 0.7.3 (Development)
|-
|July 20, 2000 || 0.7.4
|-
|September 18, 2000 || 0.7.5
|-
|December 19, 2000 || 0.7.6
|-
|June 20, 2001 || 0.7.7
|-
|July 13, 2001 || 0.7.8
|-
| February 16, 2002 || 0.7.9
|-
| April 20, 2002 || 0.7.10
|-
| September 7, 2002 || 0.8.0
|-
| December 3, 2002 || 0.9.0
|-
| December 5, 2002 || 0.9.1
|-
| June 4, 2003 || 0.9.2
|-
| October 24, 2003 || 0.9.3
|-
| March 26, 2004 || 0.9.4
|-
| July 29, 2004 || 0.9.5
|-
| October 12, 2004 || 0.9.6
|-
| January 18, 2005 || 0.9.8
|-
| November 17, 2005 || 0.9.9
|-
| April 5, 2006 || 0.9.10
|-
| May 2007 || 0.9.11-pre1
|-
| December 17, 2007 || 1.0.0
|-
| December 22, 2008 || 1.9.0
|-
| January 25, 2009 || 1.9.1
|-
| February 25, 2010 || 2.0.0
|-
| August 17, 2011 || 2.4.0
|-
| February 17, 2012 || 2.6.0
|-
| August 17, 2012 || 2.8.0
|-
| February 17, 2013 || 2.10
|-
| September 21, 2013 || 2.12
|-
| February 17, 2014 || 3.0
|-
| October 15, 2014 || 3.2
|-
| February 17, 2015 || 3.4
|-
| {{N/a}} || 3.6 (unreleased, see [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|here]])
|-
| February 17, 2016 || 2016.1.1 (new versioning scheme)
|-
| May 7, 2016 || 2016.1.2 (bugfix release)
|-
| May 17, 2016 || 2016.2.1
|-
| September 12, 2016 || 2016.3.1
|-
| November 19, 2016 || 2016.4.1
|-
| November 23, 2016 || 2016.4.2 (bugfix release)
|-
| December 5, 2016 || 2016.4.3 (bugfix release)
|-
| December 28, 2016 || 2016.4.4 (bugfix release)
|-
| February 23, 2017 || 2017.1.1
|-
| March 1, 2017 || 2017.1.2 (bugfix release)
|-
| April 4, 2017 || 2017.1.3 (bugfix release)
|-
| May 22, 2017 || 2017.2.1 (bugfix release)
|-
| September 20, 2017 || 2017.3.1
|-
| April 11, 2018 || 2018.1.1
|-
| May 22, 2018 || 2018.2.1
|-
| 2018 || 2018.3.1
|-
| 2018 || 2018.3.2 (bugfix release)
|-
| 2018 || 2018.3.3 (bugfix release)
|-
| 2018 || 2018.3.4 (bugfix release)
|-
| 2018 || 2018.3.5 (bugfix release)
|-
| 2018 || 2018.3.6 (bugfix release)
|-
| 2019 || 2019.1.1
|-
| 2020 || 2020.1.1
|-
| 2020 || 2020.1.2 (bugfix release)
|-
| 2020 || 2020.1.3 (bugfix release)
|-
| 2020 || 2020.1.4 (bugfix release)
|-
| 2020 || 2020.2.1
|-
| 2020 || 2020.3.1
|-
| 2020 || 2020.3.2 (bugfix release)
|-
| 2020 || 2020.3.3 (bugfix release)
|-
| 2020 || 2020.3.4 (bugfix release)
|}

== Cycled default airports ==

FlightGear did not start changing the default airport until version 2016.1 was released. At that time, the idea was that each new release would have a new default airport. This chart lists the default airports since 2016.1 was released.

{| class="wikitable"
|-
! Release !! ICAO !! Default Airport
|-
| 2016.1 || [[KSFO]] || San Francisco ''(transition)''
|-
| 2016.2 || [[LEBL]] || Barcelona
|-
| 2016.3 || [[SBRJ]] || Rio de Janeiro
|-
| 2016.4 || [[LSZH]] || Zürich
|-
| 2017.1 || [[ENBR]] || Bergen
|-
| 2017.2 || [[KBOS]] || Boston
|-
| 2017.3 || [[LKPR]] || Prague
|-
| 2018.1 || [[PHNL]] || Honolulu
|-
| 2018.2 || [[PHNL]] || Honolulu
|}

== External links ==
* [http://web.archive.org/web/*/http://www.flightgear.org/ Internet Archive: Wayback Machine for http://www.flightgear.org/ ]
* [http://web.archive.org/web/19981212014011/http://flightgear.org/ Old website on December 5, 1998]
* [http://web.archive.org/web/19990209082206/http://www.flightgear.org/Gallery/tucson.jpg link] ("A view from the ground near Tucson, AZ (KTUS)", old FlightGear screenshot)
* [http://web.archive.org/web/19990209050729/http://www.flightgear.org/Gallery/texture2.jpg link] ("Here's one of the Grand Canyon with a rock face texture. I know this looks funny, but I'm just experimenting here.", old FlightGear screenshot)

{{Appendix|2=
* {{wikipedia|FlightGear}}
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)
* [ftp://flightgear.wo0t.de/flightgear-ftp/ FlightGear FTP Archive]
----
{{References}}
}}

[[Category:FlightGear]]

FG777Controller

2020-12-13T17:00:37Z

Wkitty42: add missing '=' to telnet portion of command line

{{Infobox Software
| title = FG777Controller
| image = FG777Controller Panel.png
| alt = Controller Panel.
| developedby = Eduardo Crispim
| initialrelease = 1.0.0 (July, 2016)
| latestrelease = 1.0.0 (July, 2016)
| developmentstatus = active
| writtenin = Python/kivy
| os = Android
| license = [[GNU General Public License]]
| website = https://github.com/emcrispim/fg777controller/
}}

This application allows control the [[Boeing 777]] Airplane with your android device (phone,tablet).

Before you start please follow the configuration guide.

== Configuration ==

[[File:FG777Controller fgrun.png|thumb|Configuration example using FGrun with controller device ip 192.168.1.68]]

# Install/run FlightGear
# Install/Select Boeing 777 Aircraft
# Copy the xml files [https://raw.githubusercontent.com/emcrispim/fg777controller/master/xml/from_fg777controller.xml from_fg777controller.xml] and [https://raw.githubusercontent.com/emcrispim/fg777controller/master/xml/to_fg777controller.xml to_fg777controller.xml] and place in the ''FlightGear-installation-Directory''/'''Protocol''' directory.
#Run the FlighGear with the following configuration parameters:
# From command line:
#: <code>fgfs --generic=socket,in,20,,9009,udp,from_fgcontroller777 --generic=socket,out,5,'''android-device-ip''',9010,udp,to_fgcontroller777 --telnet=9000 </code>
#:Or Use FGRun to set the required parameters via '''Advanced''' > '''Input/Output''' menu.
#:Obs: Change '''android-device-ip''' with your local IP Wi-Fi network device.
#Install the apk from the play store ([https://play.google.com/store/apps/details?id=org.emcrispim.fg777controller.fg777controller link]).
#Go to the Settings (upper left corner button) and enter the IP of your computer running the FlightGear

== Features ==

The basic features will work in any aircraft and if available. The boeing 777 features may work partially with other airplanes, like the flaps but these are designed specially with the 777 variables values acceptance.

=== Basic features ===
* Steering, available touchpad or accelerometer
* Elevator trim
* Rudder
* Landing gears, if the airplane allows extend and retract the landing gears.
* Brakes
* Throttle, if the airplane have one or two engine, if you try with more engines you may have airplane crash experiences.

=== Boeing 777 Features ===
* Parking brakes
* Reverse trust
* Autobrake
* Flaps
* Throttle
* Speedbrake
* Views: captain, CDU, OH Panel, etc...
* Lights
* Autopilot

== Legend ==
[[File:FG777Controller Legend.png|1024px|FG777Controller Legend]]

# Settings menu (check settings section for more information)
# Enable Accelerometer / Enable Touchpad
#: When enable the accelerometer it will popup a message to calibrate the device. This will give a 3 seconds timer so that the user must put the device (phone/tablet) in a comfortable position that will be the neutral steering position.
#: When touchpad is enable the steering will be controlled by the pad (Item 17).
# Elevator trim up
# Elevator trim down, the current elevator trim is showed in the little white diamond
# Rudder / front wheel
# Parking brake
# Reverse trust, this also sets the throttle to 0.
# Brakes (wheels)
# Set autobrake, touch and swipe up or down, to rotate the button right or left accordingly.
# Landing gear up/down
# Open/Close view menu
# Open/Close lights menu
# Open/Close autopilot menu
# Flaps
# Throttle
# Speedbrakes
# Touchpad for steering. When accelerometer is enable it will show a steering image.

== Settings ==

The Settings menu allows you to configure properly the FG777Controller to your FlightGear and network environment, other tweaks are available to set the application to a more enjoyable e comfortable controller.

* '''FlightGear IP''' - The local network ip where your flightGear is running
* '''Outgoing UDP Port''' - The port where the FlightGear is listening (check configuration section )
* '''Incoming UPD Port''' - The port where the Flightgear is sending information (check configuration section)
* '''Telnet port''' - The telnet port where the FlightGear is listening (check configuration section)
* '''Accelerometer elevator sensitivity''' - this slider configures the elevator sensitivity
* '''Accelerometer aileron sensitivity''' - this slider configures the aileron sensitivity
* '''Accelerometer/pad threshold''' - This slider configures the threshold for the steering. If it sets low threshold (slider left), small changes in the steering controller will change the airplane steering. If it sets high threshold, small changes will not affect/change the airplane steering.
* '''Pad auto center''' - it auto centers the Pad/steering when touch release
* '''Rudder auto center''' - it auto centers the rudder when touch release
* '''Smooth rudder''' - it applies a smooth (non linear transformation) rudder response. It gives a better rudder control for small rudder flight corrections.
* '''Brakes auto disable''' - it sets no brakes when touch is released
* '''Anchor Throttle''' - If enable the throttle knobs will act as one.
* '''Disable FlightGear Controller update (time s)''' - This is the time in seconds that the controller will not update any changes that came form the flightgear. Example: if we change the throttle in the controller, the controller will wait some seconds before will listen to changes that came from flightgear.

== Related content ==
* [[FlightGear_TQPanel]] twin engine throttle Quadrant, flaps, speedbrakes, buttons

== External links ==
* [https://play.google.com/store/apps/details?id=org.emcrispim.fg777controller.fg777controller Application Google play store]
* [https://github.com/emcrispim/fg777controller Development repository ]

[[Category:Android apps ]]
[[Category:Software]]
[[Category:GPL software]]

FGAirports

2020-07-01T19:51:10Z

Wkitty42: update latest release version number and date

{{Infobox Software
| title = Flightgear Airports
| image =
| alt =
| developedby = Keith Paterson
| initialrelease = 2020
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.15 (01 Jul 2020)]
| os = Windows, GNU/Linux, MacOS X
| website = https://github.com/Portree-Kid/flightgear-airports/wiki
| license = [[GNU General Public License]]
}}

== Sidebar ==
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred.
=== Properties ===
Currently selected item can be edited here.
=== Parking List ===
Table of all parkings for easy editing.
=== Search ===
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.
=== Check result ===
=== Work in Progress ===
List of edited airports with the possibility to remove after upload.
== World view ==
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.

== Setup ==
# Set directories in settings (bottom left)
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.
## Test Directory - Work in progress can be copied here for test purpose.
# Start scans one after the other in sidebar with sync icon.

== Overview ==

[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]

== Edit Bar ==
Button with ICAO code opens the Airport data in the edit tab.
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]
* The top 4 buttons in the button bar are for zooming (+/-/details/large).
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].
* Edit switches into edit mode
* Undo undos all changes or all changes during session
* Save, saves the groundnet
* Draw taxiline
* Draw push
* Add parking
* Remove element, removes the currently selected element
* Check triggers the groundnet check.

== ToDo / Wishlist ==
{| class="wikitable"
!Work item !! Version !! Progress
|-
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}
|-
| Extend properties editing || 0.11.0 || {{Template:Done}}
|-
| Consistent click behaviour || 0.11.0 || {{Template:Done}}
|-
| Loading Performance (SET_PARKINGS) || 0.12.0 || {{Template:Done}}
|-
| ParkPos Icon Unclear || 0.14.0 || {{pending}}
|-
| Layer visibility || 0.14.0 || {{pending}}
|-
| Full Airline names in dropdown || 0.14.0 || {{pending}}
|-
| Import from X-Plane Gateway || 0.14.0 || {{pending}}
|-
| Editing of single airport (without terrasync copy) || || {{pending}}
|-
| Undo || || {{pending}}
|-
|}
[[Category:Scenery software]]
[[Category:AI Traffic]]

Emesary

2020-04-18T14:37:31Z

Wkitty42: /* Status */ fix the comment lines

{{Stub}}

[[File:Emesary-javascript-port.png|thumb|Emesary ported to Node.js (JavaScript]]
{{Nasal Navigation}}

Richard Harrison has finished porting his Emesary system to [[Nasal]] and it's now part of the base package. '''Emesary''' is a simple and efficient class-based inter-object communication system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.

There are many possible applications for Emesary within the system. It solves the problem of how to connect generic instruments to aircraft that have different implementations and properties that need to be used. Richard has been looking at how to abstract out the interface to the MFD and [[NavDisplay]].

At the highest level Emesary is a way of communicating information between objects that are otherwise unrelated and possibly separated by a physical (machine, network, process) boundary.
Two (or more) systems can be connected together by using a bridge; the bridge that Richard implemented uses the generic string properties to transmit the messages transparently (to both the sender and recipient). (documentation is possibly slightly out of date for the most recent developments that are in Richard's fgdata)
Richard has gotten the transmission of properties working using a new notification type.<ref>{{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>

There is a set of notes at [http://chateau-logic.com/content/emesary-nasal-implementation-flightgear] that explains the whole thing with a worked example (ACLS).

This is in Richard's git repository in his commit, together with the changes to the AI carriers to add ACLS (carrier ILS): https://sourceforge.net/u/r-harrison/fgdata/ci/54165c213f03638a4cb02c848c4f2b234c537f66/

Richard has plans to extend this to be able to transmit over {{Abbr|mp|Multiplayer}} (probably layered on top of mp-broadcast). It would also probably work quite well with the [[High-Level_Architecture#Federate_Object_Model|HLA FOM]] to give us a way for models to communicate with other models.<ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34985731/
| title = <nowiki>[Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 1st, 2016
| added = Apr 1st, 2016
| script_version = 0.25
}}
</ref>

<references/>

== Status ==
The longer term direction Richard wants to take is to extend the multiplayer protocol to better handle Emesary notifications bridged over MP; it has significant advantages which he's covered previously.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35777639/
|title = <nowiki> Re: [Flightgear-devel] Multiplayer packet truncated </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Apr 9th, 2017
|added = Apr 9th, 2017
|script_version = 0.40
}}</ref>

Meanwhile, Richard has nearly finished his improvements to Emesary to make it easy and seamless to transmit properties over MP instead of the of the usual way. This is a two part set of changes, the first part (complete) is to transmit from the master model, the second part is still WIP and relates to the transmission back for dual control.

<syntaxhighlight lang="nasal">
var PropertySyncNotification =
{
new: func(_ident="none", _name="", _kind=0, _secondary_kind=0)
{
var new_class = PropertySyncNotificationBase.new(_ident, _name, _kind, _secondary_kind);

new_class.addIntProperty("consumables/fuel/total-fuel-lbs", 1);
new_class.addIntProperty("controls/fuel/dump-valve", 1);
new_class.addIntProperty("engines/engine[0]/augmentation-burner", 1);
new_class.addIntProperty("engines/engine[0]/n1", 1);
new_class.addIntProperty("engines/engine[0]/n2", 1);
new_class.addNormProperty("surface-positions/wing-pos-norm", 2);
#... etc ...
return new_class;
}
};

#
# this section sets up the notifications that will be routed and the transmitters that are used
# I've separated out the transmitter that will be used to send the properties to enable better control.
var routedNotifications = [notifications.PropertySyncNotification.new(nil), notifications.GeoEventNotification.new(nil)];
var bridgedTransmitter = emesary.Transmitter.new("outgoingBridge");
var outgoingBridge = emesary_mp_bridge.OutgoingMPBridge.new("F-14mp",routedNotifications, 19, "", bridgedTransmitter);
var incomingBridge = emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
var f14_aircraft_notification = notifications.PropertySyncNotification.new("F-14"~getprop("/sim/multiplay/callsign"));
</syntaxhighlight>

That's all that is required to ship properties between multiplayer modules via Emesary. There is a limit of 128 bytes on a string which limits the amount of outgoing messages. Outgoing notifications are queued and transmitted as space permits. The way the bridge works is to publish the notification, encoded into an MP string, for a period of time to allow for lagging clients and network issues. If a notification IsDistinct then the bridge will transfer just the last message received; otherwise the bridge will transfer all received notifications over MP. In this sense IsDistinct indicates that the contents of the notification are accurate and definitive (e.g. surface position), so the last value is the most accurate. Other notification (e.g. button 12 pushed will always need to be transferred). Obviously using this technique a variable number of properties can be transmitted, and importantly it's up to the modeller to decide what to transmit. There is a flag that I've temporarily added (sim/multiplay/transmit-only-generics) that doesn't transmit the standard properties, just chat and the generics (to make more space in the packet). There can be different types of notifications sent at a different schedule (so you could have a 10 second update of very slow moving items).<ref>{{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>

== Work in progress ==
What Richard is working on now is how to make (possibly multiple) slaves communicate back to a master craft, initially the F-14 backseat. The design goal is that the same code should work for both the master and the slave, and that there should not need to be any extra logic. At the highest level this would be (master craft): 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The model receives the notification and the appropriate property is changed. 3. The property changed will be sent over Emesary to all slaves. Slaves will not transmit this data back to the master as there is no outgoing bridge configured to do this. For the slave aircraft 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The notification is bridged over MP and received by the master craft.<ref>{{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>

ALS landing lights visible on the runway from outside views are with FG since 2016.3 or so - same with the technology of lights external to the aircraft specified via relative geometry (used e.g. to illuminate the Shuttle from the ground floodlights during night landings or SRB separation at night). The latter can also be used for scenery to player or MP to MP illumination, and Richard is toying with the idea of using the Emesary MP bridge for the job.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306389#p306389
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 5th, 2017
|added = Mar 5th, 2017
|script_version = 0.40
}}</ref>
Any lighting ''always'' requires some form communication between light source and effect assigned to the surface. In Rembrandt, lots of performance is burned to set this up fairly generally via additional passes and buffers. The ALS technique requires you to set this up specifically - so there has to be an information exchange between light and effect - which is what the light manager does for the Shuttle, and which is what Emesary can do more generally between scenery object Nasal snippets and an aircraft.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306418#p306418
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 6th, 2017
|added = Mar 6th, 2017
|script_version = 0.40
}}</ref>

There are certain things that work better as addons, and with the work Richard has been doing on Emesary FlightGear is in a better position to have integration of addons than it was previously - simply because Emesary removes inter-dependencies.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318878#p318878
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

Most of the work that Richard did to the MP protocol - extending the number of properties available and improving the efficiency of transfer came out of the need for the OPRF aircraft to transmit more properties - but is something that has much wider applications. Equally Emesary developments are coming along nicely - we should soon (next few months) see Emesary used on the OPRF fleet to allow models to communicate with each other in a more structured way to provide chaff, flares, radar, missiles, bombs, link16, damage etc.
<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318872#p318872
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

To work over MP properly the model needs to use the existing property transfer over MP (e.g. in sim/multiplay/generic/).
The best and possibly easiest way to do this is using Emesary with a multiplayer bridge to transmit this (transparently) using a GeoEventNotification. <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=312137#p312137
|title = <nowiki> Re: Synchronization between 2 pc is not reliable </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Jun 9th, 2017
|added = Jun 9th, 2017
|script_version = 0.40
}}</ref>

== Background ==
We all agree having a good IPC mechanism for distributing the simulation state across threads/processes/network is critical<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Properties are much too fine-grained for exposing via HLA. Properties, and subsystems communicating using them, are implementation details of particular HLA federate, not something we’d expose across the federation.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Most solutions that don’t involve fine-grained locking of each property ultimately equate to '''message passing''' anyway<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Besides, there's the '''ownship''' assumption hard-coded all over the place - for example, right now subsystems like the replay (flight recorder) system only record and replay your "own" aircraft flight dynamics.

It would be a significant change/addition and somewhat non-trivial to capture all the data for all the AI objects and replay them as well.

We'd have to decide if the recording and playback mechanism should be part of the AI object or something external that grabs the data and then somehow can force the AI object back through
it's original path during playback. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980739/</ref>

A similar problem arises when you have a multi viewer environment where you want to interact with the carrier or when you watch AI traffic across the views ..

In this case each viewer has its own carrier AI traffic. That means the can move independently. The same applies to multiplayer mode.

We need some generic code which is able to track SGSubsystems including their child subsystems and transfer their relevant states over the network. The same interface could be used to store replay replay logs. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980743/</ref>

<references/>

== Terminology ==
=== Transmitter ===
=== Notification ===
=== Recipient ===
== Examples ==

=== Loading the framework ===
The Emesary framework is now part of the base package and available automatically. There is nothing special to be done to load it.

=== Setting up a transmitter ===
{{Note|Usually, you will just want to use the existing globalTransmitter}}

<syntaxhighlight lang="nasal">
var myTransmitter = emesary.Transmitter.new("myTransmitter");
</syntaxhighlight>

=== Setting up a notification ===
<syntaxhighlight lang="nasal">
var HelloNotification =
{
new: func(message)
{
var new_class = emesary.Notification.new("Hello", message);
return new_class;
},
};
</syntaxhighlight>

=== Setting up a receiver ===
<syntaxhighlight lang="nasal">
var HelloRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.count = 0;
new_class.Receive = func(notification)
{
if (notification.Type == "Hello")
{
me.count = me.count + 1;
print("Hello message received:", notification.message);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};
</syntaxhighlight>

=== Registering a receiver ===
<syntaxhighlight lang="nasal">
var receiver = HelloRecipient.new("my test receiver");
myTransmitter.Register(receiver);
</syntaxhighlight>

=== Notification ===
<syntaxhighlight lang="nasal">
myTransmitter.NotifyAll( HelloNotification.new("world !") );
</syntaxhighlight>

== Multiplayer bridge ==
Richard has the Emesary multiplayer bridge working ref: http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear <ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/35040437/
| title = <nowiki>Re: [Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 25th, 2016
| added = Apr 25th, 2016
| script_version = 0.25
}}
</ref>

Code is in the branch of fgdata: https://sourceforge.net/u/r-harrison/fgdata/ci/next-emesary-mp-bridge/tree/
* Nasal/emesary.nas
* Nasal/emesary_mp_bridge.nas
* Nasal/notifications.nas

The multiplayer bridge allows notifications to be routed over MP. The model creates an incoming bridge specifying the notifications that are to be received and the bridge will messages from multiplayer models. The elegance of the bridge is that neither the sender nor the receiver need to know about each other; all notifications just appear in the recipient method where they can be handled. Each aircraft would have one (or more recipients) and just handle the incoming message.

Create an incoming and outgoing in a model with the following lines.

<syntaxhighlight lang="nasal">
var routedNotifications = [notifications.GeoEventNotification.new(nil)];
var outgoingBridge = emesary_mp_bridge.OutgoingMPBridge.new("F-15mp",routedNotifications);
var incomingBridge = emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
</syntaxhighlight>

then any GeoEventNotification will arrive via MP and the transmitter in
any registered recipients, ready for handling like this

<syntaxhighlight lang="nasal">
var EmesaryRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);

new_class.Receive = func(notification)
{
if (notification.NotificationType == "GeoEventNotification")
{
print("received GeoNotification from ",notification.Callsign);
print (" pos=",notification.Position.lat(),notification.Position.lon(),notification.Position.alt());
print (" kind=",notification.Kind, " skind=",notification.SecondaryKind);
if(notification.FromIncomingBridge)
{
if(notification.Kind == 1)# created
{
if(notification.SecondaryKind >= 48 and notification.SecondaryKind <= 63)
{
# TBD: animate drop tanks
}
}
}
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
new_class.Response = ANSPN46ActiveResponseNotification.new("ARA-63");
return new_class;
},
};
#
#
# Instantiate receiver.
var recipient = EmesaryRecipient.new("F-15-recipient");
emesary.GlobalTransmitter.Register(recipient);</syntaxhighlight>

<references/>

== C++ Port ==

The C++ version should be compatible with the Nasal port, i.e. so that the same Emesary notifications, transmitter and recipients can be used in scripting space and native code, it would make sense to look at the [[Nasal/CppBind]] framework to accomplish that.

For the time being, $SG_SRC/canvas/layout/NasalWidget.cxx demonstrates how a C++ "interface" (base class) can be overridden from scripting space by using a corresponding wrapper (see $FG_ROOT/Nasal/canvas/gui/Widget.nas).

== Use Cases ==
With Richard's Emesary system now being ported to Nasal, it would actually make sense to look at it with a focus on FGPythonSys, i.e. how this could be moved to C++ space, and reused by the whole [[Talk:FGPythonSys|FGScriptingSys interface]] we've been talking about, because that could make timers, and listeners, entirely unnecessary - while providing the option to run scripts asynchronously from the main loop.
It would even be possible to come up with a Canvas mode where a Canvas (FBO) is '''only''' updated using an Emesary transmitter, which would mean that these updates could be processed in a background thread, and that OSG could be also much more aggressive about updating Canvas elements/FBOs concurrently.
Note that there is nothing Nasal specific about Emesary - it's just a way to come up with a decoupled design that lets components act with eachother without having to know much/anything about their internals, and this kind of decoupling would also be useful for any HLA efforts, because HLA would be just one kind of transport, and one that could greatly benefit from having this separation in place.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=284945#p284945
|title = <nowiki> Re: FGPython an propose for Python as an nasal alternative </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = May 12th, 2016
|added = May 12th, 2016
|script_version = 0.40
}}</ref>

=== Advanced Weather/MP ===
{{Main article|Advanced_weather#Connection_with_the_multiplayer_system}}

Richard's Emesary framework would be ideal for this sort of thing. The changes AW side would be modest - basically a shift to a dedicated random number generator, a routine to build a tile based on incoming information, one to store and encode the meta-data of tiles already created and that'd basically be it.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35491937/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Nov 15th, 2016
|added = Nov 15th, 2016
|script_version = 0.40
}}</ref>

* [[Howto:Implementing a PID Controller in Nasal]]
* [[Multiplayer]]
* [[Dual Control]]
* [[Howto:Using FlightGear as an Image Generator (IG)]]
* [[Scripted AI Objects]]
* [[Canvas MFD Framework]]
* [[NavDisplay]]

== Examples ==
Collection of examples discussed on the forum.
=== MP Traffic feeds (injection) ===
* https://forum.flightgear.org/viewtopic.php?f=27&t=29355&p=282755#p282431

== JavaScript port ==
[[File:Emesary-in-firefox-via-instant-cquotes.png|thumb|Richard's [[Emesary]] MPI system ported to JavaScript, running in Firefox as part of the [[Instant-Cquotes]] script]]
Torsten is successfully using JavaScript via nodejs for a private project with FlightGear. Communication with FGFS runs via websocket and the http/fgcommand interface, everything works as one would expect; the same technique would be possible with Python or any other scripting language that supports websockets, http-get, http-post and has some support for JSON (python has, ruby has, lua has).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34792963/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Almost every system should be able to run completely independently of the frame rate. What of course would be mandatory is to sync properties at well defined time stamps, this is what the RTI takes care of. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34796183/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 26th, 2016
|added = Jan 26th, 2016
|script_version = 0.40
}}</ref>

Instead of adding just-another-feature we need to strip it down to getting a fast and constand fps rendering engine. Everything else needs to run outside the main loop and has to interact with the core by, say HLA/RTI or whatever IPC we have.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34793778/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

{{WIP}}

<syntaxhighlight lang="javascript"> //---------------------------------------------------------------------------
//
// Title : EMESARY inter-object communication
//
// File Type : Implementation File
//
// Description : Provides generic inter-object communication. For an object to receive a message it
// : must first register with an instance of a Transmitter, and provide a Receive method
//
// : To send a message use a Transmitter with an object. That's all there is to it.
//
// References : http://www.chateau-logic.com/content/class-based-inter-object-communication
// : http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
// : http://chateau-logic.com/content/c-wpf-application-plumbing-using-emesary
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Version : 4.8
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

function print () {
var i, msg="";
for(i=0; i<arguments.length; i++)
msg += arguments[i];
console.log(msg);
}

function inherit(parent) {
return Object.create(parent);
}

var emesary = (function() {

var Transmitter =
{
ReceiptStatus_OK : 0, // Processing completed successfully
ReceiptStatus_Fail : 1, // Processing resulted in at least one failure
ReceiptStatus_Abort : 2, // Fatal error, stop processing any further recipieints of this message. Implicitly failed.
ReceiptStatus_Finished : 3, // Definitive completion - do not send message to any further recipieints
ReceiptStatus_NotProcessed : 4,// Return value when method doesn't process a message.
ReceiptStatus_Pending : 5, // Message sent with indeterminate return status as processing underway
ReceiptStatus_PendingFinished : 6,// Message definitively handled, status indeterminate. The message will not be sent any further

new: function(_ident)
{
var new_class = inherit(Transmitter);
new_class.Recipients = [];
new_class.Ident = _ident;
return new_class;
},

// Add a recipient to receive notifications from this transmitter
Register: function (recipient)
{
this.Recipients.push(recipient);
},

// Stops a recipient from receiving notifications from this transmitter.
DeRegister: function(todelete_recipient)
{
var out_idx = 0;
var element_deleted = 0;

for (var idx = 0; idx < this.RecipientCount(); idx += 1)
{
if (this.Recipients[idx] != todelete_recipient)
{
this.Recipients[out_idx] = this.Recipients[idx];
out_idx = out_idx + 1;
}
else
element_deleted = 1;
}

if (element_deleted)
this.Recipients.pop();
},

RecipientCount: function ()
{
return this.Recipients.length;
},

PrintRecipients: function ()
{
print("Recipient list");
for (var idx = 0; idx < this.RecipientCount(); idx += 1)
print("Recpient ",idx," ",this.Recipients[idx].Ident);
},

// Notify all registered recipients. Stop when receipt status of abort || finished are received.
// The receipt status from this method will be
// - OK > message handled
// - Fail > message not handled. A status of Abort from a recipient will result in our status
// being fail as Abort means that the message was not and cannot be handled, and
// allows for usages such as access controls.
NotifyAll: function(message)
{
var return_status = Transmitter.ReceiptStatus_NotProcessed;
var recipient;

this.Recipients.forEach( function(recipient, index, array)
{
if (recipient.Active)
{
var rstat = recipient.Receive(message);
if(rstat == Transmitter.ReceiptStatus_Fail)
{
return_status = Transmitter.ReceiptStatus_Fail;
}
else if(rstat == Transmitter.ReceiptStatus_Pending)
{
return_status = Transmitter.ReceiptStatus_Pending;
}
else if(rstat == Transmitter.ReceiptStatus_PendingFinished)
{
return rstat;
}
// else if(rstat == Transmitter.ReceiptStatus_NotProcessed)
// {
// ;
// }
else if(rstat == Transmitter.ReceiptStatus_OK)
{
if (return_status == Transmitter.ReceiptStatus_NotProcessed)
return_status = rstat;
}
else if(rstat == Transmitter.ReceiptStatus_Abort)
{
return Transmitter.ReceiptStatus_Abort;
}
else if(rstat == Transmitter.ReceiptStatus_Finished)
{
return Transmitter.ReceiptStatus_OK;
}
}
});
return return_status;
},
// Returns true if a return value from NotifyAll is to be considered a failure.
IsFailed: function(receiptStatus)
{
// Failed is either Fail || Abort.
// NotProcessed isn't a failure because it hasn't been processed.
if (receiptStatus == Transmitter.ReceiptStatus_Fail || receiptStatus == Transmitter.ReceiptStatus_Abort)
return 1;
return 0;
}
};

//
//
// Base class for Notifications. By convention a Notification has a type and a value.
// SubClasses can add extra properties || methods.
var Notification =
{
new: function(_type, _value)
{
var new_class = inherit(Notification);
new_class.Value = _value;
new_class.Type = _type;
return new_class;
},
};

var Recipient =
{
new: function(_ident)
{
var new_class = inherit(Recipient);
if (_ident === undefined || _ident === "")
{
_ident = id(new_class);
print("ERROR: Ident required when creating a recipient, defaulting to ",_ident);
}
return Recipient.construct(_ident, new_class);
},
construct: function(_ident, new_class)
{
new_class.Ident = _ident;
new_class.Active = 1;
new_class.Receive = function(notification)
{
print("ERROR: Receive function not implemented in recipient ",this.Ident);
return Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

return {
Transmitter: Transmitter,
Notification: Notification,
Recipient: Recipient
};

})();

//
// Instantiate a Global Transmitter
var GlobalTransmitter = emesary.Transmitter.new("GlobalTransmitter");

//---------------------------------------------------------------------------
//
// Title : EMESARY tests
//
// File Type : Implementation File
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

print("Emesary tests");

var TestFailCount = 0;
var TestSuccessCount = 0;

var TestNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotification", _value);
return new_class;
},
};
var TestNotProcessedNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotProcessedNotification", _value);
return new_class;
},
};
var RadarReturnNotification =
{
new: function(_value, _x, _y, _z)
{
var new_class = emesary.Notification.new("RadarReturnNotification", _value);
new_class.x = _x;
new_class.y = _y;
new_class.z = _z;
return new_class;
},
};

var TestRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
console.log(new_class);
new_class.count = 0;
new_class.Receive = function(notification)
{
if (notification.Type == "TestNotification")
{
this.count = this.count + 1;
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

var TestRadarRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.Receive = function(notification)
{
if (notification.Type == "RadarReturnNotification")
{
print(" :: Test recipient ",this.Ident, " recv:",notification.Type," ",notification.Value);
print(" :: ",notification.x, " ", notification.y, " ", notification.z);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

function PerformTest(tid, t)
{
if (t())
{
TestSuccessCount = TestSuccessCount + 1;
print(" Test [Pass] :",tid);
}
else
{
TestFailCount = TestFailCount + 1;
print(" Test [Fail] :",tid);
}
}

var tt = TestRecipient.new("tt recipient");
var tt1 = TestRecipient.new("tt1 recipient1");
var tt3 = TestRecipient.new("tt3 recipient3");
var tt2 = TestRadarRecipient.new("tt2: Radar Test recipient2");

PerformTest("Create Notification",
function ()
{
var tn = TestNotification.new("Test notification");
return tn.Type == "TestNotification" && tn.Value == "Test notification";
});

PerformTest("Register tt",
function ()
{
GlobalTransmitter.Register(tt);
return GlobalTransmitter.RecipientCount() == 1;
});
PerformTest("Register tt1",
function ()
{
GlobalTransmitter.Register(tt1);
return GlobalTransmitter.RecipientCount() == 2;
});
PerformTest("Register tt2",
function ()
{
GlobalTransmitter.Register(tt2);
return GlobalTransmitter.RecipientCount() == 3;
});
PerformTest("Register tt3",
function ()
{
GlobalTransmitter.Register(tt3);
return GlobalTransmitter.RecipientCount() == 4;
});

PerformTest("Notify",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == 1;
});

PerformTest("DeRegister tt1",
function ()
{
GlobalTransmitter.DeRegister(tt1);
return GlobalTransmitter.RecipientCount() == 3;
});

tt1_count = tt1.count;
PerformTest("NotifyAfterDeregister",
function ()
{
GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return tt1.count == tt1_count;
});

tt.Active = 0;
tt_count = tt.count;

PerformTest("Recipient.Active",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == tt_count;
});

PerformTest("Test Not Processed Notification",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotProcessedNotification.new("Not Processed"));
return rv == emesary.Transmitter.ReceiptStatus_NotProcessed;
});

GlobalTransmitter.NotifyAll(RadarReturnNotification.new("Radar notification", "x0","y0","z0"));

if (!TestFailCount)
print("Emesary: All ",TestSuccessCount," tests passed\n");
else
print("Emesary: ERROR: Tests completed: ",TestFailCount," failed && ",TestSuccessCount," passed\n");

</syntaxhighlight>

== Related ==
* http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear
* http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
* http://emesary.codeplex.com/
* https://emesary.codeplex.com/documentation
* http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
* {{Search|list|keywords=emesary}}
* {{Search|forum|keywords=emesary}}

{{Appendix}}

[[Category:Emesary]]

Emesary

2020-04-18T14:36:32Z

Wkitty42: /* Status */ more broken code lines

{{Stub}}

[[File:Emesary-javascript-port.png|thumb|Emesary ported to Node.js (JavaScript]]
{{Nasal Navigation}}

Richard Harrison has finished porting his Emesary system to [[Nasal]] and it's now part of the base package. '''Emesary''' is a simple and efficient class-based inter-object communication system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.

There are many possible applications for Emesary within the system. It solves the problem of how to connect generic instruments to aircraft that have different implementations and properties that need to be used. Richard has been looking at how to abstract out the interface to the MFD and [[NavDisplay]].

At the highest level Emesary is a way of communicating information between objects that are otherwise unrelated and possibly separated by a physical (machine, network, process) boundary.
Two (or more) systems can be connected together by using a bridge; the bridge that Richard implemented uses the generic string properties to transmit the messages transparently (to both the sender and recipient). (documentation is possibly slightly out of date for the most recent developments that are in Richard's fgdata)
Richard has gotten the transmission of properties working using a new notification type.<ref>{{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>

There is a set of notes at [http://chateau-logic.com/content/emesary-nasal-implementation-flightgear] that explains the whole thing with a worked example (ACLS).

This is in Richard's git repository in his commit, together with the changes to the AI carriers to add ACLS (carrier ILS): https://sourceforge.net/u/r-harrison/fgdata/ci/54165c213f03638a4cb02c848c4f2b234c537f66/

Richard has plans to extend this to be able to transmit over {{Abbr|mp|Multiplayer}} (probably layered on top of mp-broadcast). It would also probably work quite well with the [[High-Level_Architecture#Federate_Object_Model|HLA FOM]] to give us a way for models to communicate with other models.<ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34985731/
| title = <nowiki>[Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 1st, 2016
| added = Apr 1st, 2016
| script_version = 0.25
}}
</ref>

<references/>

== Status ==
The longer term direction Richard wants to take is to extend the multiplayer protocol to better handle Emesary notifications bridged over MP; it has significant advantages which he's covered previously.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35777639/
|title = <nowiki> Re: [Flightgear-devel] Multiplayer packet truncated </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Apr 9th, 2017
|added = Apr 9th, 2017
|script_version = 0.40
}}</ref>

Meanwhile, Richard has nearly finished his improvements to Emesary to make it easy and seamless to transmit properties over MP instead of the of the usual way. This is a two part set of changes, the first part (complete) is to transmit from the master model, the second part is still WIP and relates to the transmission back for dual control.

<syntaxhighlight lang="nasal">
var PropertySyncNotification =
{
new: func(_ident="none", _name="", _kind=0, _secondary_kind=0)
{
var new_class = PropertySyncNotificationBase.new(_ident, _name, _kind, _secondary_kind);

new_class.addIntProperty("consumables/fuel/total-fuel-lbs", 1);
new_class.addIntProperty("controls/fuel/dump-valve", 1);
new_class.addIntProperty("engines/engine[0]/augmentation-burner", 1);
new_class.addIntProperty("engines/engine[0]/n1", 1);
new_class.addIntProperty("engines/engine[0]/n2", 1);
new_class.addNormProperty("surface-positions/wing-pos-norm", 2);
#... etc ...
return new_class;
}
};

#
# this section sets up the notifications that will be routed and the
transmitters that are used
# I've separated out the transmitter that will be used to send the
properties to enable better control.
var routedNotifications = [notifications.PropertySyncNotification.new(nil), notifications.GeoEventNotification.new(nil)];
var bridgedTransmitter = emesary.Transmitter.new("outgoingBridge");
var outgoingBridge = emesary_mp_bridge.OutgoingMPBridge.new("F-14mp",routedNotifications, 19, "", bridgedTransmitter);
var incomingBridge = emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
var f14_aircraft_notification = notifications.PropertySyncNotification.new("F-14"~getprop("/sim/multiplay/callsign"));
</syntaxhighlight>

That's all that is required to ship properties between multiplayer modules via Emesary. There is a limit of 128 bytes on a string which limits the amount of outgoing messages. Outgoing notifications are queued and transmitted as space permits. The way the bridge works is to publish the notification, encoded into an MP string, for a period of time to allow for lagging clients and network issues. If a notification IsDistinct then the bridge will transfer just the last message received; otherwise the bridge will transfer all received notifications over MP. In this sense IsDistinct indicates that the contents of the notification are accurate and definitive (e.g. surface position), so the last value is the most accurate. Other notification (e.g. button 12 pushed will always need to be transferred). Obviously using this technique a variable number of properties can be transmitted, and importantly it's up to the modeller to decide what to transmit. There is a flag that I've temporarily added (sim/multiplay/transmit-only-generics) that doesn't transmit the standard properties, just chat and the generics (to make more space in the packet). There can be different types of notifications sent at a different schedule (so you could have a 10 second update of very slow moving items).<ref>{{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>

== Work in progress ==
What Richard is working on now is how to make (possibly multiple) slaves communicate back to a master craft, initially the F-14 backseat. The design goal is that the same code should work for both the master and the slave, and that there should not need to be any extra logic. At the highest level this would be (master craft): 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The model receives the notification and the appropriate property is changed. 3. The property changed will be sent over Emesary to all slaves. Slaves will not transmit this data back to the master as there is no outgoing bridge configured to do this. For the slave aircraft 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The notification is bridged over MP and received by the master craft.<ref>{{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>

ALS landing lights visible on the runway from outside views are with FG since 2016.3 or so - same with the technology of lights external to the aircraft specified via relative geometry (used e.g. to illuminate the Shuttle from the ground floodlights during night landings or SRB separation at night). The latter can also be used for scenery to player or MP to MP illumination, and Richard is toying with the idea of using the Emesary MP bridge for the job.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306389#p306389
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 5th, 2017
|added = Mar 5th, 2017
|script_version = 0.40
}}</ref>
Any lighting ''always'' requires some form communication between light source and effect assigned to the surface. In Rembrandt, lots of performance is burned to set this up fairly generally via additional passes and buffers. The ALS technique requires you to set this up specifically - so there has to be an information exchange between light and effect - which is what the light manager does for the Shuttle, and which is what Emesary can do more generally between scenery object Nasal snippets and an aircraft.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306418#p306418
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 6th, 2017
|added = Mar 6th, 2017
|script_version = 0.40
}}</ref>

There are certain things that work better as addons, and with the work Richard has been doing on Emesary FlightGear is in a better position to have integration of addons than it was previously - simply because Emesary removes inter-dependencies.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318878#p318878
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

Most of the work that Richard did to the MP protocol - extending the number of properties available and improving the efficiency of transfer came out of the need for the OPRF aircraft to transmit more properties - but is something that has much wider applications. Equally Emesary developments are coming along nicely - we should soon (next few months) see Emesary used on the OPRF fleet to allow models to communicate with each other in a more structured way to provide chaff, flares, radar, missiles, bombs, link16, damage etc.
<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318872#p318872
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

To work over MP properly the model needs to use the existing property transfer over MP (e.g. in sim/multiplay/generic/).
The best and possibly easiest way to do this is using Emesary with a multiplayer bridge to transmit this (transparently) using a GeoEventNotification. <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=312137#p312137
|title = <nowiki> Re: Synchronization between 2 pc is not reliable </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Jun 9th, 2017
|added = Jun 9th, 2017
|script_version = 0.40
}}</ref>

== Background ==
We all agree having a good IPC mechanism for distributing the simulation state across threads/processes/network is critical<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Properties are much too fine-grained for exposing via HLA. Properties, and subsystems communicating using them, are implementation details of particular HLA federate, not something we’d expose across the federation.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Most solutions that don’t involve fine-grained locking of each property ultimately equate to '''message passing''' anyway<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Besides, there's the '''ownship''' assumption hard-coded all over the place - for example, right now subsystems like the replay (flight recorder) system only record and replay your "own" aircraft flight dynamics.

It would be a significant change/addition and somewhat non-trivial to capture all the data for all the AI objects and replay them as well.

We'd have to decide if the recording and playback mechanism should be part of the AI object or something external that grabs the data and then somehow can force the AI object back through
it's original path during playback. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980739/</ref>

A similar problem arises when you have a multi viewer environment where you want to interact with the carrier or when you watch AI traffic across the views ..

In this case each viewer has its own carrier AI traffic. That means the can move independently. The same applies to multiplayer mode.

We need some generic code which is able to track SGSubsystems including their child subsystems and transfer their relevant states over the network. The same interface could be used to store replay replay logs. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980743/</ref>

<references/>

== Terminology ==
=== Transmitter ===
=== Notification ===
=== Recipient ===
== Examples ==

=== Loading the framework ===
The Emesary framework is now part of the base package and available automatically. There is nothing special to be done to load it.

=== Setting up a transmitter ===
{{Note|Usually, you will just want to use the existing globalTransmitter}}

<syntaxhighlight lang="nasal">
var myTransmitter = emesary.Transmitter.new("myTransmitter");
</syntaxhighlight>

=== Setting up a notification ===
<syntaxhighlight lang="nasal">
var HelloNotification =
{
new: func(message)
{
var new_class = emesary.Notification.new("Hello", message);
return new_class;
},
};
</syntaxhighlight>

=== Setting up a receiver ===
<syntaxhighlight lang="nasal">
var HelloRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.count = 0;
new_class.Receive = func(notification)
{
if (notification.Type == "Hello")
{
me.count = me.count + 1;
print("Hello message received:", notification.message);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};
</syntaxhighlight>

=== Registering a receiver ===
<syntaxhighlight lang="nasal">
var receiver = HelloRecipient.new("my test receiver");
myTransmitter.Register(receiver);
</syntaxhighlight>

=== Notification ===
<syntaxhighlight lang="nasal">
myTransmitter.NotifyAll( HelloNotification.new("world !") );
</syntaxhighlight>

== Multiplayer bridge ==
Richard has the Emesary multiplayer bridge working ref: http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear <ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/35040437/
| title = <nowiki>Re: [Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 25th, 2016
| added = Apr 25th, 2016
| script_version = 0.25
}}
</ref>

Code is in the branch of fgdata: https://sourceforge.net/u/r-harrison/fgdata/ci/next-emesary-mp-bridge/tree/
* Nasal/emesary.nas
* Nasal/emesary_mp_bridge.nas
* Nasal/notifications.nas

The multiplayer bridge allows notifications to be routed over MP. The model creates an incoming bridge specifying the notifications that are to be received and the bridge will messages from multiplayer models. The elegance of the bridge is that neither the sender nor the receiver need to know about each other; all notifications just appear in the recipient method where they can be handled. Each aircraft would have one (or more recipients) and just handle the incoming message.

Create an incoming and outgoing in a model with the following lines.

<syntaxhighlight lang="nasal">
var routedNotifications = [notifications.GeoEventNotification.new(nil)];
var outgoingBridge = emesary_mp_bridge.OutgoingMPBridge.new("F-15mp",routedNotifications);
var incomingBridge = emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
</syntaxhighlight>

then any GeoEventNotification will arrive via MP and the transmitter in
any registered recipients, ready for handling like this

<syntaxhighlight lang="nasal">
var EmesaryRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);

new_class.Receive = func(notification)
{
if (notification.NotificationType == "GeoEventNotification")
{
print("received GeoNotification from ",notification.Callsign);
print (" pos=",notification.Position.lat(),notification.Position.lon(),notification.Position.alt());
print (" kind=",notification.Kind, " skind=",notification.SecondaryKind);
if(notification.FromIncomingBridge)
{
if(notification.Kind == 1)# created
{
if(notification.SecondaryKind >= 48 and notification.SecondaryKind <= 63)
{
# TBD: animate drop tanks
}
}
}
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
new_class.Response = ANSPN46ActiveResponseNotification.new("ARA-63");
return new_class;
},
};
#
#
# Instantiate receiver.
var recipient = EmesaryRecipient.new("F-15-recipient");
emesary.GlobalTransmitter.Register(recipient);</syntaxhighlight>

<references/>

== C++ Port ==

The C++ version should be compatible with the Nasal port, i.e. so that the same Emesary notifications, transmitter and recipients can be used in scripting space and native code, it would make sense to look at the [[Nasal/CppBind]] framework to accomplish that.

For the time being, $SG_SRC/canvas/layout/NasalWidget.cxx demonstrates how a C++ "interface" (base class) can be overridden from scripting space by using a corresponding wrapper (see $FG_ROOT/Nasal/canvas/gui/Widget.nas).

== Use Cases ==
With Richard's Emesary system now being ported to Nasal, it would actually make sense to look at it with a focus on FGPythonSys, i.e. how this could be moved to C++ space, and reused by the whole [[Talk:FGPythonSys|FGScriptingSys interface]] we've been talking about, because that could make timers, and listeners, entirely unnecessary - while providing the option to run scripts asynchronously from the main loop.
It would even be possible to come up with a Canvas mode where a Canvas (FBO) is '''only''' updated using an Emesary transmitter, which would mean that these updates could be processed in a background thread, and that OSG could be also much more aggressive about updating Canvas elements/FBOs concurrently.
Note that there is nothing Nasal specific about Emesary - it's just a way to come up with a decoupled design that lets components act with eachother without having to know much/anything about their internals, and this kind of decoupling would also be useful for any HLA efforts, because HLA would be just one kind of transport, and one that could greatly benefit from having this separation in place.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=284945#p284945
|title = <nowiki> Re: FGPython an propose for Python as an nasal alternative </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = May 12th, 2016
|added = May 12th, 2016
|script_version = 0.40
}}</ref>

=== Advanced Weather/MP ===
{{Main article|Advanced_weather#Connection_with_the_multiplayer_system}}

Richard's Emesary framework would be ideal for this sort of thing. The changes AW side would be modest - basically a shift to a dedicated random number generator, a routine to build a tile based on incoming information, one to store and encode the meta-data of tiles already created and that'd basically be it.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35491937/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Nov 15th, 2016
|added = Nov 15th, 2016
|script_version = 0.40
}}</ref>

* [[Howto:Implementing a PID Controller in Nasal]]
* [[Multiplayer]]
* [[Dual Control]]
* [[Howto:Using FlightGear as an Image Generator (IG)]]
* [[Scripted AI Objects]]
* [[Canvas MFD Framework]]
* [[NavDisplay]]

== Examples ==
Collection of examples discussed on the forum.
=== MP Traffic feeds (injection) ===
* https://forum.flightgear.org/viewtopic.php?f=27&t=29355&p=282755#p282431

== JavaScript port ==
[[File:Emesary-in-firefox-via-instant-cquotes.png|thumb|Richard's [[Emesary]] MPI system ported to JavaScript, running in Firefox as part of the [[Instant-Cquotes]] script]]
Torsten is successfully using JavaScript via nodejs for a private project with FlightGear. Communication with FGFS runs via websocket and the http/fgcommand interface, everything works as one would expect; the same technique would be possible with Python or any other scripting language that supports websockets, http-get, http-post and has some support for JSON (python has, ruby has, lua has).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34792963/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Almost every system should be able to run completely independently of the frame rate. What of course would be mandatory is to sync properties at well defined time stamps, this is what the RTI takes care of. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34796183/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 26th, 2016
|added = Jan 26th, 2016
|script_version = 0.40
}}</ref>

Instead of adding just-another-feature we need to strip it down to getting a fast and constand fps rendering engine. Everything else needs to run outside the main loop and has to interact with the core by, say HLA/RTI or whatever IPC we have.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34793778/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

{{WIP}}

<syntaxhighlight lang="javascript"> //---------------------------------------------------------------------------
//
// Title : EMESARY inter-object communication
//
// File Type : Implementation File
//
// Description : Provides generic inter-object communication. For an object to receive a message it
// : must first register with an instance of a Transmitter, and provide a Receive method
//
// : To send a message use a Transmitter with an object. That's all there is to it.
//
// References : http://www.chateau-logic.com/content/class-based-inter-object-communication
// : http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
// : http://chateau-logic.com/content/c-wpf-application-plumbing-using-emesary
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Version : 4.8
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

function print () {
var i, msg="";
for(i=0; i<arguments.length; i++)
msg += arguments[i];
console.log(msg);
}

function inherit(parent) {
return Object.create(parent);
}

var emesary = (function() {

var Transmitter =
{
ReceiptStatus_OK : 0, // Processing completed successfully
ReceiptStatus_Fail : 1, // Processing resulted in at least one failure
ReceiptStatus_Abort : 2, // Fatal error, stop processing any further recipieints of this message. Implicitly failed.
ReceiptStatus_Finished : 3, // Definitive completion - do not send message to any further recipieints
ReceiptStatus_NotProcessed : 4,// Return value when method doesn't process a message.
ReceiptStatus_Pending : 5, // Message sent with indeterminate return status as processing underway
ReceiptStatus_PendingFinished : 6,// Message definitively handled, status indeterminate. The message will not be sent any further

new: function(_ident)
{
var new_class = inherit(Transmitter);
new_class.Recipients = [];
new_class.Ident = _ident;
return new_class;
},

// Add a recipient to receive notifications from this transmitter
Register: function (recipient)
{
this.Recipients.push(recipient);
},

// Stops a recipient from receiving notifications from this transmitter.
DeRegister: function(todelete_recipient)
{
var out_idx = 0;
var element_deleted = 0;

for (var idx = 0; idx < this.RecipientCount(); idx += 1)
{
if (this.Recipients[idx] != todelete_recipient)
{
this.Recipients[out_idx] = this.Recipients[idx];
out_idx = out_idx + 1;
}
else
element_deleted = 1;
}

if (element_deleted)
this.Recipients.pop();
},

RecipientCount: function ()
{
return this.Recipients.length;
},

PrintRecipients: function ()
{
print("Recipient list");
for (var idx = 0; idx < this.RecipientCount(); idx += 1)
print("Recpient ",idx," ",this.Recipients[idx].Ident);
},

// Notify all registered recipients. Stop when receipt status of abort || finished are received.
// The receipt status from this method will be
// - OK > message handled
// - Fail > message not handled. A status of Abort from a recipient will result in our status
// being fail as Abort means that the message was not and cannot be handled, and
// allows for usages such as access controls.
NotifyAll: function(message)
{
var return_status = Transmitter.ReceiptStatus_NotProcessed;
var recipient;

this.Recipients.forEach( function(recipient, index, array)
{
if (recipient.Active)
{
var rstat = recipient.Receive(message);
if(rstat == Transmitter.ReceiptStatus_Fail)
{
return_status = Transmitter.ReceiptStatus_Fail;
}
else if(rstat == Transmitter.ReceiptStatus_Pending)
{
return_status = Transmitter.ReceiptStatus_Pending;
}
else if(rstat == Transmitter.ReceiptStatus_PendingFinished)
{
return rstat;
}
// else if(rstat == Transmitter.ReceiptStatus_NotProcessed)
// {
// ;
// }
else if(rstat == Transmitter.ReceiptStatus_OK)
{
if (return_status == Transmitter.ReceiptStatus_NotProcessed)
return_status = rstat;
}
else if(rstat == Transmitter.ReceiptStatus_Abort)
{
return Transmitter.ReceiptStatus_Abort;
}
else if(rstat == Transmitter.ReceiptStatus_Finished)
{
return Transmitter.ReceiptStatus_OK;
}
}
});
return return_status;
},
// Returns true if a return value from NotifyAll is to be considered a failure.
IsFailed: function(receiptStatus)
{
// Failed is either Fail || Abort.
// NotProcessed isn't a failure because it hasn't been processed.
if (receiptStatus == Transmitter.ReceiptStatus_Fail || receiptStatus == Transmitter.ReceiptStatus_Abort)
return 1;
return 0;
}
};

//
//
// Base class for Notifications. By convention a Notification has a type and a value.
// SubClasses can add extra properties || methods.
var Notification =
{
new: function(_type, _value)
{
var new_class = inherit(Notification);
new_class.Value = _value;
new_class.Type = _type;
return new_class;
},
};

var Recipient =
{
new: function(_ident)
{
var new_class = inherit(Recipient);
if (_ident === undefined || _ident === "")
{
_ident = id(new_class);
print("ERROR: Ident required when creating a recipient, defaulting to ",_ident);
}
return Recipient.construct(_ident, new_class);
},
construct: function(_ident, new_class)
{
new_class.Ident = _ident;
new_class.Active = 1;
new_class.Receive = function(notification)
{
print("ERROR: Receive function not implemented in recipient ",this.Ident);
return Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

return {
Transmitter: Transmitter,
Notification: Notification,
Recipient: Recipient
};

})();

//
// Instantiate a Global Transmitter
var GlobalTransmitter = emesary.Transmitter.new("GlobalTransmitter");

//---------------------------------------------------------------------------
//
// Title : EMESARY tests
//
// File Type : Implementation File
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

print("Emesary tests");

var TestFailCount = 0;
var TestSuccessCount = 0;

var TestNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotification", _value);
return new_class;
},
};
var TestNotProcessedNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotProcessedNotification", _value);
return new_class;
},
};
var RadarReturnNotification =
{
new: function(_value, _x, _y, _z)
{
var new_class = emesary.Notification.new("RadarReturnNotification", _value);
new_class.x = _x;
new_class.y = _y;
new_class.z = _z;
return new_class;
},
};

var TestRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
console.log(new_class);
new_class.count = 0;
new_class.Receive = function(notification)
{
if (notification.Type == "TestNotification")
{
this.count = this.count + 1;
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

var TestRadarRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.Receive = function(notification)
{
if (notification.Type == "RadarReturnNotification")
{
print(" :: Test recipient ",this.Ident, " recv:",notification.Type," ",notification.Value);
print(" :: ",notification.x, " ", notification.y, " ", notification.z);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

function PerformTest(tid, t)
{
if (t())
{
TestSuccessCount = TestSuccessCount + 1;
print(" Test [Pass] :",tid);
}
else
{
TestFailCount = TestFailCount + 1;
print(" Test [Fail] :",tid);
}
}

var tt = TestRecipient.new("tt recipient");
var tt1 = TestRecipient.new("tt1 recipient1");
var tt3 = TestRecipient.new("tt3 recipient3");
var tt2 = TestRadarRecipient.new("tt2: Radar Test recipient2");

PerformTest("Create Notification",
function ()
{
var tn = TestNotification.new("Test notification");
return tn.Type == "TestNotification" && tn.Value == "Test notification";
});

PerformTest("Register tt",
function ()
{
GlobalTransmitter.Register(tt);
return GlobalTransmitter.RecipientCount() == 1;
});
PerformTest("Register tt1",
function ()
{
GlobalTransmitter.Register(tt1);
return GlobalTransmitter.RecipientCount() == 2;
});
PerformTest("Register tt2",
function ()
{
GlobalTransmitter.Register(tt2);
return GlobalTransmitter.RecipientCount() == 3;
});
PerformTest("Register tt3",
function ()
{
GlobalTransmitter.Register(tt3);
return GlobalTransmitter.RecipientCount() == 4;
});

PerformTest("Notify",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == 1;
});

PerformTest("DeRegister tt1",
function ()
{
GlobalTransmitter.DeRegister(tt1);
return GlobalTransmitter.RecipientCount() == 3;
});

tt1_count = tt1.count;
PerformTest("NotifyAfterDeregister",
function ()
{
GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return tt1.count == tt1_count;
});

tt.Active = 0;
tt_count = tt.count;

PerformTest("Recipient.Active",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == tt_count;
});

PerformTest("Test Not Processed Notification",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotProcessedNotification.new("Not Processed"));
return rv == emesary.Transmitter.ReceiptStatus_NotProcessed;
});

GlobalTransmitter.NotifyAll(RadarReturnNotification.new("Radar notification", "x0","y0","z0"));

if (!TestFailCount)
print("Emesary: All ",TestSuccessCount," tests passed\n");
else
print("Emesary: ERROR: Tests completed: ",TestFailCount," failed && ",TestSuccessCount," passed\n");

</syntaxhighlight>

== Related ==
* http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear
* http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
* http://emesary.codeplex.com/
* https://emesary.codeplex.com/documentation
* http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
* {{Search|list|keywords=emesary}}
* {{Search|forum|keywords=emesary}}

{{Appendix}}

[[Category:Emesary]]

Emesary

2020-04-18T14:34:15Z

Wkitty42: /* Multiplayer bridge */ more broken code lines

{{Stub}}

[[File:Emesary-javascript-port.png|thumb|Emesary ported to Node.js (JavaScript]]
{{Nasal Navigation}}

Richard Harrison has finished porting his Emesary system to [[Nasal]] and it's now part of the base package. '''Emesary''' is a simple and efficient class-based inter-object communication system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.

There are many possible applications for Emesary within the system. It solves the problem of how to connect generic instruments to aircraft that have different implementations and properties that need to be used. Richard has been looking at how to abstract out the interface to the MFD and [[NavDisplay]].

At the highest level Emesary is a way of communicating information between objects that are otherwise unrelated and possibly separated by a physical (machine, network, process) boundary.
Two (or more) systems can be connected together by using a bridge; the bridge that Richard implemented uses the generic string properties to transmit the messages transparently (to both the sender and recipient). (documentation is possibly slightly out of date for the most recent developments that are in Richard's fgdata)
Richard has gotten the transmission of properties working using a new notification type.<ref>{{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>

There is a set of notes at [http://chateau-logic.com/content/emesary-nasal-implementation-flightgear] that explains the whole thing with a worked example (ACLS).

This is in Richard's git repository in his commit, together with the changes to the AI carriers to add ACLS (carrier ILS): https://sourceforge.net/u/r-harrison/fgdata/ci/54165c213f03638a4cb02c848c4f2b234c537f66/

Richard has plans to extend this to be able to transmit over {{Abbr|mp|Multiplayer}} (probably layered on top of mp-broadcast). It would also probably work quite well with the [[High-Level_Architecture#Federate_Object_Model|HLA FOM]] to give us a way for models to communicate with other models.<ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34985731/
| title = <nowiki>[Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 1st, 2016
| added = Apr 1st, 2016
| script_version = 0.25
}}
</ref>

<references/>

== Status ==
The longer term direction Richard wants to take is to extend the multiplayer protocol to better handle Emesary notifications bridged over MP; it has significant advantages which he's covered previously.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35777639/
|title = <nowiki> Re: [Flightgear-devel] Multiplayer packet truncated </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Apr 9th, 2017
|added = Apr 9th, 2017
|script_version = 0.40
}}</ref>

Meanwhile, Richard has nearly finished his improvements to Emesary to make it easy and seamless to transmit properties over MP instead of the of the usual way. This is a two part set of changes, the first part (complete) is to transmit from the master model, the second part is still WIP and relates to the transmission back for dual control.

<syntaxhighlight lang="nasal">
var PropertySyncNotification =
{
new: func(_ident="none", _name="", _kind=0, _secondary_kind=0)
{
var new_class = PropertySyncNotificationBase.new(_ident, _name,
_kind, _secondary_kind);

new_class.addIntProperty("consumables/fuel/total-fuel-lbs", 1);
new_class.addIntProperty("controls/fuel/dump-valve", 1);
new_class.addIntProperty("engines/engine[0]/augmentation-burner", 1);
new_class.addIntProperty("engines/engine[0]/n1", 1);
new_class.addIntProperty("engines/engine[0]/n2", 1);
new_class.addNormProperty("surface-positions/wing-pos-norm", 2);
#... etc ...
return new_class;
}
};

#
# this section sets up the notifications that will be routed and the
transmitters that are used
# I've separated out the transmitter that will be used to send the
properties to enable better control.
var routedNotifications =
[notifications.PropertySyncNotification.new(nil),
notifications.GeoEventNotification.new(nil)];
var bridgedTransmitter = emesary.Transmitter.new("outgoingBridge");
var outgoingBridge =
emesary_mp_bridge.OutgoingMPBridge.new("F-14mp",routedNotifications, 19,
"", bridgedTransmitter);
var incomingBridge =
emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
var f14_aircraft_notification =
notifications.PropertySyncNotification.new("F-14"~getprop("/sim/multiplay/callsign"));</syntaxhighlight>

That's all that is required to ship properties between multiplayer modules via Emesary. There is a limit of 128 bytes on a string which limits the amount of outgoing messages. Outgoing notifications are queued and transmitted as space permits. The way the bridge works is to publish the notification, encoded into an MP string, for a period of time to allow for lagging clients and network issues. If a notification IsDistinct then the bridge will transfer just the last message received; otherwise the bridge will transfer all received notifications over MP. In this sense IsDistinct indicates that the contents of the notification are accurate and definitive (e.g. surface position), so the last value is the most accurate. Other notification (e.g. button 12 pushed will always need to be transferred). Obviously using this technique a variable number of properties can be transmitted, and importantly it's up to the modeller to decide what to transmit. There is a flag that I've temporarily added (sim/multiplay/transmit-only-generics) that doesn't transmit the standard properties, just chat and the generics (to make more space in the packet). There can be different types of notifications sent at a different schedule (so you could have a 10 second update of very slow moving items).<ref>{{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>

== Work in progress ==
What Richard is working on now is how to make (possibly multiple) slaves communicate back to a master craft, initially the F-14 backseat. The design goal is that the same code should work for both the master and the slave, and that there should not need to be any extra logic. At the highest level this would be (master craft): 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The model receives the notification and the appropriate property is changed. 3. The property changed will be sent over Emesary to all slaves. Slaves will not transmit this data back to the master as there is no outgoing bridge configured to do this. For the slave aircraft 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The notification is bridged over MP and received by the master craft.<ref>{{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>

ALS landing lights visible on the runway from outside views are with FG since 2016.3 or so - same with the technology of lights external to the aircraft specified via relative geometry (used e.g. to illuminate the Shuttle from the ground floodlights during night landings or SRB separation at night). The latter can also be used for scenery to player or MP to MP illumination, and Richard is toying with the idea of using the Emesary MP bridge for the job.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306389#p306389
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 5th, 2017
|added = Mar 5th, 2017
|script_version = 0.40
}}</ref>
Any lighting ''always'' requires some form communication between light source and effect assigned to the surface. In Rembrandt, lots of performance is burned to set this up fairly generally via additional passes and buffers. The ALS technique requires you to set this up specifically - so there has to be an information exchange between light and effect - which is what the light manager does for the Shuttle, and which is what Emesary can do more generally between scenery object Nasal snippets and an aircraft.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306418#p306418
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 6th, 2017
|added = Mar 6th, 2017
|script_version = 0.40
}}</ref>

There are certain things that work better as addons, and with the work Richard has been doing on Emesary FlightGear is in a better position to have integration of addons than it was previously - simply because Emesary removes inter-dependencies.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318878#p318878
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

Most of the work that Richard did to the MP protocol - extending the number of properties available and improving the efficiency of transfer came out of the need for the OPRF aircraft to transmit more properties - but is something that has much wider applications. Equally Emesary developments are coming along nicely - we should soon (next few months) see Emesary used on the OPRF fleet to allow models to communicate with each other in a more structured way to provide chaff, flares, radar, missiles, bombs, link16, damage etc.
<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318872#p318872
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

To work over MP properly the model needs to use the existing property transfer over MP (e.g. in sim/multiplay/generic/).
The best and possibly easiest way to do this is using Emesary with a multiplayer bridge to transmit this (transparently) using a GeoEventNotification. <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=312137#p312137
|title = <nowiki> Re: Synchronization between 2 pc is not reliable </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Jun 9th, 2017
|added = Jun 9th, 2017
|script_version = 0.40
}}</ref>

== Background ==
We all agree having a good IPC mechanism for distributing the simulation state across threads/processes/network is critical<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Properties are much too fine-grained for exposing via HLA. Properties, and subsystems communicating using them, are implementation details of particular HLA federate, not something we’d expose across the federation.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Most solutions that don’t involve fine-grained locking of each property ultimately equate to '''message passing''' anyway<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Besides, there's the '''ownship''' assumption hard-coded all over the place - for example, right now subsystems like the replay (flight recorder) system only record and replay your "own" aircraft flight dynamics.

It would be a significant change/addition and somewhat non-trivial to capture all the data for all the AI objects and replay them as well.

We'd have to decide if the recording and playback mechanism should be part of the AI object or something external that grabs the data and then somehow can force the AI object back through
it's original path during playback. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980739/</ref>

A similar problem arises when you have a multi viewer environment where you want to interact with the carrier or when you watch AI traffic across the views ..

In this case each viewer has its own carrier AI traffic. That means the can move independently. The same applies to multiplayer mode.

We need some generic code which is able to track SGSubsystems including their child subsystems and transfer their relevant states over the network. The same interface could be used to store replay replay logs. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980743/</ref>

<references/>

== Terminology ==
=== Transmitter ===
=== Notification ===
=== Recipient ===
== Examples ==

=== Loading the framework ===
The Emesary framework is now part of the base package and available automatically. There is nothing special to be done to load it.

=== Setting up a transmitter ===
{{Note|Usually, you will just want to use the existing globalTransmitter}}

<syntaxhighlight lang="nasal">
var myTransmitter = emesary.Transmitter.new("myTransmitter");
</syntaxhighlight>

=== Setting up a notification ===
<syntaxhighlight lang="nasal">
var HelloNotification =
{
new: func(message)
{
var new_class = emesary.Notification.new("Hello", message);
return new_class;
},
};
</syntaxhighlight>

=== Setting up a receiver ===
<syntaxhighlight lang="nasal">
var HelloRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.count = 0;
new_class.Receive = func(notification)
{
if (notification.Type == "Hello")
{
me.count = me.count + 1;
print("Hello message received:", notification.message);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};
</syntaxhighlight>

=== Registering a receiver ===
<syntaxhighlight lang="nasal">
var receiver = HelloRecipient.new("my test receiver");
myTransmitter.Register(receiver);
</syntaxhighlight>

=== Notification ===
<syntaxhighlight lang="nasal">
myTransmitter.NotifyAll( HelloNotification.new("world !") );
</syntaxhighlight>

== Multiplayer bridge ==
Richard has the Emesary multiplayer bridge working ref: http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear <ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/35040437/
| title = <nowiki>Re: [Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 25th, 2016
| added = Apr 25th, 2016
| script_version = 0.25
}}
</ref>

Code is in the branch of fgdata: https://sourceforge.net/u/r-harrison/fgdata/ci/next-emesary-mp-bridge/tree/
* Nasal/emesary.nas
* Nasal/emesary_mp_bridge.nas
* Nasal/notifications.nas

The multiplayer bridge allows notifications to be routed over MP. The model creates an incoming bridge specifying the notifications that are to be received and the bridge will messages from multiplayer models. The elegance of the bridge is that neither the sender nor the receiver need to know about each other; all notifications just appear in the recipient method where they can be handled. Each aircraft would have one (or more recipients) and just handle the incoming message.

Create an incoming and outgoing in a model with the following lines.

<syntaxhighlight lang="nasal">
var routedNotifications = [notifications.GeoEventNotification.new(nil)];
var outgoingBridge = emesary_mp_bridge.OutgoingMPBridge.new("F-15mp",routedNotifications);
var incomingBridge = emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
</syntaxhighlight>

then any GeoEventNotification will arrive via MP and the transmitter in
any registered recipients, ready for handling like this

<syntaxhighlight lang="nasal">
var EmesaryRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);

new_class.Receive = func(notification)
{
if (notification.NotificationType == "GeoEventNotification")
{
print("received GeoNotification from ",notification.Callsign);
print (" pos=",notification.Position.lat(),notification.Position.lon(),notification.Position.alt());
print (" kind=",notification.Kind, " skind=",notification.SecondaryKind);
if(notification.FromIncomingBridge)
{
if(notification.Kind == 1)# created
{
if(notification.SecondaryKind >= 48 and notification.SecondaryKind <= 63)
{
# TBD: animate drop tanks
}
}
}
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
new_class.Response = ANSPN46ActiveResponseNotification.new("ARA-63");
return new_class;
},
};
#
#
# Instantiate receiver.
var recipient = EmesaryRecipient.new("F-15-recipient");
emesary.GlobalTransmitter.Register(recipient);</syntaxhighlight>

<references/>

== C++ Port ==

The C++ version should be compatible with the Nasal port, i.e. so that the same Emesary notifications, transmitter and recipients can be used in scripting space and native code, it would make sense to look at the [[Nasal/CppBind]] framework to accomplish that.

For the time being, $SG_SRC/canvas/layout/NasalWidget.cxx demonstrates how a C++ "interface" (base class) can be overridden from scripting space by using a corresponding wrapper (see $FG_ROOT/Nasal/canvas/gui/Widget.nas).

== Use Cases ==
With Richard's Emesary system now being ported to Nasal, it would actually make sense to look at it with a focus on FGPythonSys, i.e. how this could be moved to C++ space, and reused by the whole [[Talk:FGPythonSys|FGScriptingSys interface]] we've been talking about, because that could make timers, and listeners, entirely unnecessary - while providing the option to run scripts asynchronously from the main loop.
It would even be possible to come up with a Canvas mode where a Canvas (FBO) is '''only''' updated using an Emesary transmitter, which would mean that these updates could be processed in a background thread, and that OSG could be also much more aggressive about updating Canvas elements/FBOs concurrently.
Note that there is nothing Nasal specific about Emesary - it's just a way to come up with a decoupled design that lets components act with eachother without having to know much/anything about their internals, and this kind of decoupling would also be useful for any HLA efforts, because HLA would be just one kind of transport, and one that could greatly benefit from having this separation in place.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=284945#p284945
|title = <nowiki> Re: FGPython an propose for Python as an nasal alternative </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = May 12th, 2016
|added = May 12th, 2016
|script_version = 0.40
}}</ref>

=== Advanced Weather/MP ===
{{Main article|Advanced_weather#Connection_with_the_multiplayer_system}}

Richard's Emesary framework would be ideal for this sort of thing. The changes AW side would be modest - basically a shift to a dedicated random number generator, a routine to build a tile based on incoming information, one to store and encode the meta-data of tiles already created and that'd basically be it.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35491937/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Nov 15th, 2016
|added = Nov 15th, 2016
|script_version = 0.40
}}</ref>

* [[Howto:Implementing a PID Controller in Nasal]]
* [[Multiplayer]]
* [[Dual Control]]
* [[Howto:Using FlightGear as an Image Generator (IG)]]
* [[Scripted AI Objects]]
* [[Canvas MFD Framework]]
* [[NavDisplay]]

== Examples ==
Collection of examples discussed on the forum.
=== MP Traffic feeds (injection) ===
* https://forum.flightgear.org/viewtopic.php?f=27&t=29355&p=282755#p282431

== JavaScript port ==
[[File:Emesary-in-firefox-via-instant-cquotes.png|thumb|Richard's [[Emesary]] MPI system ported to JavaScript, running in Firefox as part of the [[Instant-Cquotes]] script]]
Torsten is successfully using JavaScript via nodejs for a private project with FlightGear. Communication with FGFS runs via websocket and the http/fgcommand interface, everything works as one would expect; the same technique would be possible with Python or any other scripting language that supports websockets, http-get, http-post and has some support for JSON (python has, ruby has, lua has).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34792963/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Almost every system should be able to run completely independently of the frame rate. What of course would be mandatory is to sync properties at well defined time stamps, this is what the RTI takes care of. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34796183/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 26th, 2016
|added = Jan 26th, 2016
|script_version = 0.40
}}</ref>

Instead of adding just-another-feature we need to strip it down to getting a fast and constand fps rendering engine. Everything else needs to run outside the main loop and has to interact with the core by, say HLA/RTI or whatever IPC we have.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34793778/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

{{WIP}}

<syntaxhighlight lang="javascript"> //---------------------------------------------------------------------------
//
// Title : EMESARY inter-object communication
//
// File Type : Implementation File
//
// Description : Provides generic inter-object communication. For an object to receive a message it
// : must first register with an instance of a Transmitter, and provide a Receive method
//
// : To send a message use a Transmitter with an object. That's all there is to it.
//
// References : http://www.chateau-logic.com/content/class-based-inter-object-communication
// : http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
// : http://chateau-logic.com/content/c-wpf-application-plumbing-using-emesary
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Version : 4.8
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

function print () {
var i, msg="";
for(i=0; i<arguments.length; i++)
msg += arguments[i];
console.log(msg);
}

function inherit(parent) {
return Object.create(parent);
}

var emesary = (function() {

var Transmitter =
{
ReceiptStatus_OK : 0, // Processing completed successfully
ReceiptStatus_Fail : 1, // Processing resulted in at least one failure
ReceiptStatus_Abort : 2, // Fatal error, stop processing any further recipieints of this message. Implicitly failed.
ReceiptStatus_Finished : 3, // Definitive completion - do not send message to any further recipieints
ReceiptStatus_NotProcessed : 4,// Return value when method doesn't process a message.
ReceiptStatus_Pending : 5, // Message sent with indeterminate return status as processing underway
ReceiptStatus_PendingFinished : 6,// Message definitively handled, status indeterminate. The message will not be sent any further

new: function(_ident)
{
var new_class = inherit(Transmitter);
new_class.Recipients = [];
new_class.Ident = _ident;
return new_class;
},

// Add a recipient to receive notifications from this transmitter
Register: function (recipient)
{
this.Recipients.push(recipient);
},

// Stops a recipient from receiving notifications from this transmitter.
DeRegister: function(todelete_recipient)
{
var out_idx = 0;
var element_deleted = 0;

for (var idx = 0; idx < this.RecipientCount(); idx += 1)
{
if (this.Recipients[idx] != todelete_recipient)
{
this.Recipients[out_idx] = this.Recipients[idx];
out_idx = out_idx + 1;
}
else
element_deleted = 1;
}

if (element_deleted)
this.Recipients.pop();
},

RecipientCount: function ()
{
return this.Recipients.length;
},

PrintRecipients: function ()
{
print("Recipient list");
for (var idx = 0; idx < this.RecipientCount(); idx += 1)
print("Recpient ",idx," ",this.Recipients[idx].Ident);
},

// Notify all registered recipients. Stop when receipt status of abort || finished are received.
// The receipt status from this method will be
// - OK > message handled
// - Fail > message not handled. A status of Abort from a recipient will result in our status
// being fail as Abort means that the message was not and cannot be handled, and
// allows for usages such as access controls.
NotifyAll: function(message)
{
var return_status = Transmitter.ReceiptStatus_NotProcessed;
var recipient;

this.Recipients.forEach( function(recipient, index, array)
{
if (recipient.Active)
{
var rstat = recipient.Receive(message);
if(rstat == Transmitter.ReceiptStatus_Fail)
{
return_status = Transmitter.ReceiptStatus_Fail;
}
else if(rstat == Transmitter.ReceiptStatus_Pending)
{
return_status = Transmitter.ReceiptStatus_Pending;
}
else if(rstat == Transmitter.ReceiptStatus_PendingFinished)
{
return rstat;
}
// else if(rstat == Transmitter.ReceiptStatus_NotProcessed)
// {
// ;
// }
else if(rstat == Transmitter.ReceiptStatus_OK)
{
if (return_status == Transmitter.ReceiptStatus_NotProcessed)
return_status = rstat;
}
else if(rstat == Transmitter.ReceiptStatus_Abort)
{
return Transmitter.ReceiptStatus_Abort;
}
else if(rstat == Transmitter.ReceiptStatus_Finished)
{
return Transmitter.ReceiptStatus_OK;
}
}
});
return return_status;
},
// Returns true if a return value from NotifyAll is to be considered a failure.
IsFailed: function(receiptStatus)
{
// Failed is either Fail || Abort.
// NotProcessed isn't a failure because it hasn't been processed.
if (receiptStatus == Transmitter.ReceiptStatus_Fail || receiptStatus == Transmitter.ReceiptStatus_Abort)
return 1;
return 0;
}
};

//
//
// Base class for Notifications. By convention a Notification has a type and a value.
// SubClasses can add extra properties || methods.
var Notification =
{
new: function(_type, _value)
{
var new_class = inherit(Notification);
new_class.Value = _value;
new_class.Type = _type;
return new_class;
},
};

var Recipient =
{
new: function(_ident)
{
var new_class = inherit(Recipient);
if (_ident === undefined || _ident === "")
{
_ident = id(new_class);
print("ERROR: Ident required when creating a recipient, defaulting to ",_ident);
}
return Recipient.construct(_ident, new_class);
},
construct: function(_ident, new_class)
{
new_class.Ident = _ident;
new_class.Active = 1;
new_class.Receive = function(notification)
{
print("ERROR: Receive function not implemented in recipient ",this.Ident);
return Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

return {
Transmitter: Transmitter,
Notification: Notification,
Recipient: Recipient
};

})();

//
// Instantiate a Global Transmitter
var GlobalTransmitter = emesary.Transmitter.new("GlobalTransmitter");

//---------------------------------------------------------------------------
//
// Title : EMESARY tests
//
// File Type : Implementation File
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

print("Emesary tests");

var TestFailCount = 0;
var TestSuccessCount = 0;

var TestNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotification", _value);
return new_class;
},
};
var TestNotProcessedNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotProcessedNotification", _value);
return new_class;
},
};
var RadarReturnNotification =
{
new: function(_value, _x, _y, _z)
{
var new_class = emesary.Notification.new("RadarReturnNotification", _value);
new_class.x = _x;
new_class.y = _y;
new_class.z = _z;
return new_class;
},
};

var TestRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
console.log(new_class);
new_class.count = 0;
new_class.Receive = function(notification)
{
if (notification.Type == "TestNotification")
{
this.count = this.count + 1;
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

var TestRadarRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.Receive = function(notification)
{
if (notification.Type == "RadarReturnNotification")
{
print(" :: Test recipient ",this.Ident, " recv:",notification.Type," ",notification.Value);
print(" :: ",notification.x, " ", notification.y, " ", notification.z);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

function PerformTest(tid, t)
{
if (t())
{
TestSuccessCount = TestSuccessCount + 1;
print(" Test [Pass] :",tid);
}
else
{
TestFailCount = TestFailCount + 1;
print(" Test [Fail] :",tid);
}
}

var tt = TestRecipient.new("tt recipient");
var tt1 = TestRecipient.new("tt1 recipient1");
var tt3 = TestRecipient.new("tt3 recipient3");
var tt2 = TestRadarRecipient.new("tt2: Radar Test recipient2");

PerformTest("Create Notification",
function ()
{
var tn = TestNotification.new("Test notification");
return tn.Type == "TestNotification" && tn.Value == "Test notification";
});

PerformTest("Register tt",
function ()
{
GlobalTransmitter.Register(tt);
return GlobalTransmitter.RecipientCount() == 1;
});
PerformTest("Register tt1",
function ()
{
GlobalTransmitter.Register(tt1);
return GlobalTransmitter.RecipientCount() == 2;
});
PerformTest("Register tt2",
function ()
{
GlobalTransmitter.Register(tt2);
return GlobalTransmitter.RecipientCount() == 3;
});
PerformTest("Register tt3",
function ()
{
GlobalTransmitter.Register(tt3);
return GlobalTransmitter.RecipientCount() == 4;
});

PerformTest("Notify",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == 1;
});

PerformTest("DeRegister tt1",
function ()
{
GlobalTransmitter.DeRegister(tt1);
return GlobalTransmitter.RecipientCount() == 3;
});

tt1_count = tt1.count;
PerformTest("NotifyAfterDeregister",
function ()
{
GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return tt1.count == tt1_count;
});

tt.Active = 0;
tt_count = tt.count;

PerformTest("Recipient.Active",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == tt_count;
});

PerformTest("Test Not Processed Notification",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotProcessedNotification.new("Not Processed"));
return rv == emesary.Transmitter.ReceiptStatus_NotProcessed;
});

GlobalTransmitter.NotifyAll(RadarReturnNotification.new("Radar notification", "x0","y0","z0"));

if (!TestFailCount)
print("Emesary: All ",TestSuccessCount," tests passed\n");
else
print("Emesary: ERROR: Tests completed: ",TestFailCount," failed && ",TestSuccessCount," passed\n");

</syntaxhighlight>

== Related ==
* http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear
* http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
* http://emesary.codeplex.com/
* https://emesary.codeplex.com/documentation
* http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
* {{Search|list|keywords=emesary}}
* {{Search|forum|keywords=emesary}}

{{Appendix}}

[[Category:Emesary]]

Emesary

2020-04-18T14:31:43Z

Wkitty42: /* Multiplayer bridge */ fix broken code lines

{{Stub}}

[[File:Emesary-javascript-port.png|thumb|Emesary ported to Node.js (JavaScript]]
{{Nasal Navigation}}

Richard Harrison has finished porting his Emesary system to [[Nasal]] and it's now part of the base package. '''Emesary''' is a simple and efficient class-based inter-object communication system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.

There are many possible applications for Emesary within the system. It solves the problem of how to connect generic instruments to aircraft that have different implementations and properties that need to be used. Richard has been looking at how to abstract out the interface to the MFD and [[NavDisplay]].

At the highest level Emesary is a way of communicating information between objects that are otherwise unrelated and possibly separated by a physical (machine, network, process) boundary.
Two (or more) systems can be connected together by using a bridge; the bridge that Richard implemented uses the generic string properties to transmit the messages transparently (to both the sender and recipient). (documentation is possibly slightly out of date for the most recent developments that are in Richard's fgdata)
Richard has gotten the transmission of properties working using a new notification type.<ref>{{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>

There is a set of notes at [http://chateau-logic.com/content/emesary-nasal-implementation-flightgear] that explains the whole thing with a worked example (ACLS).

This is in Richard's git repository in his commit, together with the changes to the AI carriers to add ACLS (carrier ILS): https://sourceforge.net/u/r-harrison/fgdata/ci/54165c213f03638a4cb02c848c4f2b234c537f66/

Richard has plans to extend this to be able to transmit over {{Abbr|mp|Multiplayer}} (probably layered on top of mp-broadcast). It would also probably work quite well with the [[High-Level_Architecture#Federate_Object_Model|HLA FOM]] to give us a way for models to communicate with other models.<ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34985731/
| title = <nowiki>[Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 1st, 2016
| added = Apr 1st, 2016
| script_version = 0.25
}}
</ref>

<references/>

== Status ==
The longer term direction Richard wants to take is to extend the multiplayer protocol to better handle Emesary notifications bridged over MP; it has significant advantages which he's covered previously.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35777639/
|title = <nowiki> Re: [Flightgear-devel] Multiplayer packet truncated </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Apr 9th, 2017
|added = Apr 9th, 2017
|script_version = 0.40
}}</ref>

Meanwhile, Richard has nearly finished his improvements to Emesary to make it easy and seamless to transmit properties over MP instead of the of the usual way. This is a two part set of changes, the first part (complete) is to transmit from the master model, the second part is still WIP and relates to the transmission back for dual control.

<syntaxhighlight lang="nasal">
var PropertySyncNotification =
{
new: func(_ident="none", _name="", _kind=0, _secondary_kind=0)
{
var new_class = PropertySyncNotificationBase.new(_ident, _name,
_kind, _secondary_kind);

new_class.addIntProperty("consumables/fuel/total-fuel-lbs", 1);
new_class.addIntProperty("controls/fuel/dump-valve", 1);
new_class.addIntProperty("engines/engine[0]/augmentation-burner", 1);
new_class.addIntProperty("engines/engine[0]/n1", 1);
new_class.addIntProperty("engines/engine[0]/n2", 1);
new_class.addNormProperty("surface-positions/wing-pos-norm", 2);
#... etc ...
return new_class;
}
};

#
# this section sets up the notifications that will be routed and the
transmitters that are used
# I've separated out the transmitter that will be used to send the
properties to enable better control.
var routedNotifications =
[notifications.PropertySyncNotification.new(nil),
notifications.GeoEventNotification.new(nil)];
var bridgedTransmitter = emesary.Transmitter.new("outgoingBridge");
var outgoingBridge =
emesary_mp_bridge.OutgoingMPBridge.new("F-14mp",routedNotifications, 19,
"", bridgedTransmitter);
var incomingBridge =
emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
var f14_aircraft_notification =
notifications.PropertySyncNotification.new("F-14"~getprop("/sim/multiplay/callsign"));</syntaxhighlight>

That's all that is required to ship properties between multiplayer modules via Emesary. There is a limit of 128 bytes on a string which limits the amount of outgoing messages. Outgoing notifications are queued and transmitted as space permits. The way the bridge works is to publish the notification, encoded into an MP string, for a period of time to allow for lagging clients and network issues. If a notification IsDistinct then the bridge will transfer just the last message received; otherwise the bridge will transfer all received notifications over MP. In this sense IsDistinct indicates that the contents of the notification are accurate and definitive (e.g. surface position), so the last value is the most accurate. Other notification (e.g. button 12 pushed will always need to be transferred). Obviously using this technique a variable number of properties can be transmitted, and importantly it's up to the modeller to decide what to transmit. There is a flag that I've temporarily added (sim/multiplay/transmit-only-generics) that doesn't transmit the standard properties, just chat and the generics (to make more space in the packet). There can be different types of notifications sent at a different schedule (so you could have a 10 second update of very slow moving items).<ref>{{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>

== Work in progress ==
What Richard is working on now is how to make (possibly multiple) slaves communicate back to a master craft, initially the F-14 backseat. The design goal is that the same code should work for both the master and the slave, and that there should not need to be any extra logic. At the highest level this would be (master craft): 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The model receives the notification and the appropriate property is changed. 3. The property changed will be sent over Emesary to all slaves. Slaves will not transmit this data back to the master as there is no outgoing bridge configured to do this. For the slave aircraft 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The notification is bridged over MP and received by the master craft.<ref>{{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>

ALS landing lights visible on the runway from outside views are with FG since 2016.3 or so - same with the technology of lights external to the aircraft specified via relative geometry (used e.g. to illuminate the Shuttle from the ground floodlights during night landings or SRB separation at night). The latter can also be used for scenery to player or MP to MP illumination, and Richard is toying with the idea of using the Emesary MP bridge for the job.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306389#p306389
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 5th, 2017
|added = Mar 5th, 2017
|script_version = 0.40
}}</ref>
Any lighting ''always'' requires some form communication between light source and effect assigned to the surface. In Rembrandt, lots of performance is burned to set this up fairly generally via additional passes and buffers. The ALS technique requires you to set this up specifically - so there has to be an information exchange between light and effect - which is what the light manager does for the Shuttle, and which is what Emesary can do more generally between scenery object Nasal snippets and an aircraft.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306418#p306418
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 6th, 2017
|added = Mar 6th, 2017
|script_version = 0.40
}}</ref>

There are certain things that work better as addons, and with the work Richard has been doing on Emesary FlightGear is in a better position to have integration of addons than it was previously - simply because Emesary removes inter-dependencies.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318878#p318878
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

Most of the work that Richard did to the MP protocol - extending the number of properties available and improving the efficiency of transfer came out of the need for the OPRF aircraft to transmit more properties - but is something that has much wider applications. Equally Emesary developments are coming along nicely - we should soon (next few months) see Emesary used on the OPRF fleet to allow models to communicate with each other in a more structured way to provide chaff, flares, radar, missiles, bombs, link16, damage etc.
<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318872#p318872
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

To work over MP properly the model needs to use the existing property transfer over MP (e.g. in sim/multiplay/generic/).
The best and possibly easiest way to do this is using Emesary with a multiplayer bridge to transmit this (transparently) using a GeoEventNotification. <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=312137#p312137
|title = <nowiki> Re: Synchronization between 2 pc is not reliable </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Jun 9th, 2017
|added = Jun 9th, 2017
|script_version = 0.40
}}</ref>

== Background ==
We all agree having a good IPC mechanism for distributing the simulation state across threads/processes/network is critical<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Properties are much too fine-grained for exposing via HLA. Properties, and subsystems communicating using them, are implementation details of particular HLA federate, not something we’d expose across the federation.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Most solutions that don’t involve fine-grained locking of each property ultimately equate to '''message passing''' anyway<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Besides, there's the '''ownship''' assumption hard-coded all over the place - for example, right now subsystems like the replay (flight recorder) system only record and replay your "own" aircraft flight dynamics.

It would be a significant change/addition and somewhat non-trivial to capture all the data for all the AI objects and replay them as well.

We'd have to decide if the recording and playback mechanism should be part of the AI object or something external that grabs the data and then somehow can force the AI object back through
it's original path during playback. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980739/</ref>

A similar problem arises when you have a multi viewer environment where you want to interact with the carrier or when you watch AI traffic across the views ..

In this case each viewer has its own carrier AI traffic. That means the can move independently. The same applies to multiplayer mode.

We need some generic code which is able to track SGSubsystems including their child subsystems and transfer their relevant states over the network. The same interface could be used to store replay replay logs. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980743/</ref>

<references/>

== Terminology ==
=== Transmitter ===
=== Notification ===
=== Recipient ===
== Examples ==

=== Loading the framework ===
The Emesary framework is now part of the base package and available automatically. There is nothing special to be done to load it.

=== Setting up a transmitter ===
{{Note|Usually, you will just want to use the existing globalTransmitter}}

<syntaxhighlight lang="nasal">
var myTransmitter = emesary.Transmitter.new("myTransmitter");
</syntaxhighlight>

=== Setting up a notification ===
<syntaxhighlight lang="nasal">
var HelloNotification =
{
new: func(message)
{
var new_class = emesary.Notification.new("Hello", message);
return new_class;
},
};
</syntaxhighlight>

=== Setting up a receiver ===
<syntaxhighlight lang="nasal">
var HelloRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.count = 0;
new_class.Receive = func(notification)
{
if (notification.Type == "Hello")
{
me.count = me.count + 1;
print("Hello message received:", notification.message);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};
</syntaxhighlight>

=== Registering a receiver ===
<syntaxhighlight lang="nasal">
var receiver = HelloRecipient.new("my test receiver");
myTransmitter.Register(receiver);
</syntaxhighlight>

=== Notification ===
<syntaxhighlight lang="nasal">
myTransmitter.NotifyAll( HelloNotification.new("world !") );
</syntaxhighlight>

== Multiplayer bridge ==
Richard has the Emesary multiplayer bridge working ref: http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear <ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/35040437/
| title = <nowiki>Re: [Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 25th, 2016
| added = Apr 25th, 2016
| script_version = 0.25
}}
</ref>

Code is in the branch of fgdata: https://sourceforge.net/u/r-harrison/fgdata/ci/next-emesary-mp-bridge/tree/
* Nasal/emesary.nas
* Nasal/emesary_mp_bridge.nas
* Nasal/notifications.nas

The multiplayer bridge allows notifications to be routed over MP. The model creates an incoming bridge specifying the notifications that are to be received and the bridge will messages from multiplayer models. The elegance of the bridge is that neither the sender nor the receiver need to know about each other; all notifications just appear in the recipient method where they can be handled. Each aircraft would have one (or more recipients) and just handle the incoming message.

Create an incoming and outgoing in a model with the following lines.

<syntaxhighlight lang="nasal">
var routedNotifications = [notifications.GeoEventNotification.new(nil)];
var outgoingBridge =
emesary_mp_bridge.OutgoingMPBridge.new("F-15mp",routedNotifications);
var incomingBridge =
emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
</syntaxhighlight>

then any GeoEventNotification will arrive via MP and the transmitter in
any registered recipients, ready for handling like this

<syntaxhighlight lang="nasal">
var EmesaryRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);

new_class.Receive = func(notification)
{
if (notification.NotificationType == "GeoEventNotification")
{
print("received GeoNotification from ",notification.Callsign);
print (" pos=",notification.Position.lat(),notification.Position.lon(),notification.Position.alt());
print (" kind=",notification.Kind, " skind=",notification.SecondaryKind);
if(notification.FromIncomingBridge)
{
if(notification.Kind == 1)# created
{
if(notification.SecondaryKind >= 48 and notification.SecondaryKind <= 63)
{
# TBD: animate drop tanks
}
}
}
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
new_class.Response = ANSPN46ActiveResponseNotification.new("ARA-63");
return new_class;
},
};
#
#
# Instantiate receiver.
var recipient = EmesaryRecipient.new("F-15-recipient");
emesary.GlobalTransmitter.Register(recipient);</syntaxhighlight>

<references/>

== C++ Port ==

The C++ version should be compatible with the Nasal port, i.e. so that the same Emesary notifications, transmitter and recipients can be used in scripting space and native code, it would make sense to look at the [[Nasal/CppBind]] framework to accomplish that.

For the time being, $SG_SRC/canvas/layout/NasalWidget.cxx demonstrates how a C++ "interface" (base class) can be overridden from scripting space by using a corresponding wrapper (see $FG_ROOT/Nasal/canvas/gui/Widget.nas).

== Use Cases ==
With Richard's Emesary system now being ported to Nasal, it would actually make sense to look at it with a focus on FGPythonSys, i.e. how this could be moved to C++ space, and reused by the whole [[Talk:FGPythonSys|FGScriptingSys interface]] we've been talking about, because that could make timers, and listeners, entirely unnecessary - while providing the option to run scripts asynchronously from the main loop.
It would even be possible to come up with a Canvas mode where a Canvas (FBO) is '''only''' updated using an Emesary transmitter, which would mean that these updates could be processed in a background thread, and that OSG could be also much more aggressive about updating Canvas elements/FBOs concurrently.
Note that there is nothing Nasal specific about Emesary - it's just a way to come up with a decoupled design that lets components act with eachother without having to know much/anything about their internals, and this kind of decoupling would also be useful for any HLA efforts, because HLA would be just one kind of transport, and one that could greatly benefit from having this separation in place.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=284945#p284945
|title = <nowiki> Re: FGPython an propose for Python as an nasal alternative </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = May 12th, 2016
|added = May 12th, 2016
|script_version = 0.40
}}</ref>

=== Advanced Weather/MP ===
{{Main article|Advanced_weather#Connection_with_the_multiplayer_system}}

Richard's Emesary framework would be ideal for this sort of thing. The changes AW side would be modest - basically a shift to a dedicated random number generator, a routine to build a tile based on incoming information, one to store and encode the meta-data of tiles already created and that'd basically be it.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35491937/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Nov 15th, 2016
|added = Nov 15th, 2016
|script_version = 0.40
}}</ref>

* [[Howto:Implementing a PID Controller in Nasal]]
* [[Multiplayer]]
* [[Dual Control]]
* [[Howto:Using FlightGear as an Image Generator (IG)]]
* [[Scripted AI Objects]]
* [[Canvas MFD Framework]]
* [[NavDisplay]]

== Examples ==
Collection of examples discussed on the forum.
=== MP Traffic feeds (injection) ===
* https://forum.flightgear.org/viewtopic.php?f=27&t=29355&p=282755#p282431

== JavaScript port ==
[[File:Emesary-in-firefox-via-instant-cquotes.png|thumb|Richard's [[Emesary]] MPI system ported to JavaScript, running in Firefox as part of the [[Instant-Cquotes]] script]]
Torsten is successfully using JavaScript via nodejs for a private project with FlightGear. Communication with FGFS runs via websocket and the http/fgcommand interface, everything works as one would expect; the same technique would be possible with Python or any other scripting language that supports websockets, http-get, http-post and has some support for JSON (python has, ruby has, lua has).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34792963/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Almost every system should be able to run completely independently of the frame rate. What of course would be mandatory is to sync properties at well defined time stamps, this is what the RTI takes care of. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34796183/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 26th, 2016
|added = Jan 26th, 2016
|script_version = 0.40
}}</ref>

Instead of adding just-another-feature we need to strip it down to getting a fast and constand fps rendering engine. Everything else needs to run outside the main loop and has to interact with the core by, say HLA/RTI or whatever IPC we have.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34793778/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

{{WIP}}

<syntaxhighlight lang="javascript"> //---------------------------------------------------------------------------
//
// Title : EMESARY inter-object communication
//
// File Type : Implementation File
//
// Description : Provides generic inter-object communication. For an object to receive a message it
// : must first register with an instance of a Transmitter, and provide a Receive method
//
// : To send a message use a Transmitter with an object. That's all there is to it.
//
// References : http://www.chateau-logic.com/content/class-based-inter-object-communication
// : http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
// : http://chateau-logic.com/content/c-wpf-application-plumbing-using-emesary
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Version : 4.8
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

function print () {
var i, msg="";
for(i=0; i<arguments.length; i++)
msg += arguments[i];
console.log(msg);
}

function inherit(parent) {
return Object.create(parent);
}

var emesary = (function() {

var Transmitter =
{
ReceiptStatus_OK : 0, // Processing completed successfully
ReceiptStatus_Fail : 1, // Processing resulted in at least one failure
ReceiptStatus_Abort : 2, // Fatal error, stop processing any further recipieints of this message. Implicitly failed.
ReceiptStatus_Finished : 3, // Definitive completion - do not send message to any further recipieints
ReceiptStatus_NotProcessed : 4,// Return value when method doesn't process a message.
ReceiptStatus_Pending : 5, // Message sent with indeterminate return status as processing underway
ReceiptStatus_PendingFinished : 6,// Message definitively handled, status indeterminate. The message will not be sent any further

new: function(_ident)
{
var new_class = inherit(Transmitter);
new_class.Recipients = [];
new_class.Ident = _ident;
return new_class;
},

// Add a recipient to receive notifications from this transmitter
Register: function (recipient)
{
this.Recipients.push(recipient);
},

// Stops a recipient from receiving notifications from this transmitter.
DeRegister: function(todelete_recipient)
{
var out_idx = 0;
var element_deleted = 0;

for (var idx = 0; idx < this.RecipientCount(); idx += 1)
{
if (this.Recipients[idx] != todelete_recipient)
{
this.Recipients[out_idx] = this.Recipients[idx];
out_idx = out_idx + 1;
}
else
element_deleted = 1;
}

if (element_deleted)
this.Recipients.pop();
},

RecipientCount: function ()
{
return this.Recipients.length;
},

PrintRecipients: function ()
{
print("Recipient list");
for (var idx = 0; idx < this.RecipientCount(); idx += 1)
print("Recpient ",idx," ",this.Recipients[idx].Ident);
},

// Notify all registered recipients. Stop when receipt status of abort || finished are received.
// The receipt status from this method will be
// - OK > message handled
// - Fail > message not handled. A status of Abort from a recipient will result in our status
// being fail as Abort means that the message was not and cannot be handled, and
// allows for usages such as access controls.
NotifyAll: function(message)
{
var return_status = Transmitter.ReceiptStatus_NotProcessed;
var recipient;

this.Recipients.forEach( function(recipient, index, array)
{
if (recipient.Active)
{
var rstat = recipient.Receive(message);
if(rstat == Transmitter.ReceiptStatus_Fail)
{
return_status = Transmitter.ReceiptStatus_Fail;
}
else if(rstat == Transmitter.ReceiptStatus_Pending)
{
return_status = Transmitter.ReceiptStatus_Pending;
}
else if(rstat == Transmitter.ReceiptStatus_PendingFinished)
{
return rstat;
}
// else if(rstat == Transmitter.ReceiptStatus_NotProcessed)
// {
// ;
// }
else if(rstat == Transmitter.ReceiptStatus_OK)
{
if (return_status == Transmitter.ReceiptStatus_NotProcessed)
return_status = rstat;
}
else if(rstat == Transmitter.ReceiptStatus_Abort)
{
return Transmitter.ReceiptStatus_Abort;
}
else if(rstat == Transmitter.ReceiptStatus_Finished)
{
return Transmitter.ReceiptStatus_OK;
}
}
});
return return_status;
},
// Returns true if a return value from NotifyAll is to be considered a failure.
IsFailed: function(receiptStatus)
{
// Failed is either Fail || Abort.
// NotProcessed isn't a failure because it hasn't been processed.
if (receiptStatus == Transmitter.ReceiptStatus_Fail || receiptStatus == Transmitter.ReceiptStatus_Abort)
return 1;
return 0;
}
};

//
//
// Base class for Notifications. By convention a Notification has a type and a value.
// SubClasses can add extra properties || methods.
var Notification =
{
new: function(_type, _value)
{
var new_class = inherit(Notification);
new_class.Value = _value;
new_class.Type = _type;
return new_class;
},
};

var Recipient =
{
new: function(_ident)
{
var new_class = inherit(Recipient);
if (_ident === undefined || _ident === "")
{
_ident = id(new_class);
print("ERROR: Ident required when creating a recipient, defaulting to ",_ident);
}
return Recipient.construct(_ident, new_class);
},
construct: function(_ident, new_class)
{
new_class.Ident = _ident;
new_class.Active = 1;
new_class.Receive = function(notification)
{
print("ERROR: Receive function not implemented in recipient ",this.Ident);
return Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

return {
Transmitter: Transmitter,
Notification: Notification,
Recipient: Recipient
};

})();

//
// Instantiate a Global Transmitter
var GlobalTransmitter = emesary.Transmitter.new("GlobalTransmitter");

//---------------------------------------------------------------------------
//
// Title : EMESARY tests
//
// File Type : Implementation File
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

print("Emesary tests");

var TestFailCount = 0;
var TestSuccessCount = 0;

var TestNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotification", _value);
return new_class;
},
};
var TestNotProcessedNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotProcessedNotification", _value);
return new_class;
},
};
var RadarReturnNotification =
{
new: function(_value, _x, _y, _z)
{
var new_class = emesary.Notification.new("RadarReturnNotification", _value);
new_class.x = _x;
new_class.y = _y;
new_class.z = _z;
return new_class;
},
};

var TestRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
console.log(new_class);
new_class.count = 0;
new_class.Receive = function(notification)
{
if (notification.Type == "TestNotification")
{
this.count = this.count + 1;
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

var TestRadarRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.Receive = function(notification)
{
if (notification.Type == "RadarReturnNotification")
{
print(" :: Test recipient ",this.Ident, " recv:",notification.Type," ",notification.Value);
print(" :: ",notification.x, " ", notification.y, " ", notification.z);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

function PerformTest(tid, t)
{
if (t())
{
TestSuccessCount = TestSuccessCount + 1;
print(" Test [Pass] :",tid);
}
else
{
TestFailCount = TestFailCount + 1;
print(" Test [Fail] :",tid);
}
}

var tt = TestRecipient.new("tt recipient");
var tt1 = TestRecipient.new("tt1 recipient1");
var tt3 = TestRecipient.new("tt3 recipient3");
var tt2 = TestRadarRecipient.new("tt2: Radar Test recipient2");

PerformTest("Create Notification",
function ()
{
var tn = TestNotification.new("Test notification");
return tn.Type == "TestNotification" && tn.Value == "Test notification";
});

PerformTest("Register tt",
function ()
{
GlobalTransmitter.Register(tt);
return GlobalTransmitter.RecipientCount() == 1;
});
PerformTest("Register tt1",
function ()
{
GlobalTransmitter.Register(tt1);
return GlobalTransmitter.RecipientCount() == 2;
});
PerformTest("Register tt2",
function ()
{
GlobalTransmitter.Register(tt2);
return GlobalTransmitter.RecipientCount() == 3;
});
PerformTest("Register tt3",
function ()
{
GlobalTransmitter.Register(tt3);
return GlobalTransmitter.RecipientCount() == 4;
});

PerformTest("Notify",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == 1;
});

PerformTest("DeRegister tt1",
function ()
{
GlobalTransmitter.DeRegister(tt1);
return GlobalTransmitter.RecipientCount() == 3;
});

tt1_count = tt1.count;
PerformTest("NotifyAfterDeregister",
function ()
{
GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return tt1.count == tt1_count;
});

tt.Active = 0;
tt_count = tt.count;

PerformTest("Recipient.Active",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == tt_count;
});

PerformTest("Test Not Processed Notification",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotProcessedNotification.new("Not Processed"));
return rv == emesary.Transmitter.ReceiptStatus_NotProcessed;
});

GlobalTransmitter.NotifyAll(RadarReturnNotification.new("Radar notification", "x0","y0","z0"));

if (!TestFailCount)
print("Emesary: All ",TestSuccessCount," tests passed\n");
else
print("Emesary: ERROR: Tests completed: ",TestFailCount," failed && ",TestSuccessCount," passed\n");

</syntaxhighlight>

== Related ==
* http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear
* http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
* http://emesary.codeplex.com/
* https://emesary.codeplex.com/documentation
* http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
* {{Search|list|keywords=emesary}}
* {{Search|forum|keywords=emesary}}

{{Appendix}}

[[Category:Emesary]]

Emesary

2020-04-18T14:29:49Z

Wkitty42: /* Setting up a transmitter */ spelling

{{Stub}}

[[File:Emesary-javascript-port.png|thumb|Emesary ported to Node.js (JavaScript]]
{{Nasal Navigation}}

Richard Harrison has finished porting his Emesary system to [[Nasal]] and it's now part of the base package. '''Emesary''' is a simple and efficient class-based inter-object communication system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.

There are many possible applications for Emesary within the system. It solves the problem of how to connect generic instruments to aircraft that have different implementations and properties that need to be used. Richard has been looking at how to abstract out the interface to the MFD and [[NavDisplay]].

At the highest level Emesary is a way of communicating information between objects that are otherwise unrelated and possibly separated by a physical (machine, network, process) boundary.
Two (or more) systems can be connected together by using a bridge; the bridge that Richard implemented uses the generic string properties to transmit the messages transparently (to both the sender and recipient). (documentation is possibly slightly out of date for the most recent developments that are in Richard's fgdata)
Richard has gotten the transmission of properties working using a new notification type.<ref>{{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>

There is a set of notes at [http://chateau-logic.com/content/emesary-nasal-implementation-flightgear] that explains the whole thing with a worked example (ACLS).

This is in Richard's git repository in his commit, together with the changes to the AI carriers to add ACLS (carrier ILS): https://sourceforge.net/u/r-harrison/fgdata/ci/54165c213f03638a4cb02c848c4f2b234c537f66/

Richard has plans to extend this to be able to transmit over {{Abbr|mp|Multiplayer}} (probably layered on top of mp-broadcast). It would also probably work quite well with the [[High-Level_Architecture#Federate_Object_Model|HLA FOM]] to give us a way for models to communicate with other models.<ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34985731/
| title = <nowiki>[Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 1st, 2016
| added = Apr 1st, 2016
| script_version = 0.25
}}
</ref>

<references/>

== Status ==
The longer term direction Richard wants to take is to extend the multiplayer protocol to better handle Emesary notifications bridged over MP; it has significant advantages which he's covered previously.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35777639/
|title = <nowiki> Re: [Flightgear-devel] Multiplayer packet truncated </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Apr 9th, 2017
|added = Apr 9th, 2017
|script_version = 0.40
}}</ref>

Meanwhile, Richard has nearly finished his improvements to Emesary to make it easy and seamless to transmit properties over MP instead of the of the usual way. This is a two part set of changes, the first part (complete) is to transmit from the master model, the second part is still WIP and relates to the transmission back for dual control.

<syntaxhighlight lang="nasal">
var PropertySyncNotification =
{
new: func(_ident="none", _name="", _kind=0, _secondary_kind=0)
{
var new_class = PropertySyncNotificationBase.new(_ident, _name,
_kind, _secondary_kind);

new_class.addIntProperty("consumables/fuel/total-fuel-lbs", 1);
new_class.addIntProperty("controls/fuel/dump-valve", 1);
new_class.addIntProperty("engines/engine[0]/augmentation-burner", 1);
new_class.addIntProperty("engines/engine[0]/n1", 1);
new_class.addIntProperty("engines/engine[0]/n2", 1);
new_class.addNormProperty("surface-positions/wing-pos-norm", 2);
#... etc ...
return new_class;
}
};

#
# this section sets up the notifications that will be routed and the
transmitters that are used
# I've separated out the transmitter that will be used to send the
properties to enable better control.
var routedNotifications =
[notifications.PropertySyncNotification.new(nil),
notifications.GeoEventNotification.new(nil)];
var bridgedTransmitter = emesary.Transmitter.new("outgoingBridge");
var outgoingBridge =
emesary_mp_bridge.OutgoingMPBridge.new("F-14mp",routedNotifications, 19,
"", bridgedTransmitter);
var incomingBridge =
emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
var f14_aircraft_notification =
notifications.PropertySyncNotification.new("F-14"~getprop("/sim/multiplay/callsign"));</syntaxhighlight>

That's all that is required to ship properties between multiplayer modules via Emesary. There is a limit of 128 bytes on a string which limits the amount of outgoing messages. Outgoing notifications are queued and transmitted as space permits. The way the bridge works is to publish the notification, encoded into an MP string, for a period of time to allow for lagging clients and network issues. If a notification IsDistinct then the bridge will transfer just the last message received; otherwise the bridge will transfer all received notifications over MP. In this sense IsDistinct indicates that the contents of the notification are accurate and definitive (e.g. surface position), so the last value is the most accurate. Other notification (e.g. button 12 pushed will always need to be transferred). Obviously using this technique a variable number of properties can be transmitted, and importantly it's up to the modeller to decide what to transmit. There is a flag that I've temporarily added (sim/multiplay/transmit-only-generics) that doesn't transmit the standard properties, just chat and the generics (to make more space in the packet). There can be different types of notifications sent at a different schedule (so you could have a 10 second update of very slow moving items).<ref>{{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>

== Work in progress ==
What Richard is working on now is how to make (possibly multiple) slaves communicate back to a master craft, initially the F-14 backseat. The design goal is that the same code should work for both the master and the slave, and that there should not need to be any extra logic. At the highest level this would be (master craft): 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The model receives the notification and the appropriate property is changed. 3. The property changed will be sent over Emesary to all slaves. Slaves will not transmit this data back to the master as there is no outgoing bridge configured to do this. For the slave aircraft 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The notification is bridged over MP and received by the master craft.<ref>{{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>

ALS landing lights visible on the runway from outside views are with FG since 2016.3 or so - same with the technology of lights external to the aircraft specified via relative geometry (used e.g. to illuminate the Shuttle from the ground floodlights during night landings or SRB separation at night). The latter can also be used for scenery to player or MP to MP illumination, and Richard is toying with the idea of using the Emesary MP bridge for the job.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306389#p306389
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 5th, 2017
|added = Mar 5th, 2017
|script_version = 0.40
}}</ref>
Any lighting ''always'' requires some form communication between light source and effect assigned to the surface. In Rembrandt, lots of performance is burned to set this up fairly generally via additional passes and buffers. The ALS technique requires you to set this up specifically - so there has to be an information exchange between light and effect - which is what the light manager does for the Shuttle, and which is what Emesary can do more generally between scenery object Nasal snippets and an aircraft.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306418#p306418
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 6th, 2017
|added = Mar 6th, 2017
|script_version = 0.40
}}</ref>

There are certain things that work better as addons, and with the work Richard has been doing on Emesary FlightGear is in a better position to have integration of addons than it was previously - simply because Emesary removes inter-dependencies.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318878#p318878
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

Most of the work that Richard did to the MP protocol - extending the number of properties available and improving the efficiency of transfer came out of the need for the OPRF aircraft to transmit more properties - but is something that has much wider applications. Equally Emesary developments are coming along nicely - we should soon (next few months) see Emesary used on the OPRF fleet to allow models to communicate with each other in a more structured way to provide chaff, flares, radar, missiles, bombs, link16, damage etc.
<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318872#p318872
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

To work over MP properly the model needs to use the existing property transfer over MP (e.g. in sim/multiplay/generic/).
The best and possibly easiest way to do this is using Emesary with a multiplayer bridge to transmit this (transparently) using a GeoEventNotification. <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=312137#p312137
|title = <nowiki> Re: Synchronization between 2 pc is not reliable </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Jun 9th, 2017
|added = Jun 9th, 2017
|script_version = 0.40
}}</ref>

== Background ==
We all agree having a good IPC mechanism for distributing the simulation state across threads/processes/network is critical<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Properties are much too fine-grained for exposing via HLA. Properties, and subsystems communicating using them, are implementation details of particular HLA federate, not something we’d expose across the federation.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Most solutions that don’t involve fine-grained locking of each property ultimately equate to '''message passing''' anyway<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Besides, there's the '''ownship''' assumption hard-coded all over the place - for example, right now subsystems like the replay (flight recorder) system only record and replay your "own" aircraft flight dynamics.

It would be a significant change/addition and somewhat non-trivial to capture all the data for all the AI objects and replay them as well.

We'd have to decide if the recording and playback mechanism should be part of the AI object or something external that grabs the data and then somehow can force the AI object back through
it's original path during playback. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980739/</ref>

A similar problem arises when you have a multi viewer environment where you want to interact with the carrier or when you watch AI traffic across the views ..

In this case each viewer has its own carrier AI traffic. That means the can move independently. The same applies to multiplayer mode.

We need some generic code which is able to track SGSubsystems including their child subsystems and transfer their relevant states over the network. The same interface could be used to store replay replay logs. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980743/</ref>

<references/>

== Terminology ==
=== Transmitter ===
=== Notification ===
=== Recipient ===
== Examples ==

=== Loading the framework ===
The Emesary framework is now part of the base package and available automatically. There is nothing special to be done to load it.

=== Setting up a transmitter ===
{{Note|Usually, you will just want to use the existing globalTransmitter}}

<syntaxhighlight lang="nasal">
var myTransmitter = emesary.Transmitter.new("myTransmitter");
</syntaxhighlight>

=== Setting up a notification ===
<syntaxhighlight lang="nasal">
var HelloNotification =
{
new: func(message)
{
var new_class = emesary.Notification.new("Hello", message);
return new_class;
},
};
</syntaxhighlight>

=== Setting up a receiver ===
<syntaxhighlight lang="nasal">
var HelloRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.count = 0;
new_class.Receive = func(notification)
{
if (notification.Type == "Hello")
{
me.count = me.count + 1;
print("Hello message received:", notification.message);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};
</syntaxhighlight>

=== Registering a receiver ===
<syntaxhighlight lang="nasal">
var receiver = HelloRecipient.new("my test receiver");
myTransmitter.Register(receiver);
</syntaxhighlight>

=== Notification ===
<syntaxhighlight lang="nasal">
myTransmitter.NotifyAll( HelloNotification.new("world !") );
</syntaxhighlight>

== Multiplayer bridge ==
Richard has the Emesary multiplayer bridge working ref: http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear <ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/35040437/
| title = <nowiki>Re: [Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 25th, 2016
| added = Apr 25th, 2016
| script_version = 0.25
}}
</ref>

Code is in the branch of fgdata: https://sourceforge.net/u/r-harrison/fgdata/ci/next-emesary-mp-bridge/tree/
* Nasal/emesary.nas
* Nasal/emesary_mp_bridge.nas
* Nasal/notifications.nas

The multiplayer bridge allows notifications to be routed over MP. The model creates an incoming bridge specifying the notifications that are to be received and the bridge will messages from multiplayer models. The elegance of the bridge is that neither the sender nor the receiver need to know about each other; all notifications just appear in the recipient method where they can be handled. Each aircraft would have one (or more recipients) and just handle the incoming message.

Create an incoming and outgoing in a model with the following lines.

<syntaxhighlight lang="nasal">
var routedNotifications = [notifications.GeoEventNotification.new(nil)];
var outgoingBridge =
emesary_mp_bridge.OutgoingMPBridge.new("F-15mp",routedNotifications);
var incomingBridge =
emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
</syntaxhighlight>

then any GeoEventNotification will arrive via MP and the transmitter in
any registered recipients, ready for handling like this

<syntaxhighlight lang="nasal">
var EmesaryRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);

new_class.Receive = func(notification)
{
if (notification.NotificationType == "GeoEventNotification")
{
print("received GeoNotification from
",notification.Callsign);
print ("
pos=",notification.Position.lat(),notification.Position.lon(),notification.Position.alt());
print (" kind=",notification.Kind, "
skind=",notification.SecondaryKind);
if(notification.FromIncomingBridge)
{
if(notification.Kind == 1)# created
{
if(notification.SecondaryKind >= 48 and
notification.SecondaryKind <= 63)
{
# TBD: animate drop tanks
}
}
}
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
new_class.Response =
ANSPN46ActiveResponseNotification.new("ARA-63");
return new_class;
},
};
#
#
# Instantiate receiver.
var recipient = EmesaryRecipient.new("F-15-recipient");
emesary.GlobalTransmitter.Register(recipient);</syntaxhighlight>

<references/>

== C++ Port ==

The C++ version should be compatible with the Nasal port, i.e. so that the same Emesary notifications, transmitter and recipients can be used in scripting space and native code, it would make sense to look at the [[Nasal/CppBind]] framework to accomplish that.

For the time being, $SG_SRC/canvas/layout/NasalWidget.cxx demonstrates how a C++ "interface" (base class) can be overridden from scripting space by using a corresponding wrapper (see $FG_ROOT/Nasal/canvas/gui/Widget.nas).

== Use Cases ==
With Richard's Emesary system now being ported to Nasal, it would actually make sense to look at it with a focus on FGPythonSys, i.e. how this could be moved to C++ space, and reused by the whole [[Talk:FGPythonSys|FGScriptingSys interface]] we've been talking about, because that could make timers, and listeners, entirely unnecessary - while providing the option to run scripts asynchronously from the main loop.
It would even be possible to come up with a Canvas mode where a Canvas (FBO) is '''only''' updated using an Emesary transmitter, which would mean that these updates could be processed in a background thread, and that OSG could be also much more aggressive about updating Canvas elements/FBOs concurrently.
Note that there is nothing Nasal specific about Emesary - it's just a way to come up with a decoupled design that lets components act with eachother without having to know much/anything about their internals, and this kind of decoupling would also be useful for any HLA efforts, because HLA would be just one kind of transport, and one that could greatly benefit from having this separation in place.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=284945#p284945
|title = <nowiki> Re: FGPython an propose for Python as an nasal alternative </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = May 12th, 2016
|added = May 12th, 2016
|script_version = 0.40
}}</ref>

=== Advanced Weather/MP ===
{{Main article|Advanced_weather#Connection_with_the_multiplayer_system}}

Richard's Emesary framework would be ideal for this sort of thing. The changes AW side would be modest - basically a shift to a dedicated random number generator, a routine to build a tile based on incoming information, one to store and encode the meta-data of tiles already created and that'd basically be it.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35491937/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Nov 15th, 2016
|added = Nov 15th, 2016
|script_version = 0.40
}}</ref>

* [[Howto:Implementing a PID Controller in Nasal]]
* [[Multiplayer]]
* [[Dual Control]]
* [[Howto:Using FlightGear as an Image Generator (IG)]]
* [[Scripted AI Objects]]
* [[Canvas MFD Framework]]
* [[NavDisplay]]

== Examples ==
Collection of examples discussed on the forum.
=== MP Traffic feeds (injection) ===
* https://forum.flightgear.org/viewtopic.php?f=27&t=29355&p=282755#p282431

== JavaScript port ==
[[File:Emesary-in-firefox-via-instant-cquotes.png|thumb|Richard's [[Emesary]] MPI system ported to JavaScript, running in Firefox as part of the [[Instant-Cquotes]] script]]
Torsten is successfully using JavaScript via nodejs for a private project with FlightGear. Communication with FGFS runs via websocket and the http/fgcommand interface, everything works as one would expect; the same technique would be possible with Python or any other scripting language that supports websockets, http-get, http-post and has some support for JSON (python has, ruby has, lua has).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34792963/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Almost every system should be able to run completely independently of the frame rate. What of course would be mandatory is to sync properties at well defined time stamps, this is what the RTI takes care of. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34796183/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 26th, 2016
|added = Jan 26th, 2016
|script_version = 0.40
}}</ref>

Instead of adding just-another-feature we need to strip it down to getting a fast and constand fps rendering engine. Everything else needs to run outside the main loop and has to interact with the core by, say HLA/RTI or whatever IPC we have.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34793778/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

{{WIP}}

<syntaxhighlight lang="javascript"> //---------------------------------------------------------------------------
//
// Title : EMESARY inter-object communication
//
// File Type : Implementation File
//
// Description : Provides generic inter-object communication. For an object to receive a message it
// : must first register with an instance of a Transmitter, and provide a Receive method
//
// : To send a message use a Transmitter with an object. That's all there is to it.
//
// References : http://www.chateau-logic.com/content/class-based-inter-object-communication
// : http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
// : http://chateau-logic.com/content/c-wpf-application-plumbing-using-emesary
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Version : 4.8
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

function print () {
var i, msg="";
for(i=0; i<arguments.length; i++)
msg += arguments[i];
console.log(msg);
}

function inherit(parent) {
return Object.create(parent);
}

var emesary = (function() {

var Transmitter =
{
ReceiptStatus_OK : 0, // Processing completed successfully
ReceiptStatus_Fail : 1, // Processing resulted in at least one failure
ReceiptStatus_Abort : 2, // Fatal error, stop processing any further recipieints of this message. Implicitly failed.
ReceiptStatus_Finished : 3, // Definitive completion - do not send message to any further recipieints
ReceiptStatus_NotProcessed : 4,// Return value when method doesn't process a message.
ReceiptStatus_Pending : 5, // Message sent with indeterminate return status as processing underway
ReceiptStatus_PendingFinished : 6,// Message definitively handled, status indeterminate. The message will not be sent any further

new: function(_ident)
{
var new_class = inherit(Transmitter);
new_class.Recipients = [];
new_class.Ident = _ident;
return new_class;
},

// Add a recipient to receive notifications from this transmitter
Register: function (recipient)
{
this.Recipients.push(recipient);
},

// Stops a recipient from receiving notifications from this transmitter.
DeRegister: function(todelete_recipient)
{
var out_idx = 0;
var element_deleted = 0;

for (var idx = 0; idx < this.RecipientCount(); idx += 1)
{
if (this.Recipients[idx] != todelete_recipient)
{
this.Recipients[out_idx] = this.Recipients[idx];
out_idx = out_idx + 1;
}
else
element_deleted = 1;
}

if (element_deleted)
this.Recipients.pop();
},

RecipientCount: function ()
{
return this.Recipients.length;
},

PrintRecipients: function ()
{
print("Recipient list");
for (var idx = 0; idx < this.RecipientCount(); idx += 1)
print("Recpient ",idx," ",this.Recipients[idx].Ident);
},

// Notify all registered recipients. Stop when receipt status of abort || finished are received.
// The receipt status from this method will be
// - OK > message handled
// - Fail > message not handled. A status of Abort from a recipient will result in our status
// being fail as Abort means that the message was not and cannot be handled, and
// allows for usages such as access controls.
NotifyAll: function(message)
{
var return_status = Transmitter.ReceiptStatus_NotProcessed;
var recipient;

this.Recipients.forEach( function(recipient, index, array)
{
if (recipient.Active)
{
var rstat = recipient.Receive(message);
if(rstat == Transmitter.ReceiptStatus_Fail)
{
return_status = Transmitter.ReceiptStatus_Fail;
}
else if(rstat == Transmitter.ReceiptStatus_Pending)
{
return_status = Transmitter.ReceiptStatus_Pending;
}
else if(rstat == Transmitter.ReceiptStatus_PendingFinished)
{
return rstat;
}
// else if(rstat == Transmitter.ReceiptStatus_NotProcessed)
// {
// ;
// }
else if(rstat == Transmitter.ReceiptStatus_OK)
{
if (return_status == Transmitter.ReceiptStatus_NotProcessed)
return_status = rstat;
}
else if(rstat == Transmitter.ReceiptStatus_Abort)
{
return Transmitter.ReceiptStatus_Abort;
}
else if(rstat == Transmitter.ReceiptStatus_Finished)
{
return Transmitter.ReceiptStatus_OK;
}
}
});
return return_status;
},
// Returns true if a return value from NotifyAll is to be considered a failure.
IsFailed: function(receiptStatus)
{
// Failed is either Fail || Abort.
// NotProcessed isn't a failure because it hasn't been processed.
if (receiptStatus == Transmitter.ReceiptStatus_Fail || receiptStatus == Transmitter.ReceiptStatus_Abort)
return 1;
return 0;
}
};

//
//
// Base class for Notifications. By convention a Notification has a type and a value.
// SubClasses can add extra properties || methods.
var Notification =
{
new: function(_type, _value)
{
var new_class = inherit(Notification);
new_class.Value = _value;
new_class.Type = _type;
return new_class;
},
};

var Recipient =
{
new: function(_ident)
{
var new_class = inherit(Recipient);
if (_ident === undefined || _ident === "")
{
_ident = id(new_class);
print("ERROR: Ident required when creating a recipient, defaulting to ",_ident);
}
return Recipient.construct(_ident, new_class);
},
construct: function(_ident, new_class)
{
new_class.Ident = _ident;
new_class.Active = 1;
new_class.Receive = function(notification)
{
print("ERROR: Receive function not implemented in recipient ",this.Ident);
return Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

return {
Transmitter: Transmitter,
Notification: Notification,
Recipient: Recipient
};

})();

//
// Instantiate a Global Transmitter
var GlobalTransmitter = emesary.Transmitter.new("GlobalTransmitter");

//---------------------------------------------------------------------------
//
// Title : EMESARY tests
//
// File Type : Implementation File
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

print("Emesary tests");

var TestFailCount = 0;
var TestSuccessCount = 0;

var TestNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotification", _value);
return new_class;
},
};
var TestNotProcessedNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotProcessedNotification", _value);
return new_class;
},
};
var RadarReturnNotification =
{
new: function(_value, _x, _y, _z)
{
var new_class = emesary.Notification.new("RadarReturnNotification", _value);
new_class.x = _x;
new_class.y = _y;
new_class.z = _z;
return new_class;
},
};

var TestRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
console.log(new_class);
new_class.count = 0;
new_class.Receive = function(notification)
{
if (notification.Type == "TestNotification")
{
this.count = this.count + 1;
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

var TestRadarRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.Receive = function(notification)
{
if (notification.Type == "RadarReturnNotification")
{
print(" :: Test recipient ",this.Ident, " recv:",notification.Type," ",notification.Value);
print(" :: ",notification.x, " ", notification.y, " ", notification.z);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

function PerformTest(tid, t)
{
if (t())
{
TestSuccessCount = TestSuccessCount + 1;
print(" Test [Pass] :",tid);
}
else
{
TestFailCount = TestFailCount + 1;
print(" Test [Fail] :",tid);
}
}

var tt = TestRecipient.new("tt recipient");
var tt1 = TestRecipient.new("tt1 recipient1");
var tt3 = TestRecipient.new("tt3 recipient3");
var tt2 = TestRadarRecipient.new("tt2: Radar Test recipient2");

PerformTest("Create Notification",
function ()
{
var tn = TestNotification.new("Test notification");
return tn.Type == "TestNotification" && tn.Value == "Test notification";
});

PerformTest("Register tt",
function ()
{
GlobalTransmitter.Register(tt);
return GlobalTransmitter.RecipientCount() == 1;
});
PerformTest("Register tt1",
function ()
{
GlobalTransmitter.Register(tt1);
return GlobalTransmitter.RecipientCount() == 2;
});
PerformTest("Register tt2",
function ()
{
GlobalTransmitter.Register(tt2);
return GlobalTransmitter.RecipientCount() == 3;
});
PerformTest("Register tt3",
function ()
{
GlobalTransmitter.Register(tt3);
return GlobalTransmitter.RecipientCount() == 4;
});

PerformTest("Notify",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == 1;
});

PerformTest("DeRegister tt1",
function ()
{
GlobalTransmitter.DeRegister(tt1);
return GlobalTransmitter.RecipientCount() == 3;
});

tt1_count = tt1.count;
PerformTest("NotifyAfterDeregister",
function ()
{
GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return tt1.count == tt1_count;
});

tt.Active = 0;
tt_count = tt.count;

PerformTest("Recipient.Active",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == tt_count;
});

PerformTest("Test Not Processed Notification",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotProcessedNotification.new("Not Processed"));
return rv == emesary.Transmitter.ReceiptStatus_NotProcessed;
});

GlobalTransmitter.NotifyAll(RadarReturnNotification.new("Radar notification", "x0","y0","z0"));

if (!TestFailCount)
print("Emesary: All ",TestSuccessCount," tests passed\n");
else
print("Emesary: ERROR: Tests completed: ",TestFailCount," failed && ",TestSuccessCount," passed\n");

</syntaxhighlight>

== Related ==
* http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear
* http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
* http://emesary.codeplex.com/
* https://emesary.codeplex.com/documentation
* http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
* {{Search|list|keywords=emesary}}
* {{Search|forum|keywords=emesary}}

{{Appendix}}

[[Category:Emesary]]

Emesary

2020-04-18T14:28:23Z

Wkitty42: minor word fixes; remove repeated links and stanzas; paragraph adjustments; proper capitalization of Emesary

{{Stub}}

[[File:Emesary-javascript-port.png|thumb|Emesary ported to Node.js (JavaScript]]
{{Nasal Navigation}}

Richard Harrison has finished porting his Emesary system to [[Nasal]] and it's now part of the base package. '''Emesary''' is a simple and efficient class-based inter-object communication system to allow decoupled disparate parts of a system to function together without knowing about each. It allows decoupling and removal of dependencies by using notifications to cause actions or to query values.

There are many possible applications for Emesary within the system. It solves the problem of how to connect generic instruments to aircraft that have different implementations and properties that need to be used. Richard has been looking at how to abstract out the interface to the MFD and [[NavDisplay]].

At the highest level Emesary is a way of communicating information between objects that are otherwise unrelated and possibly separated by a physical (machine, network, process) boundary.
Two (or more) systems can be connected together by using a bridge; the bridge that Richard implemented uses the generic string properties to transmit the messages transparently (to both the sender and recipient). (documentation is possibly slightly out of date for the most recent developments that are in Richard's fgdata)
Richard has gotten the transmission of properties working using a new notification type.<ref>{{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>

There is a set of notes at [http://chateau-logic.com/content/emesary-nasal-implementation-flightgear] that explains the whole thing with a worked example (ACLS).

This is in Richard's git repository in his commit, together with the changes to the AI carriers to add ACLS (carrier ILS): https://sourceforge.net/u/r-harrison/fgdata/ci/54165c213f03638a4cb02c848c4f2b234c537f66/

Richard has plans to extend this to be able to transmit over {{Abbr|mp|Multiplayer}} (probably layered on top of mp-broadcast). It would also probably work quite well with the [[High-Level_Architecture#Federate_Object_Model|HLA FOM]] to give us a way for models to communicate with other models.<ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34985731/
| title = <nowiki>[Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 1st, 2016
| added = Apr 1st, 2016
| script_version = 0.25
}}
</ref>

<references/>

== Status ==
The longer term direction Richard wants to take is to extend the multiplayer protocol to better handle Emesary notifications bridged over MP; it has significant advantages which he's covered previously.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35777639/
|title = <nowiki> Re: [Flightgear-devel] Multiplayer packet truncated </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Apr 9th, 2017
|added = Apr 9th, 2017
|script_version = 0.40
}}</ref>

Meanwhile, Richard has nearly finished his improvements to Emesary to make it easy and seamless to transmit properties over MP instead of the of the usual way. This is a two part set of changes, the first part (complete) is to transmit from the master model, the second part is still WIP and relates to the transmission back for dual control.

<syntaxhighlight lang="nasal">
var PropertySyncNotification =
{
new: func(_ident="none", _name="", _kind=0, _secondary_kind=0)
{
var new_class = PropertySyncNotificationBase.new(_ident, _name,
_kind, _secondary_kind);

new_class.addIntProperty("consumables/fuel/total-fuel-lbs", 1);
new_class.addIntProperty("controls/fuel/dump-valve", 1);
new_class.addIntProperty("engines/engine[0]/augmentation-burner", 1);
new_class.addIntProperty("engines/engine[0]/n1", 1);
new_class.addIntProperty("engines/engine[0]/n2", 1);
new_class.addNormProperty("surface-positions/wing-pos-norm", 2);
#... etc ...
return new_class;
}
};

#
# this section sets up the notifications that will be routed and the
transmitters that are used
# I've separated out the transmitter that will be used to send the
properties to enable better control.
var routedNotifications =
[notifications.PropertySyncNotification.new(nil),
notifications.GeoEventNotification.new(nil)];
var bridgedTransmitter = emesary.Transmitter.new("outgoingBridge");
var outgoingBridge =
emesary_mp_bridge.OutgoingMPBridge.new("F-14mp",routedNotifications, 19,
"", bridgedTransmitter);
var incomingBridge =
emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
var f14_aircraft_notification =
notifications.PropertySyncNotification.new("F-14"~getprop("/sim/multiplay/callsign"));</syntaxhighlight>

That's all that is required to ship properties between multiplayer modules via Emesary. There is a limit of 128 bytes on a string which limits the amount of outgoing messages. Outgoing notifications are queued and transmitted as space permits. The way the bridge works is to publish the notification, encoded into an MP string, for a period of time to allow for lagging clients and network issues. If a notification IsDistinct then the bridge will transfer just the last message received; otherwise the bridge will transfer all received notifications over MP. In this sense IsDistinct indicates that the contents of the notification are accurate and definitive (e.g. surface position), so the last value is the most accurate. Other notification (e.g. button 12 pushed will always need to be transferred). Obviously using this technique a variable number of properties can be transmitted, and importantly it's up to the modeller to decide what to transmit. There is a flag that I've temporarily added (sim/multiplay/transmit-only-generics) that doesn't transmit the standard properties, just chat and the generics (to make more space in the packet). There can be different types of notifications sent at a different schedule (so you could have a 10 second update of very slow moving items).<ref>{{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>

== Work in progress ==
What Richard is working on now is how to make (possibly multiple) slaves communicate back to a master craft, initially the F-14 backseat. The design goal is that the same code should work for both the master and the slave, and that there should not need to be any extra logic. At the highest level this would be (master craft): 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The model receives the notification and the appropriate property is changed. 3. The property changed will be sent over Emesary to all slaves. Slaves will not transmit this data back to the master as there is no outgoing bridge configured to do this. For the slave aircraft 1. Inside the model bindings a notification is raised, or a property changed that will cause a notification to be raised. 2. The notification is bridged over MP and received by the master craft.<ref>{{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>

ALS landing lights visible on the runway from outside views are with FG since 2016.3 or so - same with the technology of lights external to the aircraft specified via relative geometry (used e.g. to illuminate the Shuttle from the ground floodlights during night landings or SRB separation at night). The latter can also be used for scenery to player or MP to MP illumination, and Richard is toying with the idea of using the Emesary MP bridge for the job.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306389#p306389
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 5th, 2017
|added = Mar 5th, 2017
|script_version = 0.40
}}</ref>
Any lighting ''always'' requires some form communication between light source and effect assigned to the surface. In Rembrandt, lots of performance is burned to set this up fairly generally via additional passes and buffers. The ALS technique requires you to set this up specifically - so there has to be an information exchange between light and effect - which is what the light manager does for the Shuttle, and which is what Emesary can do more generally between scenery object Nasal snippets and an aircraft.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=306418#p306418
|title = <nowiki> Re: The BK117-B2 </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 6th, 2017
|added = Mar 6th, 2017
|script_version = 0.40
}}</ref>

There are certain things that work better as addons, and with the work Richard has been doing on Emesary FlightGear is in a better position to have integration of addons than it was previously - simply because Emesary removes inter-dependencies.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318878#p318878
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

Most of the work that Richard did to the MP protocol - extending the number of properties available and improving the efficiency of transfer came out of the need for the OPRF aircraft to transmit more properties - but is something that has much wider applications. Equally Emesary developments are coming along nicely - we should soon (next few months) see Emesary used on the OPRF fleet to allow models to communicate with each other in a more structured way to provide chaff, flares, radar, missiles, bombs, link16, damage etc.
<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=318872#p318872
|title = <nowiki> Re: [Serious Request] Making flightgear combat capable. </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Sep 15th, 2017
|added = Sep 15th, 2017
|script_version = 0.40
}}</ref>

To work over MP properly the model needs to use the existing property transfer over MP (e.g. in sim/multiplay/generic/).
The best and possibly easiest way to do this is using Emesary with a multiplayer bridge to transmit this (transparently) using a GeoEventNotification. <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=312137#p312137
|title = <nowiki> Re: Synchronization between 2 pc is not reliable </nowiki>
|author = <nowiki> Richard </nowiki>
|date = Jun 9th, 2017
|added = Jun 9th, 2017
|script_version = 0.40
}}</ref>

== Background ==
We all agree having a good IPC mechanism for distributing the simulation state across threads/processes/network is critical<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Properties are much too fine-grained for exposing via HLA. Properties, and subsystems communicating using them, are implementation details of particular HLA federate, not something we’d expose across the federation.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Most solutions that don’t involve fine-grained locking of each property ultimately equate to '''message passing''' anyway<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Besides, there's the '''ownship''' assumption hard-coded all over the place - for example, right now subsystems like the replay (flight recorder) system only record and replay your "own" aircraft flight dynamics.

It would be a significant change/addition and somewhat non-trivial to capture all the data for all the AI objects and replay them as well.

We'd have to decide if the recording and playback mechanism should be part of the AI object or something external that grabs the data and then somehow can force the AI object back through
it's original path during playback. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980739/</ref>

A similar problem arises when you have a multi viewer environment where you want to interact with the carrier or when you watch AI traffic across the views ..

In this case each viewer has its own carrier AI traffic. That means the can move independently. The same applies to multiplayer mode.

We need some generic code which is able to track SGSubsystems including their child subsystems and transfer their relevant states over the network. The same interface could be used to store replay replay logs. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980743/</ref>

<references/>

== Terminology ==
=== Transmitter ===
=== Notification ===
=== Recipient ===
== Examples ==

=== Loading the framework ===
The Emesary framework is now part of the base package and available automatically. There is nothing special to be done to load it.

=== Setting up a transmitter ===
{{Note|Usually, you will just want to use the exixsting globalTransmitter}}

<syntaxhighlight lang="nasal">
var myTransmitter = emesary.Transmitter.new("myTransmitter");
</syntaxhighlight>

=== Setting up a notification ===
<syntaxhighlight lang="nasal">
var HelloNotification =
{
new: func(message)
{
var new_class = emesary.Notification.new("Hello", message);
return new_class;
},
};
</syntaxhighlight>

=== Setting up a receiver ===
<syntaxhighlight lang="nasal">
var HelloRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.count = 0;
new_class.Receive = func(notification)
{
if (notification.Type == "Hello")
{
me.count = me.count + 1;
print("Hello message received:", notification.message);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};
</syntaxhighlight>

=== Registering a receiver ===
<syntaxhighlight lang="nasal">
var receiver = HelloRecipient.new("my test receiver");
myTransmitter.Register(receiver);
</syntaxhighlight>

=== Notification ===
<syntaxhighlight lang="nasal">
myTransmitter.NotifyAll( HelloNotification.new("world !") );
</syntaxhighlight>

== Multiplayer bridge ==
Richard has the Emesary multiplayer bridge working ref: http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear <ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/35040437/
| title = <nowiki>Re: [Flightgear-devel] Message passing interface for Nasal</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Apr 25th, 2016
| added = Apr 25th, 2016
| script_version = 0.25
}}
</ref>

Code is in the branch of fgdata: https://sourceforge.net/u/r-harrison/fgdata/ci/next-emesary-mp-bridge/tree/
* Nasal/emesary.nas
* Nasal/emesary_mp_bridge.nas
* Nasal/notifications.nas

The multiplayer bridge allows notifications to be routed over MP. The model creates an incoming bridge specifying the notifications that are to be received and the bridge will messages from multiplayer models. The elegance of the bridge is that neither the sender nor the receiver need to know about each other; all notifications just appear in the recipient method where they can be handled. Each aircraft would have one (or more recipients) and just handle the incoming message.

Create an incoming and outgoing in a model with the following lines.

<syntaxhighlight lang="nasal">
var routedNotifications = [notifications.GeoEventNotification.new(nil)];
var outgoingBridge =
emesary_mp_bridge.OutgoingMPBridge.new("F-15mp",routedNotifications);
var incomingBridge =
emesary_mp_bridge.IncomingMPBridge.startMPBridge(routedNotifications);
</syntaxhighlight>

then any GeoEventNotification will arrive via MP and the transmitter in
any registered recipients, ready for handling like this

<syntaxhighlight lang="nasal">
var EmesaryRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);

new_class.Receive = func(notification)
{
if (notification.NotificationType == "GeoEventNotification")
{
print("received GeoNotification from
",notification.Callsign);
print ("
pos=",notification.Position.lat(),notification.Position.lon(),notification.Position.alt());
print (" kind=",notification.Kind, "
skind=",notification.SecondaryKind);
if(notification.FromIncomingBridge)
{
if(notification.Kind == 1)# created
{
if(notification.SecondaryKind >= 48 and
notification.SecondaryKind <= 63)
{
# TBD: animate drop tanks
}
}
}
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
new_class.Response =
ANSPN46ActiveResponseNotification.new("ARA-63");
return new_class;
},
};
#
#
# Instantiate receiver.
var recipient = EmesaryRecipient.new("F-15-recipient");
emesary.GlobalTransmitter.Register(recipient);</syntaxhighlight>

<references/>

== C++ Port ==

The C++ version should be compatible with the Nasal port, i.e. so that the same Emesary notifications, transmitter and recipients can be used in scripting space and native code, it would make sense to look at the [[Nasal/CppBind]] framework to accomplish that.

For the time being, $SG_SRC/canvas/layout/NasalWidget.cxx demonstrates how a C++ "interface" (base class) can be overridden from scripting space by using a corresponding wrapper (see $FG_ROOT/Nasal/canvas/gui/Widget.nas).

== Use Cases ==
With Richard's Emesary system now being ported to Nasal, it would actually make sense to look at it with a focus on FGPythonSys, i.e. how this could be moved to C++ space, and reused by the whole [[Talk:FGPythonSys|FGScriptingSys interface]] we've been talking about, because that could make timers, and listeners, entirely unnecessary - while providing the option to run scripts asynchronously from the main loop.
It would even be possible to come up with a Canvas mode where a Canvas (FBO) is '''only''' updated using an Emesary transmitter, which would mean that these updates could be processed in a background thread, and that OSG could be also much more aggressive about updating Canvas elements/FBOs concurrently.
Note that there is nothing Nasal specific about Emesary - it's just a way to come up with a decoupled design that lets components act with eachother without having to know much/anything about their internals, and this kind of decoupling would also be useful for any HLA efforts, because HLA would be just one kind of transport, and one that could greatly benefit from having this separation in place.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=284945#p284945
|title = <nowiki> Re: FGPython an propose for Python as an nasal alternative </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = May 12th, 2016
|added = May 12th, 2016
|script_version = 0.40
}}</ref>

=== Advanced Weather/MP ===
{{Main article|Advanced_weather#Connection_with_the_multiplayer_system}}

Richard's Emesary framework would be ideal for this sort of thing. The changes AW side would be modest - basically a shift to a dedicated random number generator, a routine to build a tile based on incoming information, one to store and encode the meta-data of tiles already created and that'd basically be it.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35491937/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Nov 15th, 2016
|added = Nov 15th, 2016
|script_version = 0.40
}}</ref>

* [[Howto:Implementing a PID Controller in Nasal]]
* [[Multiplayer]]
* [[Dual Control]]
* [[Howto:Using FlightGear as an Image Generator (IG)]]
* [[Scripted AI Objects]]
* [[Canvas MFD Framework]]
* [[NavDisplay]]

== Examples ==
Collection of examples discussed on the forum.
=== MP Traffic feeds (injection) ===
* https://forum.flightgear.org/viewtopic.php?f=27&t=29355&p=282755#p282431

== JavaScript port ==
[[File:Emesary-in-firefox-via-instant-cquotes.png|thumb|Richard's [[Emesary]] MPI system ported to JavaScript, running in Firefox as part of the [[Instant-Cquotes]] script]]
Torsten is successfully using JavaScript via nodejs for a private project with FlightGear. Communication with FGFS runs via websocket and the http/fgcommand interface, everything works as one would expect; the same technique would be possible with Python or any other scripting language that supports websockets, http-get, http-post and has some support for JSON (python has, ruby has, lua has).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34792963/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

Almost every system should be able to run completely independently of the frame rate. What of course would be mandatory is to sync properties at well defined time stamps, this is what the RTI takes care of. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34796183/
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 26th, 2016
|added = Jan 26th, 2016
|script_version = 0.40
}}</ref>

Instead of adding just-another-feature we need to strip it down to getting a fast and constand fps rendering engine. Everything else needs to run outside the main loop and has to interact with the core by, say HLA/RTI or whatever IPC we have.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/34793778/
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jan 25th, 2016
|added = Jan 25th, 2016
|script_version = 0.40
}}</ref>

{{WIP}}

<syntaxhighlight lang="javascript"> //---------------------------------------------------------------------------
//
// Title : EMESARY inter-object communication
//
// File Type : Implementation File
//
// Description : Provides generic inter-object communication. For an object to receive a message it
// : must first register with an instance of a Transmitter, and provide a Receive method
//
// : To send a message use a Transmitter with an object. That's all there is to it.
//
// References : http://www.chateau-logic.com/content/class-based-inter-object-communication
// : http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
// : http://chateau-logic.com/content/c-wpf-application-plumbing-using-emesary
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Version : 4.8
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

function print () {
var i, msg="";
for(i=0; i<arguments.length; i++)
msg += arguments[i];
console.log(msg);
}

function inherit(parent) {
return Object.create(parent);
}

var emesary = (function() {

var Transmitter =
{
ReceiptStatus_OK : 0, // Processing completed successfully
ReceiptStatus_Fail : 1, // Processing resulted in at least one failure
ReceiptStatus_Abort : 2, // Fatal error, stop processing any further recipieints of this message. Implicitly failed.
ReceiptStatus_Finished : 3, // Definitive completion - do not send message to any further recipieints
ReceiptStatus_NotProcessed : 4,// Return value when method doesn't process a message.
ReceiptStatus_Pending : 5, // Message sent with indeterminate return status as processing underway
ReceiptStatus_PendingFinished : 6,// Message definitively handled, status indeterminate. The message will not be sent any further

new: function(_ident)
{
var new_class = inherit(Transmitter);
new_class.Recipients = [];
new_class.Ident = _ident;
return new_class;
},

// Add a recipient to receive notifications from this transmitter
Register: function (recipient)
{
this.Recipients.push(recipient);
},

// Stops a recipient from receiving notifications from this transmitter.
DeRegister: function(todelete_recipient)
{
var out_idx = 0;
var element_deleted = 0;

for (var idx = 0; idx < this.RecipientCount(); idx += 1)
{
if (this.Recipients[idx] != todelete_recipient)
{
this.Recipients[out_idx] = this.Recipients[idx];
out_idx = out_idx + 1;
}
else
element_deleted = 1;
}

if (element_deleted)
this.Recipients.pop();
},

RecipientCount: function ()
{
return this.Recipients.length;
},

PrintRecipients: function ()
{
print("Recipient list");
for (var idx = 0; idx < this.RecipientCount(); idx += 1)
print("Recpient ",idx," ",this.Recipients[idx].Ident);
},

// Notify all registered recipients. Stop when receipt status of abort || finished are received.
// The receipt status from this method will be
// - OK > message handled
// - Fail > message not handled. A status of Abort from a recipient will result in our status
// being fail as Abort means that the message was not and cannot be handled, and
// allows for usages such as access controls.
NotifyAll: function(message)
{
var return_status = Transmitter.ReceiptStatus_NotProcessed;
var recipient;

this.Recipients.forEach( function(recipient, index, array)
{
if (recipient.Active)
{
var rstat = recipient.Receive(message);
if(rstat == Transmitter.ReceiptStatus_Fail)
{
return_status = Transmitter.ReceiptStatus_Fail;
}
else if(rstat == Transmitter.ReceiptStatus_Pending)
{
return_status = Transmitter.ReceiptStatus_Pending;
}
else if(rstat == Transmitter.ReceiptStatus_PendingFinished)
{
return rstat;
}
// else if(rstat == Transmitter.ReceiptStatus_NotProcessed)
// {
// ;
// }
else if(rstat == Transmitter.ReceiptStatus_OK)
{
if (return_status == Transmitter.ReceiptStatus_NotProcessed)
return_status = rstat;
}
else if(rstat == Transmitter.ReceiptStatus_Abort)
{
return Transmitter.ReceiptStatus_Abort;
}
else if(rstat == Transmitter.ReceiptStatus_Finished)
{
return Transmitter.ReceiptStatus_OK;
}
}
});
return return_status;
},
// Returns true if a return value from NotifyAll is to be considered a failure.
IsFailed: function(receiptStatus)
{
// Failed is either Fail || Abort.
// NotProcessed isn't a failure because it hasn't been processed.
if (receiptStatus == Transmitter.ReceiptStatus_Fail || receiptStatus == Transmitter.ReceiptStatus_Abort)
return 1;
return 0;
}
};

//
//
// Base class for Notifications. By convention a Notification has a type and a value.
// SubClasses can add extra properties || methods.
var Notification =
{
new: function(_type, _value)
{
var new_class = inherit(Notification);
new_class.Value = _value;
new_class.Type = _type;
return new_class;
},
};

var Recipient =
{
new: function(_ident)
{
var new_class = inherit(Recipient);
if (_ident === undefined || _ident === "")
{
_ident = id(new_class);
print("ERROR: Ident required when creating a recipient, defaulting to ",_ident);
}
return Recipient.construct(_ident, new_class);
},
construct: function(_ident, new_class)
{
new_class.Ident = _ident;
new_class.Active = 1;
new_class.Receive = function(notification)
{
print("ERROR: Receive function not implemented in recipient ",this.Ident);
return Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

return {
Transmitter: Transmitter,
Notification: Notification,
Recipient: Recipient
};

})();

//
// Instantiate a Global Transmitter
var GlobalTransmitter = emesary.Transmitter.new("GlobalTransmitter");

//---------------------------------------------------------------------------
//
// Title : EMESARY tests
//
// File Type : Implementation File
//
// Author : Richard Harrison (richard@zaretto.com)
//
// Creation Date : 29 January 2016
//
// Copyright � 2016 Richard Harrison Released under GPL V2
//
//---------------------------------------------------------------------------*/

print("Emesary tests");

var TestFailCount = 0;
var TestSuccessCount = 0;

var TestNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotification", _value);
return new_class;
},
};
var TestNotProcessedNotification =
{
new: function(_value)
{
var new_class = emesary.Notification.new("TestNotProcessedNotification", _value);
return new_class;
},
};
var RadarReturnNotification =
{
new: function(_value, _x, _y, _z)
{
var new_class = emesary.Notification.new("RadarReturnNotification", _value);
new_class.x = _x;
new_class.y = _y;
new_class.z = _z;
return new_class;
},
};

var TestRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
console.log(new_class);
new_class.count = 0;
new_class.Receive = function(notification)
{
if (notification.Type == "TestNotification")
{
this.count = this.count + 1;
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

var TestRadarRecipient =
{
new: function(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.Receive = function(notification)
{
if (notification.Type == "RadarReturnNotification")
{
print(" :: Test recipient ",this.Ident, " recv:",notification.Type," ",notification.Value);
print(" :: ",notification.x, " ", notification.y, " ", notification.z);
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};

function PerformTest(tid, t)
{
if (t())
{
TestSuccessCount = TestSuccessCount + 1;
print(" Test [Pass] :",tid);
}
else
{
TestFailCount = TestFailCount + 1;
print(" Test [Fail] :",tid);
}
}

var tt = TestRecipient.new("tt recipient");
var tt1 = TestRecipient.new("tt1 recipient1");
var tt3 = TestRecipient.new("tt3 recipient3");
var tt2 = TestRadarRecipient.new("tt2: Radar Test recipient2");

PerformTest("Create Notification",
function ()
{
var tn = TestNotification.new("Test notification");
return tn.Type == "TestNotification" && tn.Value == "Test notification";
});

PerformTest("Register tt",
function ()
{
GlobalTransmitter.Register(tt);
return GlobalTransmitter.RecipientCount() == 1;
});
PerformTest("Register tt1",
function ()
{
GlobalTransmitter.Register(tt1);
return GlobalTransmitter.RecipientCount() == 2;
});
PerformTest("Register tt2",
function ()
{
GlobalTransmitter.Register(tt2);
return GlobalTransmitter.RecipientCount() == 3;
});
PerformTest("Register tt3",
function ()
{
GlobalTransmitter.Register(tt3);
return GlobalTransmitter.RecipientCount() == 4;
});

PerformTest("Notify",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == 1;
});

PerformTest("DeRegister tt1",
function ()
{
GlobalTransmitter.DeRegister(tt1);
return GlobalTransmitter.RecipientCount() == 3;
});

tt1_count = tt1.count;
PerformTest("NotifyAfterDeregister",
function ()
{
GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return tt1.count == tt1_count;
});

tt.Active = 0;
tt_count = tt.count;

PerformTest("Recipient.Active",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotification.new("Test notification"));
return !emesary.Transmitter.IsFailed(rv) && rv != emesary.Transmitter.ReceiptStatus_NotProcessed && tt.count == tt_count;
});

PerformTest("Test Not Processed Notification",
function ()
{
var rv = GlobalTransmitter.NotifyAll(TestNotProcessedNotification.new("Not Processed"));
return rv == emesary.Transmitter.ReceiptStatus_NotProcessed;
});

GlobalTransmitter.NotifyAll(RadarReturnNotification.new("Radar notification", "x0","y0","z0"));

if (!TestFailCount)
print("Emesary: All ",TestSuccessCount," tests passed\n");
else
print("Emesary: ERROR: Tests completed: ",TestFailCount," failed && ",TestSuccessCount," passed\n");

</syntaxhighlight>

== Related ==
* http://chateau-logic.com/content/emesary-multiplayer-bridge-flightgear
* http://chateau-logic.com/content/emesary-nasal-implementation-flightgear
* http://emesary.codeplex.com/
* https://emesary.codeplex.com/documentation
* http://chateau-logic.com/content/emesary-efficient-inter-object-communication-using-interfaces-and-inheritance
* {{Search|list|keywords=emesary}}
* {{Search|forum|keywords=emesary}}

{{Appendix}}

[[Category:Emesary]]

TerraGear

2020-03-19T22:33:12Z

Wkitty42: /* Platform specific */ reformat list slightly and add link to ubuntu 14.04 terragear compilation page

{{Hatnote|Not to be confused with [[TerraSync]], a tool to download scenery on-the-fly.}}

[[File:TerraGear The Hague wireframe.png|thumb|270px|A wireframe view of detailed [[CORINE]] and [[OSM]] scenery, generated by TerraGear.]]
'''TerraGear''' is a collection of open-source tools and rendering libraries which can transform publically available GIS data in 3D representations (i.e. 3D models or 3D maps) of the earth for use in real time rendering projects. TerraGear can import 3D data sets such as DEM terrain grids, 2D polygon data sets such as coastlines, city outlines, lake outlines, and 2D raster data sets such as the 1 km NAOO land use/land cover data. It also has tools for generating realistic [[airport]]s, runways, and lighting based on available FAA data.

TerraGear is the primary tool used to generate the [[scenery]] for the [[FlightGear]] project.

Without terragear, it is possible to change Terrain '''textures''' but not terrain '''shapes'''. If you want to change the texture for cities, you change the materials file. If you want to change the coast line, you need terragear.
Check the material files in directory FGDATA/Material. Identify the material file that includes Montevideo, which is probably latin_american_cities.xml ([[Howto:Regional texturing]] and this page [[Procedural Texturing]]<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=311143#p311143
|title = <nowiki> Re: Improving terrain realism </nowiki>
|author = <nowiki> ludomotico </nowiki>
|date = May 25th, 2017
|added = May 25th, 2017
|script_version = 0.40
}}</ref>

== Introduction ==
For a variety of reasons you might want to build terrain yourself, rather than downloading it from the available scenery on FlightGear. For instance, if you use [[WED]] to create or modify an airport layout, you might wish to see how that modified airport would look in the Scenery before deciding you're happy with the results. And normally, to see and use the airport in the scenery, it's necessary to submit the modifications to the FlighGear scenery staff and then wait untill the next update of the scenery of that area is available via [[TerraSync]] or in the [http://www.flightgear.org/download/scenery/ official FlightGear Scenery] build. If you can build terrain yourself, you can start using it right away.

Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher resolution vector data (vmap1, Tiger) to get better roads/rivers. For all these reasons learning how to use TerraGear is a good idea.

== Getting TerraGear ==
=== Using the download_and_compile.sh script (Linux distros using apt) ===
Get the script download_and_compile.sh if you don't already have it. Copy it into a specific directory, no need to be root.
{{#tag: syntaxhighlight |
wget {{fgmeta url|view=raw|path=download_and_compile.sh}}
mv download_and_compile.sh\?format\=raw download_and_compile.sh
chmod 755 download_and_compile.sh
./download_and_compile.sh SIMGEAR TERRAGEAR
| lang="bash"
}}
This will build SIMGEAR (pre-requisite) and TERRAGEAR properly, installing dependencies if necessary and you will be done for the TG compilation part of the process.

=== Pre-compiled builds ===
* [http://build.flightgear.org:8080/job/TerraGearGUI-Win/lastSuccessfulBuild/artifact/*zip*/archive.zip Latest Windows build], built by the [[FlightGear Build Server]].

:*[[TerraGear_Installation_for_Windows|Detailed Windows Installation Instructions]]

=== Source ===
The source is hold in a [[Git]] repository at SourceForge..
{{#tag: syntaxhighlight |
{{terragear clone|post=flightgear-terragear}}
| lang="bash"
}}

you have to use the stable branch called "scenery/ws2.0"!
{{terragear url|branch=scenery/ws2.0/~}}

== Compilation ==
=== Dependencies ===
* TerraGear
** [[SimGear]] - '''Not''' simgear-cs! (simgear-dev package)
*** SimGear can be compiled without OSG support thus eliminating many deps, like OSG. Use "-DSIMGEAR_HEADLESS=YES" for a minimal build.
** [http://www.cgal.org/ CGAL] - For high accuracy geometric calculations
** [http://www.gdal.org/ libgdal]

=== Building ===
cmake . [options]
make install
<tt>cmake</tt> options:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Platform specific ===
* Debian: [[Building FlightGear - Debian#TerraGear]]
* Gentoo: <tt>emerge -av terragear</tt> See [[Building Flightgear - Gentoo]].
* Ubuntu: [[Building terragear in Ubuntu 910 (32- or 64-bit)]] [[TerraGear compilation - Ubuntu 14.04]]

== GUI Tool ==
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Related content ==
* [[Using Terragear]]
* [[TerraGear CORINE]]
* [[TerraGear Documentation]]
* [http://api-docs.freeflightsim.org/terragear/ TerraGear API docs]

{{Terra}}
{{Building}}

[[Category:TerraGear]]

[[es:TerraGear]]
[[fr:TerraGear]]

Scripted Compilation on Linux Debian/Ubuntu

2019-11-28T21:40:05Z

Wkitty42: remove subversion entries since dnc doesn't use/need svn

<tt>download_and_compile.sh</tt> is a Bash script that takes care of downloading and compiling FlightGear and related software from their source code repositories with just one command execution<ref name="just-one-command">Due to technical problems on the [https://sourceforge.net/ SourceForge] side, this is currently only true once you have an [[FGData]] clone. See [[User:Rominet|here]] for details.</ref> for both 32-bit and 64-bit [https://www.debian.org/ Debian]-based systems. Pre-existing versions (if any) of the software installed by <tt>download_and_compile.sh</tt> are not touched at all since the script downloads, builds and installs everything under the directory in which it is launched. You can choose the particular components to download, build and install.

Unless told not to do so, <tt>download_and_compile.sh</tt> installs packages with <tt>apt-get</tt>. For this reason, it is primarily useful on Debian-based distributions. However, if one disables package installation (using <code>-pn</code> or <code>--sudo=echo</code>) and installs the corresponding dependencies oneself, it might be useful on other distributions as well.

For hints on using <tt>rpm</tt>-based distributions such as Redhat, Fedora and CentOS, please see [[CentOS]]. Please also see [[Superbuild]].

== Introduction ==

<tt>download_and_compile.sh</tt> is a [https://www.gnu.org/software/bash/ Bash] script written for [https://www.debian.org/ Debian]-derived distributions ([https://www.ubuntu.com/ Ubuntu], [https://devuan.org/ Devuan], [https://www.linuxmint.com/ Linux Mint], etc.). Its purpose is to automatically install dependencies using the package manager, then build and install FlightGear-related programs.

By default, <tt>download_and_compile.sh</tt> installs most dependencies with <tt>apt-get</tt> run under <tt>sudo</tt>.<ref name="disabling-installation-of-dependencies-via-package-manager">If you think you already have the dependencies, this installation can be disabled either by using option <code>-pn</code> or by passing option <code>--sudo=echo</code> (the latter results in printing the <tt>apt-get</tt> command line without running it).</ref> Other dependencies, either because they aren't available in the standard APT repositories, or because of non-option arguments passed to <tt>download_and_compile.sh</tt>, are downloaded and compiled on the fly (this can be the case for [[PLIB]], [[Simgear]] and [[OpenSceneGraph]], for instance—it all depends on the arguments passed to the script).

<tt>download_and_compile.sh</tt> works in the directory it is run from: apart from dependencies installed via the package manager, all programs built by <tt>download_and_compile.sh</tt> are installed under the <tt>install</tt> subdirectory of the directory from which the script was run. In other words, installation of programs by <tt>download_and_compile.sh</tt> is clean, very easy to undo and doesn't interfere with other programs on the system.

It is possible to manage several directory trees with <tt>download_and_compile.sh</tt>; as far as it is concerned, such directory trees are completely independent from each other. For instance, if you run <tt>download_and_compile.sh</tt> in <tt>dir1</tt> and <tt>dir2</tt>, the programs installed under <tt>dir1</tt> won't “see” those installed under <tt>dir2</tt>, and vice versa.

Apart from its main purpose, <tt>download_and_compile.sh</tt> can be used to find hopefully up-to-date build-dependency information for FlightGear and related software. You would do so by inspecting [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh the script] at the point where it installs packages.<ref name="note-inspecting-download-and-compile-sh-to-gather-build-dependency-information">Look for strings such as <tt>zlib1g-dev</tt>, <tt>libglew-dev</tt> or <tt>qt5-default</tt>.</ref>

== Prerequisites ==

Before embarking on building your own FlightGear binaries, you must have already installed the necessary tools to compile the source code with. These preliminary tools are

* build-essential
* git
* cmake
* automake

They can be installed quite simply by running the following command line.

$ sudo apt-get install build-essential git cmake automake

Once these tools are installed, the download_and_compile.sh script can be run. It will install possibly needed additional tools and libraries as it runs.

== Disk space requirements and build time ==

As of April 2019, building FlightGear requires about 12 [https://en.wikipedia.org/wiki/Gibibyte GiB] of disk space. Note that this includes downloaded source code for [[SimGear]] and FlightGear, generated build files and the large [[FGData]] repository (about 6 GiB for that one).

With an Intel Core i7 860 CPU (2.80 GHz) purchased in 2009, compiling [[SimGear]] and FlightGear 2019.2 with option <code>-j8</code> takes about 14 minutes. If you don't have a fast machine and build using only one core, it may require several hours.

== Download ==

You can get <tt>download_and_compile.sh</tt> {{fgmeta source
| path = download_and_compile.sh
| text = from FGMeta
}}. It is contained in the [[FGMeta]] repository, which is maintained by the FlightGear developers. The script can be downloaded from the link given above, however, for easier updates and in order to have the command <code>download_and_compile.sh --version</code> work as intended, it is recommended to get it as explained [[#getting-download-and-compile-sh-using-an-fgmeta-clone|below]].

In case you build stable versions of FlightGear using the <code>-s</code> option of <tt>download_and_compile.sh</tt>, remember to update the script before trying to build a new version of FlightGear (see [[#updating-download-and-compile-sh-using-an-fgmeta-clone|Updating <tt>download_and_compile.sh</tt>]] below). Of course, you can update it more often in order to benefit from new features or bug fixes; this is especially useful if you are building ''next'', that is, the development branch of FlightGear.

== Getting started with <tt>download_and_compile.sh</tt> ==

Because of technical problems at SourceForge (cloning [[FGData]] using the https protocol usually fails), the initial setup is unfortunately more complex than it used to be. You'll be guided step by step though, so don't be afraid. Besides, once you have a complete clone of the FGData repository, all future operations will be really easy.

We'll first explain how to get <tt>download_and_compile.sh</tt> in a way that makes it convenient to update and causes the command <code>download_and_compile.sh --version</code> to work as intended (the reported “version” is a Git blob id such as <tt>6a5e4f05e2ccf27115eec58313be027b11266097</tt><ref name="note-on-download-and-compile-sh-version-being-a-Git-blob-id">This looks like, but is ''not'' a Git commit identifier. This kind of “version number” is admittedly not very pretty, but it doesn't pollute Git commits (the diffs) and is automatically updated by Git every time you update <tt>download_and_compile.sh</tt> the way we present here; thus, the advantages compensate for the ugliness.</ref>). Then we'll show how to clone the large FGData repository, and finally give instructions to get FlightGear up and running.

=== Notations ===

When a command should be run as an unpriviledged user, it will be preceded by a dollar sign:
$ whoami
toto
In contrast, a hash sign (#) means that the command must be run with superuser privileges to achieve the desired effect:
# whoami
root

In order to make instructions easy to understand, two directories (= folders) will be consistently used for the same purpose below:
* <tt>~/flightgear/fgmeta</tt> will contain a clone of the [[FGMeta]] repository; therefore, <tt>download_and_compile.sh</tt> will reside in that directory;
* <tt>~/flightgear/dnc-managed</tt> will be the directory from which we run <tt>download_and_compile.sh</tt>. In other words, with this setup, a typical sequence of commands could be:
$ cd ~/flightgear/dnc-managed
$ ~/flightgear/fgmeta/download_and_compile.sh SIMGEAR FGFS DATA
These are of course just examples. The aforementioned paths are not hardwired anywhere in the script; you are free to choose the directories you want for these purposes.

=== Getting <tt>download_and_compile.sh</tt> the “right way” ===

There are several ways to obtain [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh download_and_compile.sh]. The method described here makes it very easy to update the script and causes the command <code>download_and_compile.sh --version</code> to work as intended.

As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we want to clone the [[FGMeta]] repository in <tt>~/flightgear/fgmeta</tt>. Let's go:
$ mkdir -p ~/flightgear
$ cd ~/flightgear
<nowiki>$ git clone https://git.code.sf.net/p/flightgear/fgmeta</nowiki>
You now have a fresh FGMeta clone in <tt>~/flightgear/fgmeta</tt> and your brand new <tt>download_and_compile.sh</tt> script is located in that directory. You can already try it to see the available options:
<pre>$ ~/flightgear/fgmeta/download_and_compile.sh --help
download_and_compile.sh [OPTION...] [--] [COMPONENT...]
Download and compile components belonging to the FlightGear ecosystem.

Without any COMPONENT listed, or if ALL is specified, recompile all
components listed in the WHATTOBUILDALL variable. Each COMPONENT may
be one of the following words:

ALL, CMAKE, OSG, PLIB, OPENRTI, SIMGEAR, FGFS, DATA, FGRUN, FGO, FGX,
OPENRADAR, ATCPIE, TERRAGEAR, TERRAGEARGUI

Available options:
-h, --help show this help message and exit
--version print version and license information, then exit

(...)</pre>

=== Updating <tt>download_and_compile.sh</tt> ===

Now that you have <tt>download_and_compile.sh</tt> from the [[FGMeta]] repository, it is very easy to update (this assumes you didn't modify anything yourself inside <tt>~/flightgear/fgmeta</tt>!):
$ cd ~/flightgear/fgmeta && git pull

If you want to keep updates as easy as we just shown, it is best not to modify <tt>download_and_compile.sh</tt> yourself. <tt>download_and_compile.sh</tt> has plenty of options that usually make it unnecessary to modify the script. Just run <code>download_and_compile.sh --help</code> and learn about the available options when you feel the need to change something. Unless you have special needs that can only be accomodated by modifying <tt>download_and_compile.sh</tt>, you are invited to skip to the next section.

If you really, ''really'' want to modify <tt>download_and_compile.sh</tt> while keeping updates easy, a good technique is to add your changes to your FGMeta clone in the form of one or more Git ''commits'' (no need to push them anywhere, commits can remain in your clone). How to do that is beyond the scope of this document, though; read Git tutorials if you want to learn it (there are plenty on the Internet). Once you have committed your changes to your FGMeta clone, make sure the repository is clean (use <code>git status</code>), then update it with:
$ cd ~/flightgear/fgmeta && git pull --rebase
This will apply your commits on top of the latest commit of the branch that is currently checked out, which so far contained the official version of <tt>download_and_compile.sh</tt>. In case your changes conflict with the update, Git will tell you and you'll have to resolve the conflict manually (look for “Git resolve conflict” on your favorite search engine)... or start again from a pristine [[FGMeta]] clone.

=== Building FlightGear ===

For the method described below, you'll need an account at [https://sourceforge.net/ SourceForge] (this is unfortunate, but methods that don't require such an account are either unreliable or insecure, as long as [[FGData]] can't be cloned using the <tt>https</tt> protocol). If you don't already have one, go to the [https://sourceforge.net/user/registration registration page] and create an account. In all this section, we'll assume that your account name at SourceForge is ''SFusername''.

In what follows, we won't give the full path to <tt>download_and_compile.sh</tt> when showing commands to be run, but you should prepend it to <tt>download_and_compile.sh</tt> whenever you see a <tt>download_and_compile.sh</tt> command. For instance, if you used the same path as in [[#getting-started-with-download-and-compile-sh-notations|Notations]] and see the command:
$ download_and_compile.sh --help
what you should actually run is:
$ ~/flightgear/fgmeta/download_and_compile.sh --help

Apart from this harmless command, ''do not'' run other <tt>download_and_compile.sh</tt> commands from an arbitrary directory, in particular ''don't'' run them from <tt>~/flightgear/fgmeta</tt>. This is because '''most other <tt>download_and_compile.sh</tt> commands write to the current directory''' (<code>download_and_compile.sh --help</code> and <code>download_and_compile.sh --version</code> are safe to run from any directory, though).

Of course, it is always possible to make commands shorter by setting up aliases (see tips at the end of [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message]), by adding the directory containing <tt>download_and_compile.sh</tt> to your <tt>PATH</tt> or by creating a symbolink link pointing to <tt>download_and_compile.sh</tt> in a directory that is part of your <tt>PATH</tt>. This is not necessary, though; do it only if you feel the need (when enabled, persistent shell history is often enough for such things).

{{Note|The following commands should be run from an empty directory<ref name="dedicated-directory-won-t-stay-empty-forever">Well, empty before the first time; later, <tt>download_and_compile.sh</tt> is going to populate it with plenty of FlightGear files and subdirectories, of course.</ref> in a partition that has enough free space (see [[#disk-space-requirements-and-build-time | Disk space requirements and build time]]). As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we are going to choose the directory <tt>~/flightgear/dnc-managed</tt> for this purpose, in order to express that the whole directory tree is managed by <tt>download_and_compile.sh</tt>. This is just an example; feel free to choose another directory if you want.

'''Don't run the commands from a non-dedicated directory,''' because it will be filled with files and directories created by <tt>download_and_compile.sh</tt> and the FlightGear, SimGear, etc. build systems. That would be a complete mess! In particular, ''don't'' run the commands from the directory containing your [[FGMeta]] clone.}}

{{Note|As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we assume that your Unix user name (login) is <tt>toto</tt>. Don't confuse the <tt>sudo</tt> password prompt (where you need to enter <tt>toto</tt>'s password) with the password prompt for your SourceForge account! The former appears as
[sudo] password for toto:
whereas the latter is just:
Password:
}}

{{Tip|In case you want to run some other program instead of <tt>sudo</tt>, this can be done with the <code>--sudo</code> option of <tt>download_and_compile.sh</tt>. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass <code><nowiki>--sudo=echo</nowiki></code> to <tt>download_and_compile.sh</tt>. Like all other options, <code><nowiki>--sudo</nowiki></code> must be given ''before'' all arguments that are component names (such as <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt>, etc.).}}

The package manager used by <tt>download_and_compile.sh</tt> by default is <tt>apt-get</tt>. You can use another one if you want, as long as it supports the following calls:
''pkg-mgr'' update
''pkg-mgr'' install ''pkg1 pkg2'' ...
This is the case for <tt>aptitude</tt> as well as <tt>apt</tt>. If you want <tt>download_and_compile.sh</tt> to use <tt>aptitude</tt>, give it the option <code><nowiki>--package-manager=aptitude</nowiki></code> before any of the ''COMPONENT'' arguments.

All options of <tt>download_and_compile.sh</tt> can be seen by running the following command:
$ download_and_compile.sh --help
Now the instructions we promised you. You have chosen a dedicated directory where all the stuff that is downloaded and built by <tt>download_and_compile.sh</tt> will be stored. This is <tt>~/flightgear/dnc-managed</tt> in our example, and should be empty before you run <tt>download_and_compile.sh</tt> for the first time. However, it is quite correct to start <tt>download_and_compile.sh</tt> from the same directory for subsequent runs, even when non-empty (otherwise, <tt>download_and_compile.sh</tt> would automatically reclone the repositories every time you run it; that would be a sheer waste of time and bandwidth).

Ready? Let's go!
<pre>$ mkdir -p ~/flightgear/dnc-managed
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh --git-clone-site-params SourceForge=ssh:SFusername DATA
**********************************************************************
* *
* Warning: a typical SimGear + FlightGear + FGData build requires *
* about 12 GiB of disk space. The compilation part may last from a *
* few minutes to hours, depending on your computer. *
* *
* Hint: use the -j option if your CPU has several cores, as in: *
* *
* download_and_compile.sh -j$(nproc) *
* *
**********************************************************************
Running 'apt-get update'...
[sudo] password for toto:

(...)

Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Running 'apt-get install build-essential git libcurl4-openssl-dev cmake'...
[sudo] password for toto:

(...)

****************************************
**************** DATA ******************
****************************************
Fetching DATA with 'git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata'
Cloning into '.'...
The authenticity of host 'git.code.sf.net (216.105.38.16)' can't be established.
ECDSA key fingerprint is SHA256:FeVkoYYBjuQzb5QVAgm3BkmeN5TTgL2qfmqz9tCPRL4.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added 'git.code.sf.net,216.105.38.16' (ECDSA) to the list of known hosts.
Connection closed by 216.105.38.16 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
</pre>

The above messages are perfectly normal but deserve a little explanation. Here, <tt>ssh</tt> asked us to confirm that the fingerprint sent by the remote host is that of the real <tt>git.code.sf.net</tt>, as opposed to that of some malicious server ''pretending'' to be <tt>git.code.sf.net</tt>. This confirmation only has to be done once, after which it is remembered thanks to <tt>~/.ssh/known_hosts</tt>. You should visit the [https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/#fingerprint-listing page that gives the host key fingerprint of every publically-accessible SSH server at SourceForge] and carefully check that the fingerprint appearing on your terminal is listed on that page for <tt>git.code.sf.net</tt>, or some matching pattern such as <tt>*.code.sf.net</tt>.

If the fingerprint that is printed on your terminal is not listed on that page, answer <tt>no</tt> to the question ''Are you sure you want to continue connecting (yes/no)?'' and copy/paste to flightgear-devel (see [[Mailing lists]]) the above message from <tt>ssh</tt> that contains the fingerprint sent to you by the remote host which pretends to be <tt>git.code.sf.net</tt>. If this happened, you should stop here and wait for answers from readers of flightgear-devel.

From now on, we'll assume that the fingerprint you received was correct, and therefore that you have answered <tt>yes</tt> to the ''Are you sure you want to continue connecting (yes/no)?'' question.

In this example, it took us several minutes to verify the fingerprint of the <tt>git.code.sf.net</tt> server and confirm it to <tt>ssh</tt>. Because of this delay, <tt>git.code.sf.net</tt> hung up on us and closed the connection. This is absolutely ''not a problem:'' we can just rerun the <tt>download_and_compile.sh</tt> command with the same arguments as the first time. Since we answered <tt>yes</tt> to the ''Are you sure you want to continue connecting (yes/no)?'' prompt, the fingerprint of <tt>git.code.sf.net</tt>'s key has been stored in <tt>~/.ssh/known_hosts</tt>, therefore we won't get this prompt anymore. But if some server claiming to be <tt>git.code.sf.net</tt> presents a host key that has a different fingerprint in the future, <tt>ssh</tt> will print a big fat warning that the server may belong to an attacker trying to impersonate <tt>git.code.sf.net</tt>. Therefore, this SSH host key verification is very useful to protect us from future attacks (which hopefully won't happen at all).

As said, we just rerun the <tt>download_and_compile.sh</tt> command with the same arguments:
<pre>$ download_and_compile.sh --git-clone-site-params SourceForge=ssh:SFusername DATA
**********************************************************************
* *
* Warning: a typical SimGear + FlightGear + FGData build requires *
* about 12 GiB of disk space. The compilation part may last from a *
* few minutes to hours, depending on your computer. *
* *
* Hint: use the -j option if your CPU has several cores, as in: *
* *
* download_and_compile.sh -j$(nproc) *
* *
**********************************************************************
Running 'apt-get update'...
[sudo] password for toto:

(...)

Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Running 'apt-get install build-essential git libcurl4-openssl-dev cmake'...
[sudo] password for toto:

(...)

****************************************
**************** DATA ******************
****************************************
Fetching DATA with 'git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata'
Cloning into '.'...
Password:</pre>
As explained above, the preceding prompt is for your SourceForge password (which you could guess from the <code><nowiki>git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata</nowiki></code> command).
<pre>remote: Enumerating objects: 67011, done.
remote: Counting objects: 100% (67011/67011), done.
remote: Compressing objects: 100% (31342/31342), done.
remote: Total 67011 (delta 38776), reused 59640 (delta 33570)
Receiving objects: 100% (67011/67011), 2.60 GiB | 313.00 KiB/s, done.
Resolving deltas: 100% (38776/38776), done.
Checking out files: 100% (12959/12959), done.
Password:</pre>
(It will take a fair amount of time to get there, because this is the complete download of [[FGData]].) 
This is again a prompt for your SourceForge password, because <tt>download_and_compile.sh</tt> wants to run <code>git pull --rebase</code> in the repository (admittedly, it's a bit dumb after a <tt>clone</tt> operation—please forgive us). In case you were not monitoring the <tt>clone</tt> operation, you probably saw the password prompt way after <tt>git.code.sf.net</tt> got bored waiting for you and closed our second connection:
<pre>Connection closed by 216.105.38.16 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.</pre>
(if not, there should be no error message and you should have a clean FGData clone) 
No worries. Just as before, simply rerun the command with the same arguments:
<pre>$ download_and_compile.sh --git-clone-site-params SourceForge=ssh:SFusername DATA
**********************************************************************
* *
* Warning: a typical SimGear + FlightGear + FGData build requires *
* about 12 GiB of disk space. The compilation part may last from a *
* few minutes to hours, depending on your computer. *
* *
* Hint: use the -j option if your CPU has several cores, as in: *
* *
* download_and_compile.sh -j$(nproc) *
* *
**********************************************************************
Running 'apt-get update'...
[sudo] password for toto:

(...)

Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Running 'apt-get install build-essential git libcurl4-openssl-dev cmake'...
[sudo] password for toto:

(...)

****************************************
**************** DATA ******************
****************************************
DATA: the repository already exists
Password:
Already up to date.
Current branch next is up to date.
Already on 'next'
Your branch is up to date with 'origin/next'.
All optional package alternatives have found a matching package.

download_and_compile.sh has finished to work.
</pre>
There we are! You now have a clean, up-to-date [[FGData]] clone in <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> (remember: <tt>~/flightgear/dnc-managed</tt> is the directory from which you ran <tt>download_and_compile.sh</tt>). Note this place: the full path of the <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> directory is your [[$FG_ROOT]].

Now, change the protocol to use for future updates of your FGData clone:<ref name="changing-the-protocol-for-a-git-remote-manual-method">Another way would be to manually change the relevant line starting with <code><nowiki>url = ssh://SFusername@</nowiki></code> for the <code>origin</code> remote in the <tt>.git/config</tt> file that lives inside your repository clone (i.e., <tt>~/flightgear/dnc-managed/install/flightgear/fgdata/.git/config</tt> in our example).</ref>
(cd install/flightgear/fgdata && \
git remote set-url origin <nowiki>https://git.code.sf.net/p/flightgear/fgdata</nowiki>)
(you can check at any time the protocol(s) in use with the command <code>git remote -v</code> run inside a Git repository—in this case, inside the folder <tt>install/flightgear/fgdata</tt>). As a consequence of this change, all future updates of your FGData clone will use the <tt>https</tt> protocol, therefore you won't be prompted anymore for your SourceForge password.

All that remains to do is to run, from the same directory as before (<tt>~/flightgear/dnc-managed</tt> in our example):
$ download_and_compile.sh
or
$ download_and_compile.sh -j$(nproc)
(<code>-j$(nproc)</code> is “only” useful to save time—see the tip below).

When you don't pass any non-option argument to <tt>download_and_compile.sh</tt> as done here, it takes care of the three base components needed to run FlightGear: <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> (these are the component names used by <tt>download_and_compile.sh</tt>, i.e., the final arguments one can optionally give in a <tt>download_and_compile.sh</tt> command; in normal speech, they correspond to the {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}} and {{fgdata source
| text = FGData
}} repositories). Therefore, the above command is presently exactly equivalent to:
$ download_and_compile.sh SIMGEAR FGFS DATA

In case you wanted to build another component such as [[OpenSceneGraph|OSG]], you could add it to the command, like this:
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

(With current Debian stable, this is not necessary because it has OpenSceneGraph 3.4. But if your distribution only has an older version, you'll certainly need to select the <tt>OSG</tt> component like this.)

When the command terminates, you should have a script called <tt>run_fgfs.sh</tt> in the directory <tt>~/flightgear/dnc-managed</tt> from which you ran <tt>download_and_compile.sh</tt>. This will be your script to run FlightGear. For instance, in order to start the built-in launcher, you can run the following commands:<ref name="no-need-to-change-to-dnc-managed-dir-before-starting-generated-scripts">We give these commands because they are easy to read, but the <code>cd</code> command is not needed if you use the correct path, as in <code>~/flightgear/dnc-managed/run_fgfs.sh --launcher</code>.</ref>
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher
(You may omit the <code>--launcher</code> option; this would simply start FlightGear without any launcher, at the default airport and with the default aircraft.) 
In case you find this tedious to type or have more arguments to pass on a regular basis, you can follow the advice given at the end of [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message] or use another launcher such as [[FFGo]] (but the [[FlightGear Qt launcher|FlightGear built-in launcher]] started with <code>run_fgfs.sh --launcher</code> is quite fine, be sure to try it first!).

{{Tip|You can considerably speed up the build process—literally, save hours—by telling <tt>download_and_compile.sh</tt> to use several cores simultaneously when compiling. With option <code>-j$(nproc)</code>, compilations will use all cores available on your processor; thus, a typical <tt>download_and_compile.sh</tt> command is <code>download_and_compile.sh -j$(nproc)</code>. If you want to use, say, 4 cores, replace <code>-j$(nproc)</code> with <code>-j4</code>.}}

=== Updating FlightGear ===

Just go to the directory from which you you previously ran <tt>download_and_compile.sh</tt> (<tt>~/flightgear/dnc-managed</tt> in our example). This is the folder which, if you did a complete run of <tt>download_and_compile.sh</tt> as shown in the previous section, contains the <tt>run_fgfs.sh</tt> script and a log file named <tt>compilation_log.txt</tt> that records what <tt>download_and_compile.sh</tt> did in its last run. If you wish to update, say, {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}} and {{fgdata source
| text = FGData
}}, simply execute this:
$ download_and_compile.sh -pn SIMGEAR FGFS DATA
We'll explain the <code>-pn</code> in a minute. <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> are called ''components'' in <tt>download_and_compile.sh</tt> terminology. A component generally corresponds to a software repository, or something close. In fact, since <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> are often precisely the components people wish to update, they form the default components set, so that the previous command is equivalent to:
$ download_and_compile.sh -pn
Now about this <code>-pn</code>. It is equivalent to <code>-p n</code> and means “don't install packages from my (Linux) distribution” (<code>y</code> means ''yes, please install'', <code>n</code> means ''no, don't install''). In case you forgot that, simply run:
$ download_and_compile.sh --help
What does it imply to pass <code>-pn</code>? This tells <tt>download_and_compile.sh</tt> to completely skip the step where it checks for needed packages from your distribution and installs them, by default using <tt>apt-get</tt>. It thus goes straight to the following steps:
* update each repository corresponding to one of the selected components (<tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> in our example);
* compile each selected component that requires compilation;
* install each selected component in the appropriate place (under <tt>~/flightgear/dnc-managed</tt> according to our [[#getting-started-with-download-and-compile-sh-notations|Notations]]).
In case you don't have all required dependencies for the selected components, one of them is likely to fail, of course, since by passing <code>-pn</code> to <tt>download_and_compile.sh</tt>, you forbid it to install these dependencies for you. So, you can also very well update without passing the <code>-pn</code> option, it will simply take a little longer (the time to check if all dependencies of the selected components are available with <tt>APT</tt>). In fact, this is '''what you should do if the previous <tt>download_and_compile.sh</tt> run failed:''' first update <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|above]]) then run it ''without'' <code>-pn</code><ref name="passing-no-pn-option-equals-passing-py">Which is the same as passing <code>-py</code>.</ref> in case new dependencies have been recently added and you don't have them on your system yet—this would be a very likely cause for the failure.

'''Summary'''

Routine update:
$ download_and_compile.sh -pn ''COMPONENT...''
In case this fails, first update <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|above]]), then run
$ download_and_compile.sh ''COMPONENT...''
where ''COMPONENT...'' stands for the space-separated list of selected components, and defaults to <tt>SIMGEAR FGFS DATA</tt> if you don't specify any.

=== Examining the history of <tt>download_and_compile.sh</tt> ===

Looking at the latest commits that affected <tt>download_and_compile.sh</tt> is quite easy with your FGMeta clone:
$ cd ~/flightgear/fgmeta
$ git log -- download_and_compile.sh
(then quit by typing <tt>q</tt>, assuming your <tt>$GIT_PAGER</tt> is <tt>less</tt>) 

In order to do the same, but also see the patch for each commit:
$ cd ~/flightgear/fgmeta
$ git log -p -- download_and_compile.sh

== List of available components ==

The <tt>download_and_compile.sh</tt> script is able to download, compile (when applicable) and install the following components:

* ATCPIE (for the [[ATC-pie]] air traffic control simulation program)
* CMAKE (for the [https://cmake.org/ CMake] build tool—this can be useful in case CMake is too old in your distribution)
* DATA (for [[FGData]], the main set of data files used by FlightGear)
* FGFS (for FlightGear itself)
* FGO (for the [[FGo!]] FlightGear launcher)
* FGRUN (for the [[Fgrun|FGRun]] FlightGear launcher)
* FGX (for the [[FGX|FGx]] FlightGear launcher<ref name="note-on-the-status-of-FGx-support-in-download-and-compile-sh">Support for FGx in <tt>download_and_compile.sh</tt> would probably benefit from a code review.</ref>)
* OPENRADAR (for the [[OpenRadar]] air traffic control simulation program)
* OPENRTI (for [[FlightGear HLA support (High Level Architecture)#OpenRTI | OpenRTI]]<ref name="note-on-the-status-of-OpenRTI-support-in-FG">Note that OpenRTI is just an optional dependency for [[FlightGear high-level architecture support | HLA support]]. For the time being, you should be just fine building without it. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it is probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.</ref>)
* OSG (for the [[OpenSceneGraph]] library)
* PLIB (for the [[PLIB]] library)
* SIMGEAR (for the [[SimGear]] library—foundation for FlightGear and TerraGear)
* TERRAGEAR (for the [[TerraGear]] terrain building toolchain)
* TERRAGEARGUI (for [[TerraGear GUI]], a graphical interface for TerraGear)

Each of the items listed above is a ''component'' in <tt>download_and_compile.sh</tt> terminology. Components are written in uppercase by convention.

{{Note|The preceding list might not be up-to-date. The up-to-date list of components supported by <tt>download_and_compile.sh</tt> can always be obtained by running <code>download_and_compile.sh --help</code>.}}

What is the point of knowing this? Because you may pass component names to <tt>download_and_compile.sh</tt> in order to tell it what you want to download, build and install. By default, only the three essential components SIMGEAR, FGFS and DATA are taken care of, which means that the command:
$ download_and_compile.sh
is equivalent to:
$ download_and_compile.sh SIMGEAR FGFS DATA

In case you want to do the same build with just [[OpenSceneGraph]] added, you can use:
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

You get the idea. When several components are passed on the same command line, <tt>download_and_compile.sh</tt> chooses a reasonable order for processing, so don't worry about that.

== When building 'next', you may see build errors ==

Keeping in mind that this script compiles sometimes bleeding edge software, it can happen that what was successfully compiling last week, does not compile anymore today. Building the stable version should always work, unless there is a problem with the script.

That said, don't be too afraid of building the development version (called ''next''): this is the one developers use all the time, so kindly asking on the flightgear-devel [[Mailing_lists|mailing list]] in case a problem popped up<ref name="what-to-provide-when-asking-for-help">Don't forget in this case to precisely tell what you did and include the <tt>compilation_log.txt</tt> file written by <tt>download_and_compile.sh</tt>.</ref> should allow you to find good advice and get the problem quickly fixed, if it's a new one. Conversely, probably not many people (in 2019) build themselves the “stable” version of FlightGear. People who want the stable version can usually have it from their distribution, this is generally easier. On the other hand, those running <tt>download_and_compile.sh</tt> typically want to build the latest code that FlightGear developers are working on; this is useful when you want to contribute feedback, code, aircraft or scenery based on recent technology, or just want to enjoy the latest features and bugs. ;-)

== Task-specific instructions ==

{{Note|In this section, we assume you've read and followed the advice given in [[#getting-started-with-download-and-compile-sh|Getting started with <tt>download_and_compile.sh</tt>]].}}

=== Selecting the components to build ===

By default, <tt>download_and_compile.sh</tt> downloads or updates, then compiles, [[SimGear]] and FlightGear, and downloads or updates [[FGData]] (by nature, FGData can't be compiled). This is what happens when running:
$ download_and_compile.sh
The preceding command is therefore equivalent to:
$ download_and_compile.sh SIMGEAR FGFS DATA

To make <tt>download_and_compile.sh</tt> take care of other programs or libraries, use non-option arguments naming the ''components'' you want, for instance:
$ download_and_compile.sh SIMGEAR FGFS DATA OSG
SIMGEAR, FGFS, DATA and OSG are the component names respectively corresponding to [[SimGear]], FlightGear, [[FGData]] and [[OpenSceneGraph]] in <tt>download_and_compile.sh</tt>'s terminology.

A [[#list-of-available-components|list of available components]] is provided on this page, but the fully up-to-date list can always be obtained by running <code>download_and_compile.sh --help</code>.

=== Choosing between stable and development versions ===

By default, <tt>download_and_compile.sh</tt> fetches code and data from development branches of the source repositories (which sometimes causes compilation or runtime errors). However, it is possible to tell the script to download the latest ”stable” version of each component, for some suitable definition of “stable”. This is by means of the <code>-s</code> option:
$ download_and_compile.sh -s ''COMPONENT1 COMPONENT2...''

How does it work?
* For [[SimGear]], FlightGear and [[FGData]], it uses the most recent stable release branch of the corresponding Git repository.
* For some components, a known-stable version is hardcoded in <tt>download_and_compile.sh</tt> and used when the <code>-s</code> option is given<ref name="components-with-a-known-stable-version-hardcoded-in-download_and_compile_sh">As of May 2019, apart from SIMGEAR, FGFS and DATA, the only components for which <tt>download_and_compile.sh</tt> “knows” a stable version are TERRAGEAR and OPENRTI.</ref> (for instance, the hardcoded information can be the name of a Git branch).
* For the other components, the <code>-s</code> option has no effect.

{{Warning|In a given folder where <tt>download_and_compile.sh</tt> is run, you should either always use the <code>-s</code> option, or never. Building some components with <code>-s</code> and others without (all within the same base folder) is not supported.}}

Applying what we just said to the FGFS component (FlightGear) leaves us with two main options:
* build the latest stable release;
* build the current development version (bleeding edge), which lives in the {{flightgear source
| branch = next
| text = next
}} branch of the FlightGear repository.

==== Building the latest stable FlightGear release ====

When executing <tt>download_and_compile.sh</tt>, use the <code>-s</code> option to build the latest stable release:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh -s

{{Note|If you decide to use the <code>-s</code> option in a given directory tree, you should use it for all components in that directory tree (SIMGEAR, FGFS, DATA, etc.). Running <tt>download_and_compile.sh</tt> in a given directory with the <code>-s</code> option for some components and not for others is not supported.}}

==== Building the current FlightGear development version ====

When executing <tt>download_and_compile.sh</tt> without any option, the development version of every selected component is built:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh
(In this example, the implicitly-selected components are SIMGEAR, FGFS and DATA, as explained [[#selecting-the-components-to-work-on | above]].)

{{Note|The development version of FlightGear changes on an almost daily basis. It provides the latest features, but is not guaranteed to always work reliably. If you don't want to take the risk of finding new bugs when updating, you may prefer to use the latest stable release.}}

=== Passing custom arguments to CMake ===

Sometimes, when building a program, you may want to enable a feature that is not enabled by default, or disable a feature that is enabled by default. With recent versions of <tt>download_and_compile.sh</tt> (April 2019 or later), the environment variables <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt> allow one to do that for SimGear and FlightGear. For instance, in order to link SimGear with the system Expat library, you can do:
$ SG_CMAKEARGS='-DSYSTEM_EXPAT=ON' download_and_compile.sh SIMGEAR
Similarly, disabling HID-based input when building FlightGear can be achieved this way:
$ FG_CMAKEARGS='-DENABLE_HID_INPUT=OFF' download_and_compile.sh FGFS

{{Note|Such options are typically defined in <tt>CMakeLists.txt</tt> files, for example {{simgear source
| path = CMakeLists.txt
| text = here
}} for SimGear and {{flightgear source
| path = CMakeLists.txt
| text = here
}} for FlightGear.}}

This can be useful for instance to work around bugs in a part of SimGear or FlightGear that you don't need, but causes a build or runtime failure (see {{forum link|t=35740|text=here}} for example). This is often convenient when using the development version of FlightGear, but doesn't mean such bugs shouldn't be reported!

If you have several such options to pass, just use spaces to separate them inside the quotes:
$ FG_CMAKEARGS='-DENABLE_SWIFT=ON -DENABLE_HID_INPUT=OFF' download_and_compile.sh FGFS
Of course, the same thing can also be achieved this way in Bourne-style shells:
$ export FG_CMAKEARGS='-DENABLE_SWIFT=ON -DENABLE_HID_INPUT=OFF'
$ download_and_compile.sh FGFS

It is also possible to set both <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt> at the same time for a given <tt>download_and_compile.sh</tt> run:
$ export SG_CMAKEARGS='-DSYSTEM_EXPAT=ON'
$ export FG_CMAKEARGS='-DENABLE_SWIFT=ON -DENABLE_HID_INPUT=OFF'
$ download_and_compile.sh

=== Launching FlightGear ===

When using <tt>download_and_compile.sh</tt>, apart from those installed with the package manager, the FlightGear dependencies (which are typically libraries) are not installed system-wide but under the directory from which <tt>download_and_compile.sh</tt> was run. This makes it possible to easily use, for instance, different [[OpenSceneGraph]], [[SimGear]] and FlightGear versions on a single system—e.g., for testing purposes—but also to have separate build trees (optimized/debug). This is also why you either need to set LD_LIBRARY_PATH to run the built programs, or simply use the scripts created by <tt>download_and_compile.sh</tt> in the directory where it is run, such as <tt>run_fgfs.sh</tt> and <tt>run_fgfs_debug.sh</tt>: these scripts automatically set up the required environment variables according to your build settings before firing the desired program (e.g., <tt>fgfs</tt>) with the arguments you provided.

Therefore, the simplest way to run a FlightGear program built by <tt>download_and_compile.sh</tt> is to launch the <tt>run_fgfs.sh</tt> script that <tt>download_and_compile.sh</tt> created in the directory from which it was run, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher

{{Note|<code>./run_fgfs.sh --launcher</code> starts FlightGear with its built-in launcher. If you just do <code>./run_fgfs.sh</code>, FlightGear will be started without any launcher, at the default airport and with the default aircraft.}}

In order to start FlightGear without any launcher, at a given airport (say, [https://en.wikipedia.org/wiki/Paro_Airport Paro airport], whose ICAO code is VQPR) and with a chosen aircraft, you can do:
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --airport=VQPR --aircraft=dhc6
Actually, the directory change is not needed, we only gave it here for readability. Therefore, the following single command does the same:
$ ~/flightgear/dnc-managed/run_fgfs.sh --airport=VQPR --aircraft=dhc6

=== Avoiding multiple downloads of FGData ===

Some people use <tt>download_and_compile.sh</tt> to maintain several directory trees such as the tree starting at <tt>~/flightgear/dnc-managed</tt> in [[#getting-started-with-download-and-compile-sh|Getting started with <tt>download_and_compile.sh</tt>]] (this can be useful if you want to have one tree with programs compiled in Release mode and another tree where they are built in Debug mode, for instance). This can easily be done by running <tt>download_and_compile.sh</tt> in each of the directories. But since [[FGData]] is so large, it may be tempting to share a single instance of this repository among several trees. This is not officially supported, but apparently can be made to work with symbolic links.

Let's show how this can be done on an example. Suppose your master copy of FGData is in <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>. Then the following appears to work:
$ mkdir -p ~/flightgear/other-dnc-managed-tree/install/flightgear
$ cd ~/flightgear/other-dnc-managed-tree/install/flightgear
$ ln -s ../../../dnc-managed/install/flightgear/fgdata
$ cd ~/flightgear/other-dnc-managed-tree
$ download_and_compile.sh

The last of these commands will use and update the FGData repository present in <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>.

{{Warning|This can only work simply if all trees that share a given FGData repository are from the same release (e.g., current stable or development). Running a “stable“ FlightGear with FGData from the ''next'' branch or the other way round, a development version of FlightGear with FGData from a release branch, doesn't work—and FlightGear should tell you when you start it in such a situation.

That said, people comfortable with Git can check out the correct FGData branch before building or starting FlightGear, for instance:
$ cd /path/to/fgdata && git checkout release/2019.1
or
$ cd /path/to/fgdata && git checkout next
So, this is possible but somewhat acrobatic. You've been warned.}}

Note: there is a [[Avoiding multiple downloads of FGData on Linux|wiki article about this subject]], but it is severely outdated as of April 2019.

== Additional programs ==

{{Note|In this section, we assume you've read and followed the advice given in [[#getting-started-with-download-and-compile-sh|Getting started with <tt>download_and_compile.sh</tt>]].}}

If you wish to get other programs (precisely: download, build and install them), you need to launch <tt>download_and_compile.sh</tt> with the desired component names as arguments. For instance:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

See [[#list-of-available-components|above]] for the list of available components.

=== TerraGear ===

Run <tt>download_and_compile.sh</tt> with the TERRAGEAR component in order to build and install the [[TerraGear]] terrain building toolchain:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh TERRAGEAR

This creates the following scripts in <tt>~/flightgear/dnc-managed</tt>:
* <tt>run_genapts850.sh</tt>
* <tt>run_ogr-decode.sh</tt>
* <tt>run_tg-construct.sh</tt>
These scripts themselves run the corresponding TerraGear tools, as expected.

=== TerraGear GUI ===

[[TerraGear GUI]] is a graphical interface for [[TerraGear]] written with the Qt toolkit (still Qt 4 in 2019, but it works). In order to install it, run <tt>download_and_compile.sh</tt> with the TERRAGEARGUI component:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh TERRAGEARGUI
This will create a <tt>run_terrageargui.sh</tt> script in <tt>~/flightgear/dnc-managed</tt>, and also a default configuration file <tt>~/.config/TerraGear/TerraGearGUI.conf</tt>, unless you already have one. This default configuration file contains paths to the TerraGear and [[$FG_ROOT]] directories, assuming you have installed the TERRAGEAR and DATA components.

To run TerraGear GUI:
$ cd ~/flightgear/dnc-managed
$ ./run_terrageargui.sh

=== FGCom ===

{{Note|[[FGCom]] has been integrated into FlightGear long ago, therefore the following is not needed in general.}}

[[FGCom]] is the system used by FlightGear to simulate radio communications between users. It is automatically built and installed when you tell <tt>download_and_compile.sh</tt> to take care of the FGFS component. You can launch the standalone FGCom program by using the <tt>run_fgcom.sh</tt> script:
$ cd ~/flightgear/dnc-managed
$ ./run_fgcom.sh

=== FGRun ===

{{Note|As of 2019, FGRun has been superseded by the [[FlightGear Qt launcher|FlightGear built-in launcher]]. The built-in launcher is the most actively maintained launcher for FlightGear. Other launchers are [[FFGo]] and [[FGX|FGx]].}}

[[File:fgrun-page2.jpg|thumb|right]]
Before FlightGear had its built-in launcher (the one you get with <code>run_fgfs.sh --launcher</code>), many users found comfortable having FlightGear launched by the graphical utility [[Fgrun|FGRun]]. This program is built and installed when <tt>download_and_compile.sh</tt> is run with the FGRUN component. You then have to launch the <tt>run_fgrun.sh</tt> command, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgrun.sh

FGRun will save its settings in <tt>~/.fltk/flightgear.org/fgrun.prefs</tt>. You may want to save copies of the preferences customized for stable and next.

=== FGo! ===

{{Note|As of 2019, FGo! is not maintained anymore. You may want to try the built-in launcher (started with <code>run_fgfs.sh --launcher</code>) or [[FFGo]].}}

[[File:Fgo01.jpg|thumb|left]]
FGo! is a graphical utility written in [[python]]. It is downloaded and installed when <tt>download_and_compile.sh</tt> is run with the FGO component. You then have to launch the <tt>run_fgo.sh</tt> command, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgo.sh

Remember that the first time you run it, you have to go to open the ''Preferences'' dialog and set the paths to the <tt>fgfs</tt> executable and to FGData.

== Troubleshooting ==

=== Compilation errors ===
Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:
# Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
# The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
# One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only [[Fgrun|FGRun]], [[FGCom]] or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

=== OpenRTI undefined reference errors ===
Sometimes due to the way d&c build cleans up projects, linking errors might occur, this is the case with this error "libRTI-NG.so: undefined reference to xxx", sadly at this point either you need to patch the d&c script to clean OpenRTI with <code>rm -f CMakeCache.txt && rm -rf CMakeFiles/</code>, or just start from a clean environment, assuming you are in the parent project directory, you will need to issue this command to clean everything (except FGData):
$ rm -rf build/* install/simgear/ install/openrti/ install/flightgear/share/ install/flightgear/bin/

See {{forum link|t=26244|text=this thread}} for more details.

== Options ==

=== Multicore acceleration ===

Passing option <code>-j x</code> to <tt>download_and_compile.sh</tt> (where ''x'' is the number of your CPU cores you wish to assign to the job) will considerably speed up the compilation steps.

=== Advanced options ===

* Build a release version: <code>-b Release</code>
* Build a version that should run as fast as a release build, yet has debug information that can be used to post backtraces: <code>-b RelWithDebInfo</code> (this is the default)
* Build a full debug version for very complete bug reporting: <code>-b Debug</code>
* Skip download of distro packages (i.e., by default: <tt>apt-get install ...</tt>): <code>-p n</code>
* Skip retrieving of software updates (i.e., by default: <tt>apt-get update</tt>): <code>-d n</code>
* Skip the configure step (like running [https://cmake.org/ CMake] or [https://www.gnu.org/software/autoconf/ autoconf]'s <tt>./configure</tt>): <code>-r n</code>
* Skip compilation of programs: <code>-c n</code>.

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear, you can do this:
$ download_and_compile.sh -p n -d n -r n FGFS

Note that this is the same as:
$ download_and_compile.sh -pn -dn -rn FGFS

This command will only rebuild modified files and reinstall FlightGear. Note that depending on the kind of changes you made, reconfiguring and thus dropping the <code>-d n</code> option may be necessary, though (this is the case in particular if you added or removed C++ files).

== Optimus technology ==
If your computer has a GPU with Optimus technology, you need a dedicated script in order to make FlightGear run with the powerful GPU.

After having installed required tools (Bumblebee) you just need to run this command line in your FlightGear installation directory (where you executed <tt>download_and_compile.sh</tt>):
$ sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
Now you can run FlightGear with <code>./run_fgfs_optirun.sh</code>.

The same can be done for the [[FlightGear_Launch_Control|FGRun]] launcher:
$ sed 's|\./fgrun|optirun ./fgrun|' run_fgrun.sh > run_fgrun_optirun.sh && chmod +x run_fgrun_optirun.sh

== See also ==

* {{fgmeta source
| path = compile-scripts
| text = Other FlightGear build scripts
}} present in [[FGMeta]]
* {{fgmeta source
| path = fg-from-scratch
| simplepath = true
}}
* [http://geoffmclane.com/fg/fgfs-052.htm Another script] for building FlightGear and all its dependencies in an automated fashion. The page seems a bit oldish, though (as of 2019).

== References ==
<references/>

[[Category:Building from source]]

[[fr:Script de compilation sous Linux Debian/Ubuntu]]
[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

Scripted Compilation on Linux Debian/Ubuntu

2019-10-04T17:22:08Z

Wkitty42: add prerequisites section since dnc doesn't automatically pull these needed tools if they are not already installed.

<tt>download_and_compile.sh</tt> is a Bash script that takes care of downloading and compiling FlightGear and related software from their source code repositories with just one command execution<ref name="just-one-command">Due to technical problems on the [https://sourceforge.net/ SourceForge] side, this is currently only true once you have an [[FGData]] clone. See [[User:Rominet|here]] for details.</ref> for both 32-bit and 64-bit [https://www.debian.org/ Debian]-based systems. Pre-existing versions (if any) of the software installed by <tt>download_and_compile.sh</tt> are not touched at all since the script downloads, builds and installs everything under the directory in which it is launched. You can choose the particular components to download, build and install.

Unless told not to do so, <tt>download_and_compile.sh</tt> installs packages with <tt>apt-get</tt>. For this reason, it is primarily useful on Debian-based distributions. However, if one disables package installation (using <code>-pn</code> or <code>--sudo=echo</code>) and installs the corresponding dependencies oneself, it might be useful on other distributions as well.

For hints on using <tt>rpm</tt>-based distributions such as Redhat, Fedora and CentOS, please see [[CentOS]]. Please also see [[Superbuild]].

== Introduction ==

<tt>download_and_compile.sh</tt> is a [https://www.gnu.org/software/bash/ Bash] script written for [https://www.debian.org/ Debian]-derived distributions ([https://www.ubuntu.com/ Ubuntu], [https://devuan.org/ Devuan], [https://www.linuxmint.com/ Linux Mint], etc.). Its purpose is to automatically install dependencies using the package manager, then build and install FlightGear-related programs.

By default, <tt>download_and_compile.sh</tt> installs most dependencies with <tt>apt-get</tt> run under <tt>sudo</tt>.<ref name="disabling-installation-of-dependencies-via-package-manager">If you think you already have the dependencies, this installation can be disabled either by using option <code>-pn</code> or by passing option <code>--sudo=echo</code> (the latter results in printing the <tt>apt-get</tt> command line without running it).</ref> Other dependencies, either because they aren't available in the standard APT repositories, or because of non-option arguments passed to <tt>download_and_compile.sh</tt>, are downloaded and compiled on the fly (this can be the case for [[PLIB]], [[Simgear]] and [[OpenSceneGraph]], for instance—it all depends on the arguments passed to the script).

<tt>download_and_compile.sh</tt> works in the directory it is run from: apart from dependencies installed via the package manager, all programs built by <tt>download_and_compile.sh</tt> are installed under the <tt>install</tt> subdirectory of the directory from which the script was run. In other words, installation of programs by <tt>download_and_compile.sh</tt> is clean, very easy to undo and doesn't interfere with other programs on the system.

It is possible to manage several directory trees with <tt>download_and_compile.sh</tt>; as far as it is concerned, such directory trees are completely independent from each other. For instance, if you run <tt>download_and_compile.sh</tt> in <tt>dir1</tt> and <tt>dir2</tt>, the programs installed under <tt>dir1</tt> won't “see” those installed under <tt>dir2</tt>, and vice versa.

Apart from its main purpose, <tt>download_and_compile.sh</tt> can be used to find hopefully up-to-date build-dependency information for FlightGear and related software. You would do so by inspecting [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh the script] at the point where it installs packages.<ref name="note-inspecting-download-and-compile-sh-to-gather-build-dependency-information">Look for strings such as <tt>zlib1g-dev</tt>, <tt>libglew-dev</tt> or <tt>qt5-default</tt>.</ref>

== Prerequisites ==

Before embarking on building your own FlightGear binaries, you must have already installed the necessary tools to compile the source code with. These preliminary tools are

* build-essential
* git
* subversion
* cmake
* automake

They can be installed quite simply by running the following command line.

$ sudo apt-get install build-essential git subversion cmake automake

Once these tools are installed, the download_and_compile.sh script can be run. It will install possibly needed additional tools and libraries as it runs.

== Disk space requirements and build time ==

As of April 2019, building FlightGear requires about 12 [https://en.wikipedia.org/wiki/Gibibyte GiB] of disk space. Note that this includes downloaded source code for [[SimGear]] and FlightGear, generated build files and the large [[FGData]] repository (about 6 GiB for that one).

With an Intel Core i7 860 CPU (2.80 GHz) purchased in 2009, compiling [[SimGear]] and FlightGear 2019.2 with option <code>-j8</code> takes about 14 minutes. If you don't have a fast machine and build using only one core, it may require several hours.

== Download ==

You can get <tt>download_and_compile.sh</tt> {{fgmeta source
| path = download_and_compile.sh
| text = from FGMeta
}}. It is contained in the [[FGMeta]] repository, which is maintained by the FlightGear developers. The script can be downloaded from the link given above, however, for easier updates and in order to have the command <code>download_and_compile.sh --version</code> work as intended, it is recommended to get it as explained [[#getting-download-and-compile-sh-using-an-fgmeta-clone|below]].

In case you build stable versions of FlightGear using the <code>-s</code> option of <tt>download_and_compile.sh</tt>, remember to update the script before trying to build a new version of FlightGear (see [[#updating-download-and-compile-sh-using-an-fgmeta-clone|Updating <tt>download_and_compile.sh</tt>]] below). Of course, you can update it more often in order to benefit from new features or bug fixes; this is especially useful if you are building ''next'', that is, the development branch of FlightGear.

== Getting started with <tt>download_and_compile.sh</tt> ==

Because of technical problems at SourceForge (cloning [[FGData]] using the https protocol usually fails), the initial setup is unfortunately more complex than it used to be. You'll be guided step by step though, so don't be afraid. Besides, once you have a complete clone of the FGData repository, all future operations will be really easy.

We'll first explain how to get <tt>download_and_compile.sh</tt> in a way that makes it convenient to update and causes the command <code>download_and_compile.sh --version</code> to work as intended (the reported “version” is a Git blob id such as <tt>6a5e4f05e2ccf27115eec58313be027b11266097</tt><ref name="note-on-download-and-compile-sh-version-being-a-Git-blob-id">This looks like, but is ''not'' a Git commit identifier. This kind of “version number” is admittedly not very pretty, but it doesn't pollute Git commits (the diffs) and is automatically updated by Git every time you update <tt>download_and_compile.sh</tt> the way we present here; thus, the advantages compensate for the ugliness.</ref>). Then we'll show how to clone the large FGData repository, and finally give instructions to get FlightGear up and running.

=== Notations ===

When a command should be run as an unpriviledged user, it will be preceded by a dollar sign:
$ whoami
toto
In contrast, a hash sign (#) means that the command must be run with superuser privileges to achieve the desired effect:
# whoami
root

In order to make instructions easy to understand, two directories (= folders) will be consistently used for the same purpose below:
* <tt>~/flightgear/fgmeta</tt> will contain a clone of the [[FGMeta]] repository; therefore, <tt>download_and_compile.sh</tt> will reside in that directory;
* <tt>~/flightgear/dnc-managed</tt> will be the directory from which we run <tt>download_and_compile.sh</tt>. In other words, with this setup, a typical sequence of commands could be:
$ cd ~/flightgear/dnc-managed
$ ~/flightgear/fgmeta/download_and_compile.sh SIMGEAR FGFS DATA
These are of course just examples. The aforementioned paths are not hardwired anywhere in the script; you are free to choose the directories you want for these purposes.

=== Getting <tt>download_and_compile.sh</tt> the “right way” ===

There are several ways to obtain [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh download_and_compile.sh]. The method described here makes it very easy to update the script and causes the command <code>download_and_compile.sh --version</code> to work as intended.

As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we want to clone the [[FGMeta]] repository in <tt>~/flightgear/fgmeta</tt>. Let's go:
$ mkdir -p ~/flightgear
$ cd ~/flightgear
<nowiki>$ git clone https://git.code.sf.net/p/flightgear/fgmeta</nowiki>
You now have a fresh FGMeta clone in <tt>~/flightgear/fgmeta</tt> and your brand new <tt>download_and_compile.sh</tt> script is located in that directory. You can already try it to see the available options:
<pre>$ ~/flightgear/fgmeta/download_and_compile.sh --help
download_and_compile.sh [OPTION...] [--] [COMPONENT...]
Download and compile components belonging to the FlightGear ecosystem.

Without any COMPONENT listed, or if ALL is specified, recompile all
components listed in the WHATTOBUILDALL variable. Each COMPONENT may
be one of the following words:

ALL, CMAKE, OSG, PLIB, OPENRTI, SIMGEAR, FGFS, DATA, FGRUN, FGO, FGX,
OPENRADAR, ATCPIE, TERRAGEAR, TERRAGEARGUI

Available options:
-h, --help show this help message and exit
--version print version and license information, then exit

(...)</pre>

=== Updating <tt>download_and_compile.sh</tt> ===

Now that you have <tt>download_and_compile.sh</tt> from the [[FGMeta]] repository, it is very easy to update (this assumes you didn't modify anything yourself inside <tt>~/flightgear/fgmeta</tt>!):
$ cd ~/flightgear/fgmeta && git pull

If you want to keep updates as easy as we just shown, it is best not to modify <tt>download_and_compile.sh</tt> yourself. <tt>download_and_compile.sh</tt> has plenty of options that usually make it unnecessary to modify the script. Just run <code>download_and_compile.sh --help</code> and learn about the available options when you feel the need to change something. Unless you have special needs that can only be accomodated by modifying <tt>download_and_compile.sh</tt>, you are invited to skip to the next section.

If you really, ''really'' want to modify <tt>download_and_compile.sh</tt> while keeping updates easy, a good technique is to add your changes to your FGMeta clone in the form of one or more Git ''commits'' (no need to push them anywhere, commits can remain in your clone). How to do that is beyond the scope of this document, though; read Git tutorials if you want to learn it (there are plenty on the Internet). Once you have committed your changes to your FGMeta clone, make sure the repository is clean (use <code>git status</code>), then update it with:
$ cd ~/flightgear/fgmeta && git pull --rebase
This will apply your commits on top of the latest commit of the branch that is currently checked out, which so far contained the official version of <tt>download_and_compile.sh</tt>. In case your changes conflict with the update, Git will tell you and you'll have to resolve the conflict manually (look for “Git resolve conflict” on your favorite search engine)... or start again from a pristine [[FGMeta]] clone.

=== Building FlightGear ===

For the method described below, you'll need an account at [https://sourceforge.net/ SourceForge] (this is unfortunate, but methods that don't require such an account are either unreliable or insecure, as long as [[FGData]] can't be cloned using the <tt>https</tt> protocol). If you don't already have one, go to the [https://sourceforge.net/user/registration registration page] and create an account. In all this section, we'll assume that your account name at SourceForge is ''SFusername''.

In what follows, we won't give the full path to <tt>download_and_compile.sh</tt> when showing commands to be run, but you should prepend it to <tt>download_and_compile.sh</tt> whenever you see a <tt>download_and_compile.sh</tt> command. For instance, if you used the same path as in [[#getting-started-with-download-and-compile-sh-notations|Notations]] and see the command:
$ download_and_compile.sh --help
what you should actually run is:
$ ~/flightgear/fgmeta/download_and_compile.sh --help

Apart from this harmless command, ''do not'' run other <tt>download_and_compile.sh</tt> commands from an arbitrary directory, in particular ''don't'' run them from <tt>~/flightgear/fgmeta</tt>. This is because '''most other <tt>download_and_compile.sh</tt> commands write to the current directory''' (<code>download_and_compile.sh --help</code> and <code>download_and_compile.sh --version</code> are safe to run from any directory, though).

Of course, it is always possible to make commands shorter by setting up aliases (see tips at the end of [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message]), by adding the directory containing <tt>download_and_compile.sh</tt> to your <tt>PATH</tt> or by creating a symbolink link pointing to <tt>download_and_compile.sh</tt> in a directory that is part of your <tt>PATH</tt>. This is not necessary, though; do it only if you feel the need (when enabled, persistent shell history is often enough for such things).

{{Note|The following commands should be run from an empty directory<ref name="dedicated-directory-won-t-stay-empty-forever">Well, empty before the first time; later, <tt>download_and_compile.sh</tt> is going to populate it with plenty of FlightGear files and subdirectories, of course.</ref> in a partition that has enough free space (see [[#disk-space-requirements-and-build-time | Disk space requirements and build time]]). As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we are going to choose the directory <tt>~/flightgear/dnc-managed</tt> for this purpose, in order to express that the whole directory tree is managed by <tt>download_and_compile.sh</tt>. This is just an example; feel free to choose another directory if you want.

'''Don't run the commands from a non-dedicated directory,''' because it will be filled with files and directories created by <tt>download_and_compile.sh</tt> and the FlightGear, SimGear, etc. build systems. That would be a complete mess! In particular, ''don't'' run the commands from the directory containing your [[FGMeta]] clone.}}

{{Note|As explained in [[#getting-started-with-download-and-compile-sh-notations|Notations]], we assume that your Unix user name (login) is <tt>toto</tt>. Don't confuse the <tt>sudo</tt> password prompt (where you need to enter <tt>toto</tt>'s password) with the password prompt for your SourceForge account! The former appears as
[sudo] password for toto:
whereas the latter is just:
Password:
}}

{{Tip|In case you want to run some other program instead of <tt>sudo</tt>, this can be done with the <code>--sudo</code> option of <tt>download_and_compile.sh</tt>. For instance, in order to see the commands that would be run with sudo without actually running them, you can pass <code><nowiki>--sudo=echo</nowiki></code> to <tt>download_and_compile.sh</tt>. Like all other options, <code><nowiki>--sudo</nowiki></code> must be given ''before'' all arguments that are component names (such as <tt>SIMGEAR</tt>, <tt>FGFS</tt>, <tt>DATA</tt>, etc.).}}

The package manager used by <tt>download_and_compile.sh</tt> by default is <tt>apt-get</tt>. You can use another one if you want, as long as it supports the following calls:
''pkg-mgr'' update
''pkg-mgr'' install ''pkg1 pkg2'' ...
This is the case for <tt>aptitude</tt> as well as <tt>apt</tt>. If you want <tt>download_and_compile.sh</tt> to use <tt>aptitude</tt>, give it the option <code><nowiki>--package-manager=aptitude</nowiki></code> before any of the ''COMPONENT'' arguments.

All options of <tt>download_and_compile.sh</tt> can be seen by running the following command:
$ download_and_compile.sh --help
Now the instructions we promised you. You have chosen a dedicated directory where all the stuff that is downloaded and built by <tt>download_and_compile.sh</tt> will be stored. This is <tt>~/flightgear/dnc-managed</tt> in our example, and should be empty before you run <tt>download_and_compile.sh</tt> for the first time. However, it is quite correct to start <tt>download_and_compile.sh</tt> from the same directory for subsequent runs, even when non-empty (otherwise, <tt>download_and_compile.sh</tt> would automatically reclone the repositories every time you run it; that would be a sheer waste of time and bandwidth).

Ready? Let's go!
<pre>$ mkdir -p ~/flightgear/dnc-managed
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh --git-clone-site-params SourceForge=ssh:SFusername DATA
**********************************************************************
* *
* Warning: a typical SimGear + FlightGear + FGData build requires *
* about 12 GiB of disk space. The compilation part may last from a *
* few minutes to hours, depending on your computer. *
* *
* Hint: use the -j option if your CPU has several cores, as in: *
* *
* download_and_compile.sh -j$(nproc) *
* *
**********************************************************************
Running 'apt-get update'...
[sudo] password for toto:

(...)

Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Running 'apt-get install build-essential git libcurl4-openssl-dev cmake'...
[sudo] password for toto:

(...)

****************************************
**************** DATA ******************
****************************************
Fetching DATA with 'git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata'
Cloning into '.'...
The authenticity of host 'git.code.sf.net (216.105.38.16)' can't be established.
ECDSA key fingerprint is SHA256:FeVkoYYBjuQzb5QVAgm3BkmeN5TTgL2qfmqz9tCPRL4.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added 'git.code.sf.net,216.105.38.16' (ECDSA) to the list of known hosts.
Connection closed by 216.105.38.16 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
</pre>

The above messages are perfectly normal but deserve a little explanation. Here, <tt>ssh</tt> asked us to confirm that the fingerprint sent by the remote host is that of the real <tt>git.code.sf.net</tt>, as opposed to that of some malicious server ''pretending'' to be <tt>git.code.sf.net</tt>. This confirmation only has to be done once, after which it is remembered thanks to <tt>~/.ssh/known_hosts</tt>. You should visit the [https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/#fingerprint-listing page that gives the host key fingerprint of every publically-accessible SSH server at SourceForge] and carefully check that the fingerprint appearing on your terminal is listed on that page for <tt>git.code.sf.net</tt>, or some matching pattern such as <tt>*.code.sf.net</tt>.

If the fingerprint that is printed on your terminal is not listed on that page, answer <tt>no</tt> to the question ''Are you sure you want to continue connecting (yes/no)?'' and copy/paste to flightgear-devel (see [[Mailing lists]]) the above message from <tt>ssh</tt> that contains the fingerprint sent to you by the remote host which pretends to be <tt>git.code.sf.net</tt>. If this happened, you should stop here and wait for answers from readers of flightgear-devel.

From now on, we'll assume that the fingerprint you received was correct, and therefore that you have answered <tt>yes</tt> to the ''Are you sure you want to continue connecting (yes/no)?'' question.

In this example, it took us several minutes to verify the fingerprint of the <tt>git.code.sf.net</tt> server and confirm it to <tt>ssh</tt>. Because of this delay, <tt>git.code.sf.net</tt> hung up on us and closed the connection. This is absolutely ''not a problem:'' we can just rerun the <tt>download_and_compile.sh</tt> command with the same arguments as the first time. Since we answered <tt>yes</tt> to the ''Are you sure you want to continue connecting (yes/no)?'' prompt, the fingerprint of <tt>git.code.sf.net</tt>'s key has been stored in <tt>~/.ssh/known_hosts</tt>, therefore we won't get this prompt anymore. But if some server claiming to be <tt>git.code.sf.net</tt> presents a host key that has a different fingerprint in the future, <tt>ssh</tt> will print a big fat warning that the server may belong to an attacker trying to impersonate <tt>git.code.sf.net</tt>. Therefore, this SSH host key verification is very useful to protect us from future attacks (which hopefully won't happen at all).

As said, we just rerun the <tt>download_and_compile.sh</tt> command with the same arguments:
<pre>$ download_and_compile.sh --git-clone-site-params SourceForge=ssh:SFusername DATA
**********************************************************************
* *
* Warning: a typical SimGear + FlightGear + FGData build requires *
* about 12 GiB of disk space. The compilation part may last from a *
* few minutes to hours, depending on your computer. *
* *
* Hint: use the -j option if your CPU has several cores, as in: *
* *
* download_and_compile.sh -j$(nproc) *
* *
**********************************************************************
Running 'apt-get update'...
[sudo] password for toto:

(...)

Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Running 'apt-get install build-essential git libcurl4-openssl-dev cmake'...
[sudo] password for toto:

(...)

****************************************
**************** DATA ******************
****************************************
Fetching DATA with 'git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata'
Cloning into '.'...
Password:</pre>
As explained above, the preceding prompt is for your SourceForge password (which you could guess from the <code><nowiki>git clone ssh://SFusername@git.code.sf.net/p/flightgear/fgdata</nowiki></code> command).
<pre>remote: Enumerating objects: 67011, done.
remote: Counting objects: 100% (67011/67011), done.
remote: Compressing objects: 100% (31342/31342), done.
remote: Total 67011 (delta 38776), reused 59640 (delta 33570)
Receiving objects: 100% (67011/67011), 2.60 GiB | 313.00 KiB/s, done.
Resolving deltas: 100% (38776/38776), done.
Checking out files: 100% (12959/12959), done.
Password:</pre>
(It will take a fair amount of time to get there, because this is the complete download of [[FGData]].) 
This is again a prompt for your SourceForge password, because <tt>download_and_compile.sh</tt> wants to run <code>git pull --rebase</code> in the repository (admittedly, it's a bit dumb after a <tt>clone</tt> operation—please forgive us). In case you were not monitoring the <tt>clone</tt> operation, you probably saw the password prompt way after <tt>git.code.sf.net</tt> got bored waiting for you and closed our second connection:
<pre>Connection closed by 216.105.38.16 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.</pre>
(if not, there should be no error message and you should have a clean FGData clone) 
No worries. Just as before, simply rerun the command with the same arguments:
<pre>$ download_and_compile.sh --git-clone-site-params SourceForge=ssh:SFusername DATA
**********************************************************************
* *
* Warning: a typical SimGear + FlightGear + FGData build requires *
* about 12 GiB of disk space. The compilation part may last from a *
* few minutes to hours, depending on your computer. *
* *
* Hint: use the -j option if your CPU has several cores, as in: *
* *
* download_and_compile.sh -j$(nproc) *
* *
**********************************************************************
Running 'apt-get update'...
[sudo] password for toto:

(...)

Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Running 'apt-get install build-essential git libcurl4-openssl-dev cmake'...
[sudo] password for toto:

(...)

****************************************
**************** DATA ******************
****************************************
DATA: the repository already exists
Password:
Already up to date.
Current branch next is up to date.
Already on 'next'
Your branch is up to date with 'origin/next'.
All optional package alternatives have found a matching package.

download_and_compile.sh has finished to work.
</pre>
There we are! You now have a clean, up-to-date [[FGData]] clone in <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> (remember: <tt>~/flightgear/dnc-managed</tt> is the directory from which you ran <tt>download_and_compile.sh</tt>). Note this place: the full path of the <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt> directory is your [[$FG_ROOT]].

Now, change the protocol to use for future updates of your FGData clone:<ref name="changing-the-protocol-for-a-git-remote-manual-method">Another way would be to manually change the relevant line starting with <code><nowiki>url = ssh://SFusername@</nowiki></code> for the <code>origin</code> remote in the <tt>.git/config</tt> file that lives inside your repository clone (i.e., <tt>~/flightgear/dnc-managed/install/flightgear/fgdata/.git/config</tt> in our example).</ref>
(cd install/flightgear/fgdata && \
git remote set-url origin <nowiki>https://git.code.sf.net/p/flightgear/fgdata</nowiki>)
(you can check at any time the protocol(s) in use with the command <code>git remote -v</code> run inside a Git repository—in this case, inside the folder <tt>install/flightgear/fgdata</tt>). As a consequence of this change, all future updates of your FGData clone will use the <tt>https</tt> protocol, therefore you won't be prompted anymore for your SourceForge password.

All that remains to do is to run, from the same directory as before (<tt>~/flightgear/dnc-managed</tt> in our example):
$ download_and_compile.sh
or
$ download_and_compile.sh -j$(nproc)
(<code>-j$(nproc)</code> is “only” useful to save time—see the tip below).

When you don't pass any non-option argument to <tt>download_and_compile.sh</tt> as done here, it takes care of the three base components needed to run FlightGear: <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> (these are the component names used by <tt>download_and_compile.sh</tt>, i.e., the final arguments one can optionally give in a <tt>download_and_compile.sh</tt> command; in normal speech, they correspond to the {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}} and {{fgdata source
| text = FGData
}} repositories). Therefore, the above command is presently exactly equivalent to:
$ download_and_compile.sh SIMGEAR FGFS DATA

In case you wanted to build another component such as [[OpenSceneGraph|OSG]], you could add it to the command, like this:
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

(With current Debian stable, this is not necessary because it has OpenSceneGraph 3.4. But if your distribution only has an older version, you'll certainly need to select the <tt>OSG</tt> component like this.)

When the command terminates, you should have a script called <tt>run_fgfs.sh</tt> in the directory <tt>~/flightgear/dnc-managed</tt> from which you ran <tt>download_and_compile.sh</tt>. This will be your script to run FlightGear. For instance, in order to start the built-in launcher, you can run the following commands:<ref name="no-need-to-change-to-dnc-managed-dir-before-starting-generated-scripts">We give these commands because they are easy to read, but the <code>cd</code> command is not needed if you use the correct path, as in <code>~/flightgear/dnc-managed/run_fgfs.sh --launcher</code>.</ref>
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher
(You may omit the <code>--launcher</code> option; this would simply start FlightGear without any launcher, at the default airport and with the default aircraft.) 
In case you find this tedious to type or have more arguments to pass on a regular basis, you can follow the advice given at the end of [https://sourceforge.net/p/flightgear/mailman/message/36634426/ this message] or use another launcher such as [[FFGo]] (but the [[FlightGear Qt launcher|FlightGear built-in launcher]] started with <code>run_fgfs.sh --launcher</code> is quite fine, be sure to try it first!).

{{Tip|You can considerably speed up the build process—literally, save hours—by telling <tt>download_and_compile.sh</tt> to use several cores simultaneously when compiling. With option <code>-j$(nproc)</code>, compilations will use all cores available on your processor; thus, a typical <tt>download_and_compile.sh</tt> command is <code>download_and_compile.sh -j$(nproc)</code>. If you want to use, say, 4 cores, replace <code>-j$(nproc)</code> with <code>-j4</code>.}}

=== Updating FlightGear ===

Just go to the directory from which you you previously ran <tt>download_and_compile.sh</tt> (<tt>~/flightgear/dnc-managed</tt> in our example). This is the folder which, if you did a complete run of <tt>download_and_compile.sh</tt> as shown in the previous section, contains the <tt>run_fgfs.sh</tt> script and a log file named <tt>compilation_log.txt</tt> that records what <tt>download_and_compile.sh</tt> did in its last run. If you wish to update, say, {{simgear source
| text = SimGear
}}, {{flightgear source
| text = FlightGear
}} and {{fgdata source
| text = FGData
}}, simply execute this:
$ download_and_compile.sh -pn SIMGEAR FGFS DATA
We'll explain the <code>-pn</code> in a minute. <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> are called ''components'' in <tt>download_and_compile.sh</tt> terminology. A component generally corresponds to a software repository, or something close. In fact, since <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> are often precisely the components people wish to update, they form the default components set, so that the previous command is equivalent to:
$ download_and_compile.sh -pn
Now about this <code>-pn</code>. It is equivalent to <code>-p n</code> and means “don't install packages from my (Linux) distribution” (<code>y</code> means ''yes, please install'', <code>n</code> means ''no, don't install''). In case you forgot that, simply run:
$ download_and_compile.sh --help
What does it imply to pass <code>-pn</code>? This tells <tt>download_and_compile.sh</tt> to completely skip the step where it checks for needed packages from your distribution and installs them, by default using <tt>apt-get</tt>. It thus goes straight to the following steps:
* update each repository corresponding to one of the selected components (<tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> in our example);
* compile each selected component that requires compilation;
* install each selected component in the appropriate place (under <tt>~/flightgear/dnc-managed</tt> according to our [[#getting-started-with-download-and-compile-sh-notations|Notations]]).
In case you don't have all required dependencies for the selected components, one of them is likely to fail, of course, since by passing <code>-pn</code> to <tt>download_and_compile.sh</tt>, you forbid it to install these dependencies for you. So, you can also very well update without passing the <code>-pn</code> option, it will simply take a little longer (the time to check if all dependencies of the selected components are available with <tt>APT</tt>). In fact, this is '''what you should do if the previous <tt>download_and_compile.sh</tt> run failed:''' first update <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|above]]) then run it ''without'' <code>-pn</code><ref name="passing-no-pn-option-equals-passing-py">Which is the same as passing <code>-py</code>.</ref> in case new dependencies have been recently added and you don't have them on your system yet—this would be a very likely cause for the failure.

'''Summary'''

Routine update:
$ download_and_compile.sh -pn ''COMPONENT...''
In case this fails, first update <tt>download_and_compile.sh</tt> (see [[#getting-download-and-compile-sh-using-an-fgmeta-clone|above]]), then run
$ download_and_compile.sh ''COMPONENT...''
where ''COMPONENT...'' stands for the space-separated list of selected components, and defaults to <tt>SIMGEAR FGFS DATA</tt> if you don't specify any.

=== Examining the history of <tt>download_and_compile.sh</tt> ===

Looking at the latest commits that affected <tt>download_and_compile.sh</tt> is quite easy with your FGMeta clone:
$ cd ~/flightgear/fgmeta
$ git log -- download_and_compile.sh
(then quit by typing <tt>q</tt>, assuming your <tt>$GIT_PAGER</tt> is <tt>less</tt>) 

In order to do the same, but also see the patch for each commit:
$ cd ~/flightgear/fgmeta
$ git log -p -- download_and_compile.sh

== List of available components ==

The <tt>download_and_compile.sh</tt> script is able to download, compile (when applicable) and install the following components:

* ATCPIE (for the [[ATC-pie]] air traffic control simulation program)
* CMAKE (for the [https://cmake.org/ CMake] build tool—this can be useful in case CMake is too old in your distribution)
* DATA (for [[FGData]], the main set of data files used by FlightGear)
* FGFS (for FlightGear itself)
* FGO (for the [[FGo!]] FlightGear launcher)
* FGRUN (for the [[Fgrun|FGRun]] FlightGear launcher)
* FGX (for the [[FGX|FGx]] FlightGear launcher<ref name="note-on-the-status-of-FGx-support-in-download-and-compile-sh">Support for FGx in <tt>download_and_compile.sh</tt> would probably benefit from a code review.</ref>)
* OPENRADAR (for the [[OpenRadar]] air traffic control simulation program)
* OPENRTI (for [[FlightGear HLA support (High Level Architecture)#OpenRTI | OpenRTI]]<ref name="note-on-the-status-of-OpenRTI-support-in-FG">Note that OpenRTI is just an optional dependency for [[FlightGear high-level architecture support | HLA support]]. For the time being, you should be just fine building without it. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it is probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.</ref>)
* OSG (for the [[OpenSceneGraph]] library)
* PLIB (for the [[PLIB]] library)
* SIMGEAR (for the [[SimGear]] library—foundation for FlightGear and TerraGear)
* TERRAGEAR (for the [[TerraGear]] terrain building toolchain)
* TERRAGEARGUI (for [[TerraGear GUI]], a graphical interface for TerraGear)

Each of the items listed above is a ''component'' in <tt>download_and_compile.sh</tt> terminology. Components are written in uppercase by convention.

{{Note|The preceding list might not be up-to-date. The up-to-date list of components supported by <tt>download_and_compile.sh</tt> can always be obtained by running <code>download_and_compile.sh --help</code>.}}

What is the point of knowing this? Because you may pass component names to <tt>download_and_compile.sh</tt> in order to tell it what you want to download, build and install. By default, only the three essential components SIMGEAR, FGFS and DATA are taken care of, which means that the command:
$ download_and_compile.sh
is equivalent to:
$ download_and_compile.sh SIMGEAR FGFS DATA

In case you want to do the same build with just [[OpenSceneGraph]] added, you can use:
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

You get the idea. When several components are passed on the same command line, <tt>download_and_compile.sh</tt> chooses a reasonable order for processing, so don't worry about that.

== When building 'next', you may see build errors ==

Keeping in mind that this script compiles sometimes bleeding edge software, it can happen that what was successfully compiling last week, does not compile anymore today. Building the stable version should always work, unless there is a problem with the script.

That said, don't be too afraid of building the development version (called ''next''): this is the one developers use all the time, so kindly asking on the flightgear-devel [[Mailing_lists|mailing list]] in case a problem popped up<ref name="what-to-provide-when-asking-for-help">Don't forget in this case to precisely tell what you did and include the <tt>compilation_log.txt</tt> file written by <tt>download_and_compile.sh</tt>.</ref> should allow you to find good advice and get the problem quickly fixed, if it's a new one. Conversely, probably not many people (in 2019) build themselves the “stable” version of FlightGear. People who want the stable version can usually have it from their distribution, this is generally easier. On the other hand, those running <tt>download_and_compile.sh</tt> typically want to build the latest code that FlightGear developers are working on; this is useful when you want to contribute feedback, code, aircraft or scenery based on recent technology, or just want to enjoy the latest features and bugs. ;-)

== Task-specific instructions ==

{{Note|In this section, we assume you've read and followed the advice given in [[#getting-started-with-download-and-compile-sh|Getting started with <tt>download_and_compile.sh</tt>]].}}

=== Selecting the components to build ===

By default, <tt>download_and_compile.sh</tt> downloads or updates, then compiles, [[SimGear]] and FlightGear, and downloads or updates [[FGData]] (by nature, FGData can't be compiled). This is what happens when running:
$ download_and_compile.sh
The preceding command is therefore equivalent to:
$ download_and_compile.sh SIMGEAR FGFS DATA

To make <tt>download_and_compile.sh</tt> take care of other programs or libraries, use non-option arguments naming the ''components'' you want, for instance:
$ download_and_compile.sh SIMGEAR FGFS DATA OSG
SIMGEAR, FGFS, DATA and OSG are the component names respectively corresponding to [[SimGear]], FlightGear, [[FGData]] and [[OpenSceneGraph]] in <tt>download_and_compile.sh</tt>'s terminology.

A [[#list-of-available-components|list of available components]] is provided on this page, but the fully up-to-date list can always be obtained by running <code>download_and_compile.sh --help</code>.

=== Choosing between stable and development versions ===

By default, <tt>download_and_compile.sh</tt> fetches code and data from development branches of the source repositories (which sometimes causes compilation or runtime errors). However, it is possible to tell the script to download the latest ”stable” version of each component, for some suitable definition of “stable”. This is by means of the <code>-s</code> option:
$ download_and_compile.sh -s ''COMPONENT1 COMPONENT2...''

How does it work?
* For [[SimGear]], FlightGear and [[FGData]], it uses the most recent stable release branch of the corresponding Git repository.
* For some components, a known-stable version is hardcoded in <tt>download_and_compile.sh</tt> and used when the <code>-s</code> option is given<ref name="components-with-a-known-stable-version-hardcoded-in-download_and_compile_sh">As of May 2019, apart from SIMGEAR, FGFS and DATA, the only components for which <tt>download_and_compile.sh</tt> “knows” a stable version are TERRAGEAR and OPENRTI.</ref> (for instance, the hardcoded information can be the name of a Git branch).
* For the other components, the <code>-s</code> option has no effect.

{{Warning|In a given folder where <tt>download_and_compile.sh</tt> is run, you should either always use the <code>-s</code> option, or never. Building some components with <code>-s</code> and others without (all within the same base folder) is not supported.}}

Applying what we just said to the FGFS component (FlightGear) leaves us with two main options:
* build the latest stable release;
* build the current development version (bleeding edge), which lives in the {{flightgear source
| branch = next
| text = next
}} branch of the FlightGear repository.

==== Building the latest stable FlightGear release ====

When executing <tt>download_and_compile.sh</tt>, use the <code>-s</code> option to build the latest stable release:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh -s

{{Note|If you decide to use the <code>-s</code> option in a given directory tree, you should use it for all components in that directory tree (SIMGEAR, FGFS, DATA, etc.). Running <tt>download_and_compile.sh</tt> in a given directory with the <code>-s</code> option for some components and not for others is not supported.}}

==== Building the current FlightGear development version ====

When executing <tt>download_and_compile.sh</tt> without any option, the development version of every selected component is built:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh
(In this example, the implicitly-selected components are SIMGEAR, FGFS and DATA, as explained [[#selecting-the-components-to-work-on | above]].)

{{Note|The development version of FlightGear changes on an almost daily basis. It provides the latest features, but is not guaranteed to always work reliably. If you don't want to take the risk of finding new bugs when updating, you may prefer to use the latest stable release.}}

=== Passing custom arguments to CMake ===

Sometimes, when building a program, you may want to enable a feature that is not enabled by default, or disable a feature that is enabled by default. With recent versions of <tt>download_and_compile.sh</tt> (April 2019 or later), the environment variables <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt> allow one to do that for SimGear and FlightGear. For instance, in order to link SimGear with the system Expat library, you can do:
$ SG_CMAKEARGS='-DSYSTEM_EXPAT=ON' download_and_compile.sh SIMGEAR
Similarly, disabling HID-based input when building FlightGear can be achieved this way:
$ FG_CMAKEARGS='-DENABLE_HID_INPUT=OFF' download_and_compile.sh FGFS

{{Note|Such options are typically defined in <tt>CMakeLists.txt</tt> files, for example {{simgear source
| path = CMakeLists.txt
| text = here
}} for SimGear and {{flightgear source
| path = CMakeLists.txt
| text = here
}} for FlightGear.}}

This can be useful for instance to work around bugs in a part of SimGear or FlightGear that you don't need, but causes a build or runtime failure (see {{forum link|t=35740|text=here}} for example). This is often convenient when using the development version of FlightGear, but doesn't mean such bugs shouldn't be reported!

If you have several such options to pass, just use spaces to separate them inside the quotes:
$ FG_CMAKEARGS='-DENABLE_SWIFT=ON -DENABLE_HID_INPUT=OFF' download_and_compile.sh FGFS
Of course, the same thing can also be achieved this way in Bourne-style shells:
$ export FG_CMAKEARGS='-DENABLE_SWIFT=ON -DENABLE_HID_INPUT=OFF'
$ download_and_compile.sh FGFS

It is also possible to set both <tt>SG_CMAKEARGS</tt> and <tt>FG_CMAKEARGS</tt> at the same time for a given <tt>download_and_compile.sh</tt> run:
$ export SG_CMAKEARGS='-DSYSTEM_EXPAT=ON'
$ export FG_CMAKEARGS='-DENABLE_SWIFT=ON -DENABLE_HID_INPUT=OFF'
$ download_and_compile.sh

=== Launching FlightGear ===

When using <tt>download_and_compile.sh</tt>, apart from those installed with the package manager, the FlightGear dependencies (which are typically libraries) are not installed system-wide but under the directory from which <tt>download_and_compile.sh</tt> was run. This makes it possible to easily use, for instance, different [[OpenSceneGraph]], [[SimGear]] and FlightGear versions on a single system—e.g., for testing purposes—but also to have separate build trees (optimized/debug). This is also why you either need to set LD_LIBRARY_PATH to run the built programs, or simply use the scripts created by <tt>download_and_compile.sh</tt> in the directory where it is run, such as <tt>run_fgfs.sh</tt> and <tt>run_fgfs_debug.sh</tt>: these scripts automatically set up the required environment variables according to your build settings before firing the desired program (e.g., <tt>fgfs</tt>) with the arguments you provided.

Therefore, the simplest way to run a FlightGear program built by <tt>download_and_compile.sh</tt> is to launch the <tt>run_fgfs.sh</tt> script that <tt>download_and_compile.sh</tt> created in the directory from which it was run, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --launcher

{{Note|<code>./run_fgfs.sh --launcher</code> starts FlightGear with its built-in launcher. If you just do <code>./run_fgfs.sh</code>, FlightGear will be started without any launcher, at the default airport and with the default aircraft.}}

In order to start FlightGear without any launcher, at a given airport (say, [https://en.wikipedia.org/wiki/Paro_Airport Paro airport], whose ICAO code is VQPR) and with a chosen aircraft, you can do:
$ cd ~/flightgear/dnc-managed
$ ./run_fgfs.sh --airport=VQPR --aircraft=dhc6
Actually, the directory change is not needed, we only gave it here for readability. Therefore, the following single command does the same:
$ ~/flightgear/dnc-managed/run_fgfs.sh --airport=VQPR --aircraft=dhc6

=== Avoiding multiple downloads of FGData ===

Some people use <tt>download_and_compile.sh</tt> to maintain several directory trees such as the tree starting at <tt>~/flightgear/dnc-managed</tt> in [[#getting-started-with-download-and-compile-sh|Getting started with <tt>download_and_compile.sh</tt>]] (this can be useful if you want to have one tree with programs compiled in Release mode and another tree where they are built in Debug mode, for instance). This can easily be done by running <tt>download_and_compile.sh</tt> in each of the directories. But since [[FGData]] is so large, it may be tempting to share a single instance of this repository among several trees. This is not officially supported, but apparently can be made to work with symbolic links.

Let's show how this can be done on an example. Suppose your master copy of FGData is in <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>. Then the following appears to work:
$ mkdir -p ~/flightgear/other-dnc-managed-tree/install/flightgear
$ cd ~/flightgear/other-dnc-managed-tree/install/flightgear
$ ln -s ../../../dnc-managed/install/flightgear/fgdata
$ cd ~/flightgear/other-dnc-managed-tree
$ download_and_compile.sh

The last of these commands will use and update the FGData repository present in <tt>~/flightgear/dnc-managed/install/flightgear/fgdata</tt>.

{{Warning|This can only work simply if all trees that share a given FGData repository are from the same release (e.g., current stable or development). Running a “stable“ FlightGear with FGData from the ''next'' branch or the other way round, a development version of FlightGear with FGData from a release branch, doesn't work—and FlightGear should tell you when you start it in such a situation.

That said, people comfortable with Git can check out the correct FGData branch before building or starting FlightGear, for instance:
$ cd /path/to/fgdata && git checkout release/2019.1
or
$ cd /path/to/fgdata && git checkout next
So, this is possible but somewhat acrobatic. You've been warned.}}

Note: there is a [[Avoiding multiple downloads of FGData on Linux|wiki article about this subject]], but it is severely outdated as of April 2019.

== Additional programs ==

{{Note|In this section, we assume you've read and followed the advice given in [[#getting-started-with-download-and-compile-sh|Getting started with <tt>download_and_compile.sh</tt>]].}}

If you wish to get other programs (precisely: download, build and install them), you need to launch <tt>download_and_compile.sh</tt> with the desired component names as arguments. For instance:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh SIMGEAR FGFS DATA OSG

See [[#list-of-available-components|above]] for the list of available components.

=== TerraGear ===

Run <tt>download_and_compile.sh</tt> with the TERRAGEAR component in order to build and install the [[TerraGear]] terrain building toolchain:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh TERRAGEAR

This creates the following scripts in <tt>~/flightgear/dnc-managed</tt>:
* <tt>run_genapts850.sh</tt>
* <tt>run_ogr-decode.sh</tt>
* <tt>run_tg-construct.sh</tt>
These scripts themselves run the corresponding TerraGear tools, as expected.

=== TerraGear GUI ===

[[TerraGear GUI]] is a graphical interface for [[TerraGear]] written with the Qt toolkit (still Qt 4 in 2019, but it works). In order to install it, run <tt>download_and_compile.sh</tt> with the TERRAGEARGUI component:
$ cd ~/flightgear/dnc-managed
$ download_and_compile.sh TERRAGEARGUI
This will create a <tt>run_terrageargui.sh</tt> script in <tt>~/flightgear/dnc-managed</tt>, and also a default configuration file <tt>~/.config/TerraGear/TerraGearGUI.conf</tt>, unless you already have one. This default configuration file contains paths to the TerraGear and [[$FG_ROOT]] directories, assuming you have installed the TERRAGEAR and DATA components.

To run TerraGear GUI:
$ cd ~/flightgear/dnc-managed
$ ./run_terrageargui.sh

=== FGCom ===

{{Note|[[FGCom]] has been integrated into FlightGear long ago, therefore the following is not needed in general.}}

[[FGCom]] is the system used by FlightGear to simulate radio communications between users. It is automatically built and installed when you tell <tt>download_and_compile.sh</tt> to take care of the FGFS component. You can launch the standalone FGCom program by using the <tt>run_fgcom.sh</tt> script:
$ cd ~/flightgear/dnc-managed
$ ./run_fgcom.sh

=== FGRun ===

{{Note|As of 2019, FGRun has been superseded by the [[FlightGear Qt launcher|FlightGear built-in launcher]]. The built-in launcher is the most actively maintained launcher for FlightGear. Other launchers are [[FFGo]] and [[FGX|FGx]].}}

[[File:fgrun-page2.jpg|thumb|right]]
Before FlightGear had its built-in launcher (the one you get with <code>run_fgfs.sh --launcher</code>), many users found comfortable having FlightGear launched by the graphical utility [[Fgrun|FGRun]]. This program is built and installed when <tt>download_and_compile.sh</tt> is run with the FGRUN component. You then have to launch the <tt>run_fgrun.sh</tt> command, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgrun.sh

FGRun will save its settings in <tt>~/.fltk/flightgear.org/fgrun.prefs</tt>. You may want to save copies of the preferences customized for stable and next.

=== FGo! ===

{{Note|As of 2019, FGo! is not maintained anymore. You may want to try the built-in launcher (started with <code>run_fgfs.sh --launcher</code>) or [[FFGo]].}}

[[File:Fgo01.jpg|thumb|left]]
FGo! is a graphical utility written in [[python]]. It is downloaded and installed when <tt>download_and_compile.sh</tt> is run with the FGO component. You then have to launch the <tt>run_fgo.sh</tt> command, for example:
$ cd ~/flightgear/dnc-managed
$ ./run_fgo.sh

Remember that the first time you run it, you have to go to open the ''Preferences'' dialog and set the paths to the <tt>fgfs</tt> executable and to FGData.

== Troubleshooting ==

=== Compilation errors ===
Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:
# Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
# The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
# One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only [[Fgrun|FGRun]], [[FGCom]] or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

=== OpenRTI undefined reference errors ===
Sometimes due to the way d&c build cleans up projects, linking errors might occur, this is the case with this error "libRTI-NG.so: undefined reference to xxx", sadly at this point either you need to patch the d&c script to clean OpenRTI with <code>rm -f CMakeCache.txt && rm -rf CMakeFiles/</code>, or just start from a clean environment, assuming you are in the parent project directory, you will need to issue this command to clean everything (except FGData):
$ rm -rf build/* install/simgear/ install/openrti/ install/flightgear/share/ install/flightgear/bin/

See {{forum link|t=26244|text=this thread}} for more details.

== Options ==

=== Multicore acceleration ===

Passing option <code>-j x</code> to <tt>download_and_compile.sh</tt> (where ''x'' is the number of your CPU cores you wish to assign to the job) will considerably speed up the compilation steps.

=== Advanced options ===

* Build a release version: <code>-b Release</code>
* Build a version that should run as fast as a release build, yet has debug information that can be used to post backtraces: <code>-b RelWithDebInfo</code> (this is the default)
* Build a full debug version for very complete bug reporting: <code>-b Debug</code>
* Skip download of distro packages (i.e., by default: <tt>apt-get install ...</tt>): <code>-p n</code>
* Skip retrieving of software updates (i.e., by default: <tt>apt-get update</tt>): <code>-d n</code>
* Skip the configure step (like running [https://cmake.org/ CMake] or [https://www.gnu.org/software/autoconf/ autoconf]'s <tt>./configure</tt>): <code>-r n</code>
* Skip compilation of programs: <code>-c n</code>.

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear, you can do this:
$ download_and_compile.sh -p n -d n -r n FGFS

Note that this is the same as:
$ download_and_compile.sh -pn -dn -rn FGFS

This command will only rebuild modified files and reinstall FlightGear. Note that depending on the kind of changes you made, reconfiguring and thus dropping the <code>-d n</code> option may be necessary, though (this is the case in particular if you added or removed C++ files).

== Optimus technology ==
If your computer has a GPU with Optimus technology, you need a dedicated script in order to make FlightGear run with the powerful GPU.

After having installed required tools (Bumblebee) you just need to run this command line in your FlightGear installation directory (where you executed <tt>download_and_compile.sh</tt>):
$ sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
Now you can run FlightGear with <code>./run_fgfs_optirun.sh</code>.

The same can be done for the [[FlightGear_Launch_Control|FGRun]] launcher:
$ sed 's|\./fgrun|optirun ./fgrun|' run_fgrun.sh > run_fgrun_optirun.sh && chmod +x run_fgrun_optirun.sh

== See also ==

* {{fgmeta source
| path = compile-scripts
| text = Other FlightGear build scripts
}} present in [[FGMeta]]
* {{fgmeta source
| path = fg-from-scratch
| simplepath = true
}}
* [http://geoffmclane.com/fg/fgfs-052.htm Another script] for building FlightGear and all its dependencies in an automated fashion. The page seems a bit oldish, though (as of 2019).

== References ==
<references/>

[[Category:Building from source]]

[[fr:Script de compilation sous Linux Debian/Ubuntu]]
[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

Talk:Zeppelin LZ 121 Nordstern

2019-08-13T22:19:28Z

Wkitty42: /* Engine Management */

==== Engine Management ====
How do you start the engines?
[[User:Wkitty42|Wkitty42]] ([[User talk:Wkitty42|talk]]) 09:26, 13 August 2019 (EDT)

Last time I tried it was by setting magnetos, mixture rich and run the starter. Possibly I needed to increase the throttle quite a bit too? There are no special parts coded for. [[User:AndersG|AndersG]] ([[User talk:AndersG|talk]]) 15:13, 13 August 2019 (EDT)

i'll have to try playing with it some more... i had trouble with the Zeppelin NT but did get it started after i wrote on its talk page... i forget exactly what i had to do but it was increasing the throttle or something more than i had already increased it... that was several hours ago and i've forgotten now... the engines do seem to take some cranking over for a bit before they do start...
[[User:Wkitty42|Wkitty42]] ([[User talk:Wkitty42|talk]]) 18:19, 13 August 2019 (EDT)

Talk:Zeppelin NT

2019-08-13T13:54:57Z

Wkitty42: how do you start the engines?

==== Engine Management ====
How do you start the engines?
[[User:Wkitty42|Wkitty42]] ([[User talk:Wkitty42|talk]]) 09:54, 13 August 2019 (EDT)

Talk:Zeppelin LZ 121 Nordstern

2019-08-13T13:26:57Z

Wkitty42: how do you start the engines?

==== Engine Management ====
How do you start the engines?
[[User:Wkitty42|Wkitty42]] ([[User talk:Wkitty42|talk]]) 09:26, 13 August 2019 (EDT)

Command line options

2019-07-02T21:05:38Z

Wkitty42: move HUD options to HUD section

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--fg-aircraft=path Specify additional aircraft directory path(s)
(alternatively, you can use --aircraft-dir to
target a specific aircraft in a given
directory)
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:foo=bar Set property named "foo" to value "bar"
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry/resolution (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

User talk:Wkitty42

2019-05-03T12:53:49Z

Wkitty42: added welcome to the wiki template

{{Welcome to the wiki |name=Waldo | non-manual=foo }}

= Welcome =
this is my talk page. be nice. that is all.

--[[User:Wkitty42|Wkitty42]] ([[User talk:Wkitty42|talk]]) 08:53, 21 April 2016 (EDT)

== Using Template:Convert ==

while looking at the [[Lockheed_Martin_F-35B_Lightning_II]], i noted the use of units that we could automatically have converted for us using the [https://en.wikipedia.org/wiki/Template:Convert convert template] from wikipedia... i'm assuming that we can do that, right? so below is an example of how it would be used and how it would look... i've left the original entry in place for final result comparison...

<syntaxhighlight>
=== Performance Data ===
* '''Maximum Speed:''' 1,200 mph {{convert|1200|mph|kt|abbr=on}}
* '''Rate of climb:''' classified
* '''Service Ceiling:''' 60,000 ft {{convert|60000|ft|m|abbr=on}}
* '''Range:''' 1,200 mi {{convert|1200|mi|km|abbr=on}}
</syntaxhighlight>

::=== Performance Data ===
::* '''Maximum Speed:''' 1,200 mph {{convert|1200|mph|kt|abbr=on}}
::* '''Rate of climb:''' classified
::* '''Service Ceiling:''' 60,000 ft {{convert|60000|ft|m|abbr=on}}
::* '''Range:''' 1,200 mi {{convert|1200|mi|km|abbr=on}}

<strike>side note: i wish i could figure out how to do code tags like on the forum :( </strike>
:thanks, Hooray. it ain't in the menu bar at the top so i didn't see it :)
:--[[User:Wkitty42|Wkitty42]] ([[User talk:Wkitty42|talk]]) 15:38, 5 September 2017 (EDT)

:: so the other day i was doing some code stuff in this wiki and be damned if i didn't forget how to do code blocks again... i finally found another page that had the syntax-highlight or whatever tags in it and that helped a lot... those, too, needed to be added to the help thing in the editing box... there was a time on another wiki where i'd open the help in a separate window so i could ALT-Tab back and forth to see all the various editing options and then apply them to what i was entering...

:: --[[User:Wkitty42|Wkitty42]] ([[User talk:Wkitty42|talk]]) 10:11, 4 August 2018 (EDT)

== Creating sandboxes (user page subpages) ==
I saw your post mostly about page creation and sandboxes in [https://forum.flightgear.org/viewtopic.php?p=334335#p334335 this forum post]. I am very happy you asked that question (which indicates it probably can be highlighted better in the help pages).

A sandbox is pretty much a subpage to your user page, in essence with the page name <code>User:Wkitty42/Name of subpage</code>. The way I usually create them is that I search for them and then click the blue link '''[http://wiki.flightgear.org/index.php?title=User:Wkitty42/Name_of_subpage&action=edit Start the User:Wkitty42/Name of subpage page]''' in the page that pops up telling that there is no such page (yet).

When using templates you are working on you will have to use template links slightly differently, as they are not in the template namespace. instead of <code><nowiki>{{Name of subpage}}</nowiki></code> you will need to do like this <code><nowiki>{{User:Wkitty42/Name of subpage}}</nowiki></code>.

If you forget to link to the pages on your user page, you can try the [What links here http://wiki.flightgear.org/Special:WhatLinksHere/User_talk:Wkitty42] link in the menu on the left.

It will be interesting to see what you do with this. :-)

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 03:36, 4 August 2018 (EDT)

:hey, Johan... yes, it probably could be hilighted better... even as a wikipedia editor at times, i've never done anything like these sandboxes... i appreciate the explanation... i guess what i should do now is to go to your page and try to find the convert template thing you did, copy it over here into a similar sandbox and then see if i can make it do the conversions like i spoke of above?

:TBH, i don't have a clue what i would do with it other than, right now, trying this template thing ;)

:--[[User:Wkitty42|Wkitty42]] ([[User talk:Wkitty42|talk]]) 10:01, 4 August 2018 (EDT)

:: yeah, trying this template thing as well as a sandbox page... [[User:Wkitty42/playing with convert template|right here]]

:: --[[User:Wkitty42|Wkitty42]] ([[User talk:Wkitty42|talk]]) 11:01, 4 August 2018 (EDT)

Commonly used debugging tools

2019-03-30T17:05:36Z

Wkitty42: /* Finding fgfs.log */ removed the line saying to navigate to $FG_HOME since the full path is already given in the locations...

{{stub}}

There are some relatively simple but '''commonly used debugging tools''' that might answer questions of for example why your installation of FlightGear will not run properly or at all, why an aircraft might have problems or why flying in a certain area always cause FlightGear crashes.

The more useful of those tool are the console window (also known as the "black box" or confusingly the "command line"), the <code>fgfs.log</code> file and the property browser.

There are of course times when these will not do, and sometimes one would have to compile FlightGear from source ''and'' add some additional debugging features to find some bugs.

== Debug level setting ==
Before we go any further we should mention the ''debug level'' setting (also known as ''log level''). When FlightGear runs it will output information on various things. As a default only things that are expected to cause troubles are output, but by setting a higher debug level more information will be shown. At the highest debug level one can expect FlightGear to run slow due to all the debug output.

=== Debug levels ===
There are five debug levels:
; Bulk: Will output very frequent messages. Using this setting might slow down FlightGear a lot, but might show problems not otherwise found.
; Debug: Will output less frequent debug messages.
; Info: Will output informatory messages.
; Warn: Will output messages about possibly impeding problems.
; Alert: Will output messages about very possibly impeding problems. This is the default level.

=== Setting the debug level ===
==== FGRun ====
In FGRun go to the last page click {{key press|Advanced...}} then, in the list to the left, click "Debug" and then chose the desired debug level in the list.

==== Command line ====
{{note|Debug levels must be lowercase. For example <code>debug</code>, not <code><s>&ensp;Debug&ensp;</s></code>.}}

Add <code>--log-level=''debug level''</code> to your command line.

== The console window ==
Before FlightGear 2.6 this was always opened in a separate window when starting FlightGear through the [[FGRun]] wizard, but these days it is normally hidden and can be shown by ticking a checkbox, "Show command line".

== fgfs.log ==
The startup log file contains nearly the same information that is output on the console.

The goal of adding the log file was to capture some debugging output in a way that is robust for users, i.e just works, and works ‘historically’, i.e is useful when a problem occurs since it was already enabled. The level is fixed at INFO because a lower level wouldn’t contain enough detail for debugging, but a higher level (SG_DEBUG) the files would be huge for a long FG session. This is my decision of course and it can be changed if people are happy with 100MB+ text files in their FG_HOME. Or we add a new option to set the file-log-level, but again the intention was for this feature to be as automatic as possible.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35144644/
|title = <nowiki> Re: [Flightgear-devel] fgfs.log </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jun 8th, 2016
|added = Jun 8th, 2016
|script_version = 0.40
}}</ref>

=== Finding fgfs.log ===
; Mac: <code>~/Library/Application Support/FlightGear/fgfs.log</code>
; Windows: <code>C:\Users\''user name''\AppData\Roaming\flightgear.org\fgfs.log</code>
; Linux: <code>~/.fgfs/fgfs.log</code>

== The property browser ==
{{main article|Property browser}}
The property browser is a tool useful for many purposes. It might for example tell if a property is tied and can not be written to.

== Related content ==
* [[Command line]]
* [[Property browser]]
* [[Howto:Understand console output]]
* [[:Category:Troubleshooting]]

== External links ==
* [https://gitorious.org:443/fg/simgear/source/deceee899771b82b0568319863b3812b272c926d:simgear/debug/debug_types.h#L44 The debug levels as mentioned in the source code]

[[Category:Troubleshooting]]
[[Category:Aircraft enhancement]]

Howto:Multiplayer

2018-08-12T11:01:01Z

Wkitty42: /* Using multiplayer from the command line */ re-enforce not using existing callsigns - line copied from another section of this page

The '''multiplayer''' feature of [[FlightGear]] makes it possible to see other pilots and vice-versa. This makes it possible to fly in formation, perform [[mid-air refueling]] with tankers controlled by real people or contact real [[air traffic control|air traffic controllers]] to ask for guidance.

Multiplayer may cause extreme [[troubleshooting performance issues|framerate drops]] during the loading of aircraft models, especially heavy models such as the [[Boeing 777]] or [[Airbus A320neo]]. It is suggested to fly in locations other than the default [[San Francisco International Airport]], as there are often lots of pilots in the area who are often new, and do not follow ATC, or respect traffic.

== Notes ==
* Callsigns can be a maximum of seven characters.
* You might want to check the [[#Known issues|Known issues]] section.

== Connecting to Multiplayer ==
=== Built-in launcher and in-sim dialog ===
[[File:Multiplayer settings dialog.jpg|thumb|Multiplayer settings dialog]]
The easiest way to get online is to use the [[FlightGear Qt launcher|built-in launcher]] or the in-sim Multiplayer dialog. All you need to do is enter a callsign and select a server from the menu. Press Connect to go online.

=== Using FGRun ===
==== From the main page ====
[[File:Multiplayer.jpg|thumb|Multiplayer settings in [[FGRun]]]]
# Select your [[aircraft]] and starting airport as normal in [[FGRun]].
# On the last screen, tick the "Multiplayer" box. Also make sure that the "AI models" box is checked or you will not be able to see the other pilots' aircraft.
# Enter the …
#* '''Callsign''' of your choice.
#* '''Hostname:''' Enter <code>mpserverXX.flightgear.org</code> (with <code>XX</code> being the [[#Servers|server number]]).
#* '''In/Out:''' Set both ports to 5000.
# Click {{button|Run}} to start FlightGear.

To confirm that it's working, you can go to the multiplayer map at http://mpmap02.flightgear.org/ (in Hong Kong). Once FlightGear has started, you will notice chat messages that say "Hello" indicating pilots that are online. They will also pop up when a pilot joins the MP network. You can change this message by editing this line in <tt>''[http://sourceforge.net/p/flightgear/fgdata/ci/next/tree/preferences.xml#l763 $FG_ROOT/preferences.xml]''</tt>:
<syntaxhighlight lang="xml">
<chat type="string" preserve="y">Hello</chat>
</syntaxhighlight>
You may wish to use a different server, especially one closer to you.

==== From Network Settings ====
[[File:FGRun Advanced dialog - Network.png|thumb|The <tt>Network</tt> tab of the Advanced Options dialog in [[FGRun]] (in [[Changelog 3.2|FlightGear 3.2.0]]).]]
You can also change multiplayer settings in the <tt>Network</tt> tab of FGRun's Advanced Options.

# On the last page, click {{button|Advanced}}.
# Click <tt>Network</tt> in the left column.
# In the <tt>Multiplayer Options</tt> area …
#* Type your desired callsign into the box.
#* Set the parameters for the two other boxes; see [[#Using multiplayer from the command line|below]] for correct syntax.
#* Click {{button|OK}}, then run FlightGear.

=== Using multiplayer from the command line ===
When running FlightGear from the [[command line]], you can specify multiplayer settings. The two arguments are as follows:
<syntaxhighlight lang="bash">
--multiplay=direction,10,ip.address,port
--callsign=anything
</syntaxhighlight>

Obviously, <code>--callsign</code> can be anything you wish but it must be limited to 7 (seven) characters in length counting any dashes. If your callsign is too long, it will be cut off in the various displays where it is shown. Generally speaking, callsigns are of the form X-XXXXX. Check [https://fgtracker.ml/ this page] to see whether your callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems! Please don't leave your callsign as "CALLSIG".

There are four arguments to <code>--multiplay</code>:
; direction
: Either <code>in</code> or <code>out</code>. <code>in</code> tells FlightGear to listen to packets of data coming in through the specified '''port'''. <code>out</code> tells FlightGear to send data out through the '''port'''.

; ip.address
: IP address of network interface being used by FlightGear. If left blank, FlightGear will listen to all network interfaces. If '''direction''' is set to <code>in</code>, FlightGear will listen to ''only'' this IP address.

; port
: Port that data is either being sent or received through. Usually set to <code>5000</code> and above.

== Advanced usage of multiplayer ==
=== Local setup for testing ===
It is possible to set up a local multiplayer network between two FlightGear instances ''without'' using a [[FGMS|multiplayer server]]. All you need to do is map each I/O port of one instance to the corresponding port(s) of the other instance:

{{Note|
{{FGCquote
|A socket connection requires not only an IP address, but also a port number for each side of the link - imagine a port number like a "mailbox" sitting at the address. This mailbox is used by the communicating processes to send out and receive "messages". Different processes (even when possibly identical programs) will need to use different port numbers when running. Because open ports ({{=}}mailboxes) cannot be shared.
Thus, you need to modify the client-side port settings for each additional instance that you are running on the same machine, and map the output port of one instance to the input port of the other instance (and vice versa).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=83068#p83068
|title=<nowiki>Re: 2 FGFS instances / 1 win7 running same time with MP?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Jun 10</nowiki>
}}
}}
}}

Command line parameters for the first instance:
<syntaxhighlight lang="bash">
--multiplay=out,10,127.0.0.1,5000 --multiplay=in,10,127.0.0.1,5001 --callsign=Test1
</syntaxhighlight>

Command line parameters for the second instance:
<syntaxhighlight lang="bash">
--multiplay=out,10,127.0.0.1,5001 --multiplay=in,10,127.0.0.1,5000 --callsign=Test2
</syntaxhighlight>

You can use this kind of setup to test multiplayer related features or troubleshoot multiplayer related bug reports that may be otherwise hard to reproduce over MP. As you can't access the configuration of other people's FlightGear, this technique allows you to have complete control over FlightGear's settings.

[[File:Direct-p2p-multiplayer-setup.png|800px|Screenshot demonstrating a "peer-to-peer" setup between two FlightGear instances running on the same machine via localhost (127.0.0.1) without any multiplayer server.]]

You can add an arbitrary number of channels to mirror your flight onto other servers, e.g. to a private fgms (FlightGear Multiplayer Server) using
<syntaxhighlight lang="bash">
--multiplay=out,10,my.private.server.ip,5000
</syntaxhighlight>

Additionally, the <code>in</code> argument above tells FG to listen '''only''' on the loopback/local interface - it will not receive packets arriving on the other network interface(s). If you want to also bind to other interfaces, just omit the IP address by using
<syntaxhighlight lang="bash">
--multiplay=in,10,,5000
</syntaxhighlight>

Check [https://fgtracker.ml/ this page] to see whether your callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems!

==== Now, going more slowly for those who are completely lost... ====
{{Note|This section may contain out of date or inaccurate information.}}
This section ''ought'' to be unnecessary now with recent versions of the FG server. If you have problems though, it won't hurt to follow through.

First of all, you need to know the IP address of the network interface you'll be using for multiplayer FG.

If your Internet connection is via an ADSL modem that plugs directly into your computer, you should be able to find your IP address by visiting http://www.whatismyip.com.
{{Note|Your {{Abbr|ISP|Internet Service Provider}} might not give you the same IP address each time.}}

If your connection is via an Ethernet connector or by a wireless link.

* '''Linux:''' Log in as root and run <code>ifconfig</code> in the terminal. In the text that is returned, you should to look for an interface name such as <code>eth0</code> or <code>wlan0</code>. Finally, look in the text below the interface name for <code>inet addr:ip.address</code>. For example, this should read something like <code>inet addr:192.168.0.150</code>.
* '''Windows:'''
** '''Windows XP or later:''' Start Command Prompt and <code>ipconfig</code> into the terminal. Write the IP address down.
** '''Windows 98''', click start, run, and type "winipcfg" to get information about your IP address.

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

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

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

Finally, start FG using the command line given right at the start (if you're using the Windows launcher you will find entry boxes for Multiplayer arguments – insert the relevant details there). You will end up with something like this:
<syntaxhighlight lang="bash" enclose="div">
<other arguments> --callsign=test --multiplay=in,10,192.168.0.2,5000 --multiplay=out,10,mpserver05.flightgear.org,5000 --airport=KSFO --runway=28R --aircraft=hunter
</syntaxhighlight>

Choose your own callsign, but check [https://fgtracker.ml/ this page] first to see whether your desired callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems!

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

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

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

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

If it's still just not working for you, ask nicely on the [[FlightGear IRC channel|IRC channel]] or the [http://forum.flightgear.org/ forum] and someone should be able to assist.

=== Multiple connections per computer ===
It is possible to run multiple FlightGear instances on a single computer and connect them all to the multiplayer network. However, this requires some extras to keep in mind:
# Both instances use the same <code>out</code> port.
# One instance uses <code>in</code> port <code>5001</code>, the other port <code>5002</code>.
# Both instances have unique callsigns.

=== Optional collision detection in multiplayer ===

A patch has been added to FlightGear (since Version 3.5) to allow optional collision detection in multiplayer. To enable collision detection, start FlightGear with:

<syntaxhighlight>
--prop:bool:/sim/multiplay/hot=true
</syntaxhighlight>

Those who are able to patch FGData themselves, can download [http://sourceforge.net/p/flightgear/mailman/attachment/CAHs0wcrEwYZvXTddcUaH0ZMfmVNvEWRap8MXOrEoKybUDO58sQ%40mail.gmail.com/3/ mp-hot-fgdata.patch], which adds a checkbox to the Multiplayer Settings dialog to enable or disable the collision detection at runtime.

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

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

The shortcut for chatting is {{Key press|<nowiki>-</nowiki>}} (hyphen). This will bring up some text in the upper-left of the FlightGear window. By pressing the corresponding number keys, you can send pre-made messages. Pressing {{Key press|1}} will let you type in a custom message, which you can send by pressing enter. By default, other people's messages are displayed at the top of FlightGear's window for a few seconds, but it will appear for a much longer time in the window at <tt>Network > Chat</tt>. So if you think you have missed anything, go check there.

== Dealing with abusive behavior ==
Should you become victim of abusive or annoying behavior by any pilot, you have option to ignore him or her. To activate the ignore function open the <tt>Multiplayer > Pilot list</tt> dialog and click the <tt>ignore</tt> button next to the pilot's callsign. This will prevent chat messages from the ignored pilot appearing and prevent his aircraft from appearing (unless you are using FlightGear v2.2 or older).

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

There is a very nice online map which displays the location of online pilots at [http://mpmap02.flightgear.org mpmap02]. You will also find this useful to check that you are successfully connecting to the server, as well as looking up navaids, waypoints, airports, frequencies, weather, and more!

== Servers ==
The multiplayer servers are interconnected. With few exceptions you ''do not'' need to connect to a specific server in order to see other pilots who are on that server. For best performance, you should connect to the server that is either geographically closest to you, has the lowest latency (ping time), or is the least busy.
{{tip|Use [http://mpmap01.flightgear.org/mpstatus/ this link] to check if the MP servers are online. Page is automatically generated. The [[#In-sim Dialog|in-sim dialog]] will only display servers that are available.}}

{| class="wikitable sortable"
! Server address
! Status
! Location
! Tracked (by [http://fgtracker.ml fgtracker.ml] unless otherwise specified)
! Maintainer
! Maintainer's [[IRC]] name
! Maintainer's [http://flightgear.org/forums forum] name
! Comments
|-
| mpserver01.flightgear.org
| {{yes|Up}}
| Germany
| {{yes}}
| Oliver Schröder
| os
| {{N/a}}
| {{N/a|None}}
|-
| mpserver02.flightgear.org
| {{yes|Up}}
| Los Angeles, USA
| {{N/a}}
| Lloyd Stevens
| ls4680
| ls4680
| {{N/a|None}}
|-
| mpserver03.flightgear.org
| {{yes|Up}}
| Germany
| {{yes}}
| Hergen
| {{N/a}}
| {{N/a}}
| [https://mpserver03.flightgear.org mpserver03.flightgear.org]
|-
| mpserver04.flightgear.org
| {{yes|Up}}
| UK
| {{no}}
| Jon Stockill
| Nav
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=738 JonS]
| {{N/a|None}}
|-
| mpserver05.flightgear.org
| {{no|Down}}
| Chicago, USA
| {{N/a}}
| Brant
| IonCannon218
| {{N/a}}
| {{N/a|None}}
|-
| mpserver06.flightgear.org
| {{no|Down}}
| Berlin, Germany
| {{N/a}}
| Sven Teichmann
| {{N/a}}
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=11839 D-SAMI]
| Unlimited traffic
|-
| mpserver07.flightgear.org
| {{no|Down}}
| Wisconsin, USA
| {{N/a}}
| Tom Betka
| TB
| {{N/a}}
| Offline
|-
| mpserver08.flightgear.org
| {{no|Down}}
| Frankfurt am Main, Germany
| {{N/a}}
| Roland
| Quix0r
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=7512 Quix0r]
| 10 TByte traffic, mostly short pings
|-
| mpserver09.flightgear.org
| {{no|Down}}
| Köln, Germany
| {{N/a}}
| Daniel Vigano
| Fauchi95
| {{N/a}}
| Offline
|-
| mpserver10.flightgear.org
| {{no|Down}}
| Montpellier, France
| {{N/a}}
| {{usr|Xiii|Alexis Bory}}
| xiii
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=884 xiii]
| {{N/a|None}}
|-
| mpserver11.flightgear.org
| {{no|Down}}
| Vilnius, Lithuania
| {{N/a}}
| Darius
| {{N/a}}
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=1122 ffg]
| {{N/a|None}}
|-
| mpserver12.org
| {{no}}
| Amsterdam, the Netherlands
| {{no}} ([http://mpserver12.org mpserver12.org])
| Rob
| evilslut
| {{N/a}}
| Formerly mpserver12.flightgear.org<ref>http://forum.flightgear.org/viewtopic.php?f=27&t=27453&start=60#p258435</ref>
|-
| mpserver13.flightgear.org
| {{yes|Up}}
| Beauvais, France
| {{N/a}}
| Charles Ingels
| charles
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=1592 cbz-026]
| {{N/a|None}}
|-
| mpserver14.flightgear.org
| {{yes|Up}}
| UK
| {{no}}
| Pete
| {{N/a}}
| {{N/a}}
| {{N/a|None}}
|-
| mpserver15.flightgear.org
| {{yes|Up}}
| North Point, Hong Kong
| {{yes}}
| Hazuki Amamiya
| Hazuki
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=8400 Hazuki]
| {{N/a|None}}
|-
| mpserver16.flightgear.org
| {{yes|Up}}
| Kansas City, Missouri, USA
| {{no}}
| Rob Dosogne
| truthsolo
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9926 truthsolo]
| {{N/a|None}}
|-
| mpserver17.flightgear.org
| {{no|Down}}
| Cluj, Romania
| {{N/a}}
| Marius
| tuxum
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=11636 tuxum]
| Offline
|-
| mpserver18.flightgear.org
| {{no|Down}}
| Germany
| {{N/a}}
| {{N/a}}
| {{N/a}}
| {{N/a}}
| {{N/a}}
|-
| mpserver19.flightgear.org
| {{yes|Up}}
| London, UK
| {{yes}}
| Dr. R0ckso
| drr0ckso
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21111 drR0ckso]
| {{N/a|None}}
|-
| mpserver20.flightgear.org
| {{yes|Up}}
| South San Francisco, California, USA
| {{yes}}
| Marisa Giancarla
| marisag
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21604 marisag]
| {{N/a|None}}
|-
| mpserver21.flightgear.org
| {{yes|Up}}
| Tokyo, Japan
| {{yes}}
| Marisa Giancarla
| marisag
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21604 marisag]
| {{N/a|None}}
|-
| mpserver51.flightgear.org
| {{yes|Up}}
| Atlanta, Georgia, USA
| {{yes}}
| Dr. R0ckso
| drr0ckso
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21111 drR0ckso]
| Radio horizon is 414 miles
|-
| mpserver87.megaf.info
| {{yes|Up}}
| Paris, France
| {{yes}}
| Megaf
| Megaf
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21017 Megaf]
| Not linked to others yet
|}

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

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

== Known issues ==
=== Fibertel (Argentina) ===
In December 2014, it was reported that UDP connection through port 5000 was not possible for users whose ISP was {{Wikipedia|Fibertel}} (Argentina).

Fibertel Argentina apparently uses the port for setup purposes. "It should be open for the user but it might not be fully functional."

Port 5000 is a generic port, and neither FlightGear nor the {{Wikipedia|UPnP}} protocol are an "official" usage of the port.

A solution would be to spread the ports between the servers; e.g., mpserver01.flightgear.org → 5001, mpserver02.flightgear.org → 5002

See also the [http://forum.flightgear.org/viewtopic.php?f=27&t=24754 forum thread] and {{issue|1617}}.

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

{{Appendix}}

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

[[de:Howto: Multiplayer]]
[[es:Howto: Multijugador]]
[[fr:Howto: Multijoueur]]
[[it:Come fare:Multiplayer]]
[[nl:Howto: Multiplayer]]
[[pl:Konfiguracja trybu multiplayer]]
[[pt:Tutorial de Multiplayer]]

Howto:Multiplayer

2018-08-12T10:55:27Z

Wkitty42: /* Using multiplayer from the command line */ note that callsign is limited to 7 characters in length

The '''multiplayer''' feature of [[FlightGear]] makes it possible to see other pilots and vice-versa. This makes it possible to fly in formation, perform [[mid-air refueling]] with tankers controlled by real people or contact real [[air traffic control|air traffic controllers]] to ask for guidance.

Multiplayer may cause extreme [[troubleshooting performance issues|framerate drops]] during the loading of aircraft models, especially heavy models such as the [[Boeing 777]] or [[Airbus A320neo]]. It is suggested to fly in locations other than the default [[San Francisco International Airport]], as there are often lots of pilots in the area who are often new, and do not follow ATC, or respect traffic.

== Notes ==
* Callsigns can be a maximum of seven characters.
* You might want to check the [[#Known issues|Known issues]] section.

== Connecting to Multiplayer ==
=== Built-in launcher and in-sim dialog ===
[[File:Multiplayer settings dialog.jpg|thumb|Multiplayer settings dialog]]
The easiest way to get online is to use the [[FlightGear Qt launcher|built-in launcher]] or the in-sim Multiplayer dialog. All you need to do is enter a callsign and select a server from the menu. Press Connect to go online.

=== Using FGRun ===
==== From the main page ====
[[File:Multiplayer.jpg|thumb|Multiplayer settings in [[FGRun]]]]
# Select your [[aircraft]] and starting airport as normal in [[FGRun]].
# On the last screen, tick the "Multiplayer" box. Also make sure that the "AI models" box is checked or you will not be able to see the other pilots' aircraft.
# Enter the …
#* '''Callsign''' of your choice.
#* '''Hostname:''' Enter <code>mpserverXX.flightgear.org</code> (with <code>XX</code> being the [[#Servers|server number]]).
#* '''In/Out:''' Set both ports to 5000.
# Click {{button|Run}} to start FlightGear.

To confirm that it's working, you can go to the multiplayer map at http://mpmap02.flightgear.org/ (in Hong Kong). Once FlightGear has started, you will notice chat messages that say "Hello" indicating pilots that are online. They will also pop up when a pilot joins the MP network. You can change this message by editing this line in <tt>''[http://sourceforge.net/p/flightgear/fgdata/ci/next/tree/preferences.xml#l763 $FG_ROOT/preferences.xml]''</tt>:
<syntaxhighlight lang="xml">
<chat type="string" preserve="y">Hello</chat>
</syntaxhighlight>
You may wish to use a different server, especially one closer to you.

==== From Network Settings ====
[[File:FGRun Advanced dialog - Network.png|thumb|The <tt>Network</tt> tab of the Advanced Options dialog in [[FGRun]] (in [[Changelog 3.2|FlightGear 3.2.0]]).]]
You can also change multiplayer settings in the <tt>Network</tt> tab of FGRun's Advanced Options.

# On the last page, click {{button|Advanced}}.
# Click <tt>Network</tt> in the left column.
# In the <tt>Multiplayer Options</tt> area …
#* Type your desired callsign into the box.
#* Set the parameters for the two other boxes; see [[#Using multiplayer from the command line|below]] for correct syntax.
#* Click {{button|OK}}, then run FlightGear.

=== Using multiplayer from the command line ===
When running FlightGear from the [[command line]], you can specify multiplayer settings. The two arguments are as follows:
<syntaxhighlight lang="bash">
--multiplay=direction,10,ip.address,port
--callsign=anything
</syntaxhighlight>

Obviously, <code>--callsign</code> can be anything you wish but it must be limited to 7 (seven) characters in length counting any dashes. If your callsign is too long, it will be cut off in the various displays where it is shown. Generally speaking, callsigns are of the form X-XXXXX. Please don't leave your callsign as "CALLSIG".

There are four arguments to <code>--multiplay</code>:
; direction
: Either <code>in</code> or <code>out</code>. <code>in</code> tells FlightGear to listen to packets of data coming in through the specified '''port'''. <code>out</code> tells FlightGear to send data out through the '''port'''.

; ip.address
: IP address of network interface being used by FlightGear. If left blank, FlightGear will listen to all network interfaces. If '''direction''' is set to <code>in</code>, FlightGear will listen to ''only'' this IP address.

; port
: Port that data is either being sent or received through. Usually set to <code>5000</code> and above.

== Advanced usage of multiplayer ==
=== Local setup for testing ===
It is possible to set up a local multiplayer network between two FlightGear instances ''without'' using a [[FGMS|multiplayer server]]. All you need to do is map each I/O port of one instance to the corresponding port(s) of the other instance:

{{Note|
{{FGCquote
|A socket connection requires not only an IP address, but also a port number for each side of the link - imagine a port number like a "mailbox" sitting at the address. This mailbox is used by the communicating processes to send out and receive "messages". Different processes (even when possibly identical programs) will need to use different port numbers when running. Because open ports ({{=}}mailboxes) cannot be shared.
Thus, you need to modify the client-side port settings for each additional instance that you are running on the same machine, and map the output port of one instance to the input port of the other instance (and vice versa).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=83068#p83068
|title=<nowiki>Re: 2 FGFS instances / 1 win7 running same time with MP?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Jun 10</nowiki>
}}
}}
}}

Command line parameters for the first instance:
<syntaxhighlight lang="bash">
--multiplay=out,10,127.0.0.1,5000 --multiplay=in,10,127.0.0.1,5001 --callsign=Test1
</syntaxhighlight>

Command line parameters for the second instance:
<syntaxhighlight lang="bash">
--multiplay=out,10,127.0.0.1,5001 --multiplay=in,10,127.0.0.1,5000 --callsign=Test2
</syntaxhighlight>

You can use this kind of setup to test multiplayer related features or troubleshoot multiplayer related bug reports that may be otherwise hard to reproduce over MP. As you can't access the configuration of other people's FlightGear, this technique allows you to have complete control over FlightGear's settings.

[[File:Direct-p2p-multiplayer-setup.png|800px|Screenshot demonstrating a "peer-to-peer" setup between two FlightGear instances running on the same machine via localhost (127.0.0.1) without any multiplayer server.]]

You can add an arbitrary number of channels to mirror your flight onto other servers, e.g. to a private fgms (FlightGear Multiplayer Server) using
<syntaxhighlight lang="bash">
--multiplay=out,10,my.private.server.ip,5000
</syntaxhighlight>

Additionally, the <code>in</code> argument above tells FG to listen '''only''' on the loopback/local interface - it will not receive packets arriving on the other network interface(s). If you want to also bind to other interfaces, just omit the IP address by using
<syntaxhighlight lang="bash">
--multiplay=in,10,,5000
</syntaxhighlight>

Check [https://fgtracker.ml/ this page] to see whether your callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems!

==== Now, going more slowly for those who are completely lost... ====
{{Note|This section may contain out of date or inaccurate information.}}
This section ''ought'' to be unnecessary now with recent versions of the FG server. If you have problems though, it won't hurt to follow through.

First of all, you need to know the IP address of the network interface you'll be using for multiplayer FG.

If your Internet connection is via an ADSL modem that plugs directly into your computer, you should be able to find your IP address by visiting http://www.whatismyip.com.
{{Note|Your {{Abbr|ISP|Internet Service Provider}} might not give you the same IP address each time.}}

If your connection is via an Ethernet connector or by a wireless link.

* '''Linux:''' Log in as root and run <code>ifconfig</code> in the terminal. In the text that is returned, you should to look for an interface name such as <code>eth0</code> or <code>wlan0</code>. Finally, look in the text below the interface name for <code>inet addr:ip.address</code>. For example, this should read something like <code>inet addr:192.168.0.150</code>.
* '''Windows:'''
** '''Windows XP or later:''' Start Command Prompt and <code>ipconfig</code> into the terminal. Write the IP address down.
** '''Windows 98''', click start, run, and type "winipcfg" to get information about your IP address.

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

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

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

Finally, start FG using the command line given right at the start (if you're using the Windows launcher you will find entry boxes for Multiplayer arguments – insert the relevant details there). You will end up with something like this:
<syntaxhighlight lang="bash" enclose="div">
<other arguments> --callsign=test --multiplay=in,10,192.168.0.2,5000 --multiplay=out,10,mpserver05.flightgear.org,5000 --airport=KSFO --runway=28R --aircraft=hunter
</syntaxhighlight>

Choose your own callsign, but check [https://fgtracker.ml/ this page] first to see whether your desired callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems!

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

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

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

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

If it's still just not working for you, ask nicely on the [[FlightGear IRC channel|IRC channel]] or the [http://forum.flightgear.org/ forum] and someone should be able to assist.

=== Multiple connections per computer ===
It is possible to run multiple FlightGear instances on a single computer and connect them all to the multiplayer network. However, this requires some extras to keep in mind:
# Both instances use the same <code>out</code> port.
# One instance uses <code>in</code> port <code>5001</code>, the other port <code>5002</code>.
# Both instances have unique callsigns.

=== Optional collision detection in multiplayer ===

A patch has been added to FlightGear (since Version 3.5) to allow optional collision detection in multiplayer. To enable collision detection, start FlightGear with:

<syntaxhighlight>
--prop:bool:/sim/multiplay/hot=true
</syntaxhighlight>

Those who are able to patch FGData themselves, can download [http://sourceforge.net/p/flightgear/mailman/attachment/CAHs0wcrEwYZvXTddcUaH0ZMfmVNvEWRap8MXOrEoKybUDO58sQ%40mail.gmail.com/3/ mp-hot-fgdata.patch], which adds a checkbox to the Multiplayer Settings dialog to enable or disable the collision detection at runtime.

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

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

The shortcut for chatting is {{Key press|<nowiki>-</nowiki>}} (hyphen). This will bring up some text in the upper-left of the FlightGear window. By pressing the corresponding number keys, you can send pre-made messages. Pressing {{Key press|1}} will let you type in a custom message, which you can send by pressing enter. By default, other people's messages are displayed at the top of FlightGear's window for a few seconds, but it will appear for a much longer time in the window at <tt>Network > Chat</tt>. So if you think you have missed anything, go check there.

== Dealing with abusive behavior ==
Should you become victim of abusive or annoying behavior by any pilot, you have option to ignore him or her. To activate the ignore function open the <tt>Multiplayer > Pilot list</tt> dialog and click the <tt>ignore</tt> button next to the pilot's callsign. This will prevent chat messages from the ignored pilot appearing and prevent his aircraft from appearing (unless you are using FlightGear v2.2 or older).

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

There is a very nice online map which displays the location of online pilots at [http://mpmap02.flightgear.org mpmap02]. You will also find this useful to check that you are successfully connecting to the server, as well as looking up navaids, waypoints, airports, frequencies, weather, and more!

== Servers ==
The multiplayer servers are interconnected. With few exceptions you ''do not'' need to connect to a specific server in order to see other pilots who are on that server. For best performance, you should connect to the server that is either geographically closest to you, has the lowest latency (ping time), or is the least busy.
{{tip|Use [http://mpmap01.flightgear.org/mpstatus/ this link] to check if the MP servers are online. Page is automatically generated. The [[#In-sim Dialog|in-sim dialog]] will only display servers that are available.}}

{| class="wikitable sortable"
! Server address
! Status
! Location
! Tracked (by [http://fgtracker.ml fgtracker.ml] unless otherwise specified)
! Maintainer
! Maintainer's [[IRC]] name
! Maintainer's [http://flightgear.org/forums forum] name
! Comments
|-
| mpserver01.flightgear.org
| {{yes|Up}}
| Germany
| {{yes}}
| Oliver Schröder
| os
| {{N/a}}
| {{N/a|None}}
|-
| mpserver02.flightgear.org
| {{yes|Up}}
| Los Angeles, USA
| {{N/a}}
| Lloyd Stevens
| ls4680
| ls4680
| {{N/a|None}}
|-
| mpserver03.flightgear.org
| {{yes|Up}}
| Germany
| {{yes}}
| Hergen
| {{N/a}}
| {{N/a}}
| [https://mpserver03.flightgear.org mpserver03.flightgear.org]
|-
| mpserver04.flightgear.org
| {{yes|Up}}
| UK
| {{no}}
| Jon Stockill
| Nav
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=738 JonS]
| {{N/a|None}}
|-
| mpserver05.flightgear.org
| {{no|Down}}
| Chicago, USA
| {{N/a}}
| Brant
| IonCannon218
| {{N/a}}
| {{N/a|None}}
|-
| mpserver06.flightgear.org
| {{no|Down}}
| Berlin, Germany
| {{N/a}}
| Sven Teichmann
| {{N/a}}
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=11839 D-SAMI]
| Unlimited traffic
|-
| mpserver07.flightgear.org
| {{no|Down}}
| Wisconsin, USA
| {{N/a}}
| Tom Betka
| TB
| {{N/a}}
| Offline
|-
| mpserver08.flightgear.org
| {{no|Down}}
| Frankfurt am Main, Germany
| {{N/a}}
| Roland
| Quix0r
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=7512 Quix0r]
| 10 TByte traffic, mostly short pings
|-
| mpserver09.flightgear.org
| {{no|Down}}
| Köln, Germany
| {{N/a}}
| Daniel Vigano
| Fauchi95
| {{N/a}}
| Offline
|-
| mpserver10.flightgear.org
| {{no|Down}}
| Montpellier, France
| {{N/a}}
| {{usr|Xiii|Alexis Bory}}
| xiii
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=884 xiii]
| {{N/a|None}}
|-
| mpserver11.flightgear.org
| {{no|Down}}
| Vilnius, Lithuania
| {{N/a}}
| Darius
| {{N/a}}
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=1122 ffg]
| {{N/a|None}}
|-
| mpserver12.org
| {{no}}
| Amsterdam, the Netherlands
| {{no}} ([http://mpserver12.org mpserver12.org])
| Rob
| evilslut
| {{N/a}}
| Formerly mpserver12.flightgear.org<ref>http://forum.flightgear.org/viewtopic.php?f=27&t=27453&start=60#p258435</ref>
|-
| mpserver13.flightgear.org
| {{yes|Up}}
| Beauvais, France
| {{N/a}}
| Charles Ingels
| charles
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=1592 cbz-026]
| {{N/a|None}}
|-
| mpserver14.flightgear.org
| {{yes|Up}}
| UK
| {{no}}
| Pete
| {{N/a}}
| {{N/a}}
| {{N/a|None}}
|-
| mpserver15.flightgear.org
| {{yes|Up}}
| North Point, Hong Kong
| {{yes}}
| Hazuki Amamiya
| Hazuki
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=8400 Hazuki]
| {{N/a|None}}
|-
| mpserver16.flightgear.org
| {{yes|Up}}
| Kansas City, Missouri, USA
| {{no}}
| Rob Dosogne
| truthsolo
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9926 truthsolo]
| {{N/a|None}}
|-
| mpserver17.flightgear.org
| {{no|Down}}
| Cluj, Romania
| {{N/a}}
| Marius
| tuxum
| [http://forum.flightgear.org/memberlist.php?mode=viewprofile&u=11636 tuxum]
| Offline
|-
| mpserver18.flightgear.org
| {{no|Down}}
| Germany
| {{N/a}}
| {{N/a}}
| {{N/a}}
| {{N/a}}
| {{N/a}}
|-
| mpserver19.flightgear.org
| {{yes|Up}}
| London, UK
| {{yes}}
| Dr. R0ckso
| drr0ckso
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21111 drR0ckso]
| {{N/a|None}}
|-
| mpserver20.flightgear.org
| {{yes|Up}}
| South San Francisco, California, USA
| {{yes}}
| Marisa Giancarla
| marisag
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21604 marisag]
| {{N/a|None}}
|-
| mpserver21.flightgear.org
| {{yes|Up}}
| Tokyo, Japan
| {{yes}}
| Marisa Giancarla
| marisag
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21604 marisag]
| {{N/a|None}}
|-
| mpserver51.flightgear.org
| {{yes|Up}}
| Atlanta, Georgia, USA
| {{yes}}
| Dr. R0ckso
| drr0ckso
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21111 drR0ckso]
| Radio horizon is 414 miles
|-
| mpserver87.megaf.info
| {{yes|Up}}
| Paris, France
| {{yes}}
| Megaf
| Megaf
| [https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21017 Megaf]
| Not linked to others yet
|}

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

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

== Known issues ==
=== Fibertel (Argentina) ===
In December 2014, it was reported that UDP connection through port 5000 was not possible for users whose ISP was {{Wikipedia|Fibertel}} (Argentina).

Fibertel Argentina apparently uses the port for setup purposes. "It should be open for the user but it might not be fully functional."

Port 5000 is a generic port, and neither FlightGear nor the {{Wikipedia|UPnP}} protocol are an "official" usage of the port.

A solution would be to spread the ports between the servers; e.g., mpserver01.flightgear.org → 5001, mpserver02.flightgear.org → 5002

See also the [http://forum.flightgear.org/viewtopic.php?f=27&t=24754 forum thread] and {{issue|1617}}.

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

{{Appendix}}

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

[[de:Howto: Multiplayer]]
[[es:Howto: Multijugador]]
[[fr:Howto: Multijoueur]]
[[it:Come fare:Multiplayer]]
[[nl:Howto: Multiplayer]]
[[pl:Konfiguracja trybu multiplayer]]
[[pt:Tutorial de Multiplayer]]

Troubleshooting crashes

2018-08-11T18:39:26Z

Wkitty42: /* The standard procedure */ link to existing page with log level options and explanation...

{{Troubleshooting}}
{{note|'''This article is valid for FlightGear versions: 2.6, 2.8, 2.10, 2.12, 3.0+'''. Help us in keeping this article up to date! If you're facing some crash not listed here and manage to solve it, '''please add it to a proper section''', so that other can benefit from your experience!}}

Crashes are never easy to troubleshoot. It's very likely that you'll need to experiment a bit to find out the cause, or at least to provide useful feedback. In fact issues depend a lot on things like hardware components, driver support and so on. Developers can't work on your machine, so you'll need to provide them with some specific information. This article will guide you in that.

If not only FlightGear, but the whole system crashes, or freezes, please refer to [[System Crashes]].

If in the end you like bug hunting, please consider helping in [[Volunteer#Pre-Release Testers|testing future releases]].

== Known problems ==
Before diving into the real troubleshooting, first try to see if one of the following is your case. This could be a huge time saver!

'''If your problem is not listed here, please consider adding it after you have solved it! Others like you will be grateful!'''

=== Optimus/Hybrid graphics technologies for laptops ===
If FlightGear crashes with
Unknown exception in the main loop. Aborting...
Possible cause: Not enough space
and you happen to have a laptop with Optimus Technology (NVidia) or Hybrid Graphics technology (ATI) onboard, you'll find some help at [[Troubleshooting performance issues#Operating system and driver setup]]. (Note that the problem is treated there because it's mostly cause of low performance.)

=== World Scenery 2.0 and 32-bit machines ===
[[World Scenery]] 2.0 (the one with [[CORINE]] and [[OpenStreetMap]] data) highly raised memory requirements with respect to the previous version. Basically, with 4GB of RAM once you could safely use a visibility of a hundred kilometers; with Scenery 2.0, 4GB is barely enough for 10 km. A 32-bit machine can't use more than that memory, and simply kills FlightGear when it asks for more. To verify this, reduce your visibility (in-sim with ''View > Level of Detail adjustment'' and set ''Bare'' to 5000 m) and see if it stops crashing. You can also check memory consumption with the tools provided by your OS.

Sadly, the solution is keeping a low visibility, or moving to a 64-bit machine with at least 8GB of RAM, which can provide even 45km of visibility. If you're feeling "hackish", you can try the solution reported at [[Unexpected Crashes with Scenery ver.2]].

=== Old graphics cards and FlightGear 2.10 ===
If you're using FlightGear 2.10, you're seeing crashes during simulator startup (without seeing the actual aircraft/scenery), and you're using an old enough graphics card, it is possible that your crash is due to a bug in that FG version and to your card lacking [[Shader|GLSL]] support. This bug would prevent using FG even with shaders off! Ironically, this bug comes from a feature introduced to help troubleshooting bugs.

So, if you're on 2.10 and think your card could be old enough, try the minimal startup configuration below: if it keeps crashing, that's definitely it. The bug was solved immediately later (ver. 2.11)

== Troubleshooting your crash ==
FlightGear crashes are due to a number of reasons, not necessarily to bugs in its code. After all, it works "out of the box" for most users, so if something's broken it's often a system-specific issue, and yet again, it could be a system configuration that the developers couldn't test - [[Volunteer#Pre-Release Testers|you can help with that]]!)

It's just as well possible that the FlightGear default settings are not supported with your hardware/drivers. Since version 2.6, FlightGear will assume support for certain features that hardware older than 4-5 years might not give (especially graphics cards), so the default settings need to be customized to disable all unsupported features. See [[Troubleshooting performance issues]], [[Problematic Video Cards]] and [[FlightGear Hardware Recommendations]] for more details.

=== Preliminary check ===
Make sure you've got the newest driver for your video card installed and running without errors. A suggestion for a thorough updating procedure can be found at [[Graphics drivers configuration]]. '''Before proceeding any further, please make sure that you are actually able to run other OpenGL-based software/simulators/games, unrelated to FlightGear!'''

=== The standard procedure ===
Given the above, it is important to start up FlightGear with a '''minimal startup profile''', with ''all'' eye candy and features disabled (so that FG won't crash due to lack of support for them) and start re-enabling them step by step to see what's supported by your hardware. You may want to [[Commonly used debugging tools#Debug level setting|raise the FlightGear log level]], so that you get to see where the program stops starting/working, and what it was doing before it got terminated. This procedure will also help in [[troubleshooting performance issues]].

These settings use the simple UFO and a suitable scenery location to rule out aircraft or scenery as a cause for crashes. Don't even touch the aircraft and location settings (airport, azimuth, offset) until you have really fixed everything else already. Working step by step is the only real way, so don't bite off more than you can chew.

If you find it looks like the Windows "compatibility mode" that you boot into after a crash, then you understand perfectly what we're doing here. However it's not as straightforward to do, so if in trouble [http://forum.flightgear.org/viewforum.php?f=17 ask for support at the forum]!

=== Minimal startup profile ===
{{Note|If you find any other settings causing a massive improvement of performance/compatibility, please feel free to add those below, so that others can benefit from your findings.}}

<gallery mode="packed">
Tweaking-nvidia-settings1.png|Tweaking nvidia settings to obtain higher frame rates by disabling vsync to blank
Tweaking-nvidia-settings2.png|Tweaking Nvidia Powermizer to obtain higher frame rates
</gallery>

Depending on the hardware specs of the target platform, adjusting the threading mode of FG/OSG may also help: [[Howto:Activate multi core and multi GPU support]]. (If you don't know what we're talking about, you can safely leave it as it is.)

You can directly use a custom [[Fgfsrc]] file for the following sections or parse the following lines to the console (separated by one empty character, e.g. a space) after "FGFS" or set the respective options in [[Fgrun]] or in [[FlightGear configuration via XML|one of FlightGear's XML configuration files]].

Please make sure to rename/delete your autosave and fgfsrc files prior to trying these settings, or your local settings would possibly override these settings.
{{Startup Profile|name=minimal|version=3.2}}

{{Tip|Beginning with FlightGear 3.1+, you can also toggle individual scenegraph traversal masks on/off (these can be changed at runtime using the [[Property browser]]:
* <nowiki>--prop:/sim/sceneryloaded-override=1</nowiki>
* <nowiki>--prop:/sim/rendering/draw-mask/terrain=0</nowiki>
* <nowiki>--prop:/sim/rendering/draw-mask/aircraft=0</nowiki>
* <nowiki>--prop:/sim/rendering/draw-mask/models=0</nowiki>
* <nowiki>--prop:/sim/rendering/draw-mask/clouds=0</nowiki>
}}

If you're running on Windows, you can use the following batch file to start the simulator using the minimal profile. Open Notepad, copy and paste the following lines and save the file on the Desktop (name it ''fgminimal.bat''); change ''C:\Program Files\FlightGear'' to the directory you installed FlightGear in and change ''Win64'' to ''Win32'' if you are using the 32-bit version.
<pre>
@echo off
"C:\Program Files\FlightGear\bin\Win64\fgfs.exe" --fg-root="C:\Program Files\FlightGear\data" --ignore-autosave --airport=ksfo --offset-distance=4000 --offset-azimuth=90 --altitude=500 --heading=0 --model-hz=60 --disable-random-objects --prop:/sim/rendering/texture-compression=off --prop:/sim/rendering/quality-level=0 --prop:/sim/rendering/shaders/quality-level=0 --disable-ai-traffic --prop:/sim/ai/enabled=0 --aircraft=ufo --disable-sound --prop:/sim/rendering/random-vegetation=0 --prop:/sim/rendering/random-buildings=0 --disable-specular-highlight --disable-ai-models --disable-clouds --disable-clouds3d --fog-fastest --visibility=5000 --disable-distance-attenuation --disable-enhanced-lighting --disable-real-weather-fetch --prop:/sim/rendering/particles=0 --prop:/sim/rendering/multi-sample-buffers=1 --prop:/sim/rendering/multi-samples=2
</pre>
Double-click the batch file to start FlightGear.

Using these settings, frame rates between 400-500 fps and a steady frame spacing (latency) of 3-11 ms, can be achieved on a notebook from 2007 (1024x768). Disabling wireframe mode lowers the framerate by about 50-80 fps. The window should be up and running (fully initialized) within 3-5 seconds, even on moderately old hardware (absent a navcache rebuild).

[[File:Fgfs28-bare-bones.png|thumb |FlightGear 2.10 bare bones on 2006-era hardware (NVIDIA 7600GO)]]
[[File:Screen shot minimal startup profile without textures 2.12.png|thumb |FG 2.12 zero eyecandy mode on 2009-era hardware (NVIDIA 260M)]]
[[File:Screen shot minimal startup profile with textures in 2.12.png|thumb |FG 2.12 minimal eye candy mode on 2009-era hardware (NVIDIA 260M)]]

As can be seen, additional resources can be freed by flying in areas without scenery (ocean tiles), by using simple aircraft like the ufo, and by using a HUD instead of a 2D/3D cockpit panel.



=== Reporting incompatible default settings ===
Once you have located and identified settings that seem to cause reproducible issues with your hardware, it would be a good idea to report these settings using the issue tracker, so that these can hopefully be made optional in the upcoming release: http://flightgear-bugs.googlecode.com/

=== Tracking RAM utilization ===
[[File:Fg-3.2-minimal-settings.png|400px|Screen shot showing FlightGear 3.2 using the minimal startup profile with frame spacing and frame counter displayed.]]

{{WIP}}

{{FGCquote
|My measurements (below) suggest that terrain mesh (as loaded at "bare" 
LOD) is the dominant memory user, with only small contributions from the 
aircraft, terrain textures, and random objects/trees/buildings.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32445574/
|title=<nowiki>Re: [Flightgear-devel] Memory consumption reduction</nowiki>
|author=<nowiki>Rebecca N. Palmer</nowiki>
|date=<nowiki>2014-06-11</nowiki>
}}
}}

{{FGCquote
|In Ubuntu 64-bit, measured using System Monitor after it stabilizes (~1min) 
Except as stated, c172p stationary on KSFO 28R, night, Terrasync 
scenery, default settings (regional textures, LOD range 1500/9000/30000) 
baseline: 2.3-2.4GB 
Changing shader effects level or enabling/disabling random 
objects/trees/buildings: no significant change 
Global texture set: 2.2GB 
DDS texture set: 2.2GB 
Global texture set, no Textures.high: 2.1GB (and some missing effects 
textures, as they don't have the "try Textures.high first, then 
Textures" fallback mechanism) 
LOD range 1500/9000/10000: 1.4GB 
LOD range 1500/2000/30000: 2.3GB 
LOD range 500/9000/30000: 2.3GB 
1.0 scenery (from flightgear-data 3.0 due to above issue): 1.1GB 
Ocean location: 0.75GB 
F-14: 2.1GB 
777-200: 2.6GB 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32445574/
|title=<nowiki>Re: [Flightgear-devel] Memory consumption reduction</nowiki>
|author=<nowiki>Rebecca N. Palmer</nowiki>
|date=<nowiki>2014-06-11</nowiki>
}}
}}

[[File:Fg-3.2-RAM-utilization-in-minimal-mode.png|right|500px|htop showing FlightGear 3.2 RAM utilization when in minimal startup mode]]

== Further assistance ==
If you need help with the whole process, please get in touch via the FG forums.

When doing that, please fully document the whole process, i.e. including:

* startup settings (and fgfsrc if used)
* error messages and warnings (console output)
* screen shots
* screen shots showing frame rate, frame spacing, performance monitor, osg on-screen stats (see [[Howto:Use the system monitor]] )
* use the about dialog to provide other important information

== Troubleshooting Performance Issues ==

If you're able to build from source and don't mind using development looks like the built-in profiler, it would be interesting to see comparison of both builds - ideally using a simple test case with everything else disabled - you could use a pre-recorded flight and/or a flight recorder type to come up with a "test flight". From our standpoint, it would help tremendously if all features that don't seem to have an effect could be completely disabled, including complex aircraft and scenery/locations. In other words, if you can reproduce the problem using "bare" minimum settings, the resulting log file will be much easier to process.

There's a built-in profiler which you can use to create these profiles: http://wiki.flightgear.org/Built-in_Profiler
You would then want to use two different build directories, where SG/FG build settings would be identical, but using an older version of OSG: http://wiki.flightgear.org/Building_using_CMake#Multiple_build_directories

For the sake of simplicity there's a so called "minimal startup profile" that you can use: http://wiki.flightgear.org/Howto:Debugging_FlightGear_Crashes#Minimal_startup_profile
While unlikely, it would be great if the issue could be reproduced that way - but more likely than not, you'll have to re-add a few features and change a few settings, e.g. by using a different location.

Like I said, you could then use the replay system to create an test flight than can be easily reproduced - to get going more quickly, you can also use the built-in route manager to create a simple flight plan and fly the whole thing on autopilot: http://wiki.flightgear.org/Instant_Replay

You can use time warp mode to speed up simulation time and finish more quickly.

Admittedly, all this may seem a bit intimidating and tedious, but once you have such a setup working, you can reuse it over and over again for different startup profiles and provide profiling logs for each.
We do have a number of people interested in adding features to support benchmarking/profiling workflows natively:

http://wiki.flightgear.org/FlightGear_Benchmark
http://wiki.flightgear.org/Testing

If that's something you'd like to pursue, feel free to get in touch - it is definitely a worthwhile thing, even regardless of any OSG specific issues, as it will also help with unrelated performance issues.
Obviously, there's a bit of a steep learning curve involved, which is why it's normally only core developers that build multiple versions against different OSG versions and run the profiler.
But once you are able to build from source, you have already completed the most difficult step - everything else is fairly straightforward in comparison - as as you can probably tell, creating test flights using the route manager and/or flight recorder also isn't exactly rocket science.

However, before you do anything, I'd suggest to check first if you've possibly changed your driver, or if you can install a newer version

== Debugging Segfaults & Obtaining Backtraces ==
{{Note|This section is currently Linux/gdb specific. Any help in updating it to become less platform/OS/debugger-specific would be greatly appreciated!}}

A '''segfault''' is another word for "crash", it's a so called "segmentation fault", where the program is doing things that it wasn't designed to do, such as accessing invalid memory for example, so that the operating system will terminate the process because its behavior is no longer valid/correct. These '''segfaults''' will typically happen due to coding errors, either in FlightGear or one of its dependencies (libraries like SimGear, plib, OpenSceneGraph or OpenAL).

A typical segfault may look like this:
<syntaxhighlight lang="text">
Initializing splash screen
Splash screen progress init
Tungsten Graphics, Inc.
Mesa DRI R200 (RV250 4C66) x86/MMX/SSE2 TCL DRI2
1.3 Mesa 9.1.1

Program received signal SIGSEGV, Segmentation fault.
0xb71467e6 in __strlen_sse2_bsf () from /usr/lib/libc.so.6
</syntaxhighlight>

The last two lines are basically showing the actual crash, anything shown earlier is normally just an indicator how far the code could proceed shortly before the crash actually occurred.

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

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

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

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

Unfortunately, logging all this data by default has a certain run-time overhead and requires additional tools and knowledge, so it is usually too costly and not done, FlightGear will by default be heavily optimized by your compiler and not include code logging important debugging/post-crash parameters, for the sake of better performance.
.
However, as developers, we do appreciate all efforts to provide meaningful bug reports, and a reproducible bug including a good crash analysis, i.e. a so called '''backtrace''' is as good as it gets, and the likelihood of a certain bug being examined and fixed is significantly higher when the bug report includes both, a '''backtrace''', and a set of steps to reproduce the error reliably.

A good way to to provide a reproducible test case is using the [[Replay]]/flight recorder system to create a flight recorder tape that triggers the crash, alternatively, consider providing a "flight plan" that triggers the crash - ideally, without it being aircraft specific, i.e. reproducible using aircraft like the ufo

Thus, you'll want to reconfigure your SimGear/FlightGear ($SG_SRC & $FG_SRC) source trees using the '''-CMAKE_BUILD_TYPE=RelWithDebInfo''' switch, for details please refer to: [[Building using CMake#Debug_Builds]]. It is a good idea not to touch your existing build trees for this, but instead create an additional directory hierarchy for your debugging binary, please see [[Building using CMake#Multiple build directories]] for details.

Once you have rebuilt and relinked SimGear and FlightGear, you'll want to use a debugger like '''gdb''' to run your new binary. It does help to have a good way to reproduce a crash, such as using certain startup/runtime settings. For the sake of simplicity it is usually a good idea to disable all unrelated features and subsystems/settings, this includes complex aircraft and complex scenery locations (airports) if possible. For details, refer to the minimal startup profile detailed in this article.

# For gdb to be available, you'll normally have to use your package manager (apt, yum, yast etc) and install the "gdb" package first.
# next, you'd navigate to your build directory where your '''fgfs''' debug binary is located
# you'd then, run gdb
# via the gdb shell, you can specify the file to be used via '''file src/Main/fgfs'''
# this will preload the binary and its dependencies
# to actually run the file, you would use the '''run''' command
# you'll normally want to pass arguments right behind '''run''', especially the mandatory ones (i.e. to specify $FG_ROOT)
# creating a simple .[[Fgfsrc]] file helps for the sake of simplicity
# once the segfault/crash occurs, you'll want to run '''backtrace''' (with '''bt''' being the shorter equivalent)
# only if that isn't conclusive, use '''thread apply all bt full''' instead to get a full backtrace for all threads (background tasks)
# please use the issue tracker to post your backtrace

This is what a typical backtrace may look like:

<syntaxhighlight lang="gdb">(gdb) thread apply all bt

Thread 1 (Thread 0xb66c4740 (LWP 10908)):
#0 0xb71467e6 in __strlen_sse2_bsf () from /usr/lib/libc.so.6
#1 0x0886c080 in copy_string (s=s@entry=0x0)
at /home/cesar/compilation/pkg/simgear/2.10.0/src/simgear-2.10.0/simgear/props/props.cxx:161
#2 0x08870550 in set_string (val=0x0, this=0x8dd55b8)
at /home/cesar/compilation/pkg/simgear/2.10.0/src/simgear-2.10.0/simgear/props/props.cxx:524
#3 SGPropertyNode::setStringValue (this=0x8dd55b8, value=0x0)
at /home/cesar/compilation/pkg/simgear/2.10.0/src/simgear-2.10.0/simgear/props/props.cxx:1587
#4 0x08326ae1 in (anonymous namespace)::GeneralInitOperation::run (this=0x8bdea48, gc=0x8be4310)
at /home/cesar/compilation/pkg/flightgear/2.10.0/src/flightgear-2.10.0/src/GUI/gui.cxx:123
#5 0x085c2b7b in flightgear::GraphicsContextOperation::operator() (this=0x8bdea48, gc=0x8be4310)
at /home/cesar/compilation/pkg/flightgear/2.10.0/src/flightgear-2.10.0/src/Viewer/WindowSystemAdapter.cxx:41
#6 0xb78ca246 in osg::GraphicsOperation::operator()(osg::Object*) () from /usr/lib/libosg.so.80
#7 0xb78c7784 in osg::GraphicsContext::runOperations() () from /usr/lib/libosg.so.80
#8 0xb7b29fe2 in osgViewer::ViewerBase::renderingTraversals() () from /usr/lib/libosgViewer.so.80
#9 0xb7b2707c in osgViewer::ViewerBase::frame(double) () from /usr/lib/libosgViewer.so.80
#10 0x085c4841 in fgOSMainLoop ()
at /home/cesar/compilation/pkg/flightgear/2.10.0/src/flightgear-2.10.0/src/Viewer/fg_os_osgviewer.cxx:286
#11 0x082221fa in fgMainInit (argc=32, argv=0xbffff494)
at /home/cesar/compilation/pkg/flightgear/2.10.0/src/flightgear-2.10.0/src/Main/main.cxx:339
#12 0x081e71ee in main (argc=32, argv=0xbffff494)
at /home/cesar/compilation/pkg/flightgear/2.10.0/src/flightgear-2.10.0/src/Main/bootstrap.cxx:251
</syntaxhighlight>

As can be seen, the first few lines basically show exactly what happened, and where it happened, while all the subsequent lines are basically showing the callgraph, i.e. how the piece of code got triggered. For example, FlightGear started in bootstrap.cxx line 251, then called into main.cxx (line 339), at which point the osgviewer setup took place. Next, there are a few lines that do not contain a lot of interesting info, because those are all library calls into OSG - things are starting to be interesting again around line #5, where FlightGear specific code is getting called again. As can be seen in this particular example, the actual segfault was triggered in a SimGear operation here, which was due to a NULL pointer.

At first, this may look a bit confusing and even intimidating, but it does make sense to people familiar with C++ and FlightGear/SimGear - so even if you cannot understand a single thing, just post such output on the issue tracker, so that others can have a look. We'll ask for additional information if necessary.

However, at times it may be nearly impossible to see what actually goes in in FG these days simply because there's too many disparate parts involved here. For example, in the rare instance that our [[Nasal]] scripting interpreter could lead to a segfault, we could potentially see where the C code was using a debugger like gdb – but that wouldn't tell us where we were in the Nasal code.

And that similarly applies to many things, especially things that "jump" boundaries here. Another prime example is property tree listeners - Nasal listeners don't have a backtrace beyond the C code, even if it is triggered directly from a Nasal setprop()/.setValue(), because it passes through C and C++ stack frames and then back into Nasal.

Thus, valgrind/gdb/cachegrind/perftools may be too low-level to be meaningful in most cases, i.e. just look at what's going on in the scenery/aircraft department, here just identifying "hot spots" in terms of code/functions would be a red herring, because the real culprit is typically not at all in the run-time code, but the underlying scenegraph data, such as highly complex textures, 3D models or terrain/scenery.

This can now be easily verified by using Zakalawe's new draw-masks to switch off aircraft/scenery/clouds or AI model rendering.

Having acess to gdb/valgrind etc is one thing, being able to actually run and interpret the results is a completely different thing.

Thus, it is more promising -in the long term- to optionally expose certain info at run-time, so that users can access it to see how their aircraft/scenery/feature/configuration behaves in comparison to some other aircraft/scenery/feature/configuration.

Also, when it comes to using tools like gdb -and especially valgrind- the main challenge is that FlightGear is primarily a GUI application, and it doesn't lend itself it being debugged/profiled or leak-tested in an isolated fashion at all.

For example, for valgrind runs to be useful and straightforward, we would need to be able to minimize what's done inside fg_init.cxx so that we can disable things not needed, but also even run FlightGear in a [[FlightGear Headless|"headless" mode]] without a visible GUI window, so that such tests could be run directly on the build server as part of a regression testing suite. Otherwise, even just running fgfs in valgrind for 10 minutes sim time may turn out to take hours due to the nature of valgrind, i.e. it being an emulator.

valgrind et all are great if you know how to use them, but for end users, these tools are too fine-grained, we would ideally support some per-subsystem or per-feature granularity for end users.

== Using AddressSanitizer ==
{{FGCquote
|AddressSanitizer does a similar job to Valgrind with less overhead 
(~2.5x memory use, and nearly full speed), but requires recompiling; I 
haven't seen the crash under it yet (or at all today), if anyone does 
please post your log.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32749837/
|title=<nowiki>Re: [Flightgear-devel] crash in SGPropertyNode::fireValueChanged</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-08-22</nowiki>
}}
}}

<syntaxhighlight lang="bash">
#this is for Linux with llvm-3.4, libsqlite3-dev, flite1-dev, libhtsengine-dev; it will probably work on Mac (with possibly different ASAN_SYMBOLIZER_PATH) but not Windows

#simgear
cmake ../../git/simgear -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_C_FLAGS="-fsanitize=address -fno-omit-frame-pointer -O2 -g"
-DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer -O2 -g"
-DCMAKE_SHARED_LINKER_FLAGS="-fsanitize=address -fno-omit-frame-pointer
-O2 -g" -DCMAKE_VERBOSE_MAKEFILE=1 -DSIMGEAR_SHARED=ON
make
sudo make install

#flightgear
cmake ../../git/flightgear -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_C_FLAGS="-fsanitize=address -fno-omit-frame-pointer -O2 -g"
-DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer -O2 -g"
-DCMAKE_VERBOSE_MAKEFILE=1 -DSIMGEAR_SHARED=ON -DENABLE_IAX=OFF
-DENABLE_FGCOM=OFF -DSYSTEM_SQLITE=ON
make
sudo make install

#run
ASAN_SYMBOLIZER_PATH=/usr/lib/llvm-3.4/bin/llvm-symbolizer
ASAN_OPTIONS="symbolize=1 alloc_dealloc_mismatch=0" fgfs [options] 2>
asan_log.txt

#post asan_log.txt to developers mailing list and/or the issue tracker
</syntaxhighlight>

== The original idea and future developments ==
Our hope is that we can come up with a fairly safe subset of FlightGear settings that should work for 99% of our users, even on moderately old hardware. This would enable us to change the FlightGear defaults accordingly, and use these settings as a safe fallback alternative - so that FlightGear should no longer just crash for people without certain hardware/features.

There's a trend to expose more and more information via the property tree, to make the simulator increasingly runtime-configurable, and to allow subsystems to be re-initialized at runtime, so being able to start up FlightGear in some form of "safe" mode is generally a good thing and useful for anybody helping with troubleshooting on the forums, because it helps us exclude many potential problems. In the long run, such a profile could also be used as the foundation for a [[FlightGear Benchmark]] or some scripted regression suite to run FlightGear in a [[FlightGear Headless|headless]] mode to help with release preparations, and [[FGCanvas]].

== Related ==
* http://flightgear.org/forums/viewtopic.php?f=37&t=17199&p=165503#p163684
* [[System Crashes]]
* [[Hardware Recommendations]]
* [[Troubleshooting performance issues]]
* [[Problematic Video Cards]]

[[Category:Howto|Debugging FlightGear Crashes]]
[[Category:Troubleshooting]]

Command line options

2018-08-09T15:10:11Z

Wkitty42: /* General Options */ example for --prop

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:foo=bar Set property named "foo" to value "bar"
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:08:10Z

Wkitty42: /* General Options */ enable-fullscreen and disable-fullscreen are in Rendering Options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:05:42Z

Wkitty42: /* Flight Model */ wind, turbulence and ceiling are in Environment Options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:03:45Z

Wkitty42: /* Debugging Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:03:29Z

Wkitty42: /* Situation Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:03:14Z

Wkitty42: /* Environment Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:02:31Z

Wkitty42: /* Avionics Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch
Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:02:12Z

Wkitty42: /* IO Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch
Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:01:42Z

Wkitty42: /* Route/Way Point Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch
Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:01:30Z

Wkitty42: /* MultiPlayer Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch
Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:01:16Z

Wkitty42: /* Network Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch
Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:01:04Z

Wkitty42: /* Time Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch
Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:00:35Z

Wkitty42: /* Hud Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch
Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]

Command line options

2018-08-09T15:00:21Z

Wkitty42: /* Rendering Options */ alignment with other options

'''Command line options''' are a common way to tell applications what to do/how to act on startup. With [[FlightGear]] they are used for many things, from simple ones like selecting an aircraft up to complex stuff like network traffic and weather parameters.

The easiest way to handle those options for FlightGear is using a tool with a graphical user interface like the [[FlightGear Qt launcher]]. This way one doesn't have to bother about them at all.

However, there are users who don't want or are not able to run a GUI and therefore are interested in this. Those who need them or just want to learn more about FlightGear, but have no idea what we are talking about, may read the wiki page on the general usage of the [[command line]].

A good place to store the personal options is a file called [[fgfsrc]]. This file is read by FlightGear on each startup.

The following lists show the options for FlightGear including a short description and sorted by categories. Please have in mind that keeping those lists up to date on the wiki is not an easy task. Also there are different versions of FlightGear out there which don't share exactly the same options. Therefore you better also check your versions ones with <code>fgfs --help --verbose</code>. If this command fails, you may add the option <code>--fg-root=[path]</code> as well, see below.

It is sad but true, not even this command is, at least in Git, up to date all the time. At the time of writing at least one option which is supported is not shown with <code>fgfs --help --verbose</code>. So if you have serious issues with an option, the source code is, as always, also the best source for info. In the file ''src/Main/options.cxx'' all the options are listed with their hard coded ''default'' setting and type.

The file [[$FG_ROOT]]/options.xml is used to generate the output for <code>fgfs --help [--verbose]</code>. That's the reason why <code>--fg-root=[path]</code> has to be added to this, if it is not set as environmental variable or as option in fgfsrc.

Usage: <code>fgfs [OPTION [OPTION ...]]</code>

==== General Options ====

--help, -h Show the most relevant command line options
--verbose, -v Show all command line options when combined with --help or -h
--fg-root=path Specify the root data path
--fg-scenery=path[:path...] Specify the base scenery path;
Defaults to [[$FG_ROOT]]/Scenery
--language=code Select the language for this session
--launcher Enable Qt launcher
--disable-fullscreen Disable full-screen game mode
--enable-fullscreen Enable full-screen game mode
--disable-splash-screen Disable splash screen
--enable-splash-screen Enable splash screen
--disable-mouse-pointer Disable extra mouse pointer
--enable-mouse-pointer Enable extra mouse pointer
(i.e. for full screen Voodoo based cards)
--disable-random-objects Exclude random scenery objects
(buildings, etc.)
--enable-random-objects Include random scenery objects
(buildings, etc.)
--disable-ai-models Disable the AI subsystem.
(This also disables showing the models of other
multiplayer aircraft)
--enable-ai-models Enable the AI subsystem.
--disable-ai-traffic Disable the autogenerated traffic subsystem.
--enable-ai-traffic Enable the autogenerated traffic subsystem.
--disable-freeze Start in a running state
--enable-freeze Start in a frozen state
--disable-fuel-freeze Fuel is consumed normally
--enable-fuel-freeze Fuel tank quantity forced to remain constant
--disable-clock-freeze Clock advances normally
--enable-clock-freeze Do not advance clock
--enable-auto-coordination Enable auto coordination - rudder and
ailerons will be controlled together
--disable-auto-coordination Disable auto coordination (default)
--browser-app=path Specify path to your web browser
--prop:name=value Set property to
--config=path Load additional properties from path
--units-feet Use feet for distances
--units-meters Use meters for distances

==== Features ====

--disable-panel Disable instrument panel
--enable-panel Enable instrument panel
--disable-sound Disable sound effects
--enable-sound Enable sound effects
--disable-hud Disable Heads Up Display (HUD)
--enable-hud Enable Heads Up Display (HUD)
--disable-anti-alias-hud Disable anti-aliased HUD
--enable-anti-alias-hud Enable anti-aliased HUD
--disable-hud-3d Disable 3D HUD
--enable-hud-3d Enable 3D HUD
--ai-scenario=scenario Add and enable a new scenario. Multiple options
are allowed. Scenarios are in /[[$FG_ROOT]]/AI/.

==== Aircraft ====

--aircraft=name Select an aircraft profile as defined by a top
level -set.xml
--aircraft-dir=path Specify the exact directory to use for the
aircraft (normally not required, but may be
useful). Interpreted relatively to the
current directory. Causes the <path-cache>
from autosave_X_Y.xml, as well as
--fg-aircraft options and the FG_AIRCRAFT
environment variable to be bypassed.
--show-aircraft Print a list of the currently available
aircraft types

==== Flight Model ====

--fdm=name Select the core flight dynamics model
Can be one of jsb, larcsim, yasim, magic,
balloon, ada, external, or null
--aero=name Select aircraft aerodynamics model to load
--model-hz=n Run the FDM this rate (iterations per second)
--speed=n Run the FDM 'n' times faster than real time
--notrim Do NOT attempt to trim the model
(only with fdm=jsbsim)
--on-ground Start at ground level (default)
--in-air Start in air (implied when using --altitude)
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).

==== Initial Position and Orientation ====

--airport=ID Specify airport (e.g. KOAK)
--runway=rwy_no Specify starting runway (must also specify an
airport)
--vor=ID Specify starting position relative to a VOR
--ndb=ID Specify starting position relative to an NDB
--fix=ID Specify starting position relative to a fix
--parkpos=NAME Specify a gate at the airport (e.g. 747d11)
--offset-distance=nm Specify distance to reference point (statute
miles)
--offset-azimuth=degrees Specify heading to reference point
--lon=degrees Starting longitude (west = -)
--lat=degrees Starting latitude (south = -)
--altitude=value Starting altitude
(in feet unless --units-meters specified)
--heading=degrees Specify heading (yaw) angle (Psi)
--roll=degrees Specify roll angle (Phi)
--pitch=degrees Specify pitch angle (Theta)
--uBody=units_per_sec Specify velocity along the body X axis
(in feet unless --units-meters specified)
--vBody=units_per_sec Specify velocity along the body Y axis
(in feet unless --units-meters specified)
--wBody=units_per_sec Specify velocity along the body Z axis
(in feet unless --units-meters specified)
--vc=knots Specify initial airspeed
--mach=num Specify initial mach number
--glideslope=degrees Specify flight path angle (can be positive)
--roc=fpm Specify initial climb rate (can be negative)

==== Rendering Options ====

--bpp=depth Specify the bits per pixel
--fog-disable Disable fog/haze
--fog-fastest Enable fastest fog/haze
--fog-nicest Enable nicest fog/haze
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--disable-enhanced-lighting Disable enhanced runway lighting
--enable-enhanced-lighting Enable enhanced runway lighting
--season=winter Enable snow covered scenery
--disable-distance-attenuation
Disable runway light distance attenuation
--enable-distance-attenuation
Enable runway light distance attenuation
--disable-specular-highlight
Disable specular reflections on textured
objects
--enable-specular-highlight Enable specular reflections on textured objects
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--fov=degrees Specify field of view angle
--disable-fullscreen Disable fullscreen mode
--enable-fullscreen Enable fullscreen mode
--shading-flat Enable flat shading
--shading-smooth Enable smooth shading
--disable-wireframe Disable wireframe drawing mode
--enable-wireframe Enable wireframe drawing mode
--geometry=WxH Specify window geometry (640x480, etc)
--view-offset=value Specify the default forward view direction as
an offset from straight ahead. Allowable values
are LEFT, RIGHT, CENTER, or a specific number
in degrees
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--texture-filtering=number Specify anisotropic filtering of terrain textures. Valid values is 1, 2, 4, 8, 16. Default is 1.

==== Hud Options ====

--hud-tris Hud displays number of triangles rendered
--hud-culled Hud displays percentage of triangles culled

==== Time Options ====

--timeofday={dawn,noon,dusk,midnight}
Specify a time of day
--time-offset=[+-]hh:mm:ss Add this time offset
--time-match-real Synchronize time with current time at chosen airport
--time-match-local Synchronize time with system time of computer
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time

==== Network Options ====

--httpd=port Enable http server on the specified port
--telnet=port Enable telnet server on the specified port
--jpg-httpd=port Enable screen shot http server on the specified
port

==== MultiPlayer Options ====

--callsign assign a unique name to a player
--multiplay={in|out},hz,address,port
Specify multipilot communication settings
multiple instances can be used

==== Route/Way Point Options ====

--wp=ID[@alt] Specify a waypoint for the GC autopilot;
multiple instances can be used
--flight-plan=file Read all waypoints from a file

==== IO Options ====

--generic=params Open connection using a predefined
communication interface and a preselected
communication protocol
--garmin=params Open connection using the Garmin GPS protocol
--joyclient=params Open connection to an Agwagon joystick
--jsclient=params Open connection to a remote joystick
--native-ctrls=params Open connection using the FG Native Controls
protocol
--native-fdm=params Open connection using the FG Native FDM
protocol
--native=params Open connection using the FG Native protocol
--nmea=params Open connection using the NMEA protocol
--opengc=params Open connection using the OpenGC protocol
--props=params Open connection using the interactive property
manager (LEGACY/DEAD DO NOT USE same as --telnet)
--pve=params Open connection using the PVE protocol
--ray=params Open connection using the Ray Woodworth motion
chair protocol
--rul=params Open connection using the RUL protocol
--atc610x Enable atc610x interface

Under Windows, you must use a special escape sequence if you need to specify a COM port higher than 9.

Example: --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

This is per the Microsoft KB article here: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Avionics Options ====

--com1=frequency Set the COM1 radio frequency.
--com2=frequency Set the COM2 radio frequency.
--nav1=[radial:]frequency Set the NAV1 radio frequency, optionally
preceded by a radial.
--nav2=[radial:]frequency Set the NAV2 radio frequency, optionally
preceded by a radial.
--adf=[rotation:]frequency Set the ADF radio frequency, optionally
preceded by a card rotation.
--dme={nav1|nav2|frequency} Slave the ADF to one of the NAV radios, or set
its internal frequency.

==== Environment Options ====

--disable-real-weather-fetch
Disable METAR based real weather fetching
--enable-real-weather-fetch Enable METAR based real weather fetching (this
requires an open internet connection)
--disable-horizon-effect Disable celestial body growth illusion near the
horizon
--enable-horizon-effect Enable celestial body growth illusion near the
horizon
--enable-clouds Enable 2D (flat) cloud layers
--disable-clouds Disable 2D (flat) cloud layers
--enable-clouds3d Enable 3D (volumetric) cloud layers
--disable-clouds3d Disable 3D (volumetric) cloud layers
--visibility=meters Specify initial visibility
--visibility-miles=miles Specify initial visibility in miles
--wind=DIR@SPEED Specify wind coming from DIR (degrees) at SPEED
(knots)
--turbulence=0.0 to 1.0 Specify turbulence from 0.0 (calm) to 1.0
(severe)
--ceiling=FT_ASL[:THICKNESS_FT]
Create an overcast ceiling, optionally with a
specific thickness (defaults to 2000 ft).
--random-wind
--metar="metar string" Starts with a certain METAR string. Only works if live weather is disabled.

==== Situation Options ====

--failure={pitot|static|system|vacuum}
Fail the pitot, static, vacuum, or electrical
system (repeat the option for multiple system
failures).

==== Debugging Options ====

--log-level={bulk|debug|info|warn|alert}
Set the logging level for this session.
0=verbose, 5=alerts only
--pid=/pathto/some/file.pid Write current PID into file.
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

== Related content ==
=== Wiki articles ===
* [[Command line]]

=== Source files ===
* {{fgdata file|options.xml}}
* {{flightgear file|src/Main/options.hxx}}
* {{flightgear file|src/Main/options.cxx}}

[[Category:Lists]]

[[de:Command Line Options]]
[[fr:Options de ligne de commande]]