FlightGear wiki - User contributions [en]

FlightGear Newsletter April 2026

2026-04-21T01:38:51Z

SammySkycrafts: Add info about WS3 only on next

{{User:Skybike/Template:Newsletter-header-translate|2026-04}}
{{TOC_right|limit=2}}
''We would like to emphasize that the monthly newsletter cannot live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

''The new Visual Editor makes editing the wiki as simple as using a Word-processor, and even easier than using the forum as you don't even need to know the syntax for a url. Just hit the 'edit' link and start.''

== Development news ==


You can now report and track FGAddon (launcher) aircraft bugs over in the "Aircraft Issues" project, on the FlightGear bug tracker! If there is already an existing bug tracker or repository for an aircraft, we would prefer if issues were reported there instead. But if you are in doubt, create an issue and we can triage it and forward it on to the appropriate place, if that is not the FGAddon tracker. A link to the bug tracker can be found on the left of every wiki page, and at the top of every forum page. If you have a spare hour or 2, and fancy getting involved, we would love for you to come on over, choose an issue, and have a crack at fixing it!

<code>next</code>, the development branch of FlightGear has moved exclusively to WS3. This marks a huge step in the transition and development of the new terrain model known as [[World Scenery 3.0|World Scenery 3]].<ref>{{Cite web/link|link=https://sourceforge.net/p/flightgear/mailman/message/59318483/|label=[Flightgear-devel] next now WS3.0 only, 2026-04-06 19:08:31}}</ref>




== In the hangar ==









== Scenery corner ==




















== Community news ==









== Multiplayer events ==









== Screenshot of the Month ==

If you want to participate in the screenshot contest, you can submit your candidate to the {{forum link|title=this|f=88|t=}}. Be sure to see the first post for participation rules. For purposes of convenience and organization, at the end of the month or after 20 entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there.

{{Appendix}}

[[Category:Changes after 2024.1]]
[[Category:FlightGear Newsletter|2026 04]]

FlightGear Newsletter April 2026

2026-04-21T01:33:18Z

SammySkycrafts: Newsletter creation, automatic preload from here

{{User:Skybike/Template:Newsletter-header-translate|2026-04}}
{{TOC_right|limit=2}}
''We would like to emphasize that the monthly newsletter cannot live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

''The new Visual Editor makes editing the wiki as simple as using a Word-processor, and even easier than using the forum as you don't even need to know the syntax for a url. Just hit the 'edit' link and start.''

== Development news ==


You can now report and track FGAddon (launcher) aircraft bugs over in the "Aircraft Issues" project, on the FlightGear bug tracker! If there is already an existing bug tracker or repository for an aircraft, we would prefer if issues were reported there instead. But if you are in doubt, create an issue and we can triage it and forward it on to the appropriate place, if that is not the FGAddon tracker. A link to the bug tracker can be found on the left of every wiki page, and at the top of every forum page. If you have a spare hour or 2, and fancy getting involved, we would love for you to come on over, choose an issue, and have a crack at fixing it!




== In the hangar ==









== Scenery corner ==




















== Community news ==









== Multiplayer events ==









== Screenshot of the Month ==

If you want to participate in the screenshot contest, you can submit your candidate to the {{forum link|title=this|f=88|t=}}. Be sure to see the first post for participation rules. For purposes of convenience and organization, at the end of the month or after 20 entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there.

{{Appendix}}

[[Category:Changes after 2024.1]]
[[Category:FlightGear Newsletter|2026 04]]

User:Skybike/Template:This months newsletter/Newsletter example

2026-04-21T01:32:04Z

SammySkycrafts: Add mention of FGAddon Aircraft Bug Tracker, located in the FG Gitlab.

<noinclude>{{Informative template|1=
{{See also|User:Skybike/Template:This months newsletter}}
'''This''' is the right place for permanent changes to the newsletter structure and default segments. Don't hesitate to make your changes or even shorten it.
 

Due to the [[User:Skybike/Template:This months newsletter|<nowiki>{{This months newsletter}}</nowiki>]] template it is no longer necessary to copy-paste an old newsletter and change the dates manually. The newsletter header supports to (pre)load '''this draft page''' automatically during creation of a new newsletter. Next to the newsletter header you can use one of these "Create Newsletter..." links below.
 

Links to create newsletters: {{User:Skybike/Template:This months newsletter|date=now}}, {{User:Skybike/Template:This months newsletter|date=next month}}, {{User:Skybike/Template:This months newsletter|date=+2 months}},
 

<big>Parameters for this draft</big>{{-}}
The following $-parameters will be replaced during preload process:
* '''$1''' for month (01,02,...12)
* '''$2''' for Year (like {{#time: Y | now}}).
* '''$3''' for current release ({{current release|cr}}) based on {{tl|current release|cr}}.

The [https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions##time time function] supports more precise dates, like
*<code><nowiki>{{#time: form |date |lang=xx}}</nowiki></code> form is like F=FullMonthname and Y=Year, see below
*<code><nowiki>{{#time: F Y |$2-$1}}</nowiki></code> for "''{{#time: F Y |{{CURRENTYEAR}}-{{CURRENTMONTH}}}}''"
 
*Use <nowiki><noin</nowiki>clude<nowiki>> </noin</nowiki>clude> for notes to get ignored when preloading this draft into new newsletters (this template description).
*Use <nowiki><includ</nowiki>eonl<nowiki>y> <includeo</nowiki>nly> for elements to not show up here but in a newsletter. (like Categories)
 
<big>Note to Translators</big>{{-}}
The newsletter system fully supports translations. Currently there is only German but feel free to to add your language here.
* [[User:Skybike/Template:This months newsletter/De/Newslettervorlage|German]]
You would need to add your translation into [[User:Skybike/Template:This months newsletter|This months newsletter]], [[User:Skybike/Template:Newsletter-header-translate|Newsletter-header-translate]] and create new versions of this draft as well as [[FlightGear Newsletter]].

}}</noinclude>{{User:Skybike/Template:Newsletter-header-translate|<includeonly>$2-$1</includeonly>}}
{{TOC_right|limit=2}}
''We would like to emphasize that the monthly newsletter cannot live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

''The new Visual Editor makes editing the wiki as simple as using a Word-processor, and even easier than using the forum as you don't even need to know the syntax for a url. Just hit the 'edit' link and start.''

== Development news ==


You can now report and track FGAddon (launcher) aircraft bugs over in the "Aircraft Issues" project, on the FlightGear bug tracker! If there is already an existing bug tracker or repository for an aircraft, we would prefer if issues were reported there instead. But if you are in doubt, create an issue and we can triage it and forward it on to the appropriate place, if that is not the FGAddon tracker. A link to the bug tracker can be found on the left of every wiki page, and at the top of every forum page. If you have a spare hour or 2, and fancy getting involved, we would love for you to come on over, choose an issue, and have a crack at fixing it!




== In the hangar ==









== Scenery corner ==




















== Community news ==









== Multiplayer events ==









== Screenshot of the Month ==

If you want to participate in the screenshot contest, you can submit your candidate to the {{forum link|title=this|f=88|t=}}. Be sure to see the first post for participation rules. For purposes of convenience and organization, at the end of the month or after 20 entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there.

{{Appendix}}

<includeonly>[[Category:Changes after $3]]</includeonly>
<includeonly>[[Category:FlightGear Newsletter|$2 $1]]</includeonly>

<includeonly></includeonly>
<noinclude>
[[Category:Newsletter templates]]
</noinclude>

FlightGear Newsletter March 2026

2026-04-21T01:26:39Z

SammySkycrafts:

{{User:Skybike/Template:Newsletter-header-translate|2026-03}}
{{TOC_right|limit=2}}
''We would like to emphasize that the monthly newsletter cannot live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

''The new Visual Editor makes editing the wiki as simple as using a Word-processor, and even easier than using the forum as you don't even need to know the syntax for a url. Just hit the 'edit' link and start.''

== Development news ==



[https://www.flightgear.org/download/releases/2024-1-5/ FlightGear 2024.1.5] has released.

You can now report and track FGAddon (launcher) aircraft bugs over in the "Aircraft Issues" project, on the FlightGear bug tracker! A link can be found on the left of every wiki page, and at the top of every forum page. If you have a spare hour or 2, and fancy getting started with aircraft development at a basic level, we would love for you to come on over, choose an issue, and have a crack at fixing it!




== In the hangar ==




==== McDonnell Douglas MD-11 ====
The [[McDonnell Douglas MD-11]] has received an improved fuel system and the SD synoptic, amongst other improvements

* Further detailed the simulation of fuel pumps
* Fuel pumps can now be individually failed resulting in appropriate consequences
* FSC now turns off and compensates for failed fuel pumps
* Simulated manifold valve between upper/lower manifolds
* Crossfeeds have been fixed, if all pumps on a tank fail, you can now feed the engine through the transfer pump to the crossfeed of the same tank/engine
* APU Start Pump logic corrected, shuts down automatically 90 seconds after AC power is available and the appropriate tank 2 pump activates
* If upper aux tank pumps fail, lower aux tank and tail tank can now feed directly into main tanks via the auxiliary fill isolation valve, preventing trapping more fuel
* Engine suction feed logic improved
* Misc minor improvements

[[File:MD-11-Fuel-Synoptic.png]]





== Scenery corner ==




















== Community news ==









== Multiplayer events ==









== Screenshot of the Month ==

If you want to participate in the screenshot contest, you can submit your candidate to the {{forum link|title=this|f=88|t=}}. Be sure to see the first post for participation rules. For purposes of convenience and organization, at the end of the month or after 20 entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there.

{{Appendix}}

[[Category:Changes after 2024.1]]
[[Category:FlightGear Newsletter|2026 03]]

Aircraft

2026-04-21T01:15:36Z

SammySkycrafts: Update wording encouraging users to use the inbuilt launcher to download aircraft rather than directly from FGAddon SVN if they do not have a need, as this is now possible in Stable builds

[[File:FlightGear Launcher Aircraft Tab.png|thumb|The FlightGear Qt launcher, showing a handful of the aircraft that are able to be downloaded or updated from the FGAddon repository.]]

This list is not updated to include all the official [[GNU General Public License|GPL licensed]] aircraft for [[FlightGear]], but gives a visual sampling of the different types of aircraft and genres of aircraft officially available.

Most models shown here are available from the official FlightGear project and can be downloaded from the FlightGear launcher, with no additional steps required for installation. Alternatively these aircraft can be obtained directly from the [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/ FGAddon SVN repository]. If the aircraft is installed manually, you will lose the ability to check for, and install updates from within the launcher. Some models shown here are available from [[FlightGear hangars|non-official hangars]].

FlightGear aircraft features, quality, and compatibility vary significantly. Their development is dependent on the [[volunteer]]s who worked on them, with exception of some University and Government funded projects. Aircraft are listed by completeness status in [[:Category:Aircraft by status]].

To edit this list, see here: [[Template:Model_Gallery]].

=== Light civilian aircraft ===
The Cessna 172 is the default aircraft in FGFS 2.0. These aircraft typically have 1-2 piston engines, props, and avionics geared towards those with civilian pilot licenses.
{{Model Gallery | section=light_civilian_aircraft}}

===Business Jets===
Smaller aircraft with 1-2 turbofan engines, usually used by businesses and private companies.
{{Model Gallery| section=business_jets}}

===Airliners===
These typically have 2-4 turbofan engines and some of the more complicated takeoff and landing procedures (such as multiple [[flaps]]).

See [[Airliner development status]] for more info.

====Narrowbody & Midsize====
{{Model Gallery| section=modern_airliners_narrowbody_midsize}}

====Widebody & Jumbo Airliners====
{{Model Gallery| section=modern_airliners_widebody_jumbo}}

===Helicopters===
{{Main article|Helicopter}}

Helicopters have fundamentally different controls than fixed wing aircraft (see ''[[Flying the Helicopter]]''). Modern helicopter typically feature 1-2 turbine engines, which power a main rotor with 2-6 blades.
{{Model Gallery| section=helicopters}}

===Gliders, Sailplanes, & Ultralights===
These typically have the simplest controls, with minimal avionics. Flying [[:Category:Gliders|gliders]] or sailplanes using [[Soaring|thermals]] can provide more complicated experience. Ultralights on the other hand are among the simplest aircraft in FG.
{{Model Gallery| section=ultra_light}}

===Warbirds===
FlightGear includes a wide variety of vintage military aircraft. Complexity and realism is typically tied to the level of development work with a specific aircraft.
{{Model Gallery| section=warbirds}}

===Carrier-borne aircraft===
FlightGear supports landing on and taking off from [[carriers]].
{{Model Gallery| section=carrier_borne_aircraft}}

===Modern military aircraft ===
FlightGear has a wide variety of modern and retired military jets available, highlighted by features such as air-to-air refueling from the venerable KC-135 and the ability to simulate A-10 ordnance release.
{{Model Gallery| section=modern_military_aircraft}}

===Historical===
Many obscure to famous older aircraft of varying quality are available.
{{Model Gallery| section=historical_aircraft}}

===Experimental & Unique===
Experimental and special purpose aircraft.
{{Model Gallery| section=experimental}}

===Lighter than air aircraft (Available from version 1.9.0)===
These aircraft take advantage of lighter than air gas to become buoyant. In addition to typical aircraft control methods such as elevator, rudder and engine throttle, ballast and control of gas volume and pressure become options.
{{Model Gallery| section=lighter_than_air}}

===Science Fiction===
Alternative models provide a diversion of realistic simulation, but can also be useful for exploring scenery.
{{Model Gallery| section=science_fiction}}

===Spacecraft===
Things that show how small our planet Earth really is.
{{Model Gallery| section=spacecraft}}

==See Also ==
*[[Howto:Make an aircraft]]
* [[How to install aircraft]]
*[[Aircraft deployment]]
*[[Airliner Development Status]]



[[it:Aerei]]

[[Category:Lists]]
[[Category:Aircraft| ]]

[[ca:Aeronau]]
[[de:Flugzeuge]]
[[es:Avión]]
[[fa:هواپیما]]
[[fi:Lentokoneet]]
[[fr:Avions]]
[[nl:Luchtvaartuigen]]
[[pl:Samoloty]]
[[pt:Avião]]
[[ru:Самолет]]
[[zh:插件飞机]]

File:FlightGear Launcher Aircraft Tab.png

2026-04-21T01:11:14Z

SammySkycrafts: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=The FlightGear Qt launcher, showing just some of the aircraft that are able to be downloaded or updated from the FGAddon repository.}}
|date=2026-04-21
|source={{own}}
|author=[[User:SammySkycrafts|Rhys Ackerman]]
|permission=
|other versions=
}}

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

Air traffic control

2026-04-21T00:59:03Z

SammySkycrafts: Re-Add "Stub" template. I feel that it was prematurely removed and the article was not expanded in any meaningful way with additional information, there was purely just formatting changes and links to other pages. There could be a lot more added here such as limitations, even linking into things like vatsim support as possible alternatives to the limited integrated fg atc

{{Stub}}

'''Air traffic control''' (ATC) is a service mostly provided by ground-based controllers who direct aircraft on the ground and in the air. The primary purpose of ATC systems worldwide is to separate aircraft to prevent collisions, to organize and expedite the flow of traffic, and to provide information and other support for pilots when able. ATC also plays a security or defence role or is run entirely by the military in some countries.

For the common phraseologies and their meanings, see [[ATC phraseology]].

== Addons related to ATC ==
* [[Spoken ATC]] allows the pilot to listen to the directives of the Air Traffic Controller.
* [[Red Griffin ATC]] is a speaking Air Traffic Controller Addon for FlightGear.

== ATC in FlightGear multi-player ==
To know if an area is controlled or booked:
* Check for announced ATC sessions on [http://flightgear-atc.alwaysdata.net/ Lenny's website].
* Check the Pilot List in FlightGear or the [[MPMap|Multiplayer map]]. Usually, controllers:
** have a callsign ''XXXX_DE'', ''XXXX_GN'', ''XXXX_TW'' or ''XXXX_AP'' (where ''XXXX'' is the ICAO code of the airport they are manning);
** generally use ''[[OpenRadar]]'' or ''[[ATC-pie]]'', which appear as aircraft models on the map, or older ''ATC-*'' named models.

=== For pilots ===
* [[ATC Tutorial]]
* [[ATC best practices#For pilots|Best practices]]
* [[SquawkGear|Connecting to Vatsim]]

=== For controllers ===
* [[ATC best practices#For controllers|Best practices]]
* "[http://flightgear-atc.alwaysdata.net Lenny's website]" is today's ''de facto'' ATC platform featuring a [[Flight_planning|flight plan]] database, tutorials and resources, software downloads, and a schedule where ATCs announce their session and let pilots know when and which airport will be controlled

Software for controlling on FlightGear:
* Standalone programs for more realistic experience: [[OpenRadar]], [[ATC-pie]]
* FG aircraft like [[ATC-FS]], an ATC model with flight strips

[[Category:Air Traffic Control]]
[[it:Controllo Traffico Aereo]]

Carrier over MP

2026-04-13T21:46:55Z

SammySkycrafts: Update Carrier over MP page to clarify correct and up to date information

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

== Installation ==
===FlightGear 2.0.0 and later===
{{Note|It is not enough that you can see carriers in AI mode. You have to have the MPCarrier package installed to be able to see multiplayer carriers}}
This can easily be accomplished by using the [[FlightGear_Qt_launcher]] and downloading the MP Carrier package. Downloading from here will also mean that you will automatically be prompted when updates to the package are available.

[[File:FlightGear FGAddon MPCarrier.png|thumb|Screenshot of the FlightGear Launcher with the MP Carrier package selected|center]]

Alternatively, you can download directly from the FGAddon SVN located at https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/MPCarrier/. You will not be prompted when updates are available if you manually download from SVN.

===FlightGear 1.9.1===
{{Caution|This section refers to a version of FlightGear released in 2009. As a result, its instructions are out of date. Please refer to the "FlightGear 2.0.0 and later" section for up to date instructions.}}
The download for the [http://www.gidenstam.org/FlightGear/misc/Carrier_over_MP/MPCarrier_fgfs1.9.1.tar.gz MPCarrier aircraft archive] is available here: http://www.gidenstam.org/FlightGear/misc/Carrier_over_MP/

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

==Commander/Captain of the Carrier==
===Starting FlightGear ===
Command the Nimitz:
% fgfs --aircraft=nimitz
Command the Eisenhower:
% fgfs --aircraft=eisenhower

(same for Clemenceau and Vinson).

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

===Commanding the Carrier ===
Here are some principal tips:
*First see the aircraft help. Press '?'.
*To change orientation and position of the carrier (apart from using the rudder and speed, but that take a long time to cross ocean :) ), you can use the properties. You need to change the properties of the ai-carrier you are driving, e.g. for the Nimitz,find the /ai/models/carrier[i] that got Nimitz as name. Use the [[Property_browser]] to do so:
** In /ai/models/carrier[i]/position/ you can change lat, and lon to put it where you want (note that specifying lon/lat on the command line or in menu "Location->Position Aircaft in Air" will not have an effect).
** In /ai/models/carrier[i]/orientation you can make it face wind. Facing wind is important (with real weather fetch) to make the FLOLS green on approach.
*Set speed using PgUp/PgDown in manual control.
*To have a better sync between the pilots using the Nimitz, consider keeping a speed of 0 so that there's no drift between pilots.

==Pilot Using the Carrier==

=== On 2024.1 and later===

Things will work without any special configuration.

Flightgear will automatically enable the appropriate matching AI scenario when an MP carrier appears.

====Latching carriers====

By default Flightgear uses Nasal to periodically change the AI carrier's velocity to make it approximately follow the MP carrier.

One can instead force the AI carrier to exactly follow the position and orientation of the MP carrier (done in C++ in each frame), by checking '''Always latch MP and AI carrier''' in the '''Multiplayer Settings''' dialogue (menu '''Multiplayer/Multiplayer Settings''').

This can work much better but requires that MP motion is smooth, e.g. by using [[Real Time manual|Real Time]] or [[Simple-time]] - see menu '''File/Time Mode'''.

For more information, see: {{flightgear file|docs-mini/README-mp-carriers.md}}

===On 2020.3 and earlier ===

NB: You need to know which callsign and which carrier model to use.

Make sure to enable the AI scenario for the corresponding carrier (e.g. nimitz_demo if the model is the Nimitz).

====From the Launcher====
The easiest way to configure your FlightGear session for an MP carrier is to use the Launcher like in the picture (the model is the Vinson and the callsign is OPFOR21 in the example). [[File:MP carrier settings in launcher.png|thumb|In the "Settings" tab under "Additional Settings" provide the necessary command-line arguments]]

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

For the Vinson it could e.g. be:
% fgfs --ai-scenario=vinson_demo --prop:/sim/mp-carriers/vinson-callsign=MP-029X --multiplay=.....

There is no need that the callsign reflects the TACAN setting - it is just a possible pattern do make it easier for others to use. There is no need to specify the --multiplay option either, if you are using the FlightGear launcher.

====Within the Session====
An alternative way to enable MP control of a carrier when on the multiplayer network use the MP carrier dialog available from Multiplayer->"MPCarrier selection" to select which MP carrier players you wish to see. A pre-requisite is that you already have the parameters set-up as per above.

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

====Important====

As a pilot you have to run by the books:
*Have the MPCarrier downloaded (The fact that you see the carrier when running AI scenarios is not enough proof that you actually have the MPCarrier. Try to find it in the aircraft dialog. If it is there, then you are good).
*You need to set the --prop:/... correct (note the carrier model name in the string before "-callsign"). This ensures that MPCarriers won't interfer with the normal AI scenarios.
*You need to have the corresponding AI scenario activated.
*In the AI scenarios you can find the carrier from 30+ nm with TACAN. In MP you might find it only from ca. 15+nm (as of 2020.1 version).

[[Category:Multiplayer]]

File:FlightGear FGAddon MPCarrier.png

2026-04-13T21:38:26Z

SammySkycrafts: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Screenshot of the FlightGear Launcher, version 2024.2 (nightly), showing 4 aircraft. The second one is highlighted, and is the MP Carrier package.}}
|date=2026-04-13
|source={{own}}
|author=[[User:SammySkycrafts|Rhys Ackerman]]
|permission=
|other versions=
}}

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

[[Category:FGAddon hangar]]

Discord

2026-04-13T13:31:09Z

SammySkycrafts: Removed A350 server. There has not been any active users with admin access for years, and the server is regularly being targeted by scam bots, whose content can not be deleted. As a result of the spam, there has also not been any content relating to a350

'''Discord''' is used in the FlightGear community as an alternative to [[Mumble]], [[TeamSpeak]], [[FGCom]] or [[Ventrilo]].

Discord is a free voice and chat software that can be downloaded as an app or [https://discord.do/web/ used in a browser].

== Invite links ==
{{note|1=Its advised that you create a permanent account, instead of creating guest accounts as some people create duplicate accounts which clogs up the member logs and makes it more difficult to @mention people.}}

Furthermore many other FlightGear servers exist that you may need an personal invite to join. The easiest way to find them is to go to the FlightGear server and ask or ask in forums.

== FlightGear Communities on Discord ==

=== General, Help and Support, Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| FlightGear
| https://discord.gg/rzuV2DR
|-
| FlightGear Community
| https://discord.gg/RyMyQA6ZDm
|-
| FlightGear FDM School
| https://discord.gg/Uyrtsar
|-
| FlightGear Virtual Alliance
| https://discord.gg/VqzTG2N
|-
| FG Events
| https://discord.gg/GY4N6Cu
|-
| FG FDM School
| https://discord.gg/U5KXyMU
|-
| FlightGear Republic, A friendly community about FlightGear.
| https://discord.gg/sBJy46Uq7z
|-
|FlightGear soaring club
|https://discord.gg/NvJjmzMfRP
|}

=== Military Aviation Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| Operation Red Flag military FG community (OPRF)
| https://discord.gg/ptVapkE
|-
| Combined Joint Task Force 50 (OPRF event planning/hosting and more)
| https://discord.gg/2nxjb6y
|-
|FIRST AIR FORCE
|https://discord.gg/firstairforce
|}

=== Country Specific Communities ===

{| class=wikitable
! Topic !! Invite link
|-
|FlightGear Australia
| [https://discord.gg/8MY6cmDQbK https://discord.gg/nG76HMDjUE]
|-
| FlightGear Italia (ITA Mercenaries)
| https://discord.gg/5RzyXRf
|-
| FlightGear Germany
| https://discord.gg/FNnpjCPSze
|-
| FlightGear Indian Community
| https://discord.gg/Tu7n5FmG5S
|-
| FlightGear Asia
| https://discord.gg/7saCkA2jQj
|-
| FlightGear Hong Kong
| https://discord.gg/9QVKcT6skU
|-
|FlightGear Myanmar
|https://discord.gg/VbT88KEGrk
|-
|[[FlightGear Polska]]
|https://discord.gg/5J7uVYRhZV
|}

=== Aircraft-specific ===
{| class="wikitable"
! Aircraft !! Invite link
|-
| Aermacchi MB-339
| https://discord.gg/vNZ5ZPv
|-
| Boeing F/A-18C Hornet
|
https://discord.gg/8GzpdK4j8P
|-
|F-111 Aardvark
|https://discord.gg/DSrSbmx
|-
|[[General Dynamics F-16 Fighting Falcon]]
|https://discord.gg/8RcYnjA
|-
|Octal450 Hangar Development
|https://discord.gg/gxAhC3j
|-
|[[Mikoyan-Gurevich MiG-21bis]]
|https://discord.gg/bs8xyz3
|-
|[[Mirage 2000]]
|https://discord.gg/xZ3r2KR
|-
|Panavia Tornado
|https://discord.gg/SYxgzkCrSG
|-
|[[Saab 37 Viggen]]
|
https://discord.gg/RJTwS9a
|-
|SEPECAT Jaguar
|https://discord.gg/G5q5XYN
|-
|FG-1000 Stealth Fighter
| https://discord.gg/3MFZauxyPW
|-
|Boeing 777
|https://discord.gg/k5RXxFgGDA
|-
|A-10 Warthog
|https://discord.gg/RmtjmsT5vS
|-
|Soviet Aviation for FGFS
|https://discord.gg/YC2EYGK5Xf
|-
|B-1 Lancer
|https://discord.gg/d2bhwFCnX2
|-
|[[PZL-Koliber-family | PZL Koliber family]]
|https://discord.gg/beADn2sWM6
|}

==External links==
*https://discord.com/ Official website

[[de:Discord]]

[[Category:Software]]
[[Category:Community]]
[[Category:Air Traffic Control]]

Nasal optimisation

2026-04-10T01:44:46Z

SammySkycrafts: Fix Typo of "April"

{{Nasal Navigation}}

= Introduction to writing Nasal for optimum performance =

Writing optimal performing code in a real time system (in any language) is usually related to minmising the per frame impact of any given set of code; which may end up with slightly slower code but the point is to ensure that the real time frame rate does not degrade.

The basic techniques are as follows;

# Measure and locate (profile) code.
# Do less
# Cache more
# Spread out workload
# Avoid garbage collection

Inside each [[Nasal]] frame the programmer needs to ensure that the minimum necessary work is performed; ideally a predictable workload to ensure that Nasal processing per frame is constant - because otherwise there can be frame pauses - which is where an occasional frame will take much longer than usual.

Splitting any given task across frames is the normal way of ensuring that performance remains good; unfortunately a lot of Nasal doesn't do this and instead will process everything each frame. This is what the PartitionProcessor is designed to help with

Do not use getprop or setprop - these are very slow; instead use the props.nas module to refer to the property tree.

All property tree access is much slower than using native Nasal variables; and it is therefore wise to only read each property from the tree once per frame. This is what the FrameNotification is designed to help with.

Writing data to Canvas displays can be considered to be a slow operation; so only write values that are changed. props.UpdateManager can help with this.

Generally using props.UpdateManager (with the FrameNotification hash) can be generally used to perform OnChange processing that is more efficient than the property listeners - however property listeners should still be used to perform occasional actions (rather than per frame actions)

== Using the built in performance monitor ==
You can do this from the debug menu '''Monitor System Performance''' and currently the GUI only shows the top level.

When the performance monitor is active either by having the GUI on display or because <code>/sim/performance-monitor/enabled</code>is true overruns will be logged at ALRT level. An overrun is defined as exceeding<code>/sim/performance-monitor/max-time-per-frame-ms</code>).

Setting <code>/sim/performance-monitor/dump-stats</code> to non-zero will cause detailed performance info will be output to the log.

Note that it is generally a good idea not to use the integrated UI to display these stats (aka no PUI/Canvas). Instead, consider using Phi or the telnet/props interface, so that performance isn't degraded even more by displaying all these stats via the main loop.

== fdm-initialized listener ==
It is important to realise that sim/fdm-initialized will be set to true every time the model is repositioned; i.e. it does not fire just once. When sim/fdm-initialized is set to false the model should clean up all previously initialised listeners, threads, timers etc.

Generally it is much better to set timers, listeners (etc) at module level scope inside any Nasal file; as these will be executed only once. Using the Emesary FrameNotification can further simplify per frame processing because there is no need to use a timer per module and instead any modules can register themselves for frame processing simply by using GlobalNotifier.Register and all of the details are abstracted away and all that needs to happen is to handle the received notifications.

This is an example of acquiring and releasing listeners and timers.

<syntaxhighlight lang="nasal">
var l1 = nil;
var timer_loopTimer = nil;
var fdm_init = func(v) {

# always clean up values that aren't nil - this is safe
if (l1 != nil)
removelistener(l1);
l1 = nil;

if (timer_loopTimer != nil)
timer_loopTimer.stop();
timer_loopTimer = nil;

# then acquire new values
if (v.getValue()){
print("Initializing Systems");
l1 = setlistener("/some-prop", listener_func);
timer_loopTimer = maketimer(0.25, timer_loop);
timer_loopTimer.start();
}
else {
# now perform any other cleanup.
print("Cleaning up");
}
}

setlistener("sim/signals/fdm-initialized", fdm_init);
</syntaxhighlight>

However the above can be better written as follows;

<syntaxhighlight lang="nasal">
var l1 = setlistener("/some-prop", listener_func);
var timer_loopTimer = maketimer(0.25, timer_loop);

var fdm_init = func(v) {
if (v.getValue()){
timer_loopTimer.start();
}
else {
timer_loopTimer.stop();
}
}
setlistener("sim/signals/fdm-initialized", fdm_init);
</syntaxhighlight>

== Nasal threads ==

Nasal threads are of limited use because most of the time it is property tree access and other API calls that are slow and a lot of the API library (including properties) are not thread safe and should not be called from outside the main loop.

= Optimisation techniques =

The F-15 I think is the reference implementation of my three main Nasal optimisation techniques;

== Nasal Profiling ==

As yet there isn't a profiler available so instead there is an OperationTimer that is ships as part of emexec (2020.3 or later released after April 2022).

This makes it easy to output (via logprint) information about how much time a module is taking.

To create an instance of a timer there are two parameters, the first is the ident and the second the log level (3=info, 2=debug)
<code>var ot = emexec.OperationTimer.new("VSD",2);</code>
The output is a cumulative number of milliseconds since the OperationTimer was reset.
<ot.reset();
ot.log("Start");
<some code to time>
ot.log("1");
<more code>
ot.log("ed");</code>

== Emesary real time executive ==

Starting from 2020.3 released after April 2022 FGdata includes the emexec module which provides an easy to use object scheduler that uses Emesary to do most of the work.

By default it is recommended to use the built in scheduler <code>emexec.ExecModule</code>

The scheduler will adjust the frequency from 50hz right down to 4hz.

Any object that wishes to be invoked simply needs to provide an <code>update(notification)</code> method and register itself via ExecModule.register method.

The register method takes the following arguments

# ident - text to identify this object registration
# properties_to_monitor : a key value pair hash of properties to include in the notification. This helps to optimise property tree access (see FrameNotification below for the format)
# object : an instance of an objec that has an update(notification) method
# rate : frame skip rate (1/rate is the effective rate)
# frame_offset : frame skip offset. Must be less than rate and when used with rate it can allow interleaving of modules (usually for performance)

During development it would be usual to set the overrun detection active emexec.ExecModule.transmitter.OverrunDetection(9) for a warning (log leve info) of any frame that exceeds 9 ms

== FrameNotification ==

The FrameNotification is a notification sent out at defined intervals that contains a hash with property values.

Use the FrameNotificationAddProperty to request that certain properties are contained within the FrameNotification.

<syntaxhighlight lang="nasal">
notifications.FrameNotificationAddProperty.new("F15-HUD", **[HASH-Name]**, **[property-string]**)
</syntaxhighlight>

e.g.

<syntaxhighlight lang="nasal">
emesary.GlobalTransmitter.NotifyAll(notifications.FrameNotificationAddProperty.new("F15-HUD", "AirspeedIndicatorIndicatedMach", "instrumentation/airspeed-indicator/indicated-mach"));`
</syntaxhighlight>

although more typically used by having a hash that contains the keys and properties that you want to monitor and then using a loop to send out the FrameNotificationAddProperty; e.g.:

<syntaxhighlight lang="nasal">
input = {
AirspeedIndicatorIndicatedMach : "instrumentation/airspeed-indicator/indicated-mach",
Alpha : "orientation/alpha-indicated-deg",
AltimeterIndicatedAltitudeFt : "instrumentation/altimeter/indicated-altitude-ft",
ArmamentAgmCount : "sim/model/f15/systems/armament/agm/count",
ArmamentAim120Count : "sim/model/f15/systems/armament/aim120/count",
ArmamentAim7Count : "sim/model/f15/systems/armament/aim7/count",
ArmamentAim9Count : "sim/model/f15/systems/armament/aim9/count",
ArmamentRounds : "sim/model/f15/systems/gun/rounds",
AutopilotRouteManagerActive : "autopilot/route-manager/active",
AutopilotRouteManagerWpDist : "autopilot/route-manager/wp/dist",
AutopilotRouteManagerWpEtaSeconds : "autopilot/route-manager/wp/eta-seconds",
CadcOwsMaximumG : "fdm/jsbsim/systems/cadc/ows-maximum-g",
ControlsArmamentMasterArmSwitch : "sim/model/f15/controls/armament/master-arm-switch",
ControlsArmamentWeaponSelector : "sim/model/f15/controls/armament/weapon-selector",
ControlsGearBrakeParking : "controls/gear/brake-parking",
ControlsGearGearDown : "controls/gear/gear-down",
ControlsHudBrightness : "sim/model/f15/controls/HUD/brightness",
ControlsHudSymRej : "sim/model/f15/controls/HUD/sym-rej",
ElectricsAcLeftMainBus : "fdm/jsbsim/systems/electrics/ac-left-main-bus",
HudNavRangeDisplay : "sim/model/f15/instrumentation/hud/nav-range-display",
HudNavRangeETA : "sim/model/f15/instrumentation/hud/nav-range-eta",
OrientationHeadingDeg : "orientation/heading-deg",
OrientationPitchDeg : "orientation/pitch-deg",
OrientationRollDeg : "orientation/roll-deg",
OrientationSideSlipDeg : "orientation/side-slip-deg",
RadarActiveTargetAvailable : "sim/model/f15/instrumentation/radar-awg-9/active-target-available",
RadarActiveTargetCallsign : "sim/model/f15/instrumentation/radar-awg-9/active-target-callsign",
RadarActiveTargetClosure : "sim/model/f15/instrumentation/radar-awg-9/active-target-closure",
RadarActiveTargetDisplay : "sim/model/f15/instrumentation/radar-awg-9/active-target-display",
RadarActiveTargetRange : "sim/model/f15/instrumentation/radar-awg-9/active-target-range",
RadarActiveTargetType : "sim/model/f15/instrumentation/radar-awg-9/active-target-type",
InstrumentedG : "instrumentation/g-meter/instrumented-g",
VelocitiesAirspeedKt : "velocities/airspeed-kt",
};
foreach (var name; keys(input)) {
emesary.GlobalTransmitter.NotifyAll(notifications.FrameNotificationAddProperty.new("F15-HUD", name, input[name]));
}
</syntaxhighlight>

The idea of the FrameNotification is that it provides an easy way to run your update logic; simply by registering with the GlobalTransmitter and then processing the FrameNotification you can call your update logic in an efficient manner;

e.g.

<syntaxhighlight lang="nasal">
var HUDRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.MainHUD = nil;
new_class.Receive = func(notification)
{
if (notification.NotificationType == "FrameNotification")
{
if (new_class.MainHUD == nil)
new_class.MainHUD = F15HUD.new("Nasal/HUD/HUD.svg", "HUDImage1");
if (!math.mod(notifications.frameNotification.FrameCount,2)){
new_class.MainHUD.update(notification);
}
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};
</syntaxhighlight>
and then register that function with the Emesary Global transmitter.

<syntaxhighlight lang="nasal">
emesary.GlobalTransmitter.Register(HUDRecipient.new("F15-HUD"));
</syntaxhighlight>

------

== props.UpdateManager ==

This will monitor one or more property, or values from a hash and call a function (or inline function) when the value or a value changes more than a defined amount.

e.g.
<syntaxhighlight lang="nasal">
obj.update_items = [
props.UpdateManager.FromHashList(["ElectricsAcLeftMainBus","ControlsHudBrightness"] , 0.01, func(val)
{
if (val.ElectricsAcLeftMainBus <= 0
or val.ControlsHudBrightness <= 0) {
obj.svg.setVisible(0);
} else {
obj.svg.setVisible(1);
}
}),
props.UpdateManager.FromHashValue("AltimeterIndicatedAltitudeFt", 1, func(val)
{
obj.alt_range.setTranslation(0, val * alt_range_factor);
}),

props.UpdateManager.FromHashValue("VelocitiesAirspeedKt", 0.1, func(val)
{
obj.ias_range.setTranslation(0, val * ias_range_factor);
}),
props.UpdateManager.FromHashValue("ControlsHudSymRej", 0.1, func(val)
{
obj.symbol_reject = val;
}),
...
</syntaxhighlight>

and then in the update method
<syntaxhighlight lang="nasal">
foreach(var update_item; me.update_items)
{
update_item.update(notification);
}
</syntaxhighlight>
As you can see above the update method is called from the recipient of the frame notification.

== PartitionProcessor ==

When working with lists (arrays) of data that can get quite long (e.g. targets from radar) the partition processor is an easy way to only process a part of that list each frame.

What it does is to manage the processing of data in a manner suitable for real time operations. Given a data array [0..size] this will process a number of array elements each time it is called This allows for a simple way to split up intensive processing across multiple frames.

The limit is the number of elements to process per frame (invocation of .process method) or to limit the processing to a specified amount of time using a Nasal timestamp to measure the amount (in usec)

example usage (object);

<syntaxhighlight lang="nasal">
var VSD_Device =
{
new : func(designation, model_element, target_module_id, root_node)
{
...
# new : func(_name, _size, _timestamp=nil)
obj.process_targets = PartitionProcessor.new("VSD-targets", 20, nil);
obj.process_targets.set_max_time_usec(500);
...
me.process_targets.set_timestamp(notification.Timestamp);
</syntaxhighlight>

then invoke.

<syntaxhighlight lang="nasal">
# process : func (object, data, init_method, process_method, complete_method)

me.process_targets.process(me, awg_9.tgts_list,
func(pp, obj, data){
initialisation; called before processing element[0]
params
pp is the partition processor that called this
obj is the reference object (first argument in the .process)
data is the entire data array.
}
,
func(pp, obj, element){
process individual element;
params
pp is the partition processor that called this
obj is the reference object (first argument in the .process)
element is the element data[pp.data_index]
return 0 to stop processing any more elements and call the completed method
return 1 to continue processing.
},
func(pp, obj, data)
{
completed; called after the last element processed
params
pp is the partition processor that called this
obj is the reference object (first argument in the .process)
data is the entire data array.
});
</syntaxhighlight>

Howto:Animate models

2026-01-18T00:15:02Z

SammySkycrafts: /* Vertex Ordering */ Change 2020.4 to 2024.1 to reflect release

The real world is full of motion. To simulate this in [[FlightGear]], '''models must be animated'''.

FlightGear allows you to animate models in response to property changes: for example, the propellers can spin when the engine is on and the elevators can move up and down with your controller. There is no fixed limit on what parts can be animated: the only requirements are that the part is named in the 3D model file, and that there is a property in the main tree that you can use to get the positioning information.

This document provides basic information for all kind of animations. When animating your model, it is very helpful to find an aircraft with parts similar to yours and use it as an example. Cut and paste the code into your wrapper file and then edit to suit.

== Notes ==
=== File name of main model and animation XML file ===
{{main article|Aircraft-set.xml#Not used for loading multiplayer aircraft}}
The file name of the main model and animation XML file, or the .ac file if there is no XML file, (in essence the property <code>/sim/model/path</code>) will be the name of the aircraft that is transmitted when using [[multiplayer]] and will also be used for loading multiplayer aircraft.

There is also a mechanism to substitute a full aircraft model with a simpler AI aircraft model if one is available at the same file path (including for example <code>Models/Boeing-797-800.xml</code>), but in <code>[[$FG_ROOT]]/'''AI'''/Aircraft/</code> instead of <code>$FG_ROOT/Aircraft/</code>.

=== .ac files ===
{{Main article|AC files: Understanding and changing .ac code#Identifying an object}}

When referring to an .ac file in your xml animation, it is important that the <code><object-name></code> exactly matches the object named in the .ac file (this includes cases!).

'''Note for SketchUp users:''' The spatial reference X/Y/Z used in animation to locate an object or a point are different from the ones in AC3D ie X values are the same in both but Y in animation must be matched to AC3D's -Z (Z value but opposite sign) and Z value in animation must be matched to AC3D's Y value.

'''Note for SketchUp users:''' when exporting to AC3D in Sketchup, the .ac file will name the objects in your model to "blah" by default. You need to amend the relevant object names in your .ac file using text edit, so that the xml will work.

=== Animation order ===
Animations are executed by FlightGear in the order that they are read in the model's .xml file. Therefore, it is very important to pay attention to the order, especially when multiple animations are applied to the same object(s). Wrong ordering of animations might cause [[Howto:Animate models#Timed|timed]] animations (used to create flashing lights) to not work. For further details see this [https://sourceforge.net/p/flightgear/mailman/message/37090714/ thread] on the development mailing list. Updated [https://scenery.flightgear.org/app.php?c=Models&a=browse&shared=18 shared Effects models] will be available very soon.

Similar problems can be encountered with the dist-scale instead of the timed animation.
== Tags used in most animations ==
=== Name ===
With a name animation, you can group multiple objects.

<source>
<animation>
<name>Collection1</name>
<object-name>Object1</object-name>
<object-name>Object2</object-name>
<object-name>Object3</object-name>
</animation>
</source>

The example above creates a "virtual object" with the name Collection1. In animation, we can animate this group of objects, by using:

<source>
<object-name>Collection1</object-name>
</source>

=== Object-name ===
These names are set in the 3D model. Each single object has a unique name; for easy identification it is advised to use descriptive names (LeftElevator, Rudder etc.). Animations are only applied to those objects that are mentioned in an object-name line (one object per line!). Animations lacking those, will be applied to the entire model.

=== Property ===
Each animation must be associated with exactly one property from the main FlightGear property tree (remember that the properties in the wrapper file are not part of the main tree), using <code><property></code> to provide the property path:

<source>
<animation>
<type>rotate</type>
<object-name>Rudder</object-name>
<property>controls/rudder</property>
</animation>
</source>

Note the omission of the leading slash '/' when referring to the property. This assures that when the model is used for AI or multiplayer traffic the animations will follow that of the AI controller instead of that of the user.

=== Axis ===
An axis part is required in every animation that involves a rotating or moving thing.

<source>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</source>

The axis are similar to the ones of the 3D model. There is a difference between rotation and translation:
* In rotation animations, the axis part defines around what axis the object rotates. Negative/positive values make the difference between counterclockwise and clockwise rotations.
* In translate animations, the part defines along what axis the object moves. If the x-axis is poiting backwards, an x-value of -1 will result in forward motion.

You could also define two points, between which FlightGear will calculate the correct axis. This makes the use of a [[#Center|<nowiki><center></nowiki>]] tag redundant! Such coordinates are extremely useful for animating control surfaces (rudder, elevators etc.).

<source>
<axis>
<x1-m> 4.9</x1-m>
<y1-m> 7.1</y1-m>
<z1-m>-1.0</z1-m>
<x2-m> 5.9</x2-m>
<y2-m>11.2</y2-m>
<z2-m>-0.5</z2-m>
</axis>
</source>

=== Center ===
Various animations ([[#Rotate|rotate]], [[#Spin|spin]], [[#Scale|scale]]) move around a center point.

<source>
<center>
<x-m>-1.50</x-m>
<y-m> 1 </y-m>
<z-m> 0.25</z-m>
</center>
</source>

The axis are similar to the ones of the 3D model, so finding coordinates is easily done in 3D modeling software.

=== Using a geometry object for axis and centre (2017.2) ===

Added in V2017.2 is support to allow a geometry object (a line segment with two vertices) that is used to define both the centre and the axis for an animation. This will work with rotate, spin, translate and knob animations.

{{Note|Since SimGear commit 6ca9141083e62be1161d0ca2d1e3b918494dd6ad on next, this feature can also be used for slider (usage equivalent to that for a translate animation) and for any of the <*-center> / <*-axis> tags of a locked-track animation.}}

When used for translate animations, the axis line should be normalized (i.e. be 1 meter long) as its length acts as a factor for the translation distance.

The XML syntax for this is:

<source>
<axis>
<object-name>some-object</object-name>
</axis>
</source>

If the <code><axis>...</axis></code> section is omitted entirely, <code>{object-name}-axis</code> will be used by default, where <code>{object-name}</code> is the name of the object being animated (if we are animating more than one object, the first object is used). In the earlier example this would be <code>Rudder-axis</code>.

==== Vertex Ordering ====

With FG <= 2020.3 the order of the points in the vertex will be sorted based on their X coordinate and when the X coordinate is equal the order will be that of the vertices in the model.

This has been improved in 2024.1 by adding some new tags that can be used in the <axis> section.

# <order-by-xyz/> - use the new sorting rules
# <order-by-x/> - use the 2020.3 sorting rules
# <swap-axis-direction/> - when the animation goes the wrong way this is an elegant way to fix it.

There is also a new top level tag <defaults> that can have either <axis-animation-vertex-order-xyz/> or <axis-animation-vertex-order-x/>. These defaults will affect all animations in the .xml and also any included models unless the included model also has a <defaults> section.

So for modelers that want to use the new definitive vertex sorting rules adding the following to the main model is sufficient.
<source>
<defaults>
<axis-animation-vertex-order-xyz/>
</defaults>
</source>

==== Adding the axis animation 3d object to a model ====

In the '''.ac''' file, specify a SURF with type (bottom 4 bits, 0=polygon, 1=closedline, 2=line) set to 2, and two vertices that define the axis. For example:

OBJECT poly
name "aileron.l-axis"
numvert 2
3.2077502191170844 0.18160835055097943 4.055616960642423
2.6758650763079 0.28024033462188946 6.477876098622225
numsurf 1
SURF 0x12
mat 0
refs 2
0 0 0
1 0 0
kids 0

Once the object-name used for the axis has been processed the geometry object will be hidden. This also allows a visual check for any axis objects that are not yet assigned.

It is possible to reuse the same object definition multiple times within a single XML file.

[[File:Canopy-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for a canopy]]

[[File:Gauges-knobs-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for cockpit elements]]

== Additional tags that can be used in most animations ==
=== Conditions ===
Multiple animations can make use of a conditional. Check <tt>$FGDATA/Docs/README.conditions</tt> for some more details.

* '''equals:''' property value (or second property) is equal to value/(first)property.
* '''greater-than:''' property value (or second property) is larger than value/(first)property.
* '''greater-than-equals:''' property value (or second property) is greater than or equal to value/(first)property.
* '''less-than:''' property value (or second property) is smaller than value/(first)property.
* '''less-than-equals:''' property value (or second property) is smaller than or equal to value/(first)property.

The example below is true when n1 has a value greater than 25.
<source>
<condition>
<greater-than>
<property>engines/engine[1]/n1</property>
<value>25</value>
</greater-than>
</condition>
</source>

Then there are some special tags:

* '''and:'''
* '''not:'''
* '''or:'''

In the example below, the condition is true when either n1 is greater than 25% or equal to 0%.
<source>
<condition>
<or>
<greater-than>
<property>engines/engine[1]/n1</property>
<value>25</value>
</greater-than>
<equals>
<property>engines/engine[1]/n1</property>
<value>0</value>
</equals>
</or>
</condition>
</source>

An example of implementation into an animation looks as follows:

<source>
<animation>
<object-name>Object</object-name>
<type>rotate</type>
<property>suface-positions/left-aileron-pos-norm</property>
<factor>25</factor>
<condition>
<greater-than>
<property>suface-positions/left-aileron-pos-norm</property>
<value>10</value>
</greater-than>
</condition>
<center>
<x-m>-1.50</x-m>
<y-m> 1 </y-m>
<z-m> 0.25</z-m>
</center>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
</source>

=== Interpolation ===
For non-fixed factors, an interpolation "table" can be created.

<source>
<interpolation>
<entry>
<ind> 0.0</ind>
<dep> 0.0</dep>
</entry>
<entry>
<ind> 0.667</ind>
<dep> 0.0</dep>
</entry>
<entry>
<ind> 1.0</ind>
<dep> 0.5</dep>
</entry>
</interpolation>
</source>

The lines above represent the following table:

{|
!Input
!Output
|-
|0.0
|0.0
|-
|0.667
|0.0
|-
|1.0
|0.5
|}

You can add as many entries as you need. Interpolation tables are often used for gear animations (eg. to open doors during gear-movements and close them again once the gear is either retracted or fully extended).

=== Expressions ===
For some animations it is possible to define complex animations by using [[Expressions|Expressions]]. This even allows to drive the animation from multiple properties without the need for additional Nasal scripts. Here is an example for a translate animation depending on two properties and the cosine function:
<syntaxhighlight lang="xml">
<animation>
<type>translate</type>
<expression>
<product>
<property>/my/factor-property</property>
<cos>
<deg2rad>
<property>/my/angular-property</property>
</deg2rad>
</cos>
</product>
</expression>
[..]more elements[..]
</animation>
</syntaxhighlight>

Animations which can utilize [[Expressions|Expressions]] are:
* [[Howto:Animate_models#Translate|Translate]]
* [[Howto:Animate_models#Rotate|Rotate]]
* [[Howto:Animate_models#Scale|Scale]]
* [[Howto:Animate_models#Range|Range]]
* [[Howto:Animate_models#Blend|Blend]]
* [[Howto:Animate_models#Material animation|Material]]
* [[Howto:Animate_models#PBR animation|PBR]]

See more detailed info at [[Expressions|Expressions]]

== Lights ==
As of January 2021 FlightGear supports multiple light sources just like Project Rembrandt has always done.
[[Compositor#Lights|Adding lights to a model]]

== Object animations ==
=== Alpha-test ===
<source>
<animation>
<type>alpha-test</type>
<object-name>Object</object-name>
<alpha-factor>0.01</alpha-factor>
</animation>
</source>
This "animation" is a way to set an alpha test on a model branch. The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. This is particulary useful when modeling a metallic structure or a tree with a billboard. The threshold of transparency is set with the <alpha-factor> element. See also [[Pixel testing in effects]].

=== Blend ===
Blends an object with the surrounding. Comparable to a translucency animation. A value of 0 corresponds to no transparency, i.e. and ordinary solid object, and a value of 1 makes the object fully transparent, i.e., not visible at all.

<source>
<animation>
<type>blend</type>
<property>/velocities/airspeed-kt</property>
<factor>0.00025</factor>
<min>0.2</min>
<max>0.7</max>
</animation>
</source>

* '''property:'''
* '''factor:'''
* '''min:'''
* '''max:'''
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]

Note that when using the Project Rembrandt renderer, all transparent and translucent objects must be registered to display properly. [[Project_Rembrandt#Registering_all_translucent_surfaces|More information here.]]

=== Billboard ===
This faces an object towards the viewer. Often used on 2D objects, like clouds, trees and lights.

<source>
<animation>
<type>billboard</type>
<object-name>Object</object-name>
<spherical type="bool">true</spherical>
</animation>
</source>

* '''spherical:'''

=== Dist-scale ===
Used to scale an object, based on the distance to the viewer. <code><nowiki><ind></nowiki></code> and <code><nowiki><dep></nowiki></code> (independent and dependent) are the distance in meters and the scale at that distance.

<source>
<animation>
<type>dist-scale</type>
<object-name>Object</object-name>
<interpolation>
<entry>
<ind>0</ind>
<dep>1</dep>
</entry>
<entry>
<ind>300</ind>
<dep>4</dep>
</entry>
<entry>
<ind>1500</ind>
<dep>8</dep>
</entry>
</interpolation>
</animation>
</source>

You can optionally add [[#Center|<center>]] coordinates, to scale the object around that point.

=== Flash ===

Used to scale an object based on the cosine of the angle between the axis provided in the animation and the view vector.

<source>
<animation>
<type>flash</type>
<object-name>Object</object-name>
<offset>0.0</offset>
<factor>1.0</factor>
<power>2</power>
<two-sides type="bool">false</two-sides>
<min>0.0</min>
<max>1.0</max>
<center>
<x-m>0.0</x-m>
<y-m>0.0</y-m>
<z-m>0.0</z-m>
</center>
<axis>
<x>0.0</x>
<y>-1</y>
<z>0.1</z>
</axis>
</animation>
</source>

* '''offset:'''
* '''factor:'''
* '''power:'''
* '''two-sides:''' if false, nothing is drawn if the cosine is negative.
* '''min:'''
* '''max:'''

scale = factor * pow( cosine, power ) + offset

scale is then clamped between min and max.

and this scale factor is applied to the object, from the center specified. It works best if scale is less than 1. Otherwise, there will be clipping issues.

=== Noshadow ===
This animation is used to make sure an object will cast no shadow.

<source>
<animation>
<type>noshadow</type>
<object-name>Object</object-name>
</animation>
</source>

=== Range ===
: ''See also [[Modeling - Getting Started#Level of Detail (LOD)]].''

To prevent objects -like instruments- being drawn when the aircraft is actually too far away for them to be seen anyway, a range animation is used.

<syntaxhighlight lang="xml">
<animation>
<type>range</type>
<min-m>0</min-m>
<max-m>30</max-m>
</animation>
</syntaxhighlight>

* '''min-m:''' the shortest distance (in meters) from the object center at which it is visible.
* '''max-m:''' the largest distance (in meters) from the object center at which it is visible.

You could also use the generic level of detail (LOD) properties, which can be set by the user through View > Adjust LOD rangers:
{| class="wikitable"
! Property
! Description
! Default value
|-
|<tt>/sim/rendering/static-lod/bare</tt>
| only a rough exterior model
| 30,000 m
|-
|<tt>/sim/rendering/static-lod/rough</tt>
| most should be visible
| 9,000 m
|-
|<tt>/sim/rendering/static-lod/detailed</tt>
| all details should be visible
| 1,500 m
|}

The animation code will look like this:
<syntaxhighlight lang="xml">
<animation>
<type>range</type>
<min-m>0</min-m>
<max-property>sim/rendering/static-lod/bare</max-property>
</animation>
</syntaxhighlight>

You can have both ranges (max and min) bound to a property, or just one of them.
* '''min-property:'''
* '''max-property:'''
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]

=== Rotate ===
One of the most important and frequently used animations of all. It rotates an object to an absolute position in degrees, as provided by the property-value.

<source>
<animation>
<object-name>Object</object-name>
<type>rotate</type>
<property>surface-positions/left-aileron-pos-norm</property>
<factor>25</factor>
<offset-deg>25</offset-deg>
<center>
<x-m>-1.50</x-m>
<y-m> 1 </y-m>
<z-m> 0.25</z-m>
</center>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
</source>

* '''factor:''' is optional.
* '''offset-deg:''' is optional. Offset in degrees.
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]

=== Scale ===
A scale animation scales (resizes) an object. This can be either property-value dependant (first example) or a fixed scale (second example).

<source>
<animation>
<type>scale</type>
<object-name>Object</object-name>
<property>sim/time/sun-angle-rad</property>
<x-min>1.0</x-min>
<y-min>1.0</y-min>
<z-min>1.0</z-min>
<x-factor>1.4</x-factor>
<y-factor>1.4</y-factor>
<z-factor>2.0</z-factor>
</animation>
</source>

* ?-min: the mimimum scale factor for each axis. If the property value would result in a smaller factor than this setting, the scale animation will hold.
* ?-factor: the scale factor for each axis (factor*property=scale factor).

<source>
<animation>
<type>scale</type>
<x-offset>0.5</x-offset>
<y-offset>0.5</y-offset>
<z-offset>0.5</z-offset>
</animation>
</source>

* x.offset: the scale factor.
* Add [[#Center|<center>]] coordinates, to scale the object around that point.
* '''You can optionally use an [[Howto:Animate_models#Expressions|expression]] in the <factor> or <offset> inputs.''' For more details see [[Expressions|Expressions]]

=== Select ===
This animation selects (or unselects) objects when certain conditions are true (or false). The example below shows the object when the n1 of engine[1] is higher than 25%.

<source>
<animation>
<object-name>Object</object-name>
<type>select</type>
<condition>
<greater-than>
<property>engines/engine[0]/n1</property>
<value>25</value>
</greater-than>
</condition>
</animation>
</source>

=== Shader ===
<source>
<animation>
<type>shader</type>
<shader>chrome</shader>
<texture>chrome2.png</texture>
<object-name>Object</object-name>
</animation>
</source>

* '''shader:'''
* '''texture:''' path to the texture used by the shader.

=== Spin ===
Very similar to [[#Rotate|rotate]], but the property provides a value in revolutions per minute (RPM) rather than an absolute position in degrees, and offset cannot be used.

<source>
<animation>
<object-name>Object</object-name>
<type>spin</type>
<property>engines/engine[0]/n1</property>
<factor>25</factor>
<center>
<x-m>-1.50</x-m>
<y-m> 1 </y-m>
<z-m> 0.25</z-m>
</center>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
</source>

* '''factor:''' is optional.

=== Timed ===
Swtiches between objects at specified intervals. This example switches between a lights-on model and a lights-off model. Lights on are shown 0.2 seconds, while lights off are displayed for 0.8 seconds.

<source>
<animation>
<type>timed</type>
<object-name>BacklightOn</object-name>
<object-name>BacklightOff</object-name>
<use-personality type="bool">true</use-personality>
<branch-duration-sec>0.8</branch-duration-sec>
<branch-duration-sec>0.2</branch-duration-sec>
</animation>
</source>

=== Tracking ===
A ''locked-track animation'' can do exactly the same thing as the [https://docs.blender.org/manual/en/latest/animation/constraints/tracking/locked_track.html Locked Track constraint] available in Blender and can also be used to simulate simple inverse kinematic systems consisting of two bones connected with a revolute joint (aka hinge). For details see: [[Howto:Animate gear scissors using the tracking animation]]

=== Translate ===
This animation moves an object along an axis (not to be confused with the <code>textranslate</code> animation which only moves the texture on the UV map, not the geometry). The example below will move an object in the Y direction:

{| class="wikitable" border="0" cellspacing="0"
!Property value
!Output
|-
| -1
| -2.5
|-
| 0
| 2.5
|-
| 1
| 7.5
|}

<source>
<animation>
<type>translate</type>
<object-name>Object</object-name>
<property>controls/seat/pilot/position-norm</property>
<factor>5</factor>
<offset-m>2.5</offset-m>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
</source>

When using interpolation tables such as:
<source>
<interpolation>
<entry><ind>0.0</ind><dep> 0</dep></entry>
<entry><ind>0.666</ind><dep>0.18</dep></entry>
<entry><ind>1.0</ind><dep>0.27</dep></entry>
</interpolation>
</source>
The first figure (<code><ind></code>) refers to the value of the property associated with the object and the second figure (<code><dep></code>) refers to the amount that the object moves in metres. For example, in this case, the object moves 18cm when the value reads 0.66 and 27cm when the value is 1.

'''IF used WTIHOUT property''' : The object is placed at some (Value of Offset) meters away from its original position, along the virtual axis formed by said original position and the point with coordinates x/y/z defined in the <axis> tag.
Mathematically, assuming the Object to translate is (in the model space) placed at point A (x1, y1, z1) and you want to relocate it to point B (x2, y2, z2) then x2,y2,z2 are the values in the <axis> tag of the Translate animation and <offset> can be computed as SQRT((x2-x1)^2+(y2-y1)^2+(z2-z1)^2)

* '''factor:''' is optional.
* '''offset-m:''' is optional. Offset in meters.
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]

== PBR animation ==

Animate the PBR (Physically-Based Rendering) materials. Keep in mind that your model must use the model-pbr.eff Effect or be a [[glTF]] model.

<source lang="xml">
<animation>
<type>pbr</type>
<object-name>Object</object-name>
<property-base>sim/model/c172p/material/</property-base>
<base-color-factor>
<r>1.0</r>
<g>0.3</g>
0.1
<a>1.0</a>
</base-color-factor>
<metallic-factor>0.0</metallic-factor>
<roughness-factor>0.3</roughness-factor>
<emissive-factor>
<r><property>panel-brightness</property></r>
<g><property>panel-brightness</property></g>
<property>panel-brightness</property>
</emissive-factor>
</animation>
</source>

* <tt>property-base</tt>: All other properties of this animation will be relative to this property node.
* <tt>base-color-factor</tt>: The base color texture will be multiplied by this value. Should be an RGBA color.
* <tt>metallic-factor</tt>: The metallic texture will be multiplied by this value. Should be a single floating point value.
* <tt>roughness-factor</tt>: The roughness texture will be multiplied by this value. Should be a single floating point value.
* <tt>emissive-factor</tt>: The emissive texture will be multiplied by this value. Should be an RGB color.

For each of the color components you can use an [[expression]]. Every parameter is '''optional'''.

== Material animation ==
Animate the material properties of an object, such as it's texture, shininess or color.

<source lang="xml">
<animation>
<type>material</type>
<object-name>Object</object-name>
<property-base>sim/model/c172p/material</property-base>
...
lines as mentioned below
...
</animation>
</source>

'''Optional:'''
* '''property-base:''' All other properties of this animation will be relative to this property node.

'''Notes:'''
* Numbers are clamped to 0.0 - 1.0, except <code>shininess</code>, which is clamped to 0 - 128.
* By appending <tt>-prop</tt> each of the material properties can read its value from another property.
* '''New since SimGear commit <code>51149bf</code>''': For each of the color components (<code>ambient</code>, <code>diffuse</code>, <code>emission</code> and <code>specular</code>), the <code>red</code>, <code>green</code>, <code>blue</code>, <code>factor</code> and <code>offset</code> tags can each contain an [[Expressions|expression]] instead of a value.

=== Ambient ===
<source>
<ambient>
<red>1.0</red>
<green>0.2</green>
<blue>0.0</blue>
</ambient>
</source>

=== Diffuse ===
<source>
<diffuse>
<red>1.0</red>
<green>0.2</green>
<blue>0.0</blue>
</diffuse>
</source>

=== Emission ===
{{Main article|Howto: Illuminate faces}}
<source>
<emission>
<red>1.0</red>
<green>0.2</green>
<blue>0.0</blue>
<factor-prop>controls/lighting/panel-norm</factor-prop>
</emission>
</source>

Emission colors are multiplied by the factor-prop value. 1 is maximum color intensity, while 0 is the minimum. Colors are calculated according to the [http://en.wikipedia.org/wiki/RGB_color_model RGB color model].

=== Specular ===
<source>
<specular>
<red>1.0</red>
<green>0.2</green>
<blue>0.0</blue>
</specular>
</source>

=== Transparency ===
<source>
<transparency>
<alpha-prop>rotors/tail/rpm</alpha-prop>
<factor>-0.0015</factor>
<offset>1</offset>
</transparency>
</source>

=== Shininess ===
Shininess is clamped to 0-128.
<source>
<shininess>105</shininess>
</source>

=== Threshold ===
<source>
<threshold>0.001</threshold>
</source>

=== Texture ===
Used for the [[Livery over MP]] system.

<source>
<property-base>sim/model/livery</property-base>
<texture-prop>engine</texture-prop>
<texture>KLM.png</texture>
</source>

== Texture Animations ==
Applying different matrix transformations to the textures of an object.

=== Textranslate ===
A very important animation for cockpits! This animation moves textures over a surface.

<source>
<animation>
<type>textranslate</type>
<object-name>Object</object-name>
<property>autopilot/settings/target-speed-kt</property>
<bias>0.0001</bias>
<factor>0.001</factor>
<step>100</step>
<axis>
<x>0</x>
<y>1</y>
</axis>
</animation>
</source>

* '''bias:''' Adds an offset to the property before factor/step. A small value is needed to compensate for [http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems floating point accuracy].
* '''factor:''' property * factor * texture width/height = the amount of pixels that the texture should be translated. If your texture is 256 pixels, an textranslate of 0.1 will result in the texture moving with 26 pixels, into the direction specified by the axis settings.
* '''step:''' the step size at which the texture is translated. If this is set to 0.1, the texture will only be translated at 0.1, 0.2, 0.3 etc.
* '''axis:''' the direction in which the texture is translated. Y is up/down, while X is left/right.

=== Texrotate ===

<source>
<animation>
<object-name>Object</object-name>
<type>texrotate</type>
<property>some/property/path</property>
<factor>25</factor>
<offset-deg>25</offset-deg>
<center>
<x>0.5</x>
<y>0.5</y>
<z>0</z>
</center>
<axis>
<x>0</x>
<y>0</y>
<z>1</z>
</axis>
</animation>
</source>

=== Textrapezoid ===

<source>
<animation>
<type>textrapezoid</type>
<object-name>HUD.l.canvas</object-name>
<property>/hud/trapezoid-correction</property>
<side>bottom</side>
</animation>
</source>

* '''side''': side of quad which should be scaled (''top'' (default)/''right''/''bottom''/''left'')

=== Texmultiple ===

Only one texture matrix can be applied to each object. With ''textmultiple'' multiple texture animations can be combined into a single matrix, applied to the specified object.

<source>
<animation>
<type>texmultiple</type>
<object-name>HUD.l.canvas</object-name>
<transform>
<subtype>textranslate</subtype>
<property>/hud/offset-x</property>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</transform>
<transform>
<subtype>textranslate</subtype>
<property>/hud/offset-y</property>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</transform>
<transform>
<subtype>textrapezoid</subtype>
<property>/hud/trapezoid-correction</property>
</transform>
</animation>
</source>

== Object interaction animations ==
=== Enable-hot ===
Scenery objects are automatically defined as solid by FlightGear, meaning that an aircraft can taxi on them and/or crash when touching. For certain objects (groundmarkings, beacon light-beams etc.) this might be an unwanted feature. The solidness can be disabled with the following animation:

<source>
<animation>
<object-name>Object</object-name>
<enable-hot type="bool">false</enable-hot>
</animation>
</source>

* '''enable-hot:''' can be either true or false. Remember that objects are automatically solid, so it should not be necessary to set this at all when wanting solidness.

=== Interactions ===
<source>
<animation>
<type>interaction</type>
<object-name>Object</object-name>
<interaction-type>carrier-wire</interaction-type>
</animation>
</source>

* '''interaction-type:''' can have the following values:
**'''carrier-catapult:'''
** '''carrier-wire:''' makes the object act as an arresting wire, as used on [[aircraft carrier]]s.

== Direct manipulation animations ==
=== Knob / slider (v. 2.11-) ===
{{Main article|Knob / slider animation}}

=== Pick ===
{{Main article|Howto: Make a clickable panel#Pick}}

=== Touch ===

The touch animation provides the normalized coordinates of a touch (or click) event on a 2d surface. The coordinates are passed in the argument and can be accessed using cmdarg() in Nasal.

* Touch animation is designed to work with a quad that is being used as a Canvas placement (display).
* The touch animation must not be combined with a pick animation on the same object.
* More info here: [[Touch Animation]]

==== touch example ====

<animation>
<type>touch</type>
<visible>true</visible>
<object-name>CanvasPlacement</object-name>
<action>
<touch>0</touch>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>print("touch input (",cmdarg().getNode("x").getValue(),",",cmdarg().getNode("y").getValue())</script>
</binding>
</action>
</animation>

== Shadow Handling ==
There exist several possibilites for handling of shadows. 
See '''[[ALS_technical_notes|ALS Technical Notes]]''' and more specific '''[[ALS_technical_notes#ALS_fuselage_shadow_effect|Fuselage Shadow Effect with ALS]]''' for a relatively simple shadow handling. 
See '''[[Project Rembrandt]]''' which - amongst other functionality - implements a very realistic shadow mapping.
As of January 2021 Project Rembrandt was replaced by the '''[[Compositor]]''' renderer which combines both Project Rembrandt and ALS in a single rendering engine. This also means that the Fuselage Shadow Effect with ALS is now deprecated.

== References ==
{{Appendix|all|
* {{cite web |url=http://www.opensubscriber.com/message/flightgear-devel@flightgear.org/958955.html |title="material" animation (and the bo105 as an example) |first=Melchior |last=Franz |date=22 March 2005 |work=FlightGear-devel mailinglist }}
* {{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01546.html |title=flash animation |first=Frederic |last=Bouvier |date=22 Feb 2006 |work=FlightGear-devel mailinglist }}
}}

== Related content ==
=== Wiki articles ===
* [[MP Fallback models]]
* [[Howto:Animate gear scissors]]
* [[Howto:Animate helicopters]]
* [[Howto:Creating 3D instruments]]

=== Forum topics ===
* {{forum link|t=37353|title=3d models, how to produce them in an understandable way}} (April 2020-) - Touches on the subject of not using LOD range animations in scenery models.
* {{forum link|t=36545|title=speedo Drum settings}} (November 2019) - Animating a mechanical multi-digit drum counter

[[Category:Aircraft enhancement|Animate models]]
[[Category:Howto|Animate models]]
[[Category:Modeling|Animate models]]
[[Category:Scenery enhancement|Animate models]]

Compositor

2025-12-02T02:41:32Z

SammySkycrafts: Clarify HDR specific lighting paramaters replace legacy paramaters rather than complement.

{{forum|47|Effects & Shaders}}

{{infobox subsystem
|image = Compositor logo.png
|name = Compositor Framework
|started = 01/2018 (Available since FlightGear 2020.4)
|description = Dynamic rendering pipeline configured via the [[Property tree]] and [[PropertyList XML File|XML]]
|status = Stable (merged and actively maintained)
|developers = Fernando García Liñán <ref>https://sourceforge.net/u/fgarlin/profile/</ref>
|changelog = https://sourceforge.net/u/fgarlin/profile/feed.rss
|folders =
* {{simgear file|simgear/scene/viewer}}
* {{flightgear file|src/Viewer}}
* {{fgdata file|Compositor}}
}}

{{Rendering}}

The '''Compositor''' aims to bring multi-pass rendering to FlightGear. It encapsulates a rendering pipeline and exposes its parameters to a [[Property Tree]] interface. At startup, FlightGear reads the pipeline definition file for each physical viewport defined on the [[Howto:Configure camera view windows|CameraGroup settings]]. If no Compositor file is specified for a physical camera, the one given by the <code>--compositor=</code> startup command will be used. If such startup option is not used either, FlightGear will look for a valid Compositor file in <tt>$FG_ROOT/Compositor/default.xml</tt>.

The Compositor introduces a new dedicated fgdata directory for new/custom rendering pipelines: {{Fgdata file|Compositor}}.

== Background ==

First discussed in 03/2012 during the early [[Rembrandt]] days, Zan (Lauri Peltonen) came up with a set of patches demonstrating how to create an XML-configurable rendering pipeline. Back then, this work was considered to look pretty promising <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28946515/
|title = <nowiki> Re: [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Mathias Fröhlich </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref> and at the time plans were discussed to unify this with the ongoing Rembrandt implementation (no longer maintained).

Adopting Zan's approach would have meant that efforts like [[Rembrandt]] (deferred rendering) could have been implemented without requiring C++ space modifications, i.e. purely in [[Base package]] space. Rembrandt's developer (FredB) suggested to extend the format to avoid duplicating the stages when you have more than one viewport, i.e. specifying a pipeline as a template, with conditions like in effects, and have the current camera layout refer the pipeline that would be duplicated, resized and positioned for each declared viewport <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28944773/
|title = <nowiki> Re: [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Frederic Bouvier </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref>

Zan's original patches can still be found in his newcameras branches which allow the user to define the rendering pipeline in preferences.xml: {{gitorious source|proj=fg|repo=zans-flightgear|branch=newcameras|text=FlightGear}}, {{gitorious source|proj=fg|repo=zans-simgear|branch=newcameras|text=SimGear}}. At that point, it didn't have everything Rembrandt's pipeline needs, but most likely could be easily enhanced to support those things. Basically, the original version added support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28944733/
|title = <nowiki> [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Lauri Peltonen </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref>

Since the early days of Zan's groundwork, providing the (hooks) infrastructure to enable base package developers to prototype, test and develop distinct rendering pipelines without requiring C++ space modifications has been a long-standing idea, especially after the [[Canvas]] system became available in early 2012, which demonstrated how RTT-rendering buffers (FBOs) could be set up, created and manipulated procedurally (i.e. at run-time) using XML, the property tree and [[Nasal]] scripting. <ref>{{forum link|type=search|title=Zan's Rembrandt and Canvas work|keywords=zan+rembrandt+canvas}}</ref>

The new '''Compositor''' is an improved re-implementation of Zan's original work using not just XML, but also [[Property Tree|properties]] and a handful of [[Canvas]] concepts.

== Features ==

* Completely independent of other parts of the simulator, i.e. it's part of [[SimGear]] and can be used in a standalone fashion if needed, ala Canvas.
* Although independent, its aim is to be fully compatible with the current rendering framework in FG. This includes the [[Effects]] system, [[Howto:Configure camera view windows|CameraGroup]], [[Rembrandt]], [[ALS]] and [[Canvas]].
* Its functionality overlaps Rembrandt: what can be done with Rembrandt can be done with the Compositor, but not vice versa.
* Fully configurable via an XML interface without compromising performance (ala Effects, using [[PropertyList XML File|PropertyList files]]).
* Flexible, expandable and compatible with modern graphics.
* It doesn't increase the hardware requirements, it expands the hardware range FG can run on. People with integrated GPUs (Intel HD etc) can run a Compositor with a single pass that renders directly to the screen like before, while people with more powerful cards can run a Compositor that implements deferred rendering, for example.
* Static branching support. Every pipeline element can be enabled/disabled at startup via a [[Conditions|<condition> block]].
* The entire rendering pipeline can be reloaded via an fgcommand (<tt>reload-compositor</tt>).

== How to enable the Compositor ==

The Compositor is now the default renderer framework in FlightGear since 2020/11/17. It will be included as part of version 2020.4 onwards.

If you compile FlightGear from source, you can already try the Compositor. Make sure you are pulling the latest version of the 'next' branch. You can also try out the latest nightly build from the [[FlightGear build server]].

== Notes for aircraft developers ==

=== Lights ===

The Compositor introduces a new way of defining lights that is renderer agnostic, so every rendering pipeline will be able to access the lights that have been implemented like this. The resulting light volumes can be visualized for debugging purposes by setting the property <tt>/sim/debug/show-light-volumes</tt> to true.

You can edit existing lights with the '''[[Illuminator addon|Illuminator]]''', but you have to define them first e.g. in your aircraft. The Illuminator add-on is meant for fine-tuning the light parameters.

[[Project Rembrandt]] light definitions are also read by the Compositor for backwards compatibility reasons. However, it is not recommended to use the old syntax for new/updated projects.

{|cellpadding=10|
|valign=top style="width: 20%;"|
<syntaxhighlight lang="xml">
<light>
<name>my-spotlight</name>
<type>spot</type>
<position>
<x-m>-7.7476</x-m>
<y-m>0</y-m>
<z-m>-1.7990</z-m>
</position>
<direction>
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</direction>
<ambient>
<r>0.03</r>
<g>0.03</g>
0.03
<a>1</a>
</ambient>
<diffuse>
<r>0.95</r>
<g>0.9</g>
0.9
<a>1</a>
</diffuse>
<specular>
<r>0.95</r>
<g>0.9</g>
0.9
<a>1</a>
</specular>
<attenuation>
<c>1.0</c>
<l>0.09</l>
<q>0.032</q>
</attenuation>
<spot-exponent>5</spot-exponent>
<spot-cutoff>40</spot-cutoff>
<range-m>50</range-m>
<dim-factor>
<property>controls/lighting/instruments-norm</property>
</dim-factor>
</light>
</syntaxhighlight>
|valign=top style="width: 80%;"|
* <tt>'''name'''</tt>. An {{tag|animation}} will be able to reference the light by this name. Most [[Howto:Animate_models|animations]] will work as expected (rotate, translate, spin etc). Material animations are not supported.
* <tt>'''type'''</tt>. <tt>spot</tt> or <tt>point</tt>.
* <tt>'''position'''</tt>. The position of the light source in model space and in meters.
* <tt>'''direction'''</tt>. Only available in <tt>spot</tt> lights. It indicates the direction of the spotlight. This parameter can be specified in three different ways:
{| class="wikitable" style="border: 1px solid darkgray;"
! scope="col" style="width:33%;" |Direction vector
! scope="col" style="width:33%;" |Look-at point
! scope="col" style="width:33%;" |Rotation angles
|-
| style="padding: 10px" | A vector in model space that specifies the direction. Doesn't have to be normalized.
<syntaxhighlight lang="xml">
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</syntaxhighlight>
| style="padding: 10px" | The spotlight will calculate its direction by looking at this position from the light position. The point is in model space and in meters.
<syntaxhighlight lang="xml">
<lookat-x-m>-8.031</lookat-x-m>
<lookat-y-m>0</lookat-y-m>
<lookat-z-m>-2</lookat-z-m>
</syntaxhighlight>
| style="padding: 10px" | A three angle rotation in degrees that rotates the spotlight around the three axes. A 0 degree angle in all axes makes the spotlight point downwards (negative Z).
<syntaxhighlight lang="xml">
<pitch-deg>90</pitch-deg>
<roll-deg>0</roll-deg>
<heading-deg>0</heading-deg>
</syntaxhighlight>
|}
* <tt>'''ambient'''</tt>, <tt>'''diffuse'''</tt> and <tt>'''specular'''</tt>. Four-component vectors that specify the light color.
* <tt>'''attenuation'''</tt>. Three-component vector where <code><c></code> specifies the constant factor, <code><l></code> specifies the linear factor and <code><nowiki><q></nowiki></code> specifies the quadratic factor. These factors are plugged into the OpenGL light attenuation formula [[File:Spotlight_attenuation.png]] where d is the distance of the fragment to the light source. See this [http://wiki.ogre3d.org/tiki-index.php?page=-Point+Light+Attenuation table] for a list of attenuation values based on the range of the light.
* <tt>'''range-m'''</tt>. Maximum range from the light source position in meters. This value will be used by the renderers to determine if a fragment is illuminated by this source. Every fragment outside this range isn't guaranteed to be affected by the light, even if the attenuation factor isn't 0 in that particular fragment.
* <tt>'''spot-cutoff'''</tt>. Only available in <tt>spot</tt> lights. It specifies the maximum spread angle of a light source. Only values in the range 0 90 are accepted. If the angle between the direction of the light and the direction from the light to the fragment being lighted is greater than the spot cutoff angle, it won't be lit.
* <tt>'''spot-exponent'''</tt>. Only available in <tt>spot</tt> lights. Higher spot exponents result in a more focused light source, regardless of the spot cutoff angle.
* <tt>'''dim-factor'''</tt> ('''Optional'''). Controls the dimming of the light source through an [[Expressions|expression]].
* <tt>'''debug-color'''</tt> ('''Optional'''). Sets the color of the debug light volume. By default it's red.
'''Important: '''The following parameters are '''only''' available in the [[HDR Pipeline]].
* <tt>'''color'''</tt>. The color or hue of emitted light. It is expected to be in the sRGB color space.
* <tt>'''intensity'''</tt>. The brightness of the light. This value can be (and will almost always be) higher than 1.
When using the [[HDR Pipeline]], these parameters replace the legacy paramaters: '''ambient''', '''diffuse''', '''specular''', and '''attenuation'''.
|}

=== Shadows ===

The shadow mapping algorithm can be customized entirely by the rendering pipeline. This means that each pipeline will have its own requirements when it comes to shadows. Here are some general recommendations:

* Use the [[Howto:Animate models#Noshadow|<tt>noshadow</tt> animation]] to disable shadows on objects that don't need them. An example would be billboarded lights (light sprites) or really small cockpit elements that don't need shadows and would cause degraded performance.
If the casted aircraft shadow appears blocky then there probably are some objects which need the noshadow animation applied. Most notably are billboarded lights which include [[ALS_technical_notes#ALS procedural lights|ALS procedural lights]].
* Try to mark as many cockpit objects as possible as <tt>interior</tt>.
<syntaxhighlight lang="xml">
<model>
<name>interior</name>
<usage>interior</usage>
<path>Aircraft/JA37/Models/ja37-interior.xml</path> 
</model>
</syntaxhighlight>
* Unlike in Rembrandt, polygons facing the Sun are the ones used to generate the shadow map, so single sided surfaces and non-closed objects should be rendered correctly.

== Effects and Shaders ==

=== Schemes ===

Effects can have different implementations depending on the Compositor pipeline being used. For example, a grass Effect implemented for a high quality pipeline might have much more detail than one that targets low specification machines. Still, they both implement the "look" of grass, so they share the same Effect file (grass.eff).

The Compositor chooses which implementation of an Effect to render based on the <tt><scheme></tt> of the techniques.
<syntaxhighlight lang="xml">
<technique n="15">
<scheme>test-scheme</scheme>
[...]
</technique>
</syntaxhighlight>

In this case the technique will be chosen if the Compositor pipeline <tt><scene></tt> pass uses the <tt>test-scheme</tt> Effect scheme. Consequently, porting an Effect to a Compositor pipeline will require knowing which Effect schemes it uses and writing a technique for each one. The only exception to this is the Classic/default pipeline, which uses techniques with no scheme.

=== Built-in uniforms ===

The Compositor provides a set of built-in uniforms that are passed along to every shader. These uniforms must '''not''' be defined in the Effect file, as they are defined and updated in C++.

{|class="wikitable" style="font-size: 85%; width: auto; table-layout: fixed;
!Name
!Type
!Description
|-
|<tt>fg_TextureMatrix</tt>
|<tt>mat4</tt>
|Texture matrix that replaces the old fixed-function behaviour. If no texture animations are present it corresponds to the identity matrix.
|-
|<tt>fg_Viewport</tt>
|<tt>vec4</tt>
|Viewport geometry for the current pass (x, y, width, height).
|-
|<tt>fg_PixelSize</tt>
|<tt>vec2</tt>
|Inverse of the width and height of the viewport.
|-
|<tt>fg_ViewMatrix</tt>
|<tt>mat4</tt>
|View matrix given by CameraGroup for this Compositor.
|-
|<tt>fg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|Inverse of the view matrix given by CameraGroup for this Compositor.
|-
|<tt>fg_ProjectionMatrix</tt>
|<tt>mat4</tt>
|Projection matrix given by CameraGroup for this Compositor.
|-
|<tt>fg_ProjectionMatrixInverse</tt>
|<tt>mat4</tt>
|Inverse of the projection matrix given by CameraGroup for this Compositor.
|-
|<tt>fg_PrevViewMatrix</tt>
|<tt>mat4</tt>
|Previous frame view matrix given by CameraGroup for this Compositor.
|-
|<tt>fg_PrevViewMatrixInverse</tt>
|<tt>mat4</tt>
|Previous frame inverse of the view matrix given by CameraGroup for this Compositor.
|-
|<tt>fg_PrevProjectionMatrix</tt>
|<tt>mat4</tt>
|Previous frame projection matrix given by CameraGroup for this Compositor.
|-
|<tt>fg_PrevProjectionMatrixInverse</tt>
|<tt>mat4</tt>
|Previous frame inverse of the projection matrix given by CameraGroup for this Compositor.
|-
|<tt>fg_CameraPositionCart</tt>
|<tt>vec3</tt>
|Position of the camera in world space, expressed in cartesian coordinates.
|-
|<tt>fg_CameraPositionGeod</tt>
|<tt>vec3</tt>
|Position of the camera in world space, expressed in geodesic coordinates (longitude in radians, latitude in radians, elevation in meters).
|-
|<tt>fg_CameraDistanceToEarthCenter</tt>
|<tt>float</tt>
|Distance from the camera to the center of the Earth in meters.
|-
|<tt>fg_CameraWorldUp</tt>
|<tt>vec3</tt>
|Camera up vector in world space.
|-
|<tt>fg_CameraViewUp</tt>
|<tt>vec3</tt>
|Camera up vector in view space.
|-
|<tt>fg_EarthRadius</tt>
|<tt>float</tt>
|Earth radius right below the camera position in meters.
|-
|<tt>fg_NearFar</tt>
|<tt>vec2</tt>
|Near and far clipping planes in meters. x component is the near plane, y component is the far plane.
|-
|<tt>fg_Fcoef</tt>
|<tt>float</tt>
|Used by logarithmic depth.
|-
|<tt>fg_FOVScale</tt>
|<tt>vec2</tt>
|Used by logarithmic depth.
|-
|<tt>fg_SunDirection</tt>
|<tt>vec3</tt>
|Normalized Sun (directional light) direction in view space.
|-
|<tt>fg_SunDirectionWorld</tt>
|<tt>vec3</tt>
|Normalized Sun (directional light) direction in world space.
|-
|<tt>fg_SunZenithCosTheta</tt>
|<tt>float</tt>
|Dot product between the Sun direction and the up vector at the camera position.
|-
|<tt>fg_MoonDirection</tt>
|<tt>vec3</tt>
|Normalized Moon (directional light) direction in view space.
|-
|<tt>fg_MoonDirectionWorld</tt>
|<tt>vec3</tt>
|Normalized Moon (directional light) direction in world space.
|-
|<tt>fg_MoonZenithCosTheta</tt>
|<tt>float</tt>
|Dot product between the Moon direction and the up vector at the camera position.
|}

== Creating a custom rendering pipeline ==

Since the Compositor is completely data-driven, new rendering pipelines can be created by writing a custom XML pipeline definition. This section tries to document most of the available parameters, but the best and most up-to-date resource is the Compositor parsing code in SimGear ({{simgear file|simgear/scene/viewer}}). See existing pipelines in {{fgdata file|Compositor}} for practical examples on how to use these parameters.

Also keep in mind that every pipeline element can be enabled/disabled through a [[Conditions|<condition> block]]. This allows for dynamic rendering pipelines that have toggleable features. However, the pipeline can't be updated in real-time: the simulator has to be restarted or the Compositor has to be reloaded through the <tt>reload-compositor</tt> [[Fgcommands|fgcommand]].

=== Buffers ===

A buffer represents a texture or, more generically, a region of GPU memory.

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>name</tt>
| {{No}}
| string
|
| Passes will be able to address the buffer by this name
|-
! scope="row"| <tt>type</tt>
| {{No}}
| <tt>1d, 2d, 2d-array, 2d-multisample, 3d, rect, cubemap</tt>
|
| Any texture type allowed by OpenGL
|-
! scope="row"| <tt>width</tt>
| {{No}}
| Any unsigned integer or <tt>screen</tt> to use the physical viewport width. The <code><property></code> tag can also be used to use a property value
|
| Texture width
|-
! scope="row"| <tt>screen-width-scale</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
| If <tt>screen</tt> was used, this controls the width scaling factor
|-
! scope="row"| <tt>height</tt>
| {{No}}
| Any unsigned integer or <tt>screen</tt> to use the physical viewport height. The <code><property></code> tag can also be used to use a property value
|
| Texture height
|-
! scope="row"| <tt>screen-height-scale</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
| If <tt>screen</tt> was used, this controls the height scaling factor
|-
! scope="row"| <tt>depth</tt>
| {{No}}
| Any unsigned integer. The <code><property></code> tag can also be used to use a property value
|
| Texture depth
|-
! scope="row"| <tt>format</tt>
| {{Yes}}
| See {{simgear file|simgear/scene/viewer/CompositorBuffer.cxx}} for the latest available values
| <tt>rgba8</tt>
| Specifies the texture format. It corresponds to the ''internalformat'', ''format'' and ''type'' arguments of the OpenGL function ''glTexImage2D''
|-
! scope="row"| <tt>min-filter, mag-filter</tt>
| {{Yes}}
| <tt>linear, linear-mipmap-linear, linear-mipmap-nearest, nearest, nearest-mipmap-linear, nearest-mipmap-nearest</tt>
| <tt>linear</tt>
| Change the minification and magnification filtering respectively
|-
! scope="row"| <tt>wrap-s, wrap-t, wrap-r</tt>
| {{Yes}}
| <tt>clamp, clamp-to-edge, clamp-to-border, repeat, mirror</tt>
| <tt>clamp-to-border</tt>
| They change the wrap mode for each coordinate
|-
! scope="row"| <tt>anisotropy</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
|
|-
! scope="row"| <tt>border-color</tt>
| {{Yes}}
| vec4
| <tt>(0.0f, 0.0f, 0.0f, 0.0f)</tt>
|
|-
! scope="row"| <tt>shadow-comparison</tt>
| {{Yes}}
| bool
| <tt>true</tt>
|
|-
! scope="row"| <tt>shadow-texture-mode</tt>
| {{Yes}}
| <tt>luminance, intensity, alpha</tt>
| <tt>luminance</tt>
|
|-
! scope="row"| <tt>shadow-compare-func</tt>
| {{Yes}}
| <tt>never, less, equal, lequal, greater, notequal, gequal, always</tt>
| <tt>lequal</tt>
|
|}

=== Passes ===

A pass wraps around an [http://public.vrac.iastate.edu/vancegroup/docs/OpenSceneGraphReferenceDocs-3.0/a00089.html osg::Camera]. Passes all have some common parameters:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>clear-color, clear-accum, clear-depth and clear-stencil</tt>
| {{Yes}}
| vec4
| black, black, <tt>1.0</tt>, <tt>0</tt> respectively
| Pass clear colors
|-
! scope="row"| <tt>clear-mask</tt>
| {{Yes}}
| <tt>color, stencil, depth, accum</tt>
| <tt>color depth</tt>
| Pass clear mask
|-
! scope="row"| <tt>effect-scheme</tt>
| {{Yes}}
| Valid effect scheme name
| None
| The pass will try to use the specified effect scheme to draw every object.
|}

Passes can render to a buffer (Render to Texture), to several buffers (Multiple Render Targets) or directly to the framebuffer. This is accomplished by the <code><attachment></code> tag. Possible parameters of an attachment are:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>buffer</tt>
| {{No}}
| Valid buffer name
|
| The name of the buffer to output to
|-
! scope="row"| <tt>component</tt>
| {{No}}
| <tt>color, color0</tt> to <tt>color15, depth, stencil, depth-stencil</tt>
|
| FBO attachment point
|-
! scope="row"| <tt>level</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Mipmap level of the texture that is attached
|-
! scope="row"| <tt>face</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Face of cube map texture or z-level of 3d texture
|-
! scope="row"| <tt>mipmap-generation</tt>
| {{Yes}}
| bool
| <tt>false</tt>
| Whether mipmap generation should be done for texture
|-
! scope="row"| <tt>multisample-samples</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Multisample anti-aliasing (MSAA) samples
|-
! scope="row"| <tt>multisample-color-samples</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Multisample anti-aliasing (MSAA) color samples
|}

Passes can also receive buffers as input and use them in their shaders. This is accomplished by the <code><binding></code> tag, which has the following parameters:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>buffer</tt>
| {{No}}
| Valid buffer name
|
| The name of the buffer to bind
|-
! scope="row"| <tt>unit</tt>
| {{No}}
| int
|
| The texture unit to place the texture on. Effects will be able to access the buffer on this texture unit
|}

There are specific pass types, each with their own set of custom parameters.

==== scene ====
Renders the scene from the point of view given by the CameraGroup.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>cull-mask</tt>
| {{Yes}}
| A 32 bit number. See {{simgear file|simgear/scene/util/RenderConstants.hxx}} to know which bits enable what
| <tt>0xffffffff</tt>
| Specifies the cull mask to be used in the underlying <tt>osg::Camera</tt>
|-
! scope="row"| <tt>z-near, z-far</tt>
| {{Yes}}
| float
| 0.0 uses the value given by the CameraGroup
| Sets a custom near and far values. Useful for implementing depth partition and limiting the depth range on cubemap passes
|-
! scope="row"| <tt>cubemap-face</tt>
| {{Yes}}
| int
| <tt>-1</tt> (don't use cubemap)
| Ignores the given view and projection matrices and uses a custom one that renders the scene as if it was seen from inside a cubemap looking towards the specified face
|-
! scope="row"| <tt>use-shadow-pass</tt>
| {{Yes}}
| string
| Empty
| Name of a shadow mapping pass. Exposes shadow mapping related uniforms to the shaders of the current pass
|}

Scene passes can also use the tag <code><clustered-shading></code> to enable clustered shading (lights). The following parameters are available:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>max-pointlights</tt>
| {{Yes}}
| int
| 1024
| Maximum amount of point light sources allowed on the entire scene
|-
! scope="row"| <tt>max-spotlights</tt>
| {{Yes}}
| int
| 1024
| Maximum amount of spot light sources allowed on the entire scene
|-
! scope="row"| <tt>max-light-indices</tt>
| {{Yes}}
| int
| 256
| Size of the light indices texture. Keep in mind that it is a 2D texture, so the total size will be e.g. 256x256
|-
! scope="row"| <tt>tile-size</tt>
| {{Yes}}
| int
| 128
| Size of each clustered shading tile
|-
! scope="row"| <tt>num-threads</tt>
| {{Yes}}
| int
| 1
| Number of threads to use during the light culling process. Keep in mind that a high thread count when there aren't many lights will worsen performance due to the thread creation overhead
|-
! scope="row"| <tt>depth-slices</tt>
| {{Yes}}
| int
| 1
| Number of slices to partition the view frustum in the Z axis. Higher numbers will cull lights more aggressively, increasing performance if there are many lights further out that don't contribute much to the overall scene's lighting
|}

==== quad ====
Renders a fullscreen quad with an optional [[Effects|effect]] applied. Useful for screen space shaders (like SSAO, Screen Space Reflections or bloom) and deferred rendering.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>geometry</tt>
| {{Yes}}
| float values for <code><x>, <y>, <width>, <height>, <scale></code>
| <tt>0.0, 0.0, 1.0, 1.0, 1.0</tt> respectively
| Size of the fullscreen quad inside the viewport using normalized coordinates.
|-
! scope="row"| <tt>effect</tt>
| {{Yes}}
| Valid Effect file
| None
| This Effect will be applied to the quad geometry
|}

==== csm ====
Implements Cascaded Shadow Mapping by rendering the scene from a light's point of view (the Sun by default). For now it only supports directional light sources. There has to be one <tt>csm</tt> pass for each cascade.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>light-name</tt>
| {{Yes}}
| Valid light name that exists in the scene graph
| <tt>FGLightSource</tt> (Sun)
| The name of the <tt>osg::LightSource</tt> to use for this shadow map
|-
! scope="row"| <tt>render-at-night</tt>
| {{Yes}}
| bool
| true
| Whether to render the shadows at night or not
|-
! scope="row"| <tt>near-m, far-m</tt>
| {{No}}
| float (meters)
|
| They specify the range of the shadow map
|}

== References ==
{{Appendix}}

== Related content ==
=== Wiki articles ===
* [[HDR Pipeline]]
* [[glTF]]
* [[Canvas View Camera Element]]
* [[CompositeViewer Support]]
* [[Uniform Buffer Objects]]
* [[FlightGear CIGI Support (Common Image Generator Interface)]]

=== Forum topics ===
* {{forum link|t=36269|text=The Compositor}}
* {{forum link|t=35095|text=Clustered Forward Rendering}} (12/2018)
* {{forum link|t=33045|text=Getting started with RTT}}

[[Category:Compositor]]

Building FlightGear - Devuan

2025-07-05T19:06:14Z

SammySkycrafts: fix fgdata repo link typo

How-To build [[FlightGear]] on [https://devuan.org/ Devuan] GNU/Linux Stable (Daedalus). Instructions probably apply to [https://debian.org/ Debian] GNU/Linux Bookworm, too.

The meaning of this article is to be a short, ''checklist'' like, overview of the specific steps to compile FlightGear and components on Devuan. For more detailed information please refer to the main article [[Building_FlightGear_-_Linux | Building FlightGear on Linux]].

[[File:Zeichen_144_icon.png|21px]] For beginners with compiling it is highly recommended to follow this guide step by step. Any modification to most of the herein used commands will cause trouble.

== Requirements and Preparations ==
A bunch of packages (as well as some of their dependencies) are required to compile FlightGear:

'''Tools'''
su - -c "apt-get install cmake g++ gcc git make sed"

'''Dependencies'''
: If you prefer you might replace <code>libcurl4-openssl-dev</code> by <code>libcurl4-gnutls-dev</code>.
: On Debian replace <code>libeudev-dev</code> with <code>libudev-dev</code>.
: For VR support add package <code>libopenxr-dev</code> to the list below.
: [[File:Zeichen_144_icon.png|21px]] During installation development packages of libraries which are going to be compiled ''must not'' be installed. They can safely be re-installed after compilation. Namely these are <code>libc-ares-dev</code>, <code>libplib-dev</code>, <code>libpopenscenegraph-dev</code> and <code>libsimgear-dev</code>.
su - -c "apt-get remove libc-ares-dev libopenscenegraph-dev libplib-dev libsimgear-dev"

su - -c "apt-get install freeglut3-dev libavcodec-dev libavformat-dev libboost-dev libcurl4-openssl-dev libdbus-1-dev libeudev-dev libevent-dev libfreetype6-dev libglew-dev libjpeg62-turbo-dev liblzma-dev libopenal-dev libqt5quick5 libqt5svg5-dev librsvg2-dev libswscale-dev libxi-dev libxmu-dev pkg-config qtbase5-dev qtbase5-private-dev qtdeclarative5-dev qttools5-dev zlib1g-dev"

== Build and install ==
Some things require customisation. We'll use [https://wiki.debian.org/EnvironmentVariables environment variables] for them: 
: '''FG_VERSION''' – The version of FlightGear to build and install. This is either <code>next</code> (for the bleeding edge development branch) or a release number in the form <code>release/2024.1</code>. For a list of valid releases see [https://sourceforge.net/p/flightgear/flightgear/ref/next/branches/ here]. 
: '''FG_SRC_DIR''' – The absolute path to the directory which is supposed to hold the source codes. In case your user belongs to the group ''staff'', <code>/usr/local/src/</code> would be an appropriate location. But any location is fine, too, e.g. <code>$HOME/src/</code>. In any case the user has to have write access there. 
: '''FG_INSTALL_DIR''' – The absolute path to where FlightGear is going to be installed. Again, <code>/usr/local/</code> is appropriate, if your user belongs to ''staff''. But any location where the user has write access is ok, e.g. <code>$HOME/FlightGear/</code>. 

# Examples, adapt to your own needs:
export FG_VERSION=release/2024.1 #OR# export FG_VERSION=next
export FG_SRC_DIR=$HOME/src/
export FG_INSTALL_DIR=$HOME/FlightGear/
: Remember to export these variables in each console you use in the process.
From here on it should™ be possible to just copy and paste the entire content of each code box at once into the console.
# Create specified directories if they do not exist:
mkdir -p $FG_SRC_DIR
mkdir -p $FG_INSTALL_DIR

For more/advanced cmake options and SimGear's and FlightGear's optional features see the [[Building_using_CMake#Optional_Features|cmake]] article.

[[File:Zeichen_144_icon.png|21px]] Do '''not''' mix versions for SimGear, FlighGear and fgdata! Mixing versions will almost certainly break the installation.

=== libc-ares ===
This step is only required to compile FlightGear 'next':
cd $FG_SRC_DIR
<nowiki>git clone https://github.com/c-ares/c-ares.git libc-ares.git</nowiki>
cd libc-ares.git
git checkout v1.34.2
mkdir -p $FG_SRC_DIR/build-c-ares && cd $FG_SRC_DIR/build-c-ares
cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_INSTALL_PREFIX="$FG_INSTALL_DIR" $FG_SRC_DIR/libc-ares.git
make -j$(nproc)
make install

=== [[plib|libplib]] ===
While just installing package libplib-dev should work, it's [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended] to build it from source. In this case libplib-dev ''must not'' be installed during the installation process of Simgear and Flightgear!
cd $FG_SRC_DIR
<nowiki>git clone git://git.code.sf.net/p/libplib/code libplib.git</nowiki>
cd libplib.git
echo "1.8.6" > version
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
git commit --all --message "Increase tiny version to 6."
mkdir -p $FG_SRC_DIR/build-plib && cd $FG_SRC_DIR/build-plib
cmake -D CMAKE_INSTALL_PREFIX:PATH="$FG_INSTALL_DIR" $FG_SRC_DIR/libplib.git
make -j$(nproc)
make install

=== [[OpenSceneGraph]] ===
To compile FlightGear release version branch <code>release/2024-build</code> is required, for FlightGear next branch <code>next</code>.
if [ "$FG_VERSION" = "release/2024.1" ]; then export FG_OSG_VERSION=release/2024-build; fi
if [ "$FG_VERSION" = "next" ]; then export FG_OSG_VERSION=next; fi

cd $FG_SRC_DIR
<nowiki>git clone https://gitlab.com/flightgear/openscenegraph.git FG-OpenSceneGraph.git</nowiki>
cd FG-OpenSceneGraph.git
git checkout $FG_OSG_VERSION
mkdir -p $FG_SRC_DIR/build-osg && cd $FG_SRC_DIR/build-osg
cmake -D LIB_POSTFIX="" -D CMAKE_INSTALL_PREFIX:PATH="$FG_INSTALL_DIR" $FG_SRC_DIR/FG-OpenSceneGraph.git
make -j$(nproc)
make install



=== [[SimGear]] ===
cd $FG_SRC_DIR
<nowiki>git clone https://gitlab.com/flightgear/simgear.git simgear.git</nowiki>
cd simgear.git
git checkout $FG_VERSION
mkdir -p $FG_SRC_DIR/build-sg && cd $FG_SRC_DIR/build-sg
cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_INSTALL_PREFIX:PATH="$FG_INSTALL_DIR" $FG_SRC_DIR/simgear.git
make -j$(nproc)
make install


=== [[FGData|FlightGear data]] ===
mkdir -p $FG_INSTALL_DIR/share && cd $FG_INSTALL_DIR/share
git clone https://gitlab.com/flightgear/fgdata<nowiki/>.git fgdata
cd fgdata
git checkout $FG_VERSION

=== FlightGear source ===
cd $FG_SRC_DIR
<nowiki>git clone https://gitlab.com/flightgear/flightgear.git flightgear.git</nowiki>
cd flightgear.git
git checkout $FG_VERSION
mkdir -p $FG_SRC_DIR/build-fg && cd $FG_SRC_DIR/build-fg
cmake -D CMAKE_BUILD_TYPE=Release -D FG_BUILD_TYPE=Release -D FG_DATA_DIR:PATH="$FG_INSTALL_DIR/share/fgdata" -D CMAKE_INSTALL_PREFIX:PATH="$FG_INSTALL_DIR" $FG_SRC_DIR/flightgear.git
make -j$(nproc)
make install


== Trial run and finishing process ==
When all the builds are done and the data download has finished it is time for a test run. In case your FG_INSTALL_DIR is <code>/usr/local/</code>, just run <code>fgfs --launcher</code>.

In case it's anywhere else on the system, things are a tad more complicated:
export LD_LIBRARY_PATH=$FG_INSTALL_DIR/lib/:$LD_LIBRARY_PATH
$FG_INSTALL_DIR/bin/fgfs --launcher
: The <code>fgfs</code> binary needs to find our self compiled libraries at runtime and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.
: Since [http://www.linfo.org/path_env_var.html $PATH] most likely does not cover the FG_INSTALL_DIR, the full path to the fgfs binary is required to run it.
: Even though it's a tad more laborious than installing it to <code>/usr/local/</code>, this approach has the advantage of easlily managing several FlightGear installations.

To make it permanent and less complicated one option would be to create an alias:
echo -e "alias fgfs='LD_LIBRARY_PATH=$FG_INSTALL_DIR/lib/:$LD_LIBRARY_PATH $FG_INSTALL_DIR/bin/fgfs' \n" >> $HOME/.bashrc
source $HOME/.bashrc
: Now running <code>fgfs --launcher</code> will start the simulator.

To keep the source code git repos up to date have a look at our [[Git_for_Laymen#Keeping_it_current|git for laymen]] section.

== Uninstalling ==
To uninstall Flightgear and its components from e.g. <code>/usr/local/</code>, run <code>make uninstall</code> inside each software's build directory:
cd $FG_SRC_DIR/build-fg && make uninstall
cd $FG_SRC_DIR/build-sg && make uninstall
cd $FG_SRC_DIR/build-osg && make uninstall; rm -R $FG_SRC_DIR/lib/osgPlugins-3.6.5
rm -RI $FG_INSTALL_DIR/include/plib; rm $FG_INSTALL_DIR/lib/libplib*.a
rm -RI $FG_INSTALL_DIR/share/fgdata

Please report issues or any kind of feedback to the [[Talk:Building_FlightGear_-_Devuan|talk page]].

{{Building}}

Addon

2025-02-28T16:00:06Z

SammySkycrafts: Update wording for launcher method of addon installation

[[File:Fgaddonslogo202x89.png|right]]
To make it easier to create '''addons''' there is since FlightGear 2017.3 a new way to create addons. In essence FlightGear will load an overlay XML into the property tree and start a well known Nasal function.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=314620#p314620
|title = <nowiki> Re: New Feature: Addon - "API" </nowiki>
|author = <nowiki> Torsten </nowiki>
|date = Jul 19th, 2017
|added = Jul 19th, 2017
|script_version = 0.40
}}</ref>

We now have a simple way to add addons to FlightGear without the need to mess around with <code>FGData/Nasal</code> or <code>FGHome/Nasal</code> directories.<ref name="Forum_announcement">{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=314563#p314563
|title = <nowiki> New Feature: Addon - "API" </nowiki>
|author = <nowiki> Torsten </nowiki>
|date = Jul 18th, 2017
}}</ref>

{{TOC limit|3}}

== Installing and using an addon ==
Download and copy the addon to a directory on your computer.

If you use the launcher, select the Add-ons page from the icon bar on the left, then find the section Add-on Module folders and click the Add(+) button. Select the folder where you put the addon. Once the addon is shown in the list, make sure its check box is selected.

Or alternatively, use the command line switch <code>--addon=/path/to/some/addon</code><ref name="Forum_announcement"/> if you are not using the launcher.

== Creating an addon ==
There is a very simple Skeleton addon available in FGAddon to be used as a template.<ref name="Forum_announcement"/> See {{fgaddon source|path=Addons/Skeleton}}.

A leading slash (<code>/</code>) in this section indicates the base directory of the directory structure of the addon.

=== Minimum configuration ===
An addon may be installed in a directory anywhere on your hard disk and need at least two files:

* <code>/addon-config.xml</code> - A standard [[PropertyList XML files|PropertyList XML file]] to be used to populate or modify the [[property tree]]. (Same as to be used in <code>--config=foo.xml</code>)
* <code>/addon-main.nas</code> - The Nasal hook for the logic. This file needs a function called <code>main()</code> which will be called from the global addon initializer (<code>addons.nas</code>)

=== Additional common files ===
* <code>/addon-metadata.xml</code> - A PropertyList XML file with metadata about the addon it.
* <code>/addon-menubar-items.xml</code> - A PropertyList XML file describing menus to be added to the FlightGear menu bar.
* <code>/gui/dialogs/<my-foobar-dialog>.xml</code> - PropertyList XML files to create custom dialogs.

=== Good to know ===
The new addon mechanism lets you add a <code>addon-config.xml</code> to override the settings in <code>defaults.xml</code> and other files.

That will allow an addon to
* Override key bindings (as in the spoken ATC addon)
* Add or override autopilots and property rules
* Introduce XML state machines

Unless your really want to add/change/remove those at runtime, this should cater for most use cases.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=314902#p314902
|title = <nowiki> Re: Spoken </nowiki>
|author = <nowiki> Torsten </nowiki>
|date = Jul 23rd, 2017
|added = Jul 23rd, 2017
|script_version = 0.40
}}</ref>

We have some instructions how to use SVN [[FGAddon|in our wiki]]. It covers mostly aircraft development but the workflow is pretty much the same for addons.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=314647#p314647
|title = <nowiki> Re: Spoken ATC </nowiki>
|author = <nowiki> Torsten </nowiki>
|date = Jul 19th, 2017
|added = Jul 19th, 2017
|script_version = 0.40
}}</ref>

=== Sound Support ===
Sound support is available using fgcommand's.

See [[Nasal FAQ]] "play-audio-sample"

https://sourceforge.net/p/flightgear/flightgear/ci/5acf2e26d085b7553b2387b9753e9253e8b4bff4

[[Hackathon Proposal:Addon specific Sound Queues]]

== Addon initialization ==
On initialization fgfs takes care of:
* Through {{flightgear source|path=src/Main/options.cxx|text=<code>options.cxx</code>}}:<ref name="Forum_announcement"/>
** Creating a property under <code>/addons/addon[n]/path=/path/to/some/addon</code>
** Loading <code>/path/to/some/addon/addon-config.xml</code> into the property tree (same as <code>--config=/path/to/some/addon/addon-config.xml</code>)
** Adding <code>/path/to/some/addon</code> to the list of allowed directories (same as <code>--fg-aircraft=/path/to/some/addon</code>)
* Through {{fgdata source|path=Nasal/addons.nas|text=<code>addons.nas</code>}}:
** Loading <code>/foo/bar/baz/addon-main.nas</code> into namespace <code>__addon[ADDON_ID]__</code>
** Calling <code>main(addonGhost)</code> from <code>/foo/bar/baz/addon-main.nas</code>.

== Aircraft specific config (addon-hints) ==
Some addons need per-aircraft configuration. While addons should strive to be self-contained (ie. the addon should contain means to
detect different aircraft and apply config from whithin the addon) there is also the possibility for the addon to read so called "addon-hints".

For this, a special property tree exists: <code>/sim/addon-hints/<addon>/...</code>
The tree is expected to be populated from the aircraft.xml file. The addon can then read the properties from a common place regardless of loaded aircraft.

<syntaxhighlight lang="xml">
<sim>
<addon-hints>
<my-addon>
...
</my-addon>
</addon-hints>
</sim>
</syntaxhighlight>

== APIs ==
{{hatnote|For more details about these APIs, see the readme file, {{readme file|add-ons}}.}}
=== C++ API ===
There is a C++ API on FlightGear's side that handle some on the addon related tasks manly through the <code>AddonManager()</code>, <code>Addon()</code> and <code>AddonVersion()</code> classes.

=== Nasal API ===
The Nasal add-on API lives in the 'addons' namespace and can for example do queries to <code>AddonManager()</code> and read data from <code>addons.Addon</code> objects. It can for example compare addon versions if there is dependencies.

See: {{Repo link|site=gitlab|proj=flightgear|repo=fgdata|branch=next|path=Nasal/addons.nas}}

== Background ==
{{See also|Howto:Creating a simple modding framework}}

ATC chatter was removed in 2015, see fgdata commit: [https://sourceforge.net/p/flightgear/fgdata/ci/81607f734e13add9be02816ddaec305d05bc4e47/ 81607f734e13add9be02816ddaec305d05bc4e47]

And the devel list messages referenced in the commit log.
the other relevant commit is this: b60736ba7add2a7cd39af3d8a974d5be3ea46e8b
It would not be very difficult to restore this functionality, or even generalize/improve it significantly (which was the scope of the original discussion on the devel list)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=288388#p288388
|title = <nowiki> Re: Whatever happened to radom radio </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 11th, 2016
|added = Jun 11th, 2016
|script_version = 0.40
}}</ref>

The restored functionality could be distributed as a tarball that is extracted into $FG_ROOT - alternatively, into $FG_HOME, because Nasal files there are treated as overlays, which basically means that you can install user-specific extensions there without having to tamper with $FG_ROOT, it would only take very minor changes to turn the chatter feature into a corresponding "addon" - not unlike fgcamera ...<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=288392#p288392
|title = <nowiki> Re: Whatever happened to radom radio </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Jun 11th, 2016
|added = Jun 11th, 2016
|script_version = 0.40
}}</ref>

We should absolutely stop telling anyone to edit preferences.xml in FG_ROOT; any documentation or advice which says to should be changes ASAP. <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=192632#p192632
|title = <nowiki> Re: NavCache:init failed:Sqlite error:Sqlite API abuse </nowiki>
|author = <nowiki> zakalawe </nowiki>
|date = Oct 26th, 2013
|added = Oct 26th, 2013
|script_version = 0.40
}}</ref>

As of 12/2017, the addon API is in the process of being significantly updated <ref>https://sourceforge.net/p/flightgear/mailman/message/36146017/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36150159/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36150444/</ref>

== List of Addons ==
You can find the official repository at {{fgaddon source|path=Addons}}

* [https://github.com/slawekmikula/flightgear-addon-hudheli Additional Heli HUD's] - ([https://github.com/slawekmikula/flightgear-addon-hudheli/blob/master/doc/manual.md manual]) - encapsulation of HeliHUD package as an addon
* [https://github.com/PlayeRom/flightgear-addon-aerotow-everywhere Aerotow Everywhere] AI towing aircraft for gliders at every airport.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=40742
|title = <nowiki> Re: Aerotow Everywhere </nowiki>
|author = <nowiki> Roman Ludwicki (PlayeRom) </nowiki>
|date = Aug 14th, 2022
|added = Aug 14th, 2022
|script_version = 0.40
}}</ref>
* [https://github.com/SP-NTX/AnotherGUI AnotherGUI] - An add-on that adds a new GUI style.
* ATC Chatter (ported by Torsten) {{progressbar|100}}
* [[Blacklist add-on]] - Automatically ignore pilots with certain callsigns or multiplayer models.
* [[Cargo Towing Addon]] <ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=36824
|title = <nowiki> Re: Cargo Towing Addon </nowiki>
|author = <nowiki> Wayne Bragg (wlbragg) </nowiki>
|date =
|added =
|script_version = 0.40
}}</ref>
* cockpit-view (work in progress by wkitty42)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=316498#p316498
|title = <nowiki> Re: </nowiki>
|author = <nowiki> wkitty42 </nowiki>
|date = Aug 13th, 2017
|added = Aug 13th, 2017
|script_version = 0.40
}}</ref>
* [[Earthview#Customization]] - High resolution customization
* [[FaceTrackNoIR]] (ported by HHS)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36454826/
|title = <nowiki> Re: </nowiki>
|author = <nowiki> Unknown, HHS</nowiki>
|date = Nov 1th, 2018
}}</ref> - An addon to interface this [[Head tracking|head tracker]] with FlightGear
* [https://forum.flightgear.org/viewtopic.php?f=5&t=24792 Fencemaker] (Eases creating Fence-like scenery objects. Originally by VaLeo, converted to an addon by sfr) - ([https://www.mediafire.com/file/cf0la63v9g352md/fencemaker_addon.zip/file download])<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?f=5&t=24792&start=45#p390066
|title = <nowiki> Re: </nowiki>
|author = <nowiki> Stefan Frank </nowiki>
|maintainer = <nowiki> Stefan Frank </nowiki>
|date = Aug 8th, 2021
}}</ref>
* [https://github.com/PlayeRom/flightgear-addon-fgcamera FGCamera] - ([https://github.com/PlayeRom/flightgear-addon-fgcamera/blob/master/Docs/manual.md manual]) - [[FGCamera | Wiki Page]]
* [[FGPlot]]
* [[Ground Services]] (ported by ThomasS)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=316400#p316400
|title = <nowiki> Re: </nowiki>
|author = <nowiki> ThomasS </nowiki>
|date = Aug 12th, 2017
|added = Aug 12th, 2017
|script_version = 0.40
}}</ref>
* {{fgaddon source|path=Addons/Headtracker/|text=Headtracker addon}} Helps integrate FaceTrackNoIR and opentrack with FlightGear.
* [[HighAirTrader]] An in-sim mini game in which you transport goods to different airports.
* [https://github.com/tdammers/fg-hoppie-acars Hoppie ACARS client] - connect to [http://www.hoppie.nl/acars Hoppie's ACARS], used on VATSIM and other networks.
* [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Addons/Illuminator/ Illuminator] - configure lights attached to 3D models (e.g. taxi light, landing light or a light attached to a scenery model like a light pole) at runtime.
* [https://github.com/slawekmikula/flightgear-addon-protocolkml KML Exporter (Google Earth)] - ([https://github.com/slawekmikula/flightgear-addon-protocolkml/blob/master/doc/manual.md manual])
* [[Landing Rate addon]] [https://forum.flightgear.org/viewtopic.php?f=6&t=33101&p=327787#p327787]
* [https://github.com/slawekmikula/flightgear-addon-linuxtrack LinuxTrack Head Tracker integration] - ([https://github.com/slawekmikula/flightgear-addon-linuxtrack/blob/master/doc/manual.md manual])
* [https://github.com/slawekmikula/flightgear-addon-littlenavmap LittleNavMap integration] - ([https://github.com/slawekmikula/flightgear-addon-littlenavmap/blob/master/doc/manual.md manual])
* [https://github.com/PlayeRom/flightgear-addon-logbook Logbook] all your flights to CSV file.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?t=41070
|title = <nowiki> Re: Logbook Add-on </nowiki>
|author = <nowiki> Roman Ludwicki (PlayeRom) </nowiki>
|date = Dec 11th, 2022
|added = Dec 11th, 2022
|script_version = 0.40
}}</ref>
* [[Log time-stamper add-on]] - Will print simulated UTC time, real local time, and/or real UTC time time-stamps at configurable intervals to the console and log.
* [https://gitlab.com/mdanil/flightgear-hax mdanilov hax!]: landing evaluation and aircraft development tools, TerraSync toggler
* [[Model Cockpit View]]
* [https://github.com/SP-NTX/MPChatImprovments MPChatImprovments] Multi-key commands for Multiplayer, new features for chat,...
* [https://github.com/hbeni/fgfs-noGroundDamage noGroundDamage] - Addon to temporarily disable damage after landing and for ground operations for the c172/c182
* [[Oscilloscope addon]] - Allows displaying a property of Nasal function over time
* [[PAR instrument]] - Precision Approach Radar and Ground Controlled Approach
* [[Red Griffin ATC]] - Speaking Air Traffic Controller<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?f=6&t=36755
|title = <nowiki> Re: </nowiki>
|author = <nowiki> RedGriffin </nowiki>
|date = Jan 6th, 2020
|added = Jan 6th, 2020
|script_version = 1.0.0 RC2
}}</ref>
* [https://github.com/tdammers/fg-simbrief-addon SimBrief import] - Import flightplans, weights, fuel, and winds alof, from SimBrief.
* [[Spoken ATC]] (ported by Torsten)<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=314095#p314095
|title = <nowiki> Re: </nowiki>
|author = <nowiki> Torsten </nowiki>
|date = Jul 10th, 2017
|added = Jul 10th, 2017
|script_version = 0.40
}}</ref>
* [[Spoken GCA]] - An offline ground controlled approach (GCA) addon
* [https://gitlab.com/mdanil/flightgear-mickey Tiny HUD for mouse flying in FlightGear] - Visual feedback for mouse flying, to make up for mouse's lack of self-centering
* [https://github.com/slawekmikula/flightgear-addon-vfrflight VFRFlight integration] - ([https://github.com/slawekmikula/flightgear-addon-vfrflight/blob/master/doc/manual.md manual])
* [https://github.com/slawekmikula/flightgear-addon-vfrnavigator VFR Flying Helper] - ([https://github.com/slawekmikula/flightgear-addon-vfrnavigator/blob/master/doc/usage.md manual])
* [[YASim Development Tools]] (by jsb)

== Experimental Addons ==

Addons which are in the development stage/unfinished but can be used as a quick view of addon functionality
* [https://github.com/slawekmikula/flightgear-addon-missions FlightGear Missions addon] - Add-on for missions/adventures code

== Ideas ==
=== Hooking into features using legacy OpenGL code ===
{{See also|Unifying the 2D rendering backend via canvas}}
In 09/2018, James suggested that legacy features using raw OpenGL calls (e.g. HUD/2D panels) could be easily replaced via scripted Canvas/Nasal solutions at the mere cost of providing a mechanism to hook into the legacy code implementing these features (namely, the HUD/instrumentation subsystems) <ref>https://sourceforge.net/p/flightgear/mailman/message/36399261/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36399261/</ref>

=== Catalog & Package Manager support ===
if this works with more complex, pre-existing addons such as [[Bombable]], where the file layout is a replica of the old FGData layout, these types of mature addons might be better as SourceForge FlightGear sub-projects rather than being copied into FGAddon. Maybe the config file and nasal script could be used to automate the installation process ?<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35953179/
|title = <nowiki> Re: [Flightgear-devel] Simple API for creating FlightGear
addons/plugins </nowiki>
|author = <nowiki> Edward d'Auvergne </nowiki>
|date = Jul 19th, 2017
|added = Jul 19th, 2017
|script_version = 0.40
}}</ref>
The [[Bombable]] addon is one of the most popular addons out there, and a large number of aircraft in FGAddon have bombable support, so it is worth not forgetting about. Especially if the addon system one day becomes automated through a [[Catalog metadata|catalog.xml type system]]<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35953650/
|title = <nowiki> Re: [Flightgear-devel] Simple API for creating FlightGear
addons/plugins </nowiki>
|author = <nowiki> Edward d'Auvergne </nowiki>
|date = Jul 19th, 2017
|added = Jul 19th, 2017
|script_version = 0.40
}}</ref>

== References ==
{{Appendix}}

== Related content ==
=== Wiki articles ===
* [[FG Add-on FAQ]]
* [[Modules.nas]]
* [[FlightGear configuration via XML]]
* [[FlightGear configuration via XML#preferences.xml]]
* [[Nasal]]
* [[Property tree]]
* [[Properties persistent between sessions]]
* [[PropertyList XML File]]

=== Forum topics ===
* {{forum link|t=32561|title=New Feature: Addon - "API"}}

=== Readme files ===
* {{readme file|add-ons}}
* {{readme file|gui}} - Details on how to add menus and custom dialogs.

=== Source code ===
==== FGAddon ====
* {{fgaddon source|path=Addons/Skeleton}} - Skeleton addon to be used as a template.

==== FGData ====
* {{fgdata source|path=Nasal/addons.nas}}

==== FlightGear ====
* {{flightgear source|path=src/Main/options.cxx}}
* {{flightgear source|path=src/Add-ons/}}

[[Category:FlightGear addons| ]]

Howto:Install aircraft

2025-02-28T00:17:20Z

SammySkycrafts: Remove "Modify FGData" method of installing aircraft, replace with Launcher Folder option and explain the benefits

{{installing}}

The preferred option to install the latest official [[aircraft]] is through the ''Aircraft'' tab in the [[FlightGear Qt launcher|built-in launcher]], as explained in the following video. The remainder of this article describes the manual process, only to be performed when you don't use the aircrafts from the official FGAddon hangar.

{{#ev:youtube|a-UIrw7nEy4}}

== Manual installation process ==
Aircraft packages are available on [http://www.flightgear.org/download/ FlightGear.org Aircraft]. These require unzipping software to extract from a compressed file format. Then these must be manually installed in a FlightGear software installation to use. The details depend on the method of download, operating system, and user setup.

Alternatively if you are using the [[FlightGear Build Server|nightly builds]] or a [[Building FlightGear|version controlled copy of FlightGear]], or you wish to manage your aircraft collection using version control tools, the aircraft can be obtained directly from the [[FGAddon|official FlightGear aircraft repository - FGAddon]].

=== Linux ===
(Ubuntu 12.04)
# Download the aircraft
# Create a directory to store your aircraft if you have not already done so. Make sure this directory is outside <tt>/usr/share/games/flightgear/</tt>. For example, use <tt>/home/{YourUserName}/FlightGear/CustomAircraft</tt>.
# Extract your aircraft file into the folder (the one you created above)
#: unzip XXXXX.zip
# Start up FlightGear with Launcher. In Launcher, go to the ''Add-ons'' tab. In the ''Additional aircraft folders'' section, click the ''Add'' button and select the main folder for additional aircrafts (in our case <tt>/home/{YourUserName}/FlightGear/CustomAircraft</tt>). Now your plane should appear on the list of planes, otherwise restart FlightGear.

Now, you just need to unzip the next downloaded aircraft in the same directory and it should already be visible on FlightGear.

=== Macintosh OS X ===

# Download the aircraft
# Create a directory to store your aircraft if you have not already done so. Make sure this directory is somewhere you can find easily, For example, use <code>/Users/{YourUserName}/Aircraft</code>.
# Extract your aircraft file into the folder (the one you created above)
# Start up FlightGear with Launcher. In Launcher, go to the ''Add-ons'' tab. In the ''Additional aircraft folders'' section, click the ''Add'' button and select the main folder for additional aircrafts (in our case <code>/Users/{YourUserName}/Aircraft</code>). Now your plane should appear on the list of planes, otherwise restart FlightGear.

Now, you just need to unzip the next downloaded aircraft in the same directory and it should already be visible on FlightGear. This method is preferred over modifying FGData as it allows you to more easily access the aircrafts files, as well as having the benefit of persisting across FG updates, saving the hassle of having to redownload and install your aircraft each time you update FlightGear.

=== Windows ===
# Download an aircraft and save it on your desktop.
# Unzip the file using a file archiver, for example the open source file archiver [http://www.7-zip.org/ 7-Zip].
# Create a directory to store your aircraft if you have not already done so. Make sure this directory is outside your <tt>[[$FG_ROOT]]</tt> directory. For example, use <tt>C:\Users\{YourUserName}\FlightGear\CustomAircraft</tt>.
# Move the unzipped folder (usually the aircraft's name) to your that aircraft directory.
# Start up FlightGear with Launcher. In Launcher, go to the ''Add-ons'' tab. In the ''Additional aircraft folders'' section, click the ''Add'' button and select the main folder for additional aircrafts (in our case <tt>C:\Users\{YourUserName}\FlightGear\CustomAircraft</tt>). Now your plane should appear on the list of planes, otherwise restart FlightGear.

Now, you just need to unzip the next downloaded aircraft in the same directory and it should already be visible on FlightGear.

=== From the command line ===
Launching FlightGear from the command line, use the <code>--fg-aircraft=path</code> option, which in our case can be: <code>--fg-aircraft=/home/{YourUserName}/FlightGear/CustomAircraft</code>.

== When installing an aircraft fails ==
=== Rename aircraft folder ===
If FlightGear fails to start with the new aircraft you have installed, or if it starts but the aircraft is invisible you might have to rename the folder where the aircraft files are.
This issue is most often encountered when downloading a .zip file from some online git repository. In those cases you will most likely end up with a folder name of the following form MyZippedRepo-[branch]. In this case you should rename the folder to be just '''MyZippedRepo'''.

If the above doesn't work, or for other cases, check for a readme file and have a look there for instructions.

Otherwise open the aircraft-set.xml file and search in it for paths containing '''Aircraft/AircraftFolderName'''. The name of the folder should match '''AircraftFolderName'''.

For instance if in the imaginary-set.xml you would find an instance like this:
<syntaxhighlight lang="xml">
<splash-texture>Aircraft/MyCreation/splash1.png</splash-texture>
</syntaxhighlight>
that means that you should rename the folder where imaginary-set.xml is to '''MyCreation'''.

=== XML files with wrong encoding ===
If you start FlightGear with the new plane you installed and there is no cockpit or exterior, this may be because the XML files are in the wrong encoding.

To fix this on Linux try this:
<syntaxhighlight lang="bash">
$ cd path/to/aircraft/directory/
$ find . -name "*.xml" -print | xargs sed -i 's/<?xml version="1.0" encoding="UTF-8"?>/<?xml version="1.0" encoding="ISO-8859-1"?>/g'
</syntaxhighlight>

If any of the methods above do not work, ask around on the [[Howto:Multiplayer#Multiplayer chat|multiplayer chat]], [[FlightGear IRC channel|IRC]] or on the {{forum link|f=11|text=forum}}.

== Choosing aircraft ==
If you are looking for information to decide what aircraft to download, try:
* [[Aircraft]]
* [[Helicopter]]
* [[Vehicle]]
* [[Table of models]]
External links to third party aircraft can be found at [[FlightGear hangars]]. Remember that the latest aircraft may not load with previous versions. If you happen to use an older version of FlightGear, look for older aircraft in the links section.

==Video tutorial by the community==
{{#ev:youtube|OiqGjc8W880|480px||Tutorial on downloading and installing aircraft from Github pages by PINTO. Adding manually downloaded aircraft folders in the [[FlightGear_Qt_launcher|qt-launcher]] is pretty much the same for non-github downloads too. Aircraft are often developed on Github. This shows you to the download Github versions of aircraft that are not in FGAddon yet for whatever reason, and the latest work-in-progress state of some aircraft in FGAddon for testing and feedback. (September 2019)}}

== Related content ==
* [[Installing Scenery]]

[[Category:Howto|Install aircraft]]

[[de:Howto:Flugzeuge Installieren]]
[[es:Cómo:Instalar_aviones]]
[[fr:Howto Installer un avion]]
[[pl:Instalowanie_samolotów]]

Triaging and improving bug reports

2025-01-16T19:00:36Z

SammySkycrafts: Update FG Issue Tracker link

== Testing and triaging tickets ==

We use [https://gitlab.com/groups/flightgear/-/issues GitLab Issues] to track FlightGear bugs.

We encourage people to file tickets into the system, but some people report a ticket and then vanish or don't follow it up. Therefore we have a large collection of older bug reports to re-check and classify, and help with this is appreciated. If you're unsure about details, do ask on the developer list or similar. It's quite okay to ask 'what might be causing this?' and get more opinions. You need to ask for permissions to edit certain features of bugs, ask one of the admins for permissions.

We do also collect aircraft and scenery bug reports in the tracker, but these don't always make sense. For an aircraft which is unmaintained it's reasonable to track issues ourselves, but where development occurs in another place, or with an active development team, it's better to close the issue in our tracker, after pointing the aircraft developers at the issue. For scenery bug reports there is usually nothing we can do without a full scenery rebuild, unfortunately (trees on airport, taxiway underwater, missing new runways, etc).

Feature-request tickets also need handling: the tracker is not really ideal for these, better to propose them on the forum or the developer list and see if anyone is interested to work on them, or add them to a wiki page of requests. But they can be tagged with the 'feature' label and then marked as 'WontFix' : this gives us a way to find them with a query, but avoids them being counted towards the open bug totals for a milestone.

== Add missing data ==

Especially, add labels for the area: replay, launcher, Canvas, crashes.
Set the affected milestone: since SF only allows one milestone, not multiple, set the milestone the bug occurs in now: we don't care when the bug first appeared.. That likely means the current release.
Consider renaming the ticket if the title is not accurate: new users often don't pick clear titles for bugs, since they focus on the wrong issue

For crashes, try to get a crash-trace with symbols, either from the reporter or if you can reproduce, your own build. For other bugs, ask to get the log file if it makes sense: especially FDM issues, or visual ones (missing texture or shaders that don't compile)

For visual things (broken GUI), screenshots are very helpful.

For aircraft, please ask for which version of the aircraft was tested: it needs to be a defined version in FGAddon or a git-repo, not just 'the latest F-14', since that changes continuously. Same for any add-on or custom scenery.

== Check the bug still occurs ==

This is the most important: follow the steps to reproduce the bug. If you can't, ask the original reporter for more info, or find a friend to check (eg on a different platform or with a different video card). If multiple people can't reproduce the issue, consider closing the bug as 'not reproducible', but take care to allow for bugs which depend on the system configuration, eg language, OS, or other factors which are hard to identify.

If the steps to reproduce are unclear, set the state as 'Need Info' and ping the original reporter. If you find a bug which is in this state (waiting for more info from the original reporter) and they didn't update the ticket in say six months (or maybe a year), consider closing the ticket as 'WontFix', since there is no value in tracking such tickets. Often you need to check with the reporter how their system differs from a known working setup: are the running from a network share, have they changed their download directory, do they have a firewall from their ISP which blocks certain ports?

If you can reproduce the bug in the current version, update the milestone.

== Simplification ==

Try to eliminate possible causes: if the bug was reported with a complex aircraft, does it also happen with the UFO? If it happens with a high shader setting, does it go away with a lower one? It does help to avoid strange customizations in your test setup: try to be testing something as close to stock as possible. This likely means keeping an unmodified version of the current and previous versions around, don't use a development build for triaging. Fortunately SSDs got cheap, you might need more disk space.

== De-duplication ==

This requires some knowledge of other bugs, so consider asking on the developer list, but if the bug is about one aircraft, consider if the same bug might exist in other aircraft. For example, if sounds are broken in one aircraft, do they work in another one? Is something broken in all gliders, or all Yasim helicopters, or just this one particular aircraft? Since many aircraft copy code from each other, ask or check if the function is common and see what other aircraft might be affected. Search on similar labels or titles, unfortunately the SF tracker search is not very smart. (This is why good titles are important, to help finding duplicates)

If you do find a duplicate, add a comment on both tickets with a link to the other one. That way, when the original ticket is fixed, both bugs can be verified.

== Expired / ancient bugs ==

If the bug is more than two years old, and is not moving forward (no way to reproduce, no further info from the original reporter), close it as 'expired' or 'invalid'. If it's a feature request which no one seems interested in after a year, close it as 'wont-fix'. Or if you feel someone might be be interested to work on it, raise on the developer list or forum.

== Regressions ==

If possible, check the behaviour in older versions to see if it's a regression or always behaved the same way. This can take more time so be strategic about it : test 2020.3 first, and then decide if it's worth checking older or newer versions. But it's probably more useful to check twenty tickets in the current version, than spend four hours installing a historical one, to research a very old ticket.

[[Category:Development]]

HDR Pipeline

2024-11-08T23:21:48Z

SammySkycrafts: Change version number of next

{{forum|47|Effects & Shaders}}

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

{{Rendering}}

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

== Background ==

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

== Status ==
'''Last updated: 11/2023'''

The HDR pipeline is more or less stable, and is currently available on <tt>next</tt> for anyone adventurous enough to try it. Version 2024.1 will not support HDR.

Keep in mind that the HDR pipeline might not work in your system until we finish [[FlightGear and OpenGL Core Profile|moving to the OpenGL core profile]]. AMD graphics cards (regardless of age) and Intel integrated GPUs are known to be problematic.

== Notes for aircraft developers ==

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

=== PBR and glTF ===

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

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

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

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

=== Lights ===

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

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

An example light definition is shown below:

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

== References ==
{{Appendix}}

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

[[Category:Compositor Pipelines]]

Fairchild Republic A-10 Thunderbolt II

2024-09-26T14:29:06Z

SammySkycrafts: Update development status and make clearer

{{Note|For the A-10 under current development, please see https://wiki.flightgear.org/Fairchild_Republic_A-10_Thunderbolt_II,_OPRF_Version|width=125}}{{:{{PAGENAME}}/info}}

The '''Fairchild A-10 Thunderbolt II''' (aka '''Warthog''') offers a wide variety of features and controls. Special features include the ability to simulate ordnance use, and a detailed 3D textured cockpit. Many of the A-10's flight systems are modeled as well, such as support for [[Tactical_Air_Navigation|TACAN]].

== About the aircraft ==
The Fairchild Republic A-10, also named Warthog, is a U.S. single-seat, twin-engine, very robust jet aircraft designed for ground attack.

== User's Manual ==
In the current version, the aircraft simulation begins with the aircraft powered down.

The electrical power systems and the {{Abbr|APU's|Auxiliary Power Unit's}} operation are simulated to a large extent. [[Howto:Aerial_refueling|Mid-air refueling]] is also implemented.

The navigation instruments are [[Tactical_Air_Navigation|TACAN]], {{Abbr|ILS|Instrument Landing System}} and also a VHF so you can have homing on a VOR station.

Several external loads are available and the [[HUD]] provides a {{abbr|CCIP|Continuous Computed Impact Point}}.

=== Electrical power with APU starting procedure ===
[[File:A-10-electrical-power-control-panel.jpg|thumb|Electrical control panel]]
At FlightGear startup, both electrical power and APU are shut down and there is no external power supplied.

You, might see, early on, some needles spinning back on the engines gauges panel and the VSI ... this is only a software initialization artifact.

So, look at the right console, there is a panel with 6 switches, that's the Main Electrical Control Panel. Hit Ctrl-c and you will have a view of where to click.

Let's connect the battery: switch on the battery switch. A few indicators should light up, but not all of them. Now with the battery connected you can start the APU.

The APU start/stop switch is located near the throttle on the left console. Switch it on. Now check the APU's tachometer and EGT on the engine gauge panel.

If the APU has started successfuly you should see the EGT (Exhaust Gas Temperature) rapidly climb to 800/900 °C and then stabilize when the RPMs reach 60%.

[[File:A-10-throttle-engine-start.jpg|thumb|Throttle, engines operation and APU panel]]

Now the APU has sufficient RPMs to provide electrical power through its generator. So let's turn on the APU generator. This one is on the main electrical control panel, upper left corner of the electrical control panel, right console again.

With the APU generator powered up most of the instruments receive electrical power and now the AOA]] indexer lights up and the HSI (the compass) and ADI (artificial horizon) look much better.

At 85% RPM the APU supplies enough bleed air to start the engines.

[[File:engine-gauges.jpg|thumb|APU running, Engines gauges at stop.]]

=== Engines starting procedure ===
Now that we have minimum electrical power and bleed air supplied by the APU, starting the engines is straight forward.

Just click on one of the throttle rails (Ctrl-c to see them), the throttle will move from stop to idle and the engine start. Wait for the starting cycle light to turn off, turn on the corresponding generator and repeat with the second engine.

Now the complete electrical circuit is powered and you can stop the APU to save some fuel. It wont be useful anymore. (This could change with future development of engines failures...)

=== Fuel System ===
FlightGear A-10 starts with all internal tanks full.

2 wing tanks (left and right), 2 fuselage tanks: left main (aft) linked to left system and right main (forward) linked to right system, up to 3 external tanks (2 wings and 1 fuselage).

Normally the left wing and left main tanks feed the left engine and the APU. The right wing and right main tanks feed the right engine. The two feed lines can be interconnected by opening the cross feed valve ('''E''' switch).

The wing boost pumps ('''G''' switch) supply the respective engines until the wing tanks are empty, then the wing boost pumps automatically shut off. The main boost pumps then supply the respective engines with the remainder fuel in main tanks.

In case of a wing tank boost pump failure, the wing tank fuel will gravity feed its respective main tank if the main tank fuel level is below 600 lbs. Check valves prevent reverse fuel flow from the main tanks to the wing tanks.

In case of a main tank boost pump failure, the affected engine will suction-feed from the affected tank for all power setting up to an altitude of nearly 10,000 feet.

Unequal fuel level between left (aft) main and right (forward) main tank (imbalance superior 750 lbs) will cause a longitudinal CG shift that may exceed allowable limits. In this case, opening the valve "tank gate" create a link between the two main tanks.

Fuel from the external tanks is transfered to the wing or main tanks by pressure from the bleed air system. Wing tanks can be topped when the fuel level is below 1590 lbs.
Main tanks can be topped when the fuel level is below 3034 lbs.
The cycling is repeated until fuel is depleted from the external wing tanks first, and external fuselage tank secondly.

For negative G flight, collector tanks will supply the engine with sufficient fuel for 10 seconds operation at MAX power.

With fully loaded fuel tanks and a full load of armament, the A-10 is heavy--about 50,000 pounds. At this weight the plane is quite difficult to fly. Symptoms you would notice are difficult to take off, difficulty gaining altitude, difficult to manoeuvre without triggering stall warnings or actual stalls.

To avoid these problems, if you choose to equip the plane with full armament you may wish to fill the tanks only half full or so--the plane becomes much easier to fly and half fuel is still enough for a reasonably long flight.

[[File:A-10-fuel-control-doc.jpg|thumb|Fuel Control panel.]]

The '''Fuel Control panel''' is located on the forward part of left console. 1 lever, 4 push buttons and 8 switches are functional.

: ('''A''') Fill Disable buttons, left and right wings tanks. Here fill disabled (button up showing red stripe). Refuel disabled for the wings tanks.

: ('''B''') Fill Disable buttons, left and right main tanks (practically forward and aft fuselage tanks). Here fill enabled (button down hiding red stripe). Refuel enabled for the main tanks.

: ('''C''') Refuel Receiver Door lever.

: ('''D''') External Tanks switches, Wings and Fuselage. Set to OFF to un-pressurize external tanks

: ('''E''') Cross Feed switch, allow any operating boost pump to feed both engines.

: ('''F''') Tank Gate switch, open a valve linking the left (aft) and right (forward) main fuel tanks.

: ('''G''') Boost Pumps (Wing)

: ('''H''') Boost Pumps (Main)

=== HUD ===
[[File:A-10-hud-control-panel.jpg|thumb|HUD Control panel]]

The Head Up Display is turned off by default at aircraft startup. To turn it on electrical power on at least one of the three generator is needed as it isn't wired to the battery.

The '''HUD Control panel''' is located on the upper left corner of the main instrument panel. Three knobs are functional.

: ('''A''') Mode Selector Switch: OFF, TEST (standard display), NAV (standard display), CCIP (standard display + Countinuous Computed Impact Point), CCRP (standard display), EXP (standard display), STBY (standard display). Actually you will mostly use NAV and CCIP as other modes are not modeled yet. See later in Weapons System about reticles use.

: ('''B''') INTEN knob: Adjust the HUD luminosity.

: ('''C''') DEPR knob: Changes the vertical position of the primary aiming reticle in the HUD, There is a digital index in the HUD showing its position, range from -1.00 to 1.00 followed by the letter "D".

'''HUD Symbology:'''

[[File:A-10-hud-symbology.jpg|thumb|HUD Symbology]]

: ('''D''') Pitch ladder.

: ('''E''') Indicated Air Speed, Kts.

: ('''F''') Primary Aiming Reticle.

: ('''G''') Horizon Line

: ('''H''') Primary Aiming Reticle Digital index.

: ('''I''') Magnetic Heading Tape.

: ('''J''') Indicated Altitude in feet (ASL).

: ('''K''') Radar Altitude in feet (AGL) followed by letter "R".

: ('''I''') Aircraft Pitch in degrees, boxed.

: ('''M''') Total Velocity Vector indicator.

: ('''N''') Pointer showing the rudders deflection.

=== Weapons system ===
[[File:A-10-arm-1.jpg|thumb|Armament panel]]
Be sure to have energy before trying to use the armament panel. The gun's rounds counter ('''A''') should be lighted in blue and the HUD should be active.

There is actually 2 AIM-9, the GAU9 gatling gun, and MK85 250 pound bombs.

First of all push up the Master Switch to ARM ('''B''').

For the gun, push up the Gun Rate Switch to HI (right of the rounds counter). You should have on the left side of the main panel a red light indicating 'Gun Ready'. Press key 'e' on the keyboard to fire the gun.

For AIM-9, turn ('''C''') the AIM-9 Mode Knob to SEL (click on the right side of the knob). Now a big circle appears on the HUD symbology, that the searching aera of the AIM-9. Now select Pylon #11, you should ear the seeker sound. This sound is audible only when an AIM-9 is available, selected and searching. Press key ',' to fire the AIM-9.

(In Flightgear, the key ',' is usaly used for left brake, in the A-10 a nasal script intercepts the binding for weapons release, this is not a definitive solution).

You can also choose to fly without the AIM-9s and the ECM pod, press Tab or Ctrl-I on the keyboard to display the config menu.

== See also ==
[[A-10 Thunderbolt II FDM]]

== External links ==
* [http://brenthugh.com/flightgear/Sun_Valley_Tank_Invasion1.zip Several ground bombing scenarios suitable for the A-10, involving moving and static tank formations, explodable M1 Abrams tanks, etc.]

{{air-to-air refueling}}

[[Fr:Fairchild Republic A-10 Thunderbolt II]]
[[Ru:Fairchild Republic A-10 Thunderbolt II]]

Fairchild Republic A-10 Thunderbolt II, OPRF Version

2024-09-26T14:24:00Z

SammySkycrafts: Update repository link, update Weapon information for upgraded weapons system

The '''Fairchild A-10 Thunderbolt II''' (aka '''Warthog''') offers a wide variety of features and controls. Special features include the ability to simulate ordnance use, and a detailed 3D textured cockpit. Many of the A-10's flight systems are modeled as well, such as support for [[Tactical_Air_Navigation|TACAN]].
{{infobox aircraft
| name = Fairchild A-10
| hangar = OPRF
| aircraft = A-10
| image = A-10-3.png
| alt = The "Warthog"
| image2 = A-1-1.png
| alt2 = A-10 Warthog Taking off from KXTA
| type = Military aircraft/Attack aircraft
| config = Low wing aircraft
| propulsion = Twinjet
| manufacturer = Fairchild Republic
| authors = Lee Elliott/Alexis Bory/David Bastien/Pinto/Steve Brown/Rudolf/J Maverick 16/Zorka/EAGLE01/Wolf
| fdm = YASim
| fgname = A-10
| status-fdm = 3
| status-systems = 5
| status-cockpit = 4
| status-model = 4
| ready = airrefuel/Emesary
| wikipedia = Fairchild Republic A-10 Thunderbolt II
| navbar = 1
|download=https://github.com/l0k1/A-10/archive/refs/heads/master.zip|devel-repo=https://github.com/l0k1/A-10}}
This is the version used by [[Operation Red Flag|OPRF (Operation Red Flag)]] and is the branch that is being actively developed.

==About the aircraft==
The Fairchild Republic A-10, nicknamed "Warthog," is a U.S. single-seat, twin-engine, very robust jet aircraft designed for ground attack.
==User's Manual==
In the current version, the aircraft simulation begins with the aircraft powered down and [[Emesary|damage]] disabled.

The electrical power systems and the {{Abbr|APU's|Auxiliary Power Unit's}} operation are simulated to a large extent. [[Howto:Aerial_refueling|Mid-air refueling]] is also implemented.

The navigation instruments are [[Tactical_Air_Navigation|TACAN]], {{Abbr|ILS|Instrument Landing System}} and also a VHF so you can have homing on a VOR station.

Several external loads are available and the [[HUD]] provides a {{abbr|CCIP|Continuous Computed Impact Point}}.

== Keybinds ==
<code>j/k</code> Extend/Retract Speedbrakes

<code>[/]</code> Extend/Retract Flaps

<code>f</code> Slats

<code>e</code> Trigger

<code>Shift+q</code> Flares

===Electrical power with APU starting procedure===
[[File:A-10-electrical-power-control-panel.jpg|thumb|Electrical control panel]]At FlightGear startup, both electrical power and APU are shut down and there is no external power supplied.

You, might see, early on, some needles spinning back on the engines gauges panel and the VSI ... this is only a software initialization artifact.

So, look at the right console, there is a panel with 6 switches, that's the Main Electrical Control Panel. Hit Ctrl-c and you will have a view of where to click.

Let's connect the battery: switch on the battery switch. A few indicators should light up, but not all of them. Now with the battery connected you can start the APU.

The APU start/stop switch is located near the throttle on the left console. Switch it on. Now check the APU's tachometer and EGT on the engine gauge panel.

If the APU has started successfuly you should see the EGT (Exhaust Gas Temperature) rapidly climb to 800/900 °C and then stabilize when the RPMs reach 60%.[[File:A-10-throttle-engine-start.jpg|thumb|Throttle, engines operation and APU panel]]Now the APU has sufficient RPMs to provide electrical power through its generator. So let's turn on the APU generator. This one is on the main electrical control panel, upper left corner of the electrical control panel, right console again.

With the APU generator powered up most of the instruments receive electrical power and now the AOA]] indexer lights up and the HSI (the compass) and ADI (artificial horizon) look much better.

At 85% RPM the APU supplies enough bleed air to start the engines.

[[File:engine-gauges.jpg|thumb|APU running, Engines gauges at stop.]]
===Engines starting procedure===
Now that we have minimum electrical power and bleed air supplied by the APU, starting the engines is straight forward.

Just click on one of the throttle rails (Ctrl-c to see them), the throttle will move from stop to idle and the engine start. Wait for the starting cycle light to turn off, turn on the corresponding generator and repeat with the second engine.

Now the complete electrical circuit is powered and you can stop the APU to save some fuel. It wont be useful anymore. (This could change with future development of engines failures...)

===Fuel System===
FlightGear A-10 starts with all internal tanks full.

2 wing tanks (left and right), 2 fuselage tanks: left main (aft) linked to left system and right main (forward) linked to right system, up to 3 external tanks (2 wings and 1 fuselage).

Normally the left wing and left main tanks feed the left engine and the APU. The right wing and right main tanks feed the right engine. The two feed lines can be interconnected by opening the cross feed valve ('''E''' switch).

The wing boost pumps ('''G''' switch) supply the respective engines until the wing tanks are empty, then the wing boost pumps automatically shut off. The main boost pumps then supply the respective engines with the remainder fuel in main tanks.

In case of a wing tank boost pump failure, the wing tank fuel will gravity feed its respective main tank if the main tank fuel level is below 600 lbs. Check valves prevent reverse fuel flow from the main tanks to the wing tanks.

In case of a main tank boost pump failure, the affected engine will suction-feed from the affected tank for all power setting up to an altitude of nearly 10,000 feet.

Unequal fuel level between left (aft) main and right (forward) main tank (imbalance superior 750 lbs) will cause a longitudinal CG shift that may exceed allowable limits. In this case, opening the valve "tank gate" create a link between the two main tanks.

Fuel from the external tanks is transfered to the wing or main tanks by pressure from the bleed air system. Wing tanks can be topped when the fuel level is below 1590 lbs. Main tanks can be topped when the fuel level is below 3034 lbs. The cycling is repeated until fuel is depleted from the external wing tanks first, and external fuselage tank secondly.

For negative G flight, collector tanks will supply the engine with sufficient fuel for 10 seconds operation at MAX power.

With fully loaded fuel tanks and a full load of armament, the A-10 is heavy--about 50,000 pounds. At this weight the plane is quite difficult to fly. Symptoms you would notice are difficult to take off, difficulty gaining altitude, difficult to manoeuvre without triggering stall warnings or actual stalls.

To avoid these problems, if you choose to equip the plane with full armament you may wish to fill the tanks only half full or so--the plane becomes much easier to fly and half fuel is still enough for a reasonably long flight.[[File:A-10-fuel-control-doc.jpg|thumb|Fuel Control panel.]]The '''Fuel Control panel''' is located on the forward part of left console. 1 lever, 4 push buttons and 8 switches are functional.

:('''A''') Fill Disable buttons, left and right wings tanks. Here fill disabled (button up showing red stripe). Refuel disabled for the wings tanks.
:('''B''') Fill Disable buttons, left and right main tanks (practically forward and aft fuselage tanks). Here fill enabled (button down hiding red stripe). Refuel enabled for the main tanks.
:('''C''') Refuel Receiver Door lever.
:('''D''') External Tanks switches, Wings and Fuselage. Set to OFF to un-pressurize external tanks
:('''E''') Cross Feed switch, allow any operating boost pump to feed both engines.
:('''F''') Tank Gate switch, open a valve linking the left (aft) and right (forward) main fuel tanks.
:('''G''') Boost Pumps (Wing)
:('''H''') Boost Pumps (Main)
:
===HUD===
[[File:A-10-hud-control-panel.jpg|thumb|HUD Control panel]]The Head Up Display is turned off by default at aircraft startup. To turn it on electrical power on at least one of the three generator is needed as it isn't wired to the battery.

The '''HUD Control panel''' is located on the upper left corner of the main instrument panel. Three knobs are functional.

:('''A''') Mode Selector Switch: Modes available are:
:* OFF
:* TEST - Currently shows a placeholder "Initializing" screen. In the real aircraft this is used mainly to control the LASTE (Weapon and Navigation system) menu, however this is currently not implemented
:* NAV - Standard display, shows speed, altitude, distance and time to next waypoint aswell as navigation to the steerpoint.
:* CCIP - Same as NAV with the addition of CCIP (Continuiously Computed Impact Point) weapon symbology
:* CCRP - Not Implemented
:* EXP - Not Implemented
:* STBY - Not Implemented
:('''B''') INTEN knob: Adjust the HUD luminosity.
:('''C''') DEPR knob: Not Implemented

'''HUD Symbology:'''[[File:A-10-hud-symbology.jpg|thumb|HUD Symbology]]
:('''D''') Pitch ladder.
:('''E''') Indicated Air Speed, Kts.
:('''F''') Primary Aiming Reticle.
:('''G''') Horizon Line
:('''H''') Primary Aiming Reticle Digital index.
:('''I''') Magnetic Heading Tape.
:('''J''') Indicated Altitude in feet (ASL).
:('''K''') Radar Altitude in feet (AGL) followed by letter "R".
:('''I''') Aircraft Pitch in degrees, boxed.
:('''M''') Total Velocity Vector indicator.
:('''N''') Pointer showing the rudders deflection.
:
===Weapons system===
Weapons Currently Available:

* LAU-68 (Launcher with 7 High-Explosive rockets)
* Mk-82 (Available in single and triple racks, High drag and Low drag)
* MK-84
* CBU-87
* AGM-64B
* AIM-9M (A/A Missile, available in dual racks)
* AN/ALQ-131 (ECM pod, currently no use)

[[File:A-10-arm-1.jpg|thumb|Armament panel]]Be sure to have electric power before trying to use the armament panel. The gun's rounds counter ('''A''') should be lighted in blue and the HUD should be in CCIP mode. This is needed to see targeting symbology for your weapons, there will be no symbology in NAV mode.

First of all push up the Master Switch to ARM ('''B''').

To use the gun, push up the Gun Rate Switch to HI (right of the rounds counter). At the top/left of the main panel a green light indicating 'Gun Ready' will light up. Press <code>e</code> to fire the gun. Aiming is done with the circle on the HUD which will indicate close to where the rounds will land. As you get closer the circle symbology changes to indicate your range. If you are using the gun for Air to Air, switch the AIM-9 Mode Knob to SEL. This will put the weapon system into Air to Air mode and the gunning symbology will change to something more useful for Air to Air use.

To release the Mk-82s and fire the LAU-68s, select the green squares in the center of the weapons panel and press <code>E</code> to fire. Keep in mind that only one type of weapon can be selected at one time, and the order in which you select the pylons will affect the order in which the ordnance on them is released.

To use the AIM-9s, turn the AIM-9 Mode Knob ('''C''') to SEL (click on the right side of the knob). Then select the pylons with AIM-9s mounted. There will be a small circle about a 3rd of the way down the HUD - This is your Seeker. Maneuver the aircraft to place the seeker near an enemy aircraft and if the missile has a good enough lock on it, it will track it and the tone will change to a higher pitched tone. At this point you can fire. It is best to fire within 7 miles if the aircraft is hot, or coming towards you, and around 3 if the aircraft is cold, or going way from you. The other aircraft maneuvering will also affect missile performance so you may want to wait until you ger closer for a higher chance of a likk As soon as you turn the knob past the first mode, OFF, the AIM-9's will start to cool. This takes around 30 seconds. You can still use the AIM-9s in this time however their range and effectiveness in keeping a lock will be reduced. If the AIM-9 system has not been powered on, the missile will not track and will fly unguided and unarmed.

== Gallery ==
<gallery>
File:Hawg-5.png
File:Hawg-3.png
File:Hawg-1.png
File:Hawg-2.png
File:Hawg-4.png
File:A-10-2.png|A-10 using its GAU-8 30mm Gun
File:A-10 Warthog in Bombable.png|alt=A-10 in Bombable|A-10 in Bombable
File:A-10.jpg
</gallery>

== Work In Progress ==
{| class="wikitable"
|+
!Task
!Status
!Remarks
|-
|Rewrite Weapon System handling code
|Done! ✅
|
|-
|Add additional weapon loadouts (something guided? GBU-12/AGM-65?)
|{{Progressbar|percentage=90}}
|CBUs, Mk-82R, AGM-65, Mk-84 and ECM pods have been added
|-
|Paintkit fix
|Done! ✅
|
|-
|Weapons Graphical update
|Done! ✅
|
|-
|Full cockpit functionality
|{{Progressbar|percentage=60}}
|Getting there, Maverick screen still needs work...
|-
|FDM rework
|{{Progressbar|percentage=90}}
|JSB file is there, just needs some refining and implementation
|-
|Canvas HUD rewrite
|Done! ✅
|
|-
|Additional Liveries
|{{Progressbar|percentage=50}}
|Got a lot, thanks to Bat. Still need some more!
|}

<gallery>
File:A-10–clusters.png|Full load of CBU-87s
</gallery>

==See also==
[[A-10 Thunderbolt II FDM]]
==External links==
*
*A-10 Development Discord Server: https://discord.gg/RmtjmsT5vS
{{air-to-air refueling}}

PUI

2024-09-24T23:48:36Z

SammySkycrafts: Update version to reflect 2024.1 LTS being last planned version to contain PUI

{{Feature to be removed|version=2024.2|reason=[[Plib]]/PUI is to be removed and replaced by a [[Canvas widget matrix|Canvas/Nasal based solution]] to help improve compatibility with [[OSG]] 3.6+ and [[OpenGL]] 4.x ([[Core Profile support|OpenGL Core Profile]], see [[2022.X Release plan]] ) and improve performance by [[Unifying the 2D rendering backend via canvas|phasing out legacy OpenGL code]]. Therefore, people should be careful when extending the '''PUI''' based legacy GUI engine<ref>https://sourceforge.net/p/flightgear/mailman/message/34921495/</ref><ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35157325/
|title = <nowiki> Re: [Flightgear-devel] GUI options (Was: Aircraft center) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Jun 14th, 2016
|added = Jun 14th, 2016
|script_version = 0.40
}}</ref> and coordinate any related work with the devel mailing list first-this applies particularly to adding any [[Template:PUI_widget|additional hard-coded PUI widgets]]. }}
[[File:Exit.png|thumb|FlightGear GUI dialog (exit.xml)stored in $FG_ROOT/gui/dialogs]]
{{GUI Navbar}}

[[File:Custom-autopilot-dialog.png|right|200px]]
[[PUI]] is the standard GUI engine used in FlightGear, it is part of [[PLIB]] and is using raw, fixed-pipeline, [[OpenGL]] code internally (no [[OpenSceneGraph]]). As of mid 2021, FlightGear is in the process of working towards adopting the OpenGL Core Profile, this means that [[PUI]] is causing trouble and needs to be replaced/disabled or ported.

PUI provides a fairly basic, but robust, set of widgets. PUI is also used for rendering the [[Menubar]].

FlightGear uses a GUI widget set that is implemented on top of raw (legacy) [[OpenGL]]. This has many advantages from a portability standpoint and from the standpoint of integrating with window systems. [[PUI]] doesn't have every feature under the sun, but it was never meant to. It's relatively small, lean, mean, and written on top of [[OpenGL]] which makes life *much* easier for us.

[[PUI]] already is a separate distinct library within Plib. It depends on some central utility stuff, but that's about it. So it is pretty stripped down and separate already.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26011.html</ref>

We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft.<ref>https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25985.html</ref>

Flightgear can look amazing when you use the HDR pipeline. We absolutely need this to stay relevant. The problem is that HDR is not compatible with OpenGL1 PUI. Work on getting rid of PUI has been going on for over a decade (longer than it took to implement it).<ref>https://sourceforge.net/p/flightgear/mailman/message/37727346/</ref>

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

== Replacement status ==
{{See also|FlightGear_and_OpenGL_ES#Example:_disabling_PUI}}

{{Note| Update 09/2022: The PUI replacement [[QtQuick_use_in_FlightGear#Background|was going to be Qt]] but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight Canvas based approach now.

Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’.

So now James is going with something much more lightweight using some C++ compatibility code, some Nasal for styling and the existing [[Canvas widgets|Canvas widget rendering]] from Thomas Geymayer (TheTom) with [[Canvas Widget Matrix|some extensions and additions]], based on the [[Howto:Processing_legacy_PUI_dialogs_using_Canvas#Original_Discussion|plans originally discussed when the Canvas GUI system was added to FlightGear]]: some pieces are in FlightGear & FGData already.

James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping him since we could probably move things also faster <ref>https://sourceforge.net/p/flightgear/mailman/message/37701750/</ref>}}

=== Motivation ===
{{Main article|Core Profile support}}

The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatibility mode.

Improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

{{Note|There is now an alternative to ShivaVG in SimGear - ShaderVG, which is working pretty much as good as ShivaVG. It can be enabled by passing -DENABLE_SHADERVG to cmake when building SImGear from source.}}

Given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, many people are convinced PUI needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

== Canvas Emulation ==
{{See also|Canvas widget matrix}}
'''Last updated: 04/2023 <ref>https://sourceforge.net/p/flightgear/mailman/message/37805054/</ref>
'''
=== Gallery ===

<gallery>
About-dialog-xmldialog-04-2023.png|about.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Logging-dialog-via-xmldialog-04-2023.png|logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Failures-dialog-via-xmldialog-04-2023.png|failures dialog-via-xmldialog-04-2023.png{{!}}thumb{{!}}logging.xml PUI/XML dialog parsed/rendered via the [[Canvas GUI]] and the underlying XMLDialog.nas parser/translator (04-2023)
Environment-dlg-via-canvas-bridge-04-2023.png|Screen shot showing the XMLDialog.nas bridge in use to parse/render the environment.xml PUI/XML dialog (unmodified)
</gallery>

=== Status ===
As of 01/2023, the replacement for PUI is making good progress<ref>https://sourceforge.net/p/flightgear/mailman/message/37765706/</ref>.

In February 2022, James reported having something in progress locally, and that should even be something we can try in March/April 2022. Hopefully that’s quick enough, knowing it has been a long time coming.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606439/</ref>

There's now an XML to Nasal bridge, to keep PUI dialogs working (Disabled by a CMake option). This is implemented on top of the [[Canvas]] system.

This builds equivalent C++ objects to what the [[PUI]] dialogs build, with properties exposed to Nasal. Peer objects are created by Nasal [[callbacks]], which can implement the various dialog functions needed to keep compatibility, especially the [[#Background|‘update’ and ‘apply’ hooks]].<ref>https://sourceforge.net/p/flightgear/flightgear/ci/cbd5ef9e7b8f433dbc1ba97bae7d7cfc894e7cef/</ref>

For remaining work to be done, please refer to [https://sourceforge.net/p/flightgear/mailman/message/37881226/]

{{Note|The PUI Compatible Canvas GUI is a compile time option: Use the following [[Building using CMake|cmake option]] to enable this code: {{CMake Build Option|option=ENABLE_PUICOMPAT|default=ON|description=This requires latest SG/FG AND FGDATA}}. But this is all highly fluid and most of it really developer only. At one point they will become default or be accessible in the launcher.<ref>https://sourceforge.net/p/flightgear/mailman/message/37834004/</ref>

If you compiled with PUICompatibility enabled, but still don't see any dialogs - only the menubar, you might need to enable the GUI module in defaults.xml:{{PropArg}}<ref>https://sourceforge.net/p/flightgear/mailman/message/37833149/</ref>}}

The new Compatibility files can now be found in $FG_SRC/GUI:

* {{flightgear file|src/GUI/FGPUICompatDialog.cxx }}
* {{flightgear file|src/GUI/FGPUICompatDialog.hxx }}
* {{flightgear file|src/GUI/PUICompatObject.cxx }}

<s>01/2023: James is slowly working on creating the pop-up menu and combo-box widgets [...]</s>

<s>One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref></s>

<s>James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references.</s>

<s>The general non-fun-ness of that kind of debugging is James has been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref></s>

Popup menus and combo box widgets are working now - also, the simulator doesn't have to be restarted anymore - any Nasal module (including the canvas module can now be reloaded live:

<code>fgcommand("nasal-reload", {"module": "canvas"})</code>

=== Todo ===
<s>Nothing in particular: help debugging the grid layout (which is in simgear) would be good. For now, you could create a grid layout manually using some Nasal.</s>

The grid layout is now mostly working (from my experience) but it behaves weirdly when there isn't enough place to accommodate all widgets.

Global menu keybindings won’t worry but don’t touch that, I have a separate plan for it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805736/</ref>

As of 04/2023, remaining items on the todo list are: <ref>https://sourceforge.net/p/flightgear/mailman/message/37805060/</ref>

* Grid layout
** GridLayout needs debugged: After this, the basic UI is usable, would probably make it a switchable option on ‘next’ (I can already use the simulator with the new UI today, but all the sizes are off in the grid layouts which we use everywhere)

* list {{Done}}
* table (and tree ?) models corresponding views
* waypoint list
* Re-write the waypoint list and airport dialog to work again (since these use custom widgets):
** log list
** airport-list equivalents
* Nasal access to the menu i18n functions
* selection support for single- and multi-line text (which is being worked on -> CanvasPangoText){{Note|For the LineEdit widget, a hack has been implemented to provide more-or-less working selection highlighting while the PangoText element isn't done.}}
* Keyboard shortcut handling, although this is not really a PUI vs replacement issue, to me we should handle UI shortcuts in the same was normal keyboard.xml shortcuts
** this previously worked because PUI got ‘first chance’ at handling key input. But we always had duplication between keyboard.xml and other places, so I would rather standardise on keyboard.xml, but allow a UI element to set a scope for shortcuts. (So that Copy/paste shortcuts etc can work in a text input, at least … but probably some other standard ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/37805188/</ref>
* Ensure all the places which use the PUI combo-box and list-widget work : there’s a few of these.

The CanvasPangoText stuff is needed but we can perfectly well run the UI on next without it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37805176/</ref>

=== Parser ===
{{Main article|pui2canvas}}
The corresponding Nasal/Canvas module to dynamically "translate" legacy PUI/XML dialogs into Canvas dialogs (at runtime), is to be found in {{fgdata file|Nasal/gui/XMLDialog.nas}} <ref>https://sourceforge.net/p/flightgear/fgdata/ci/fe7c87b21a69f88ddb87d89453c48d12b69660e2/</ref>

=== Widgets ===
{{Main article|Howto:Creating a Canvas GUI Widget}}

It’s split between Simgear (see classes with widget / layout in the name) and in FGData. (Eg widgets/Button.nas). To be able to use the existing dialog XML files un-modified (which is a design goal), James is extending the widget types with many additional ones (eg PUI has slider, dial, combo-box, checkbox, all of which need to be created, see [[Canvas widget matrix]].

Thomas’s canvas widgets have a very good separation of API + state from appearance, so all styling is in its own file, and James is being very strict about maintaining this separation, so we also retain the re-styling feature of the PUI UI, which many people also rely on. This does make the process of adding new widgets more complex, however.

{{See also|Canvas widgets}}

=== Layouting ===
The other thing is to preserve all the layouting: James has added a grid layout to Simgear, since that is supported by the existing PUI code (even though the layouts are not actually part of PUI itself). The problem is getting the sizing / hinting of all the widgets to match the PUI values, so that dialogs look approximately the same under the new UI as they did with PUI; again this a design goal so that all existing dialogs in aircraft and add-ons, which we can’t update, continue to work and be usable. Debugging that is also proving quite tricky, since there’s all kinds of hard-coded assumptions built into PUI widgets about pixels, font-sizes etc which are not true in the new system.<ref>https://sourceforge.net/p/flightgear/mailman/message/37701792/</ref>

== Background ==
In FlightGear, PUI dialogs are standard [[PropertyList XML File]]s that are stored in $FG_ROOT/gui/dialogs, they can contain the widgets mentioned in {{readme file|gui}}, using a simple layout engine discussed in {{readme file|layout}}, and bindings using a combination of so called fgcommands operating on properties (see {{readme file|commands}}) and custom [[Nasal]] (FlightGear scripting) code.

In addition, each PUI/XML dialog may contain Nasal script sections that are executed when opening/closing the dialog, a feature which is commonly used for procedurally creating/updating widgets using the [[Nasal_library#cmdarg.28.29|cmdarg() API]], which allows the dialog tree to be traversed and manipulated prior to the dialog being rendered.
Widgets can be conditionally hidden/shown using a wrapper for [[Conditions|SGCondition]] in [[Nasal_library/props|props.nas]]
The <code>canvas</code> widget also supports its own embedded Nasal code section to execute arbitrary widget specific Nasal code upon opening/closing the dialog/widget.

PUI/XML dialogs can be loaded, dynamically created, updated and closed using a handful of fgcommands:
* {{fgcommand|dialog-new}}
* {{fgcommand|dialog-show}}
* {{fgcommand|dialog-update}}
* {{fgcommand|dialog-apply}}
* {{fgcommand|dialog-close}}

PUI related OpenGL code is particularly infamous for causing rendering artifacts for people on AMD/ATI and Intel hardware (especially in combination with certain fonts/styles and [[Effects|effects]]/[[Shaders|shaders]]), see {{Issue|2213}}.

PUI is also known to affect rendering performance quite significantly (see {{search |keywords=anthrax+gui}}), while also preventing FlightGear from using a more recent version of OpenGL<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref><ref>http://forum.flightgear.org/viewtopic.php?f=71&t=24046</ref>.

However, improving the frame-rate and modernised 3D rendering, can’t be worked on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

Besides, while most people seem to agree PUI needs to be replaced, it sounds as if the fallout from doing so would be more painful (cumulatively) than the pain its existence causes.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35623408/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Jan 24th, 2017
|added = Jan 24th, 2017
|script_version = 0.40
}}</ref>

But given that with many graphics drivers PUI doesn't render correctly when higher shader quality is on, graphics folks are also convinced it needs to be replaced.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35624918/
|title = <nowiki> Re: [Flightgear-devel] canvas non svg-elements broken </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

In addition, [[OpenSceneGraph]] (OSG) can obviously not help optimize any PUI related GL code and PUI widgets are generally considered to be pretty archaic and not easy to extend<ref>http://sourceforge.net/p/flightgear/mailman/message/26832164/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587120/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/10587272/</ref>.

{{Note|We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in $FG_SRC/Viewer/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. }}

As of late 2015, there is heavy activity towards providing alternatives to a PUI-based UI:
* [[Integrated Web GUI]] (external, browser-based - fully asynchronous)
* [[Howto:Processing legacy PUI dialogs using Canvas]] (internal, using the [[Canvas]] system and a simple [[Nasal]] parser to deal with existing PUI/XML dialogs)

<gallery mode="packed">
Early-Phi-screen shot.PNG|Screenshot showing [[Phi]]
About-dialog-rendered-by-canvas.png|Screenshot showing a dialog rendered by the [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas parser]]
</gallery>

== History ==
{{See also|QtQuick use in FlightGear}}
{{Caution|This is merely kept for future reference, many of the ideas discussed below have become obsolete as of 09/2022, if in doubt, please get in touch via devel-list.}}
=== 2021 ===
In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job.

The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref>

Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point.

Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future.

Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref>

In mid 2021, James reported that he is working on some ‘PUICompat’ classes which hold/own/represent the GUI state in C++, but which can be used with [[Nasal/CppBind|Nasal CppBind]]. And of course we could indeed expose those later on. <ref>https://sourceforge.net/p/flightgear/mailman/message/37297727/</ref>

In July 2021, James suggested not to worry about the existing GUI code, it’s going in the bin.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325905/</ref>

For the time being, the in-sim GUi can’t do Unicode yet, but James is working on it, hopefully available soon.<ref>https://sourceforge.net/p/flightgear/mailman/message/37328200/</ref>
Also, the in-sim menubar will change with the new GUI, *and* we use a native menubar on macOS. Until James replaces the PUI fonts we can’t use Unicode symbols. So, will have to come back to it once the new GUI is merged.<ref>https://sourceforge.net/p/flightgear/mailman/message/37327237/</ref>

=== 2020 ===
As of 03/2020, the PLIB replacement was reported to be in the backlog <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36951255/
|title = <nowiki>Re: [Flightgear-devel] C++ and/or OSG question </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Mar 18th, 2020
|added = Mar 18th, 2020
|script_version = 0.50
}}</ref>.

With PLIB replacement work likely being re-scheduled for [[Post FlightGear 2020.2 LTS changes]] <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36985375/
|title = <nowiki>Re: [Flightgear-devel] Working Group Proposal - Boost and PLIB replacement - Delegation and Teamwork </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = April 18th, 2020
|added = April 18th, 2020
|script_version = 1.10
}}</ref>.

In 08/2020, James stated that he was still working (exceptionally slowly!) on replacing PUI (as part of removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)), and that he doesn't think /any/ of us *want* to be working on these features particularly, but projects like these need to be done before anyone can have fun with VSG or Vulkan (personally James would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it)). Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. <ref>https://sourceforge.net/p/flightgear/mailman/message/37077158/</ref>

In 10/2020, the estimation is that PUI should be going away really ‘soon’, the replacement code is already in next / 2020.2. (There’s no plan to actually /use/ the new UI code in 2020.2, but if the bugs in it prove simple, we could actually turn it for specific dialog: it seems very unlikely this makes sense for a stable release however)<ref>https://sourceforge.net/p/flightgear/mailman/message/37123818/</ref>

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and James is going to focus on PUI in the rest of 2020). James hopes that means next year he can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.<ref>https://sourceforge.net/p/flightgear/mailman/message/37129098/</ref>

The PUI UI and replacement can co-exist in the same build (they already do, effectively.<ref>https://sourceforge.net/p/flightgear/mailman/message/37131297/</ref>

In 11/2020, James suggested not to worry about details such as PUI styling/theming etc: we’re not making such changes for the LTS, and PUI should be gone before the next release.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142225/</ref> Also, he recommended (to everyone) to stop touching GUI stuff for a few weeks, as he's about to turn it all on its head.<ref>https://sourceforge.net/p/flightgear/mailman/message/37142356/</ref>

=== 2019 ===
The new GUI has been incubating for a few years, but there's apparently been a lot of progress as of 10/2019.

It is likely the new GUI will be a user opt-in feature - at least initially. The sunset of the PLIB library _could_ happen relatively soon, but
people will need to see the new GUI and react to it before we could commit to PLIB removal <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36784489/
|title = <nowiki>Re: [Flightgear-devel] in Flightgear/Simgear C++ Code: What needs Doing? What are YOU Doing? What would you do if you had the time? </nowiki>
|author = <nowiki> Scott Giese </nowiki>
|date = Oct 14th, 2019
|added = Oct 14th, 2019
|script_version = 0.50
}}</ref>.

In 02/2019, James stated that the new UI is coming quite soon. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36589420/
|title = <nowiki> Re: [Flightgear-devel] Lagging </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Feb 17th, 2019
|added = Feb 17th, 2019
|script_version = 0.40
}}</ref>

=== 2018 ===
{{See also|QtQuick use in FlightGear}}

According to James, we have to accept that changes like testing or making [[PUI]] a modular thing or moving the JS code tend to have an immediate pain for some people (because strange stuff gets broken, and takes some time to get fixed), whereas the payoff in terms of improved joystick handling or replacing the UI or testing of all subsystems will take some months or years to be felt.<ref>https://sourceforge.net/p/flightgear/mailman/message/36323240/</ref>

James said he was in the middle of porting the launcher’s final tab (location) to the new UI scheme, once that’s done he will start sketching out the ‘in sim’ settings UI using the same pieces. He’ll send a request for contributions around about that in the next three-four weeks, once he has enough templates & examples that there is a clear pattern to follow.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/2d10f16c-ddc8-07f3-07e7-eca2a0a0d55f%40zaretto.com/#msg36293586</ref>

James announced that the launcher is now feature complete with the QtQuick UI, he’ll keep making bug-fixes of course as people report them, but my todo list for the core features is now done<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>.

=== 2017 ===

In 10/2017, James said he was getting really close to having the PUI replacement UI suitable for beta-testing.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36067646/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 7th, 2017
|added = Oct 7th, 2017
|script_version = 0.40
}}</ref>

Originally, James was hoping to land the PUI replacement GUI in the last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current PUI/Canvas approaches, but are trivial with the new [[QtQuick use in FlightGear|QtQuick based UI scheme]].<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36059822/
|title = <nowiki> Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP,
VFR Sectionals </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 1st, 2017
|added = Oct 1st, 2017
|script_version = 0.40
}}</ref>

Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36061229/
|title = <nowiki> Re: [Flightgear-devel] FGFS macOS Menubar </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 2nd, 2017
|added = Oct 2nd, 2017
|script_version = 0.40
}}</ref>

Technically, this entails replacing dialog.cxx with some code which builds up some special ‘PUI-Emulation’ QtQuick controls, so that existing dialogs (especially from Aircraft) continue to work. This mode will look somewhat ugly but hopefully no more ugly than PUI! And it helps that the set of widgets we have in PUI is limited, and the ‘tricky’ widgets (map, scrolling list, etc) are in the dialogs will will replace with new ones first.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068767/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

This PUI emulation isn't going to use any code from PLIB<ref>https://sourceforge.net/p/flightgear/mailman/message/36985303/</ref>, so what will remain from it in FG afterwards will be the FNT and JS components (reworked).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/36068817/
|title = <nowiki> Re: [Flightgear-devel] PLIB features in plib svn but not in any
release </nowiki>
|author = <nowiki> Florent Rougon </nowiki>
|date = Oct 8th, 2017
|added = Oct 8th, 2017
|script_version = 0.40
}}</ref>

=== 2016 ===
We need to explore if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim.

James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. Hell create some QObjects which expose commands and the property tree and Nasal.

This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. James got this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if he can make it work on a normal, non-Qt OSG window inside FlightGear.<ref>https://sourceforge.net/p/flightgear/mailman/message/35156051/</ref>

The idea is to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources.

Of course, aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.<ref>https://sourceforge.net/p/flightgear/mailman/message/35155721/</ref>


== References ==
{{Appendix}}

[[Category:PUI| ]]
[[Category:Rendering roadblocks]]

Discord

2024-03-12T15:48:31Z

SammySkycrafts: /* Aircraft-specific */ Update Tonka server invite link

'''Discord''' is used in the FlightGear community as an alternative to [[Mumble]], [[TeamSpeak]], [[FGCom]] or [[Ventrilo]].

Discord is a free voice and chat software that can be downloaded as an app or used in a browser.

== Invite links ==
{{note|1=Its advised that you create a permanent account, instead of creating guest accounts as some people create duplicate accounts which clogs up the member logs and makes it more difficult to @mention people.}}

Furthermore many other FlightGear servers exist that you may need an personal invite to join. The easiest way to find them is to go to the FlightGear server and ask or ask in forums.

== FlightGear Communities on Discord ==

=== General, Help and Support, Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| FlightGear
| https://discord.gg/rzuV2DR
|-
| FlightGear FDM School
| https://discord.gg/Uyrtsar
|-
| FlightGear Air Race League
| https://discord.gg/HCAuU9D
|-
| FlightGear Virtual Alliance
| https://discord.gg/VqzTG2N
|-
| FG Events
| https://discord.gg/GY4N6Cu
|-
| FG FDM School
| https://discord.gg/U5KXyMU
|-
| FlightGear Republic, A friendly community about FlightGear.
| https://discord.gg/sBJy46Uq7z
|-
|FlightGear soaring club
|https://discord.gg/NvJjmzMfRP
|}

=== Military Aviation Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| Operation Red Flag military FG community (OPRF)
| https://discord.gg/ptVapkE
|-
| Combined Joint Task Force 50 (OPRF event planning/hosting and more)
| https://discord.gg/2nxjb6y
|-
| Warbirds, WWII-era aircraft
| https://discord.gg/yJaP5Wn
|}

=== Country Specific Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| FlightGear Australia (Scenery Development & Community)
| https://discord.gg/JzTEXsZ
|-
| FlightGear Italia (ITA Mercenaries)
| https://discord.gg/5RzyXRf
|-
| FlightGear Germany
| https://discord.gg/FNnpjCPSze
|-
| FlightGear Indian Community
| https://discord.gg/Tu7n5FmG5S
|-
| FlightGear Asia
| https://discord.gg/7saCkA2jQj
|-
| FlightGear Hong Kong
| https://discord.gg/9QVKcT6skU
|-
|FlightGear Myanmar
|https://discord.gg/VbT88KEGrk
|-
|FlightGear Poland (FlightGear Polska)
|https://discord.gg/5J7uVYRhZV
|}

=== Aircraft-specific ===
{| class="wikitable"
! Aircraft !! Invite link
|-
| Aermacchi MB-339
| https://discord.gg/vNZ5ZPv
|-
| Airbus [[Airbus A320 Family|A320]] & A330 Development
| https://discord.gg/7kzg9Te
|-
| Airbus A350 Development
| https://discord.gg/vK5f2s6
|-
| Boeing F/A-18C Hornet
| https://discord.gg/8GzpdK4j8P
|-
| LincolnWorks (747 and A380)
| https://discord.gg/2DMVpnJ
|-
| F-111 Aardvark
| https://discord.gg/DSrSbmx
|-
| [[General Dynamics F-16 Fighting Falcon]]
| https://discord.gg/8RcYnjA
|-
| [[PZL-Koliber-family | PZL Koliber family]]
| https://discord.gg/beADn2sWM6
|-
| Octal450 Hangar Development
| https://discord.gg/gxAhC3j
|-
| [[Mikoyan-Gurevich MiG-21bis]]
| https://discord.gg/bs8xyz3
|-
| [[Mirage 2000]]
| https://discord.gg/xZ3r2KR
|-
| Panavia Tornado
| https://discord.gg/SYxgzkCrSG
|-
| [[Saab 37 Viggen]]
| https://discord.gg/RJTwS9a
|-
| SEPECAT Jaguar
| https://discord.gg/G5q5XYN
|-
| FG-1000 Stealth Fighter
| https://discord.gg/3MFZauxyPW
|-
|Boeing 777
|https://discord.gg/8McTuYdK
|-
|A-10 Warthog
|https://discord.gg/RmtjmsT5vS
|-
|Soviet Aviation for FGFS
|https://discord.gg/YC2EYGK5Xf
|-
|B-1 Lancer
|https://discord.gg/d2bhwFCnX2
|}

==External links==
*https://discord.com/ Official website

[[de:Discord]]

[[Category:Software]]
[[Category:Community]]
[[Category:Air Traffic Control]]

$FG HOME

2024-01-21T22:12:28Z

SammySkycrafts: Update macOS hidden folder information

[[File:Fghome-3.7.png|400px|right|Screen shot showing typical structure [[$FG_HOME]]]]

The [[Environment variables|environment variable]]<code>'''$FG_HOME'''</code> is a '''setting''' indicating the main location where user-specific FlightGear data is stored (not application data). <code>$FG_HOME</code> is a notable place were FlightGear data is written to. <code>$FG_HOME</code> is also where large amounts of data downloaded by FlightGear like [[TerraSync]] scenery or Aircraft data is written to, by default.

<code>$FG_HOME</code> should not be confused with <code>[[$FG_ROOT]]</code>, which is generally read-only.

<code>$FG_HOME</code> is normally used to refer to the operating system specific location for some settings/folders. Its default value is determined by the <code>fgfs</code> binary during startup and is a directory that varies with the operating system supported by FG (Windows, OS X and Linux). ''It is [https://sourceforge.net/p/flightgear/mailman/message/34995089/ highly recommended] to rely on the default value (i.e., not setting <code>$FG_HOME</code> yourself in any way), unless you Really Know What You Are Doing™.''

Very advanced users (i.e. power users and developers) who wish to run parallel installs of FlightGear can specify a different <code>$FG_HOME</code> for each install as described below.

{{note|The <code>/sim/fg-home</code> property should be considered read-only, for similar reasons why <code>$FG_HOME</code> shouldn't be explicitly set by users.}}
{{note|FlightGear reads the <code>[[Fgfsrc|fgfsrc]]</code> config file from <code>$FG_HOME</code> if it exists (<tt>fgfsrc</tt> without any leading dot), in addition to <tt>.fgfsrc</tt> from <code>$HOME</code> (with a leading dot in this case).}}

== Content ==
In <code>$FG_HOME</code> is information stored between sessions. That information is for example configuration/preferences, properties marked with the <code>user-archive</code> attribute and aircraft-specific settings (using the data helper class in <code>aircraft.nas</code>). <code>$FG_HOME</code> is also the location for the SQLite-based [[Navdata cache|navdata cache]].

== Common paths ==
You can determine the location of your <code>$FG_HOME</code> by using the [[property browser]] and checking the value of <code>/sim/fg-home</code>, but the usual paths are shown below.

You can also use the [[Nasal Console]] to print out <code>$FG_HOME</code>:
<syntaxhighlight lang="nasal">
var path = getprop("/sim/fg-home");
print("Your $FG_HOME is at: ", path);
</syntaxhighlight>

The <code>/sim/</code> property subtree is also the place where you can find other folders, such as <code>fg-root</code>, <code>fg-scenery</code> and the current working directory (<code>fg-current</code>).

=== Linux ===
<code>~/.fgfs/</code>

=== Mac OS X ===
<code>~/Library/Application Support/FlightGear</code> (`~/Library` is a hidden folder by default. In versions of macOS newer than 10.12, you can use the shortcut `Cmd + Shift + .` to view hidden folders. For older versions, see [http://www.mikesel.info/show-hidden-files-mac-os-x-10-7-lion/])

As all future FlightGear versions will take their preferences from here, it is a good idea to have their access available easily.

Desktop/Finder/Go/Go to Folder is where you need to start.

When given the option, input: <code>~/Library/Application Support/FlightGear</code>

It is probably a good idea to have <code>~/Library/Application Support/FlightGear</code> saved on a Stickies note just in case you forget it.

If you want/need to refer to any of these files frequently, you could make an alias of a file, or the whole folder, and place it somewhere easier to access. TerraSync data is stored in <code>$FG_HOME/TerraSync</code> in the default configuration, see [[TerraSync]] for details.

=== Windows ===

==== FlightGear 2020.3 and later ====
<code>%userprofile%\FlightGear</code>

<code>%userprofile%</code> is the directory that contains the [https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/bb776892(v=vs.85) Windows user profile] ([http://web.archive.org/web/20210320110758/https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/bb776892%28v=vs.85%29 perm])<code>.</code>Ways to find the<code>%userprofile%</code> directory: 1). Press <code>Windows key+R</code>or bring up the RUN box. Type <code>%userprofile%</code> to open. 2). In command prompt, type <code>cd</code> <code>%userprofile%</code>

<code>%userprofile%</code> is<code>%homedrive%\Users\''User name''</code> by default. Usually on most peoples systems: <Code>%homedrive%</Code> is C:\.

For example if your user profile was called <code>MyUserProfile</code>, it would most often be located under <code>C:\Users\MyUserProfile</code> . Then the path to <code>$FG_HOME</code> would be <code>C:\Users\MyUserProfile\FlightGear.</code>

In 2020.3.x the [[FlightGear Qt launcher|qt-launcher]] will notify users who have data in the old location under <code>%userprofile%\Documents\FlightGear</code>, and prompt users to move files to the new location under <code>%userprofile%\FlightGear</code>.

==== FlightGear 3.0 and later ====
<code>%userprofile%\Documents\FlightGear</code>

<code>%userprofile%</code> is <code>%homedrive%\Users\''User name''</code> by default, and <Code>%homedrive%</code> is usually C:\.

==== Before FlightGear 3.0 ====
<code>%APPDATA%\flightgear.org\</code>

<code>%APPDATA%</code> is another environment variable that depends on your Windows version. On XP and older, it can be found under <code>C:\Documents and Settings\''User name''\Application Data</code>. On Vista and later it can be found under <code>C:\Users\''User name''\AppData\Roaming</code>. The folder is hidden by default. See [http://windows.microsoft.com/en-US/windows-vista/show-hidden-files these instructions] to show the folder.

== Use in troubleshooting ==
As one user once said, "When in doubt delete <code>$FG_HOME</code>". Many problems, including corrupted databases, broken [[TerraSync]] and many others can be fixed by deleting <code>fgfs_0.txt</code>, <code>fgfs.txt</code>, <code>terrasync_cache</code>, and the [[Navdata cache|navdata cache]].

When you encounter problems, try deleting the files, but '''always''' keep the <code>[[Commonly used debugging tools#fgfs.log|fgfs.log]]</code> and <code>fgfs_0.log</code> log files to help in troubleshooting.

== Power Users ==

=== Parallel installs of FlightGear ===
Note you can also override FG_HOME in the environment, to have totally distinct installs - this would be my recommend approach to running multiple versions in parallel.
(The installers will always replace the stable / dev version as other commenters pointed out, so you can't use those so easily, you need to copy files around - I'm nota Windows expert so I don't know if there something that could be changed or improved here)
If you start multiple instances (the same version or different) of FGFS using the same value of FG_HOME (whether that be the default or a custom one), we use a lock file to ensure only one (the first) has write access. The rest will go into read-only mode, and as you can maybe guess, treat FG_HOME as read-only.
Sharing of aircraft / scenery is entirely about which paths are configured, BTW. However, one final caveat is that having multiple instances both running TerraSync, using the same terrasync dir, would likely act a bit funny. It ought to actually work, but it might download some things twice, and it's not a tested or supported configuration for the moment.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=304170#p304170
|title = <nowiki> Re: Is it possible to install multiple instanes of FG in Win </nowiki>
|author = <nowiki> zakalawe </nowiki>
|date = Jan 25th, 2017
|added = Jan 25th, 2017
|script_version = 0.40
}}</ref>

Using the same [[TerraSync|TerraSyn]]<nowiki/>c directory can save a lot of downloading and disk space. You can use the --terrasync-dir=path [[Command line options|command line]] option. For example --terrasync-dir=C:\Path\to\my\separate\terrasync\folder\TerraSync. It's possible to add this option in the <code>Settings > Additional Settings</code> section of the [[qt-launcher]].

== Related content ==
=== Wiki articles ===
* [[FlightGear configuration via XML]]
* [[$FG_ROOT]]
* [[Property browser]]
* [[Properties persistent between sessions]]

=== References ===
{{Appendix}}

[[Category:Special directories|HOME]]
[[Category:Environment variables]]

Discord

2023-11-18T15:38:08Z

SammySkycrafts: Add B-1 Development server and change name of A-10 server

'''Discord''' is used in the FlightGear community as an alternative to [[Mumble]], [[TeamSpeak]], [[FGCom]] or [[Ventrilo]].

Discord is a free voice and chat software that can be downloaded as an app or used in a browser.

== Invite links ==
{{note|1=Its advised that you create a permanent account, instead of creating guest accounts as some people create duplicate accounts which clogs up the member logs and makes it more difficult to @mention people.}}

Furthermore many other FlightGear servers exist that you may need an personal invite to join. The easiest way to find them is to go to the FlightGear server and ask or ask in forums.

== FlightGear Communities on Discord ==

=== General, Help and Support, Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| FlightGear
| https://discord.gg/rzuV2DR
|-
| FlightGear FDM School
| https://discord.gg/Uyrtsar
|-
| FlightGear Air Race League
| https://discord.gg/HCAuU9D
|-
| FlightGear Virtual Alliance
| https://discord.gg/VqzTG2N
|-
| FG Events
| https://discord.gg/GY4N6Cu
|-
| FG FDM School
| https://discord.gg/U5KXyMU
|-
| FlightGear Republic, A friendly community about FlightGear.
| https://discord.gg/sBJy46Uq7z
|-
|FlightGear soaring club
|https://discord.gg/NvJjmzMfRP
|}

=== Military Aviation Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| Operation Red Flag military FG community (OPRF)
| https://discord.gg/ptVapkE
|-
| Combined Joint Task Force 50 (OPRF event planning/hosting and more)
| https://discord.gg/2nxjb6y
|-
| Warbirds, WWII-era aircraft
| https://discord.gg/yJaP5Wn
|}

=== Country Specific Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| FlightGear Australia (Scenery Development & Community)
| https://discord.gg/JzTEXsZ
|-
| FlightGear Italia (ITA Mercenaries)
| https://discord.gg/5RzyXRf
|-
| FlightGear Germany
| https://discord.gg/FNnpjCPSze
|-
| FlightGear Indian Community
| https://discord.gg/Tu7n5FmG5S
|-
| FlightGear Asia
| https://discord.gg/7saCkA2jQj
|-
| FlightGear Hong Kong
| https://discord.gg/9QVKcT6skU
|-
|FlightGear Myanmar
|https://discord.gg/VbT88KEGrk
|-
|FlightGear Poland (FlightGear Polska)
|https://discord.gg/5J7uVYRhZV
|}

=== Aircraft-specific ===
{| class="wikitable"
! Aircraft !! Invite link
|-
| Aermacchi MB-339
| https://discord.gg/vNZ5ZPv
|-
| Airbus [[Airbus A320 Family|A320]] & A330 Development
| https://discord.gg/7kzg9Te
|-
| Airbus A350 Development
| https://discord.gg/vK5f2s6
|-
| Boeing F/A-18C Hornet
| https://discord.gg/8GzpdK4j8P
|-
| LincolnWorks (747 and A380)
| https://discord.gg/2DMVpnJ
|-
| F-111 Aardvark
| https://discord.gg/DSrSbmx
|-
| [[General Dynamics F-16 Fighting Falcon]]
| https://discord.gg/8RcYnjA
|-
| [[PZL-Koliber-family | PZL Koliber family]]
| https://discord.gg/beADn2sWM6
|-
| MD-11, MD-80, ITAF by Octal
| https://discord.gg/gxAhC3j
|-
| [[Mikoyan-Gurevich MiG-21bis]]
| https://discord.gg/bs8xyz3
|-
| [[Mirage 2000]]
| https://discord.gg/xZ3r2KR
|-
| Panavia Tornado
| https://discord.gg/26rvkr2
|-
| [[Saab 37 Viggen]]
| https://discord.gg/RJTwS9a
|-
| SEPECAT Jaguar
| https://discord.gg/G5q5XYN
|-
| FG-1000 Stealth Fighter
| https://discord.gg/3MFZauxyPW
|-
|Boeing 777
|https://discord.gg/8McTuYdK
|-
|A-10 Warthog
|https://discord.gg/RmtjmsT5vS
|-
|Soviet Aviation for FGFS
|https://discord.gg/YC2EYGK5Xf
|-
|B-1 Lancer
|https://discord.gg/d2bhwFCnX2
|}

==External links==
*https://discord.com/ Official website

[[de:Discord]]

[[Category:Software]]
[[Category:Community]]
[[Category:Air Traffic Control]]

Carrier over MP

2023-10-01T14:03:54Z

SammySkycrafts: Change titles to make it clearer that the "older versions" actually includes LTS

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

== Installation ==
===FlightGear 2.0.0 and later===
NB: It is not enough that you can see carriers in AI mode. You have to have MPCarrier in your aircraft path.

This can easily be accomplished by using the [[FlightGear_Qt_launcher]] directly accessing [[FGAddon]] and downloading the MP Carriers.

Alternatively: Download from the FGAddon archive in [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/MPCarrier/].

=== FlightGear 1.9.1 ===

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

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

== Commander/Captain of the Carrier ==
=== Starting FlightGear ===
Command the Nimitz:
% fgfs --aircraft=nimitz
Command the Eisenhower:
% fgfs --aircraft=eisenhower

(same for Clemenceau and Vinson).

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

=== Commanding the Carrier ===
Here are some principal tips:
* First see the aircraft help. Press '?'.
* To change orientation and position of the carrier (apart from using the rudder and speed, but that take a long time to cross ocean :) ), you can use the properties. You need to change the properties of the ai-carrier you are driving, e.g. for the Nimitz,find the /ai/models/carrier[i] that got Nimitz as name. Use the [[Property_browser]] to do so:
** In /ai/models/carrier[i]/position/ you can change lat, and lon to put it where you want (note that specifying lon/lat on the command line or in menu "Location->Position Aircaft in Air" will not have an effect).
** In /ai/models/carrier[i]/orientation you can make it face wind. Facing wind is important (with real weather fetch) to make the FLOLS green on approach.
* Set speed using PgUp/PgDown in manual control.
* To have a better sync between the pilots using the Nimitz, consider keeping a speed of 0 so that there's no drift between pilots.

== Pilot Using the Carrier ==

=== On next ===

[as of 2021-10-25]

Things will work without any special configuration.

Flightgear will automatically enable the appropriate matching AI scenario when an MP carrier appears.

==== Latching carriers ====

By default Flightgear uses Nasal to periodically change the AI carrier's velocity to make it approximately follow the MP carrier.

One can instead force the AI carrier to exactly follow the position and orientation of the MP carrier (done in C++ in each frame), by checking '''Always latch MP and AI carrier''' in the '''Multiplayer Settings''' dialogue (menu '''Multiplayer/Multiplayer Settings''').

This can work much better but requires that MP motion is smooth, e.g. by using [[Real_Time_manual]] or [[SimpleTime]] - see menu '''File/Time Mode'''.

For more information, see: {{flightgear file|docs-mini/README-mp-carriers.md}}

=== On 2020.3 and earlier ===

NB: You need to know which callsign and which carrier model to use.

Make sure to enable the AI scenario for the corresponding carrier (e.g. nimitz_demo if the model is the Nimitz).

==== From the Launcher====
The easiest way to configure your FlightGear session for an MP carrier is to use the Launcher like in the picture (the model is the Vinson and the callsign is OPFOR21 in the example). [[File:MP carrier settings in launcher.png|thumb|In the "Settings" tab under "Additional Settings" provide the necessary command-line arguments]]

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

For the Vinson it could e.g. be:
% fgfs --ai-scenario=vinson_demo --prop:/sim/mp-carriers/vinson-callsign=MP-029X --multiplay=.....

There is no need that the callsign reflects the TACAN setting - it is just a possible pattern do make it easier for others to use. There is no need to specify the --multiplay option either, if you are using the FlightGear launcher.

==== Within the Session ====
An alternative way to enable MP control of a carrier when on the multiplayer network use the MP carrier dialog available from Multiplayer->"MPCarrier selection" to select which MP carrier players you wish to see. A pre-requisite is that you already have the parameters set-up as per above.

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

==== Important ====

As a pilot you have to run by the books:
* Have the MPCarrier downloaded (The fact that you see the carrier when running AI scenarios is not enough proof that you actually have the MPCarrier. Try to find it in the aircraft dialog. If it is there, then you are good).
* You need to set the --prop:/... correct (note the carrier model name in the string before "-callsign"). This ensures that MPCarriers won't interfer with the normal AI scenarios.
* You need to have the corresponding AI scenario activated.
* In the AI scenarios you can find the carrier from 30+ nm with TACAN. In MP you might find it only from ca. 15+nm (as of 2020.1 version).

[[Category:Multiplayer]]

Hardware recommendations

2022-03-26T23:07:59Z

SammySkycrafts: /* Recommendations for FlightGear in 2021 (2020.3 LTS) */

{{Disclaimer|id=final-fixed-function-release}}

These '''hardware recommendations for [[FlightGear]]''' are based on community feedback, be sure to consult other sources before making serious decisions regarding computer hardware.

The performance of FlightGear depends on three main components in your computer: the CPU (processor), which makes all the computations; the graphics card, which renders the visual aspect of FlightGear, and RAM (also known as memory) which generally allows FlightGear to have more information running (for the lack of a more technical phrase).

You may also want to check out the following article on building your own FlightGear box based on decommissioned and refurbished server at [[Howto: Build a cheap FlightGear box]], and also learn about how the FlightGear project handles old hardware support at [[FlightGear and old Hardware]] - see [[Minimal Startup Profile]] to start with a bare minumum and turn up settings one by one.

Also see: [[FlightGear Benchmark]]

== Recommendations for FlightGear in 2022 (2020.3 LTS) ==
{{Stub|section=yes}}
FlightGear can scale the quality to run on a huge range of hardware at different quality settings.

''Note for old hardware'': Towards the less powerful end of the range, for FlightGear to run smoothly, it requires a video card with OpenGL drivers 2.0 or higher. You need to spend some time learning settings, and tweaking for bottlenecks, to run FlightGear on very old systems. See [[Minimal Startup Profile]] to start with a bare minimum and then turn settings up.

Quick notes:

* The LTS you should be running is the current 2020.3.12+ LTS. (February 2022).

* People buying new hardware with FlightGear in mind are encouraged to wait until LTS ''after'' the current 2020.3 LTS, ''if possible'' - that is, if they imagine they will be using the hardware for a long while so it makes a difference.
*# Future performance requirements will not be known until the LTS after the current LTS. Some of the big projects underway on the FlightGear next branch need to be finished before requirements can be determined. These projects include moving to: the new [[Compositor]] rendering framework, the [[World Scenery 3.0 roadmap|next generation scenery]] rendering and data format, a higher version of OpenGL, in-sim UI replacement, and so on.
*# Hardware prices will be expected to drop once the situation with the pandemic eases. Hardware is getting steadily faster. Hardware with the same performance is getting cheaper. You should never buy hardware for a ''future'' version of FlightGear or any other program. It's always better to wait until the application releases (and until the hardware purchase is justifiable as you have time to start using it properly).
*# There is a 1st rollout of buildings, roads, and objects for the world based on OSM data. Please don't buy hardware based on this rollout. The performance in future rollouts will improve drastically as objects are changed to a newer format. See [[OSM2City 1st Worldbuild]] for details.
* For current hardware requirements (with scenery layers containing the new OSM2City world-build disabled): FlightGear 2020.3 LTS is faster than the 2018.3 LTS. The 2018.3 LTS hardware profile below is valid - but only one profile and hardware build is available in the 2018.3 LTS section as of writing this.
* The DDS texture cache should be turned on:
:<code>[[Qt-launcher|Qt Launcher]] > Settings tab > Rendering > Show more > enable Cache graphics for faster loading</code> '''or''',
:<code>in-sim menu > View > Rendering > enable Use disk space for faster loading (DDS texture cache)</code>.
:The DDS texture cache makes loading faster, and can make the sim feel smoother. it also helps older systems - as it reduces VRAM usage on the Graphics card (GPU), as well as reducing RAM usage. The DDS texture cache will grow in size mainly as you try new aircraft. It will grow in size a bit as you visit new locations, if you have scenery objects like landmarks enabled.
* There is a new graphics profile system being developed for future FlightGear. This will at least have some named settings presets which can be associated with some hardware and performance categories.

== Recommended hardware for FlightGear 2018.3 LTS ==
Only one target performance and settings profile has been written below. Other settings profiles are to-do. FlightGear can scale the quality to run on a huge range of hardware at different quality settings.

''Note for old hardware:'' Towards the less powerful end of the range, for FlightGear to run smoothly, it requires a video card with OpenGL drivers 2.0 or higher. You need to spend some time learning settings, and tweaking for bottlenecks, to run FlightGear on very old systems. See [[Minimal Startup Profile]] to start with a bare minimum and then turn settings up.

Before selecting a GPU and CPU have a look at the benchmark lists in the [[Hardware recommendations#Mostly high and Max settings with 2015.2B mid range GPU|profile]] below for an approximate idea of performance. If you are choosing a laptop see the manufacturers website for that model to find out your GPU and CPU, and check the list. Remember the slowest component will be the limiting component. For example: if you want high graphics but your GPU is slow, having a very fast CPU will not help. Higher resolutions need faster GPUs: for example, you can't run FlightGear at 4k resolution with a laptop if your manufacturer has not included a very fast GPU, even if they have included a reasonably fast dedicated GPU - in these laptops you need to run FlightGear at lower resolution, or find a laptop with faster GPU. If you run out of RAM then you cannot have really high visibility ranges or object densities even if your GPU and CPU is fast. The tips in the sections below about avoiding Intel integrated GPUs, mobile laptop GPUs, and low range NVIDIA GPUs (xx10, xx20, xx30, xx40) apply.

''Note on hardware requirements''

Requirements are only valid for a target FPS, monitor resolution, usage, and graphics / simulation quality settings. People have a huge range of hardware.

For flight simulators the usage can vary depending on the craft used, how the craft is used, and over what scenery the craft is used. The visibility range can change with altitude, and how fast the scenery is loaded can change with speeds. How complex the visuals are depends on how much vegetation, or man-made buildings/objects, are in the visible scenery. The following all place different demands: slow and low with a balloon/[[pterosaur]]/glider/wingsuit/ground effect vehicle, slightly faster and higher in a single prop [[Cessna 172P|C172P]]/[[Cessna 182S|C182]]/[[Piper J3 Cub|Cub]]/[[Piper PA28 Warrior II|PA]], fast and low in a supersonic [[Saab 37 Viggen|Viggen]]/[[Grumman F-14 Tomcat|F-14]] jet, higher altitude but slower in a [[Airbus A320 Family|A320]] airliner, fast and high in a Concorde, extremely fast and high in suborbital craft like the [[X-15]] , or using a [[Space Shuttle|Shuttle]] or [[Vostok-1]] space craft that is fast enough to reach orbit. View distances can vary from [[:File:EC135 Heer.jpeg|individual grass blades]] in airport keep to seeing [[:Category:Screenshots of Earthview|entire continents]] from orbit using a separate orbital renderer. Flying over a dense forest can mean [[:File:Alouette-lll over the Carpathian Mountains in Romania in Autumn (Flightgear 2018.x).jpg|vast]] amounts of trees are in view, while flying over a barren desert or ocean can mean there are few objects. You can always fly with a lower scenery loading distance and/or a lower visibility distance. A cloudless day can mean there are fewer clouds to draw and also may be lighter on CPU to simulate as Advanced Weather tracks lifecyles of individual clouds. On very old systems turning down cloud density and visibility range can help - as can turning off parts of the Advanced Weather simulation, or using basic weather. If you are flying at night using instruments for navigation, you can turn down graphics settings a lot :) . Different craft place different demands on CPU and GPU. Some craft have detailed electrical, electronic, and mechanical systems which are demanding on the CPU to simulate, while a craft like a glider does not. Some craft have high fidelity graphics and complex electronic displays - these can be demanding on the CPU and loading times, not just the GPU!. Some craft have options to reduce graphics. Some craft have options to reduce CPU usage by making parts of the simulation less responsive or less fine-grained - but these craft tend to be craft which are demanding on the CPU to start with.

Tip: If you have a slow GPU or CPU, you may be able to find craft that are less demanding for your bottleneck. Different aspects of craft can be demanding on the GPU or CPU - systems & instruments, aircraft interior art, aircraft exterior art, or flight dynamics model (FDM). For example, some craft may have detailed systems and instruments but have simple interior art. Some research projects just produce a flight dynamics model with no art and simple systems. Don't worry about the CPU time taken by the flight dynamics model - it isn't really heavy on CPU to simulate - think of an offline flight dynamics engine like JSBSim as a photo viewer for digital fine-art - it may take hours, days or weeks to render a fine-art quality ray-traced [https://commons.wikimedia.org/wiki/File:Raytraced_image_of_several_glass_objects.png digital image] but your web browser can display it very quickly - similarly JSBSim can take the results of computational fluid dynamics done on a supercomputing cluster (like a ray-traced digital image), or taken from windtunnel data (like taking a photo), and simulate flight dynamics quite quickly. Tip: You can use the filter in <code>[[FlightGear Qt launcher|FlightGear Qt Launcher]] > Air craft tab > Browse > Filter using ratings > click Adjust minimum ratings</code> ([[FlightGear Qt launcher#Community video walkthroughs|video tutorial]]) to lower minimum ratings and look for craft which have e.g. good systems and flight dynamics model but simpler art - but this only gives a ''small'' clue - some craft like a glider may not have much systems to simulate or have a simple model so they are not demanding even when recreated in detail.

Without target FPS, monitor resolution, usage, and settings, requirements are meaningless other than for maximum settings (i.e. meaningless for what hardware people actually have) - even maximum settings are hard to predict as they depend on what scenery a flight can take place. It's not trivial to find exact specifications, even for commercial applications with lots of test systems. Some commercial 3d applications do give out specifications for less than max settings but these mostly do not give target performance/quality/usage at all, and a lot of 3d applications like games have limited usage patterns making it easier to check - since commercial screenshot galleries tend to be on the most powerful systems at time of release without stating hardware, not giving detailed performance/quality/usage targets is also a way of making people forget quality may not look anything like advertised on their hardware. The topic of quality and performance is not as simple as commercial applications make it out to be in their advertising. People should consider that a bit of time spent tweaking settings for the performance bottlenecks in your hardware, for your typical usages, can make a huge difference to visuals and FPS.

=== Mostly high and Max settings with 2015+ mid range GPU ===

==== Target performance: ====

* '''20-30 FPS''' with default [[Cessna 172P|C172P]]. Monitor resolution 1920 by 1080 (also known as 1080p , Full HD, or FHD).
** Note: actual smoothness depends on frame-spacing spikes - average FPS helps lower overall frame spacing.

==== Target settings: rendering and scenery: ====

* Renderer: [[Atmospheric light scattering|ALS]] (advanced renderer)
* <code>View > rendering</code> dialog:
** Maximum shaders: all shader sliders maxed (i.e. overlays: on).
** Scenery layers: Vegetation density: Very High (if you run into RAM issues try turning this down).
** Scenery layers: Vegetation shadows: on.
** Scenery layers: Buildings: Random buildings - or OSM2City with light scenery near small towns, but not OSM2City near areas dense with big buildings (heavier scenery needs a faster CPU). Tweaking random building density: Try setting<code>/sim/rendering/building-density</code> in the range of 1-10. You can set this in the [[property browser]], or as a [[Command line options|command-line option]] set in various ways including the [[FlightGear Qt launcher|Qt launcher]],
** Scenery layers: everything else on: Scenery objects (includes airport terminals), roads and railways, pylons, random scenery objects
** Cloud density and visibility range sliders: max.
* <code>View menu > Adjust LOD ranges</code> dialog
**[[Level Of Detail (LOD) Ranges#Scenery ranges|Level of detail ranges]]: default (single prop planes): 1.5km/9km/30km.
* [[Anti-aliasing]]: 4x or 8x Multi-sampling(MSAA). [[Anti-aliasing#Transparency anti-aliasing|Transparency anti-aliasing]] (called Adaptive anti-aliasing on AMD GPUs): Multisample.

* <code>Environment > weather > detailed weather</code> dialog:
**[[Weather#Advanced Weather|Advanced Weather]]: on.
** [[Weather#Advanced configuration|Advanced settings]] dialog: Enabled features: All: <code>Cloud shadows</code>, <code>Realistic visibility</code>, <code>Generate thermals</code>, <code>Terrain effects</code>, <code>Terrain pre-sampling</code>, etc. <code>Max visibility</code> : 250km

=== Hardware build: ===

* '''GPU''' (Graphics Processing Unit, or Graphics Card): A GTX 960 or 1050 Ti - or equivalent performance. More than 3000 ratings in this list: as of [http://web.archive.org/web/20210412095421/https://benchmarks.ul.com/compare/best-gpus April 2021]. [https://benchmarks.ul.com/compare/best-gpus Direct link] (Note: ratings numbers and list may have changed by the time you see it). Note: a GPU with this performance is capable of much more than 30 FPS.
* '''CPU''': 4 core Intel Sandybridge [https://en.wikipedia.org/wiki/Sandy_Bridge#Desktop_platform i5 2500] (released 2012) or faster. This build will be '''limited by the CPU''' . Try to get a newer generation [https://en.wikipedia.org/wiki/Intel_Core Intel CPU], or equivalent AMD Ryzen CPU, if possible - e.g. a 4th generation Intel [https://en.wikipedia.org/wiki/Haswell_(microarchitecture)#Desktop_processors Haswell] (4xxx) i5 CPU, or faster. For a fairly approximate idea of CPU performance needed (Sandybridge i5 2500 has a rating of ~1700) see this archived copy of a single-core benchmark list: [http://web.archive.org/web/20210412100323/https://www.cpubenchmark.net/singleThread.html April 2021] . [https://www.cpubenchmark.net/singleThread.html Direct link] (Note: this direct list may have changed ratings numbers by the time you see it). This list only gives single-core performance - and it is approximate - for example, when an application uses more than one core processor the frequency will drop slightly lowering performance. The only reason a 2012 Sandybridge 2500 can manage 20-30FPS is because core performance hasn't gone up that much - it has increased by about 2x. FlightGear uses multiple cores. Some people may be able to get FG to run fine with a fast high clock 2 core CPU from a newer generation of CPU. But a 4 core is recommended as future FlightGear will use cores even more.

*'''Memory''' (RAM): 8GB (12-16 GB preferred). If you lack RAM you need to reduce the level of detail ranges so less scenery is displayed.
*'''Disk:''' to do! .

=== FlightGear settings tips: ===

* This build is '''limited by CPU'''. If your CPU is not faster (newer generation), at least you can try turning up graphics more to give the GPU something to do (try increasing Anti-aliasing, turning up transparency anti-aliasing by selecting super-sampling variety, increasing tree density).
* GPU limited: Try turning down the resolution and [[anti-aliasing]] if you are GPU limited. The higher the resolution the more work the GPU must do. A 4k (UHD) resolution is like the pixel shader load of rendering on four 1080p screens at once! See [[Anti-aliasing#The%20trade%20off%20between%20graphics%20content.2C%20FPS.2C%20and%20graphics%20settings%20like%20anti-aliasing|The trade off between graphics content, FPS, and graphics settings like anti-aliasing]]
* GPU: For '''4k monitors''': Try reducing resolution to 1080p. A lot of laptops come with slow GPUs but have 4k screens. You should try the equivalent of a GTX 1080/2070 or a rating of about 7800 in this archived list, but you may have to tweak settings a bit: [http://web.archive.org/web/20210412095421/https://benchmarks.ul.com/compare/best-gpus April 2021]. [https://benchmarks.ul.com/compare/best-gpus Direct link] (Note: ratings numbers and list may have changed by the time you see it). See the advice on the [[Anti-aliasing#Tips on using anti-aliasing settings|anti-aliasing]] page.
** Notes: It's overlays and tree density that can put stress on the GPU.
* GPU: overlays require strong GPU power (that level of detail is not trivial).
* CPU: Aircraft that are heavier on CPU than than the C172P can drag down performance more if you are CPU limited.
* RAM & GPU: Trees at ultra consume a lot of RAM. They need GPU power too.
* RAM: If you run into RAM issues try turning down : [[Level Of Detail (LOD) Ranges#Scenery ranges|LoD:Rough]] (in <code>View menu > Adjust LOD range</code>), tree density, and LoD: bare.
* CPU & RAM: Using OSM2City scenery can also use up RAM and CPU. OSM2City version 2017.2 is compatible with FlightGear 2018.3 LTS. Try turning off roads and pylons if you are CPU limited. Try turning down LoD:rough if you are RAM/CPU limited. Random scenery objects can be heavy on CPU, try turning them off.
* GPU: ALS shaders sliders can be maxed in a lot dedicated GPUs, even quite old ones provided they are dedicated GPUs (and not integrated/mobile GPUs). It's mostly the scenery layer settings including tree density and LoD ranges that can be intensive.
* GPU / Disk space: turn on the <code>View > rendering > texture cache</code> for smoother FPS frame spacing and faster loading. This will take up extra space.
* ...what does this look like? Only the screenshots that have been uploaded to the wiki by volunteers are available right now. There is a wiki category with '''roughly''' [[:Category:Screenshots at high settings|high settings screenshots]]. Note: a lot of these screenshots use settings that are below this profile, the overlays screenshots typically have transparency anti-aliasing higher than multisampling, some screenshots are with a much older FlightGear, a substantial amount of screenshots laptops with weaker GPUs or computers with less than 16 GB of RAM, some screenshots are at slightly higher settings than this profile or at 4k resolution.To get to the highest settings in the category at 1080p and trees at ultra, you would need a GTX 1060 or higher (about [http://web.archive.org/web/20210314111800/https://benchmarks.ul.com/compare/best-gpus 4100] in ratings), 12-16 GB of RAM - lowering LoD ranges will help (low ranges are fine for low altitude flights especially in mountain areas). Not turning up transparency AA will help. The CPU would be maybe a bit faster than i5 2500 to populate trees quickly at ultra e.g. a fast Haswell i5, or an overclocked Sandybridge i5 2500k @ close to 5GhZ.

== Recommended hardware for FlightGear 3.20+ ==
{{See also|SIMD Support}}
Generally, if you want to see frame rates in the 20's and above and medium/high graphical settings, which is typically preferred, you should have a budget of at least $1000. The following list is recommended hardware. It is not required to any degree; however, if you're purchasing a new computer dedicated to FlightGear, it is highly recommended that you get a computer with at least these requirements.
; Display
* A screen with a resolution of at least 1024x768 @32bpp (most GUI dialogs cannot be used otherwise currently)
; Graphics processing unit
* A 3D video card (with AMD or NVIDIA chipset) with support for [[OpenGL]] 2.1 or better and at least 1024-2048MB of dedicated DDR3+ (DDR5 preferred) VRAM (i.e. 512 Mb VRAM minimum). FlightGear requires an '''OpenGL 2.1-compliant''' hardware-accelerated 3D video card to run at reasonable frame-rates. Most modern PCs have hardware-accelerated 3D cards. If your FlightGear video is not running smoothly, see [[Graphics drivers configuration]].
* See [[Supported Video Cards]] for a list of video cards known to work with FlightGear.
* Cards with working GLSL/shader support will enable FlightGear to run with more visual effects.
* If you are serious about running FlightGear, you should [[Problematic Video Cards#Intel GMA|avoid Intel HD/GMA cards]] at all costs - these are integrated chipsets that provide only basic OpenGL/GLSL support. See [[problematic video cards]] for a list of video cards that may not properly run.
; Processor
* At least 2-4 Gb '''free''' RAM (and more is better: when building/buying a new system, consider 6-8gb total the absolute minimum these days). FlightGear uses more than 500 Mb of RAM by default. If less free RAM is available, FlightGear would be slowed down significantly due to OS swapping.
* At least a quad core processor with ~ 2 GHz each, 64 bit architecture (and operating system) recommended (multi-core processors have benefits for some FlightGear components such as the threaded tile loader). When buying a new computer, buying at least a quad core computer (i.e. i7) is a good idea these days.
; Storage disk
* 5 Gb HD space for a minimum installation, approx. 10 Gb if you want to compile it yourself, plus up to 80 Gb for optional world-wide scenery. More space is required for people wanting to check out the latest base package from [[Git]]. People using [[Scripted Compilation on Linux Debian/Ubuntu]], will approximately need 30 Gb of disk space in total.
; Input devices
* A three button mouse or two button mouse with scroll wheel
* An optional [[joystick]]/yoke and/or pedals - Gameport or USB (HID compatible), see <tt>[[$FG_ROOT]]/Input</tt> for a list of input hardware known to work with FlightGear.
; Sound card
* An optional sound card, Soundblaster compatible, preferably with EAX support.

== NVIDIA ==
''April 2021 note:'' Check a GPU benchmark list like this for a '''rough''' idea of performance: [https://benchmarks.ul.com/compare/best-gpus Direct link] ([http://web.archive.org/web/20210412095421/https://benchmarks.ul.com/compare/best-gpus April 2021 archive]). If you are selecting a laptop find out what your GPU is - ask or check the manufacturers website page for the model of the laptop. Laptop GPUs: Laptops with NVIDIA 9xx and earlier series GPUs often have the mobile "M" variant. These are a lot slower than the normal version e.g. a GTX 960M is slower than a GTX 960. NVIDIA 10xx series and later use desktop equivalents in all laptops, or close to it. This is due to recent GPU technology using less power making it easier on laptop batteries. There are also Q-MAX variants that are only slightly slower than normal versions but use less battery - e.g. a GTX 1060 Q-MAX is only slightly slower than a GTX 1060 - see benchmarks. (April 2021)

Recent NVIDIA price/performance trends (March 2021):

* Each GPU slot tends to get the performance of the GPU slot above it from the last generation. e.g. A GTX 1650 (xx50 slot) will get the a the performance of a GTX 1060 (xx60 slot).
* The price and performance sweet spot are the midrange cards xx50, XX50 Ti and xx60. xx50 Ti might be around the best slot.
* The fastest cards are released first each GPU generation (e.g. xx80 Ti or xx90), and are priced high to sell to enthusiasts - for GPU chips yields are also low to start so there's a limited number of hardware.GPUs are released in decreasing order of performance to tempt people to buy a performance range that they don't need. AMD follows the same pattern.
* Hardware prices are expected to drop as the situation with the global pandemic eases.

Stay away from nVidia GPUs with a low second digit (x20, xx20, x40, xx40). Higher 2nd digit means more CUDA cores.

The number of CUDA cores matters much more than a few Mhz in frequency, since you can process more, in parallel.
Also watch out for bus width, as that has a big impact on data throughput. The more CUDA cores it has, the better. A GTX680 is lots and lots and lots more important than a CPU with a zillion cores.

In case of doubt, go for an older generation x60 (460, or 560), even a 260 would be much more of an improvement than the 620. Basically, Nvidia cards compile GLSL shaders and OpenCL kernels into CUDA kernels (sort of), so more CUDA kernels = more shader power.

Whatever GPU (and other hardware) you get, first of all make sure that it is fully supported by your OS of choice.
Thorsten mentioned in another thread that he purchased a computer with an NVIDIA GTX670 that ended up not being fully supported under Linux, so I'd suggest to be really careful here.

== Notebooks ==
If you are interested in running FlightGear on a notebook, you may also want to check out [[Notebooks known to run FlightGear]]. A regular notebook is not recommended if you plan to fly often on FlightGear.

== Components ==
Your overall experience on FlightGear generally depends on these components:
*Your '''CPU''', which makes all the calculations. This component isn't as important as your graphics card. However, you should keep in mind that your CPU is the brain of your computer. As stated above, it's recommended that you purchase a CPU that has at least 4 cores.
*Your '''graphics card''', which renders the visuals of FlightGear. This component is extremely important. If you have an amazing CPU but a lackluster graphics card, your framerate will be low. Also, it's recommended that you purchase a relatively new graphics card, as old ones (even if very powerful) have been known to cause rendering glitches.
*Your '''RAM''' (memory), which allows temporary storage of information. Memory is probably least important of the three when it comes to framerate; however, any less than 4 GB memory has been known to cause crashes in FlightGear.

=== Should I purchase a computer or build my own? ===
It is generally recommended that you build your own computer. Your money will get you much farther. However, it is also recommended that if you build your own computer, you know someone who knows their way around computers. Buying parts that you ''think'' may be powerful but truthfully are not, or worse case, not compatible, can lead to disappointment.

== Related content ==
* [[Supported Video Cards]]
* [[Graphics drivers configuration]]
* [[Troubleshooting Problems]]

[[Category:Articles to be updated for each release]]
[[Category:Hardware|Recommendations]]

[[de:Hardwareempfehlungen]]
[[es:Recomendaciones de hardware]]
[[fr:Hardware Recommendations]]
[[pl:Wymagania systemowe‎]]

Discord

2021-12-24T18:38:56Z

SammySkycrafts: /* Aircraft-specific */ Corrected "Boeing" Typo

'''Discord''' is used in the FlightGear community as an alternative to [[Mumble]], [[TeamSpeak]], [[FGCom]] or [[Ventrilo]].

Discord is a free voice and chat software that can be downloaded as an app or used in a browser.

== Invite links ==
{{note|1=Its advised that you create a permanent account, instead of creating guest accounts as some people create duplicate accounts which clogs up the member logs and makes it more difficult to @mention people.}}

Furthermore many other FlightGear servers exist that you may need an personal invite to join. The easiest way to find them is to go to the FlightGear server and ask or ask in forums.

== FlightGear Communities on Discord ==

=== General, Help and Support, Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| FlightGear
| https://discord.gg/rzuV2DR
|-
| FlightGear FDM School
| https://discord.gg/Uyrtsar
|-
| FlightGear Air Race League
| https://discord.gg/HCAuU9D
|-
| FlightGear Virtual Alliance
| https://discord.gg/VqzTG2N
|-
| FG Events
| https://discord.gg/GY4N6Cu
|-
| FG FDM School
| https://discord.gg/U5KXyMU
|-
| FlightGear Republic, A friendly community about FlightGear.
| https://discord.gg/sBJy46Uq7z
|}

=== Military Aviation Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| Operation Red Flag military FG community (OPRF)
| https://discord.gg/ptVapkE
|-
| Combined Joint Task Force 50 (OPRF event planning/hosting and more)
| https://discord.gg/2nxjb6y
|-
| Warbirds, WWII-era aircraft
| https://discord.gg/yJaP5Wn
|}

=== Country Specific Communities ===

{| class=wikitable
! Topic !! Invite link
|-
| FlightGear Australia (Scenery Development & Community)
| https://discord.gg/JzTEXsZ
|-
| FlightGear Italia (ITA Mercenaries)
| https://discord.gg/5RzyXRf
|-
| FlightGear Germany
| https://discord.gg/FNnpjCPSze
|-
| FlightGear Indian Community
| https://discord.gg/Tu7n5FmG5S
|-
| FlightGear Asia
| https://discord.gg/7saCkA2jQj
|-
| FlightGear Hong Kong
| https://discord.gg/9QVKcT6skU
|-
|FlightGear Myanmar
|https://discord.gg/VbT88KEGrk
|}

=== Aircraft-specific ===
{| class=wikitable
! Aircraft !! Invite link
|-
| Aermacchi MB-339
| https://discord.gg/vNZ5ZPv
|-
| Airbus [[Airbus A320 Family|A320]] & A330 Development
| https://discord.gg/7kzg9Te
|-
| Airbus A350 Development
| https://discord.gg/vK5f2s6
|-
| Boeing F/A-18C Hornet
| https://discord.gg/8GzpdK4j8P
|-
| LincolnWorks (747 and A380)
| https://discord.gg/2DMVpnJ
|-
| F-111 Aardvark
| https://discord.gg/DSrSbmx
|-
| [[General Dynamics F-16 Fighting Falcon]]
| https://discord.gg/8RcYnjA
|-
| MD-11 and Autoflight by Octal
| https://discord.gg/gxAhC3j
|-
| [[Mikoyan-Gurevich MiG-21bis]]
| https://discord.gg/bs8xyz3
|-
| [[Mirage 2000]]
| https://discord.gg/xZ3r2KR
|-
| Panavia Tornado
| https://discord.gg/26rvkr2
|-
| [[Saab 37 Viggen]]
| https://discord.gg/RJTwS9a
|-
| SEPECAT Jaguar
| https://discord.gg/G5q5XYN
|-
| FG-1000 Stealth Fighter
| https://discord.gg/3MFZauxyPW
|-
|Boeing 777
|https://discord.gg/8McTuYdK
|-
|A-10A Warthog
|https://discord.gg/RmtjmsT5vS
|}

== External links ==
* https://discord.com/ Official website

[[de:Discord]]

[[Category:Software]]
[[Category:Community]]
[[Category:Air Traffic Control]]

Howto:Animate models

2021-12-19T22:31:39Z

SammySkycrafts: /* Lights */ Corrected typo in "FlightGear"

The real world is full of motion. To simulate this in [[FlightGear]], '''models must be animated'''.

FlightGear allows you to animate models in response to property changes: for example, the propellers can spin when the engine is on and the elevators can move up and down with your controller. There is no fixed limit on what parts can be animated: the only requirements are that the part is named in the 3D model file, and that there is a property in the main tree that you can use to get the positioning information.

This document provides basic information for all kind of animations. When animating your model, it is very helpful to find an aircraft with parts similar to yours and use it as an example. Cut and paste the code into your wrapper file and then edit to suit.

== Notes ==
=== File name of main model and animation XML file ===
{{main article|Aircraft-set.xml#Not used for loading multiplayer aircraft}}
The file name of the main model and animation XML file, or the .ac file if there is no XML file, (in essence the property <code>/sim/model/path</code>) will be the name of the aircraft that is transmitted when using [[multiplayer]] and will also be used for loading multiplayer aircraft.

There is also a mechanism to substitute a full aircraft model with a simpler AI aircraft model if one is available at the same file path (including for example <code>Models/Boeing-797-800.xml</code>), but in <code>[[$FG_ROOT]]/'''AI'''/Aircraft/</code> instead of <code>$FG_ROOT/Aircraft/</code>.

=== .ac files ===
{{Main article|AC files: Understanding and changing .ac code#Identifying an object}}

When referring to an .ac file in your xml animation, it is important that the <code><object-name></code> exactly matches the object named in the .ac file (this includes cases!).

'''Note for SketchUp users:''' The spatial reference X/Y/Z used in animation to locate an object or a point are different from the ones in AC3D ie X values are the same in both but Y in animation must be matched to AC3D's -Z (Z value but opposite sign) and Z value in animation must be matched to AC3D's Y value.

'''Note for SketchUp users:''' when exporting to AC3D in Sketchup, the .ac file will name the objects in your model to "blah" by default. You need to amend the relevant object names in your .ac file using text edit, so that the xml will work.

=== Animation order ===
Animations are executed by FlightGear in the order that they are read in the model's .xml file. Therefore, it is very important to pay attention to the order, especially when multiple animations are applied to the same object(s). Wrong ordering of animations might cause [[Howto:Animate models#Timed|timed]] animations (used to create flashing lights) to not work. For further details see this [https://sourceforge.net/p/flightgear/mailman/message/37090714/ thread] on the development mailing list. Updated [https://scenery.flightgear.org/app.php?c=Models&a=browse&shared=18 shared Effects models] will be available very soon.

Similar problems can be encountered with the dist-scale instead of the timed animation.
== Tags used in most animations ==
=== Name ===
With a name animation, you can group multiple objects.

<source>
<animation>
<name>Collection1</name>
<object-name>Object1</object-name>
<object-name>Object2</object-name>
<object-name>Object3</object-name>
</animation>
</source>

The example above creates a "virtual object" with the name Collection1. In animation, we can animate this group of objects, by using:

<source>
<object-name>Collection1</object-name>
</source>

=== Object-name ===
These names are set in the 3D model. Each single object has a unique name; for easy identification it is advised to use descriptive names (LeftElevator, Rudder etc.). Animations are only applied to those objects that are mentioned in an object-name line (one object per line!). Animations lacking those, will be applied to the entire model.

=== Property ===
Each animation must be associated with exactly one property from the main FlightGear property tree (remember that the properties in the wrapper file are not part of the main tree), using <code><property></code> to provide the property path:

<source>
<animation>
<type>rotate</type>
<object-name>Rudder</object-name>
<property>controls/rudder</property>
</animation>
</source>

Note the omission of the leading slash '/' when referring to the property. This assures that when the model is used for AI or multiplayer traffic the animations will follow that of the AI controller instead of that of the user.

=== Axis ===
An axis part is required in every animation that involves a rotating or moving thing.

<source>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</source>

The axis are similar to the ones of the 3D model. There is a difference between rotation and translation:
* In rotation animations, the axis part defines around what axis the object rotates. Negative/positive values make the difference between counterclockwise and clockwise rotations.
* In translate animations, the part defines along what axis the object moves. If the x-axis is poiting backwards, an x-value of -1 will result in forward motion.

You could also define two points, between which FlightGear will calculate the correct axis. This makes the use of a [[#Center|<nowiki><center></nowiki>]] tag redundant! Such coordinates are extremely useful for animating control surfaces (rudder, elevators etc.).

<source>
<axis>
<x1-m> 4.9</x1-m>
<y1-m> 7.1</y1-m>
<z1-m>-1.0</z1-m>
<x2-m> 5.9</x2-m>
<y2-m>11.2</y2-m>
<z2-m>-0.5</z2-m>
</axis>
</source>

=== Center ===
Various animations ([[#Rotate|rotate]], [[#Spin|spin]], [[#Scale|scale]]) move around a center point.

<source>
<center>
<x-m>-1.50</x-m>
<y-m> 1 </y-m>
<z-m> 0.25</z-m>
</center>
</source>

The axis are similar to the ones of the 3D model, so finding coordinates is easily done in 3D modeling software.

=== Using a geometry object for axis and centre (2017.2) ===

Added in V2017.2 is support to allow a geometry object (a line segment with two vertices) that is used to define both the centre and the axis for an animation. This will work with rotate, translate and the knob animations.

The axis line should be balanced, i.e. it should protrude equal amounts. The axis line should be normalized (i.e. 1m) as its length acts as a factor (affecting translate animations).

The syntax for this is
<source>
<axis>
<object-name>some-object</object-name>
</axis>
</source>

Once the object-name used for the axis has been processed the geometry object will be hidden. This also allows a visual check for any axis objects that are not yet assigned.

It is possible to reuse the same object definition multiple times within a single XML file.

[[File:Canopy-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for a canopy]]

[[File:Gauges-knobs-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for cockpit elements]]

== Additional tags that can be used in most animations ==
=== Conditions ===
Multiple animations can make use of a conditional. Check <tt>$FGDATA/Docs/README.conditions</tt> for some more details.

* '''equals:''' property value (or second property) is equal to value/(first)property.
* '''greater-than:''' property value (or second property) is larger than value/(first)property.
* '''greater-than-equals:''' property value (or second property) is greater than or equal to value/(first)property.
* '''less-than:''' property value (or second property) is smaller than value/(first)property.
* '''less-than-equals:''' property value (or second property) is smaller than or equal to value/(first)property.

The example below is true when n1 has a value greater than 25.
<source>
<condition>
<greater-than>
<property>engines/engine[1]/n1</property>
<value>25</value>
</greater-than>
</condition>
</source>

Then there are some special tags:

* '''and:'''
* '''not:'''
* '''or:'''

In the example below, the condition is true when either n1 is greater than 25% or equal to 0%.
<source>
<condition>
<or>
<greater-than>
<property>engines/engine[1]/n1</property>
<value>25</value>
</greater-than>
<equals>
<property>engines/engine[1]/n1</property>
<value>0</value>
</equals>
</or>
</condition>
</source>

An example of implementation into an animation looks as follows:

<source>
<animation>
<object-name>Object</object-name>
<type>rotate</type>
<property>suface-positions/left-aileron-pos-norm</property>
<factor>25</factor>
<condition>
<greater-than>
<property>suface-positions/left-aileron-pos-norm</property>
<value>10</value>
</greater-than>
</condition>
<center>
<x-m>-1.50</x-m>
<y-m> 1 </y-m>
<z-m> 0.25</z-m>
</center>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
</source>

=== Interpolation ===
For non-fixed factors, an interpolation "table" can be created.

<source>
<interpolation>
<entry>
<ind> 0.0</ind>
<dep> 0.0</dep>
</entry>
<entry>
<ind> 0.667</ind>
<dep> 0.0</dep>
</entry>
<entry>
<ind> 1.0</ind>
<dep> 0.5</dep>
</entry>
</interpolation>
</source>

The lines above represent the following table:

{|
!Input
!Output
|-
|0.0
|0.0
|-
|0.667
|0.0
|-
|1.0
|0.5
|}

You can add as many entries as you need. Interpolation tables are often used for gear animations (eg. to open doors during gear-movements and close them again once the gear is either retracted or fully extended).

=== Expressions ===
For some animations it is possible to define complex animations by using [[Expressions|Expressions]]. This even allows to drive the animation from multiple properties without the need for additional Nasal scripts. Here is an example for a translate animation depending on two properties and the cosine function:
<syntaxhighlight lang="xml">
<animation>
<type>translate</type>
<expression>
<product>
<property>/my/factor-property</property>
<cos>
<deg2rad>
<property>/my/angular-property</property>
</deg2rad>
</cos>
</product>
</expression>
[..]more elements[..]
</animation>
</syntaxhighlight>

Animations which can utilize [[Expressions|Expressions]] are:
* [[Howto:Animate_models#Translate|Translate]]
* [[Howto:Animate_models#Rotate|Rotate]]
* [[Howto:Animate_models#Scale|Scale]]
* [[Howto:Animate_models#Range|Range]]
* [[Howto:Animate_models#Blend|Blend]]

See more detailed info at [[Expressions|Expressions]]

== Lights ==
As of January 2021 FlightGear supports multiple light sources just like Project Rembrandt has always done.
[[Compositor#Lights|Adding lights to a model]]

== Object animations ==
=== Alpha-test ===
<source>
<animation>
<type>alpha-test</type>
<object-name>Object</object-name>
<alpha-factor>0.01</alpha-factor>
</animation>
</source>
This "animation" is a way to set an alpha test on a model branch. The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. This is particulary useful when modeling a metallic structure or a tree with a billboard. The threshold of transparency is set with the <alpha-factor> element. See also [[Pixel testing in effects]].

=== Blend ===
Blends an object with the surrounding. Comparable to a translucency animation. A value of 0 corresponds to no transparency, i.e. and ordinary solid object, and a value of 1 makes the object fully transparent, i.e., not visible at all.

<source>
<animation>
<type>blend</type>
<property>/velocities/airspeed-kt</property>
<factor>0.00025</factor>
<min>0.2</min>
<max>0.7</max>
</animation>
</source>

* '''property:'''
* '''factor:'''
* '''min:'''
* '''max:'''
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]

Note that when using the Project Rembrandt renderer, all transparent and translucent objects must be registered to display properly. [[Project_Rembrandt#Registering_all_translucent_surfaces|More information here.]]

=== Billboard ===
This faces an object towards the viewer. Often used on 2D objects, like clouds, trees and lights.

<source>
<animation>
<type>billboard</type>
<object-name>Object</object-name>
<spherical type="bool">true</spherical>
</animation>
</source>

* '''spherical:'''

=== Dist-scale ===
Used to scale an object, based on the distance to the viewer. <code><nowiki><ind></nowiki></code> and <code><nowiki><dep></nowiki></code> (independent and dependent) are the distance in meters and the scale at that distance.

<source>
<animation>
<type>dist-scale</type>
<object-name>Object</object-name>
<interpolation>
<entry>
<ind>0</ind>
<dep>1</dep>
</entry>
<entry>
<ind>300</ind>
<dep>4</dep>
</entry>
<entry>
<ind>1500</ind>
<dep>8</dep>
</entry>
</interpolation>
</animation>
</source>

You can optionally add [[#Center|<center>]] coordinates, to scale the object around that point.

=== Flash ===

Used to scale an object based on the cosine of the angle between the axis provided in the animation and the view vector.

<source>
<animation>
<type>flash</type>
<object-name>Object</object-name>
<offset>0.0</offset>
<factor>1.0</factor>
<power>2</power>
<two-sides type="bool">false</two-sides>
<min>0.0</min>
<max>1.0</max>
<center>
<x-m>0.0</x-m>
<y-m>0.0</y-m>
<z-m>0.0</z-m>
</center>
<axis>
<x>0.0</x>
<y>-1</y>
<z>0.1</z>
</axis>
</animation>
</source>

* '''offset:'''
* '''factor:'''
* '''power:'''
* '''two-sides:''' if false, nothing is drawn if the cosine is negative.
* '''min:'''
* '''max:'''

scale = factor * pow( cosine, power ) + offset

scale is then clamped between min and max.

and this scale factor is applied to the object, from the center specified. It works best if scale is less than 1. Otherwise, there will be clipping issues.

=== Noshadow ===
This animation is used to make sure an object will cast no shadow.

<source>
<animation>
<type>noshadow</type>
<object-name>Object</object-name>
</animation>
</source>

=== Range ===
: ''See also [[Modeling - Getting Started#Level of Detail (LOD)]].''

To prevent objects -like instruments- being drawn when the aircraft is actually too far away for them to be seen anyway, a range animation is used.

<syntaxhighlight lang="xml">
<animation>
<type>range</type>
<min-m>0</min-m>
<max-m>30</max-m>
</animation>
</syntaxhighlight>

* '''min-m:''' the shortest distance (in meters) from the object center at which it is visible.
* '''max-m:''' the largest distance (in meters) from the object center at which it is visible.

You could also use the generic level of detail (LOD) properties, which can be set by the user through View > Adjust LOD rangers:
{| class="wikitable"
! Property
! Description
! Default value
|-
|<tt>/sim/rendering/static-lod/bare</tt>
| only a rough exterior model
| 30,000 m
|-
|<tt>/sim/rendering/static-lod/rough</tt>
| most should be visible
| 9,000 m
|-
|<tt>/sim/rendering/static-lod/detailed</tt>
| all details should be visible
| 1,500 m
|}

The animation code will look like this:
<syntaxhighlight lang="xml">
<animation>
<type>range</type>
<min-m>0</min-m>
<max-property>sim/rendering/static-lod/bare</max-property>
</animation>
</syntaxhighlight>

You can have both ranges (max and min) bound to a property, or just one of them.
* '''min-property:'''
* '''max-property:'''
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]

=== Rotate ===
One of the most important and frequently used animations of all. It rotates an object to an absolute position in degrees, as provided by the property-value.

<source>
<animation>
<object-name>Object</object-name>
<type>rotate</type>
<property>surface-positions/left-aileron-pos-norm</property>
<factor>25</factor>
<offset-deg>25</offset-deg>
<center>
<x-m>-1.50</x-m>
<y-m> 1 </y-m>
<z-m> 0.25</z-m>
</center>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
</source>

* '''factor:''' is optional.
* '''offset-deg:''' is optional. Offset in degrees.
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]

=== Scale ===
A scale animation scales (resizes) an object. This can be either property-value dependant (first example) or a fixed scale (second example).

<source>
<animation>
<type>scale</type>
<object-name>Object</object-name>
<property>sim/time/sun-angle-rad</property>
<x-min>1.0</x-min>
<y-min>1.0</y-min>
<z-min>1.0</z-min>
<x-factor>1.4</x-factor>
<y-factor>1.4</y-factor>
<z-factor>2.0</z-factor>
</animation>
</source>

* ?-min: the mimimum scale factor for each axis. If the property value would result in a smaller factor than this setting, the scale animation will hold.
* ?-factor: the scale factor for each axis (factor*property=scale factor).

<source>
<animation>
<type>scale</type>
<x-offset>0.5</x-offset>
<y-offset>0.5</y-offset>
<z-offset>0.5</z-offset>
</animation>
</source>

* x.offset: the scale factor.
* Add [[#Center|<center>]] coordinates, to scale the object around that point.
* '''You can optionally use an [[Howto:Animate_models#Expressions|expression]] in the <factor> or <offset> inputs.''' For more details see [[Expressions|Expressions]]

=== Select ===
This animation selects (or unselects) objects when certain conditions are true (or false). The example below shows the object when the n1 of engine[1] is higher than 25%.

<source>
<animation>
<object-name>Object</object-name>
<type>select</type>
<condition>
<greater-than>
<property>engines/engine[0]/n1</property>
<value>25</value>
</greater-than>
</condition>
</animation>
</source>

=== Shader ===
<source>
<animation>
<type>shader</type>
<shader>chrome</shader>
<texture>chrome2.png</texture>
<object-name>Object</object-name>
</animation>
</source>

* '''shader:'''
* '''texture:''' path to the texture used by the shader.

=== Spin ===
Very similar to [[#Rotate|rotate]], but the property provides a value in revolutions per minute (RPM) rather than an absolute position in degrees, and offset cannot be used.

<source>
<animation>
<object-name>Object</object-name>
<type>spin</type>
<property>engines/engine[0]/n1</property>
<factor>25</factor>
<center>
<x-m>-1.50</x-m>
<y-m> 1 </y-m>
<z-m> 0.25</z-m>
</center>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
</source>

* '''factor:''' is optional.

=== Timed ===
Swtiches between objects at specified intervals. This example switches between a lights-on model and a lights-off model. Lights on are shown 0.2 seconds, while lights off are displayed for 0.8 seconds.

<source>
<animation>
<type>timed</type>
<object-name>BacklightOn</object-name>
<object-name>BacklightOff</object-name>
<use-personality type="bool">true</use-personality>
<branch-duration-sec>0.8</branch-duration-sec>
<branch-duration-sec>0.2</branch-duration-sec>
</animation>
</source>

=== Tracking ===
The new (in 2.11) [[Howto:Animate gear scissors using the tracking animation|''locked-track animation'']] can do exactly the same thing as the [https://docs.blender.org/manual/en/latest/animation/constraints/tracking/locked_track.html Locked Track constraint] available in Blender. However it can also be used to simulate simple inverse kinematic systems consisting of two bones connected with a revolute joint (aka hinge). See [[Howto:Animate gear scissors using the tracking animation|detailed explanation]].

=== Translate ===
The same as [[#Textranslate|textranslate]], but this animation moves a whole object (so including fixed textures). The example below will move an object in the y-direction:

{| class="wikitable" border="0" cellspacing="0"
!Property value
!Output
|-
| -1
| -2.5
|-
| 0
| 2.5
|-
| 1
| 7.5
|}

<source>
<animation>
<type>translate</type>
<object-name>Object</object-name>
<property>controls/seat/pilot/position-norm</property>
<factor>5</factor>
<offset-m>2.5</offset-m>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>
</source>

When using interpolation tables such as:
<source>
<interpolation>
<entry><ind>0.0</ind><dep> 0</dep></entry>
<entry><ind>0.666</ind><dep>0.18</dep></entry>
<entry><ind>1.0</ind><dep>0.27</dep></entry>
</interpolation>
</source>
The first figure (<ind> refers to the value of the property associated with the object and the second figure (in <dep>) refers to the amount that the object moves in metres. For example, in this case, the object moves 18cm when the value reads 0.66 and 27cm when the value is 1.

'''IF used WTIHOUT property''' : The object is placed at some (Value of Offset) meters away from its original position, along the virtual axis formed by said original position and the point with coordinates x/y/z defined in the <axis> tag.
Mathematically, assuming the Object to translate is (in the model space) placed at point A (x1, y1, z1) and you want to relocate it to point B (x2, y2, z2) then x2,y2,z2 are the values in the <axis> tag of the Translate animation and <offset> can be computed as SQRT((x2-x1)^2+(y2-y1)^2+(z2-z1)^2)

* '''factor:''' is optional.
* '''offset-m:''' is optional. Offset in meters.
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]

== Material animation ==
An animation type that can be used in various ways. Of course you can combine the below mentiond systems into one (big) animation.

<source>
<animation>
<type>material</type>
<object-name>Object</object-name>
<property-base>sim/model/c172p/material</property-base>
<global type="bool">true</global> 
...
lines as mentioned below
...
</animation>
</source>

'''Optional:'''
* '''property-base:''' when using prop(erties), you might want to set a property-base. All props will be relative to this path.
* '''global (deprecated):''' by setting this to <tt>true</tt>, all objects using the same material as the defined object(s) (via <tt><object-name></tt>) will be affected by the animation. This is preferred to listing several objects in <object-name> tags. It's not only faster, but also doesn't break animations by forcing objects together. This tag is no longer supported

'''Notes:'''
* Numbers are clamped to 0.0-1.0, except "shininess", which is clamped to 0-128.
* By appending <tt>-prop</tt> each of the material properties can read its value from another property.

=== Ambient ===
<source>
<ambient>
<red>1.0</red>
<green>0.2</green>
<blue>0.0</blue>
</ambient>
</source>

=== Diffuse ===
<source>
<diffuse>
<red>1.0</red>
<green>0.2</green>
<blue>0.0</blue>
</diffuse>
</source>

=== Emission ===
{{Main article|Howto: Illuminate faces}}
<source>
<emission>
<red>1.0</red>
<green>0.2</green>
<blue>0.0</blue>
<factor-prop>controls/lighting/panel-norm</factor-prop>
</emission>
</source>

Emission colors are multiplied by the factor-prop value. 1 is maximum color intensity, while 0 is the minimum. Colors are calculated according to the [http://en.wikipedia.org/wiki/RGB_color_model RGB color model].

=== Shininess ===
Shininess is clamped to 0-128.
<source>
<shininess>105</shininess>
</source>

=== Specular ===
<source>
<specular>
<red>1.0</red>
<green>0.2</green>
<blue>0.0</blue>
</specular>
</source>

=== Texture ===
Used for the [[Livery over MP]] system.

<source>
<property-base>sim/model/livery</property-base>
<texture-prop>engine</texture-prop>
<texture>KLM.png</texture>
</source>

=== Transparency ===
<source>
<transparency>
<alpha-prop>rotors/tail/rpm</alpha-prop>
<factor>-0.0015</factor>
<offset>1</offset>
</transparency>
</source>

=== Threshold ===
<source>
<threshold>0.001</threshold>
</source>

== Texture Animations ==

Applying different matrix transformations to the textures of an object.

=== Textranslate ===
A very important animation for cockpits! This animation moves textures over a surface.

<source>
<animation>
<type>textranslate</type>
<object-name>Object</object-name>
<property>autopilot/settings/target-speed-kt</property>
<bias>0.0001</bias>
<factor>0.001</factor>
<step>100</step>
<axis>
<x>0</x>
<y>1</y>
</axis>
</animation>
</source>

* '''bias:''' Adds an offset to the property before factor/step. A small value is needed to compensate for [http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems floating point accuracy].
* '''factor:''' property * factor * texture width/height = the amount of pixels that the texture should be translated. If your texture is 256 pixels, an textranslate of 0.1 will result in the texture moving with 26 pixels, into the direction specified by the axis settings.
* '''step:''' the step size at which the texture is translated. If this is set to 0.1, the texture will only be translated at 0.1, 0.2, 0.3 etc.
* '''axis:''' the direction in which the texture is translated. Y is up/down, while X is left/right.

=== Texrotate ===

<source>
<animation>
<object-name>Object</object-name>
<type>texrotate</type>
<property>some/property/path</property>
<factor>25</factor>
<offset-deg>25</offset-deg>
<center>
<x>0.5</x>
<y>0.5</y>
<z>0</z>
</center>
<axis>
<x>0</x>
<y>0</y>
<z>1</z>
</axis>
</animation>
</source>

=== Textrapezoid ===

<source>
<animation>
<type>textrapezoid</type>
<object-name>HUD.l.canvas</object-name>
<property>/hud/trapezoid-correction</property>
<side>bottom</side>
</animation>
</source>

* '''side''': side of quad which should be scaled (''top'' (default)/''right''/''bottom''/''left'')

=== Texmultiple ===

Only one texture matrix can be applied to each object. With ''textmultiple'' multiple texture animations can be combined into a single matrix, applied to the specified object.

<source>
<animation>
<type>texmultiple</type>
<object-name>HUD.l.canvas</object-name>
<transform>
<subtype>textranslate</subtype>
<property>/hud/offset-x</property>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</transform>
<transform>
<subtype>textranslate</subtype>
<property>/hud/offset-y</property>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</transform>
<transform>
<subtype>textrapezoid</subtype>
<property>/hud/trapezoid-correction</property>
</transform>
</animation>
</source>

== Object interaction animations ==
=== Enable-hot ===
Scenery objects are automatically defined as solid by FlightGear, meaning that an aircraft can taxi on them and/or crash when touching. For certain objects (groundmarkings, beacon light-beams etc.) this might be an unwanted feature. The solidness can be disabled with the following animation:

<source>
<animation>
<object-name>Object</object-name>
<enable-hot type="bool">false</enable-hot>
</animation>
</source>

* '''enable-hot:''' can be either true or false. Remember that objects are automatically solid, so it should not be necessary to set this at all when wanting solidness.

=== Interactions ===
<source>
<animation>
<type>interaction</type>
<object-name>Object</object-name>
<interaction-type>carrier-wire</interaction-type>
</animation>
</source>

* '''interaction-type:''' can have the following values:
**'''carrier-catapult:'''
** '''carrier-wire:''' makes the object act as an arresting wire, as used on [[aircraft carrier]]s.

== Direct manipulation animations ==
=== Knob / slider (v. 2.11-) ===
{{Main article|Knob / slider animation}}

=== Pick ===
{{Main article|Howto: Make a clickable panel#Pick}}

=== Touch ===

The touch animation provides the normalized coordinates of a touch (or click) event on a 2d surface. The coordinates are passed in the argument and can be accessed using cmdarg() in Nasal.

* Touch animation is designed to work with a quad that is being used as a Canvas placement (display).
* The touch animation must not be combined with a pick animation on the same object.
* More info here: [[Touch Animation]]

==== touch example ====

<animation>
<type>touch</type>
<visible>true</visible>
<object-name>CanvasPlacement</object-name>
<action>
<touch>0</touch>
<repeatable>false</repeatable>
<binding>
<command>nasal</command>
<script>print("touch input (",cmdarg().getNode("x").getValue(),",",cmdarg().getNode("y").getValue())</script>
</binding>
</action>
</animation>

== Shadow Handling ==
There exist several possibilites for handling of shadows. 
See '''[[ALS_technical_notes|ALS Technical Notes]]''' and more specific '''[[ALS_technical_notes#ALS_fuselage_shadow_effect|Fuselage Shadow Effect with ALS]]''' for a relatively simple shadow handling. 
See '''[[Project Rembrandt]]''' which - amongst other functionality - implements a very realistic shadow mapping.
As of January 2021 Project Rembrandt was replaced by the '''[[Compositor]]''' renderer which combines both Project Rembrandt and ALS in a single rendering engine. This also means that the Fuselage Shadow Effect with ALS is now deprecated.

== References ==
{{Appendix|all|
* {{cite web |url=http://www.opensubscriber.com/message/flightgear-devel@flightgear.org/958955.html |title="material" animation (and the bo105 as an example) |first=Melchior |last=Franz |date=22 March 2005 |work=FlightGear-devel mailinglist }}
* {{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01546.html |title=flash animation |first=Frederic |last=Bouvier |date=22 Feb 2006 |work=FlightGear-devel mailinglist }}
}}

== Related content ==
=== Wiki articles ===
* [[MP Fallback models]]
* [[Howto:Animate gear scissors]]
* [[Howto:Animate helicopters]]
* [[Howto:Creating 3D instruments]]

=== Forum topics ===
* {{forum link|t=37353|title=3d models, how to produce them in an understandable way}} (April 2020-) - Touches on the subject of not using LOD range animations in scenery models.
* {{forum link|t=36545|title=speedo Drum settings}} (November 2019) - Animating a mechanical multi-digit drum counter

[[Category:Aircraft enhancement|Animate models]]
[[Category:Howto|Animate models]]
[[Category:Modeling|Animate models]]
[[Category:Scenery enhancement|Animate models]]

Dassault Mirage 2000-5

2021-11-21T16:42:45Z

SammySkycrafts: Edited OPRF Site URL to correct dead link

{{Distinguish|Dassault Mirage 2000}}
{{Note|The new JSBsim version is now in master.}}
{{:{{PAGENAME}}/info}}
The '''Dassault Mirage 2000-5''' is a French multirole, single-engine fourth-generation jet fighter manufactured by Dassault Aviation. An improvement of the [[Mirage 2000]], it was improved by Thomson-CSF (now Thales Group) in the early 1990s in response to the Mirage 2000's ageing compared to the latest [[F-16]] fighter models.

Improvements over the Mirage 2000 include the capability to carry a laser designator pod, new pulse-doppler multi-target radar, new defensive systems, and updated avionics, including a night vision-compatible glass cockpit, wide-angle [[HUD]], and {{Abbr|HOTAS|Hands On Throttle And Stick}} controls.

Coming into service with the French Air Force (''Armée de l'Air''), and exported to several countries, Dassault further improved it by creating the {{Wikipedia|Dassault Mirage 2000#Mirage 2000-5 Mark 2|Mirage 2000-5 Mark 2}}, the most advanced of all Mirage 2000s.

== Keyboard Controls ==
{| class="keytable"
! Key
! Function
|-
| {{key press|d}} || Open/close canopy (3 positions : opened, closed and half-opened)
|-
| {{key press|e}} || Fire weapon
|-
| {{key press|Shift|e}} || Parachute (landing)
|-
| {{key press|Shift|j}} || Jettison tank
|-
| {{key press|Shift|t}} || Toggle ECM & RWR
|-
| {{key press|t}} || Change radar distances (10, 20 50, 100, 150)
|-
| {{key press|Shift|r}} || Activate/deactivate targeting the nearest in the HUD (the target has to be bellow radar range)
|-
| {{key press|Shift|h}} || Toggle armament circles
|-
| {{key press|<nowiki>}</nowiki>}} || On/off Engines (autostart)
|-
| {{key press|l}} || Flare out
|-
| {{key press|Shift|l}} || Landing lights
|-
| {{key press|n}} || Next target
|-
| {{key press|Ctrl|n}} || Previous target
|-
| {{key press|Ctrl|b}} || Air brake
|-
| {{key press|w}} || Cycle stick weapon mode selector
|}

== Specifications ==
[[File:Mirage 2000-5's colored afturburner.png|thumb|mirage 2000-5's colored afturburner at night]]
=== General characteristics ===
* Crew: 1
* Length: 14.36 m (47 ft 1 in)
* Wingspan: 9.13 m (29 ft)
* Height: 5.20 m (17 ft)
* Wing area: 41 m2 (441.3 ft2)

=== Weight ===
* Empty weight: 7,500 kg (16,350 lb)
* Loaded weight: 13,800 kg (30,420 lb)
* Max. takeoff weight: 17,000 kg (37,500 lb)

=== Engine ===
* Powerplant: 1 x SNECMA M53-P2 afterburning turbofan
** Dry thrust: 64.3 kN (14,500 lbf)
** Thrust with afterburner: 95.1 kN (21,400 lbf)

=== Performance ===
* Maximum speed:
** High altitude: Mach 2.2 (2,530+ km/h, 1,500+ mph)
** Low altitude: 1,110 km/h (690 mph)
* Range: 1,550 km (837 nmi, 963 mi) with drop tanks
* Ferry range: 3,335 km (1,800 nmi, 2,073 mi) with auxiliary fuel
* Service ceiling: 17,060 m (59,000 ft)
* Rate of climb: 285 m/s (56,000 ft/min)
* Wing loading: 337 kg/m2 (69 lb/ft2)
* Thrust/weight: 0.91
* Roll Rate: 270 deg/sec
* G limits: +9.0 g / -3.2 g (override mode: 11 g, structural limit: 12 g)

== Help ==
=== Weapons ===
[[File:Mirage 2000-5's weapons.png|thumb|some mirage 2000-5's air-air weapons]]
Available weapons for FlightGear's Mirage 2000-5 are as follows:

* Guns: 2 x 30 mm (1.18 in) DEFA 554 revolver cannon, 125 rounds per gun

* Missiles:
** Air-to-air missiles: {{Wikipedia|MBDA MICA}}, {{Wikipedia|R.550 Magic|Matra R.550 Magic 2}}, {{Wikipedia|Super 530|Matra Super 530}} {{clarify}}, {{Wikipedia|AIM-120 AMRAAM}}, {{Wikipedia|AIM-9 Sidewinder}}, {{Wikipedia|AIM-54 Phoenix}}, and the {{Wikipedia|R-73 (missile)#Variants|Vympel R-74}}.
** Air-to-ground missiles: {{Wikipedia|Storm Shadow}} (''SCALP'' in French service), {{Wikipedia|Sea Eagle (missile)|Sea Eagle}}, {{Wikipedia|AGM-65 Maverick}}, {{Wikipedia|GBU-16}}, and the {{Wikipedia|GBU-12}}.

==== How to fire a guided missile ====
# Select your missile on the graphical MFD, with the top button of the left series button.
# Then, select your weapon mode with {{key press|w}} (cycles through nothing, guns, missiles)
# Press {{key press|Shift|r}} to activate radar illumination.
# Acquire your target.
# Fire with {{key press|e}}.

{{Note|Due to the generic missile script, FlightGear's Mirage 2000-5 can carry missiles not carried on the aircraft in real life. For a list of weapons available to the aircraft in real life, please see {{Wikipedia|Dassault Mirage 2000#Specifications (Mirage 2000C)}}.}}
{{Caution|It is a bad idea to fire a missile while under negative G.}}

=== Refueling ===
The Mirage is capable of [[mid-air refueling]]. You can enter the desired [[TACAN]] code into the right MFD (see second video), and then use both radar and the TACAN to guide you in.

=== Radar ===
The radar has 5 ranges (10, 20, 50, 100, and 150 nm) which can be switched with {{key press|t}}. It can identify multiple targets and show some information about them.

=== HUD ===
The HUD shows both potential targets and the locked target. It also shows if the undercarriage is extended, the distance to the ground if the altitude is below 5,000 feet, and the Mach speed if the aircraft is going faster than Mach 0.8.
=== Dual seat in Multiplayer Mode ===
You can flight in the back seat as a passenger in [[Multiplayer]] mode
This is under development, the goal is to make the mirage 2000 [[Dual Control]] ready !

how to test multiplayer on same PC ?
* run flightgear with parameters :
<syntaxhighlight lang="bash">
--aircraft=m2000-5B --multiplay=out,10,127.0.0.1,5000 --multiplay=in,10,127.0.0.1,5001 --callsign="PILOT" --prop:/sim/remote/pilot-callsign="NOSA"
</syntaxhighlight>
* run another instance with parameters :
<syntaxhighlight lang="bash">
--aircraft=m2000-5B-backseat --multiplay=out,10,127.0.0.1,5001 --multiplay=in,10,127.0.0.1,5000 --callsign="NOSA" --prop:/sim/remote/pilot-callsign="PILOT"
</syntaxhighlight>
[[File:Mirage2000-5 multiplayer dual seat.png|thumb|mirage 2000-5 multiplayer dual seat]]

FYI : NOSA (Navigateur Officier Systèmes d'Armes) mean Weapons Systems Officer Navigator.

=== Sky Knights Squadron textbook ===

==== I. Weapons use ====
FOX-3:
MICA-EM: under 40 NM, choose the radar range just above your enemy's distance. Comparable to AIM-120, but better at a shorter distance. Extremely maneuverable due to thrust vectoring.

FOX-1:
Super 530D: under 25 NM, rather precise at close range too. Slightly better than the AIM-7.

FOX-2:
MICA-IR: use under 20 NM, target must be locked with radar. Very useful in dogfights because of its superiority towards the AIM-9. Extremely maneuverable due to thrust vectoring.
Magic II: under 7 NM, target must be locked with radar. Corrects trajectory every 2/10th of second, rather precise, but inferior to AIM-9.

Guns: 125 rounds, don't waste them by shooting above 1000 meters, shoot at close range only when you have a solution. In a fight against several enemies, you can't be winchester.

WARNING against aircraft like the F-15, the Mirage has a slight disadvantage (less missiles) and it's better if you can go nearer and engage dogfight, in which the Mirage outturns many fighters.

==== II. ACM ====
The Mirage has a very good turn rate, which means you can keep on with full reheat for several minutes in a high-G turn. Against a fighter like the JA-37 or the F-15, it is recommended to enter a two-circle fight. Against better turning aircraft such as the F-16, it is recommended to choose a one-circle fight.
When merging with your opponent, it is suggested to throttle up 1 or 2 nautical miles before crossing your enemy, as the engine is a bit slow in response time. Also, the Mirage tends to lose lots of speed when turning: since it is a delta wing, it is basically a flying airbrake.
Don't waste energy by climbing high, because you lose speed and offer a still target for your enemy.
The Mirage 's turn rate is best around 250-350kts, and you should have full reheat to keep on turning.
If you stay close to the ground (where the Mirage is very manoeuverable), the other pursuing you might crash, but pay attention to your speed, if you stall, there’s no way you can regain your speed before crashing at low altitude. Although against other good aircraft at low level, such as the Viggen, it is better to push them to the stall in a one circle fight, as it is slightly under-powered and a formidable opponent at low altitude.

==== III. Checklist for a dogfight ====
Start-up:
* Check fuel
* Switch the battery on
* Turn on both alternators
* Turn on the transformator
* Switch the cut-off and secure it
* Switch the left and right (G and D) pumps to “M”
* Switch the “VENT ON”
* Open the protection of the starter
* Check that the BP button has been switched
* Press the starter during 1 second
* Press the fuel P button
* Wait about 30 seconds for the fuel pumps to reach the correct level
* Open the guard and switch the start selector to ON, the engines will spool up
* Deselect the Fuel P
The engines are now idle, you can go on to the next part of the tutorial.

Pre-flight:
* Close the canopy
* Turn on A/C and set it to 16.9 – 18°C by turning the knob (WARNING: F=froid=cold and C=chaud=hot)
* Select flight mode to TO
* Set transponder according to your mission
* Set the right MFD according to your mission (compass; radio; RWR; engine dialog; map)
* Set the navigation dialog according to your mission
* Reload flares and guns
* Toggle multiplayer shot report
* Remove automatic missile view
* Select payload

Engaging:
* Set link16 accordingly if you have wingmen
* Master arm on
* Set the right MFD to RWR
* Radar active set at the correct distance
* MICA-EM selected for BVR, guns for WVR
* FOV 100-120°, looking up a bit so that you keep eye contact with your opponent in dogfight, but keep sight of your RWR
* Turn the pilot cam view slightly up and decrease FOV so you have a wide angle
* If incoming missile, launch a few flares/chaffs and push nose down so the missile, anticipating your movements, will crash to the ground. Other missile evading techniques also valid.
* Try to engage dogfight, as the Mirage is one of the best in this category
* Try to break off the fight before the bingo. A fight is won when you are back at your base, safe on ground, and the other is down. It’s no use winning if you crash to the ground after this.

== Gallery ==
{{#ev:youtube|uAhXLSO1tt4|||{{en|Video showing the new features of the Mirage 2000-5 (Feb 2015 version)}}|frame}}
{{#ev:youtube|i9FXj03IDfs|||{{en|Video explaining how to navigate and use the [[autopilot]] & MFD}}|frame}}
{{#ev:youtube|clKk-Zb2Okw|||{{en|Little demo to explain how work the sniping pod for GBU}}|frame}}

=== Miscelleanous ===
<gallery mode="packed">
Mirage 2000-5's flight in formation lights.png|mirage 2000-5's flight in formation lights
Mirage 2000-5 flying over France.png|mirage 2000-5 over France
Mirage 2000-5's mini-hud and logo "2000-5".png|mirage 2000-5's mini-hud and logo "2000-5"
Mirage2000-5 2seats with ground equipment.png|mirage 2000-5 2 seats with ground equipment
Mirage2000-5 2seats with some stores.png|mirage 2000-5 2 seats with some stores
Mirage2000-5 2seats landing nellis.png|mirage 2000-5 2 seats landing nellis
Mirage2000-5 2seats ready to start.png|mirage 2000-5 2 seats ready to start
Mirage2000-5 2seats takeoff under rain.png|mirage 2000-5 2 seats takeoff under rain
Mirage2000-5 raindrops1.png|mirage 2000-5 raindrops1
Mirage2000-5 raindrops2.png|mirage 2000-5 raindrops2
Mirage2000-5 basse altitude with pod.png|mirage 2000-5 flying low altitude with pod "PDLCT"
</gallery>

=== Refueling ===
<gallery mode="packed">
M2000-5 Refueling.png|[[Mid-air refueling]] with an A330-MRTT
Refueling using RADAR TACAN.png|Refuelling using [[TACAN]] and radar
Mirage-2000-5weapons managment.png|Graphical weapon selection
M2000-5 EICAS.png|EICAS for engine mamagement
</gallery>

=== Liveries and logos ===
<gallery mode="packed">
Mirage 2000-5's green-blue ardennes.png|mirage 2000-5's green/blue camo (squadron "Ardennes")
Mirage 2000-5's blue-grey camo chimere.png|mirage 2000-5's blue/grey camo (squadron "Chimère d'argent")
Mirage 2000-5's desert camo lafayette.png|mirage 2000-5's desert camo (squadron "Lafayette")
Mirage2000-5 one seat grey livery.png|mirage 2000-5's grey livery (squadron "Alsace")
</gallery>

== Changelog ==

=== May 2017 version ===
==== 3D model ====
* a new two seats version (the mirage 2000B, N and D)
* new HD (high definition) liveries
* specific liveries : green digital, snow, black, etc
* a lot of corrections on littles details (antennas, refueling pole, gears doors, intakes shades, cockpit, wheels, reddish engine) for both versions (one and two seats)
* ground equipment
==== effects ====
* rain effects (sound, raindrops, effects on the fuselage)
* shakes on high gload, mach 1
* realistic blackout/redout
==== Systems ====
* new improvments on fly by wire systems (the purpose is to obtain maximum realism when flying : pitch limitations on high gload or high angle of attack, pitch and roll limitations when airbrakes are active)
* more stability with an "auto-trim system"
* new realistic radar with ground and doppler effects
* new instruments
* canvas nav-display
* partial canvas hud : radar detected targets are designed on the hud
==== Weapons and stores ====
* more realistic weapons to dogfight [http://opredflag.com/ OPRF team] : realistic damages, counter measures, missile trajectory
* new weapons or 3d improvment for : matra mica IR, mica EM, magic, exocet
* liveries on external tanks
* inert pod : PDLCT (pod de designation laser - camera thermique)

=== Feb 2015 version ===
==== 3D model ====
* Several more instrument in the cockpit, including startup instrument, and light variator instruments.
* New, more realistic gun explosion.
* New, more realistic missile explosion.
* New afterburner flames that take differents colors, depending on the sun position.
* New [[Rembrandt]] light effects in the cockpit.
* New rule about each instrument's light effects
* Possibility to hide the pilot model when in the cockpit.
* Deactivate the temporary non-Rembrandt shadow, because it had a big MP issue and did not allow a correct dogfight.
* New exhaust.
* Separated livery & logos. Logos are now independent of the livery.
==== Systems ====
* Center MFD can switch between old version and Canvas [[NavDisplay]] version.
* Working startup procedure.
* Working cockpit light variator.
* Utilisation of the <code><nowiki><usage></nowiki></code> tag.
==== Weapons ====
* You can now create a ground target, by clicking on the ground and then clicking "Create a Target" in the "Mirage 2000 > Fast Config" menu.
==== Nasal ====
* Centralised function launch and update instead of multiple separate loops/listeners.
* Loads are now visible over MP.

=== August 2013 version ===
* Much better autopilot (see video).
* Multi-page MFDs.
* Radio management on the right MFD.
* An EICAS page.
* Cockpit general graphics are improved.
* A weapons selection page on the left MFD.
* Better sound and missile script improved.
* Working alert panel.
* New clock
* And lots of other stuff not listed here...

== Todo ==
=== Models ===
* High-resolution liveries. {{done}}
* Throttle stick, gear green/red light, jettison all button. {{Done}}
* Add some "ground" feature (equipment, external power). {{done}}
* Modify exterior pylons shade. {{done}}
* Modelize stick. {{done}}
* Modelize rudder pedals {{not done}}
* Modify cockpit 3d model (single and dual seat). {{done}}
* Homogenize instruments texture and materials. {{done}}
* Smooth canopy arch. {{done}}
* Create crashed models. {{not done}}

=== MultiPlayer ===
* Make the loads visibles in MP. {{done}}
* Dual control. {{not done}}
=== Instruments ===
* Add more clickable instruments and complete tooltips. {{progressbar|90}}
* Complete the alert panel. {{progressbar|60}}
* Canvas HUD. {{progressbar|60}}
* Move flight in formation lights. {{not done}}
* Make the RWR work. {{not done}}
* Modelize the Inertial measurement unit {{not done}}

=== Systems ===
* Make the start procedure more realistic. {{Done}}
* Correct the radar issue due to the generic function radardist and multiplayer ATC. {{done}}
* Improve FDM. {{done}}
=== Weapons ===
* Put missiles in a generic folder. {{done}}
* Improve missile models. {{done}}
* Improve the missile script. {{done}}
* Put sound on the missiles. {{done}}
* Make a working ECM (missiles have to be reworked first). {{not done}}

=== Other ===
* Checklist. {{not done}}
* update help : landing, takeoff. '''On going'''

== Thanks ==
'''Helijah''' (for the 3D model), '''Buckaroo''' (for the FDM), '''5HIN0B1''' (for the working weapons and systems), '''Koubi''' (for the engine script), '''FG-TUX''' (for testing), '''Ray''' (for helping on the MFD), '''Anusil''' (for testing), '''F-Sig''', '''Xiii''' (for fox2.nas, the initial missile script), '''the F-16 team''' (for the radar and HUD), '''the Citation X team''' (for the middle MFD), all those who created missile models, '''Niko''' (for the wiki page and the original ask for the project), '''Thomas''' (for the liveries), '''Gijs''' (for the wiki page), '''Hardball''' (for the two seats 3d model, the liveries, minihud and some other stuff), '''Leto''', '''Richard''', '''Swamp''', '''FB''', '''onox''', '''Octal450''', '''legoboyvdlp''', '''Domokos Jüttner (Rudolf)''' (All '''OPRF''' team) and all those forgotten here ('''Nicolas de Lemos''')…

'''''Thanks to all.'''''

== External link ==
* {{Wikipedia|Dassault_Mirage_2000#Mirage_2000-5|Dassault Mirage 2000-5}} (Wikipedia)

{{Dassault}}
{{air-to-air refueling}}