FlightGear wiki - User contributions [en]

Modern IFR Navigation

2024-11-30T14:39:28Z

Ranguli:

{{Delete|reason=This article is incomplete and likely does not meet the quality standards of the wiki.|day=30|month=11|year=2024}}
On July 3d, David Megginson wrote to the mailing list,
{{FGCquote
|1= The airspace system is in the process of changing drastically, and I'm following it this summer by finally biting the bullet and installing an IFR GPS (Garmin GTN 650) and ADS-B transponder (Garmin GTX 345) in my Piper Warrior II. What this means that for the first time in the 15 years since I started flying in real life, I won't be able to use FlightGear to practice the IFR approaches I'm flying in real life.
|2= {{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35924395/
|title = <nowiki> [Flightgear-devel] RFD: FlightGear and the changing state of air
navigation </nowiki>
|author = <nowiki> David Megginson </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.39
}}
}}
This article is about the discussion which followed that message, which focused heavily on modern IFR navigation.

== Advanced RNAV Approaches ==
In the modern world, RNAV approaches are a lot more complex than following a magenta line and manually calculating a vertical speed or using VNAV. Modern RNAV approaches involve things such as "radius-to-fix" segments, which allow curved paths around mountains, which the aircraft can follow. One example is the RNAV (RNP) Y to 05R at Auckland: http://www.aip.net.nz/pdf/NZAA_45.3_45.4.pdf.

{{FGCquote
|1= One thing that is very important moving into the future is the RF approach (radius to fix). Please read this:
https://en.wikipedia.org/wiki/Performance-based_navigation#RNAV_and_RNP_specific_functions... This style of RNAV approach is becoming more and more common, and FlightGear cannot yet simulate it.
|2= {{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35924695/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> legoboyvdlp </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.39
}}
}}

{{FGCquote
|1= DME arc transitions still exist, and I enjoy flying them both in FlightGear and in real life. There are two important differences for the radial-to-fix transitions (as I understand so far, still studying up the new-to-me RNAV procedures):
* You can fly them around any fix, not just a DME/TACAN (typically colocated with a VOR). Granted, you could do that in FlightGear now simply by using the GPS distance, but ...
* The CDI actually gives you (and the autopilot) guidance for where you should be flying, so you're not manually estimating your course based on the DME/GPS distance while flying 90° to the navaid bearing.

It's the second one that will trip us up for using FlightGear as a way to practice modern IFR procedures.
|2= {{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35924993/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> David Megginson </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.39
}}
}}

{{FGCquote
|1= Are you wondering about the math to give you a guidance target for flying around a given point? Or are you wondering how to render the 'fly-to' indicator?
The first basically is the same as the Shuttle HAC intercept where Rdot (the derivative of the radius to the center point) in combination with R
can be used as error for guidance and the second depends on your particular instrument - the Shuttle HUD shows a corresponding indicator (and so does the PFD) - but I suspect the instrument of choice of a GA aircraft will display it differently.
So this should be possible to code by any aircraft maintainer without much fuss as far as I can see.
|2= {{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35925333/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.39
}}
}}

{{FGCquote
|1= The Route Manager should be able to handle most of the "magenta line" tasks, but it may be that the more complicated routing such as the RF approach, fly-by vs fly-over requires some new autopilot coding as you describe.
|2= {{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35925369/
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of
air navigation </nowiki>
|author = <nowiki> Stuart Buchanan </nowiki>
|date = Jul 3rd, 2017
|added = Jul 3rd, 2017
|script_version = 0.39
}}
}}

Howto:Multiplayer

2024-11-16T20:25:10Z

Ranguli:

{{Out of date}}{{Obsolete}}

The '''multiplayer''' feature of [[FlightGear]] makes it possible to see other pilots and vice-versa. This makes it possible to fly in formation, perform [[mid-air refueling]] with tankers controlled by real people or contact real [[air traffic control|air traffic controllers]] to ask for guidance.

Multiplayer may cause extreme [[troubleshooting performance issues|framerate drops]] during the loading of aircraft models, especially heavy models such as the [[Boeing 777]] or [[Airbus A320neo]]. It is suggested to fly in locations other than the default [[San Francisco International Airport]], as there are often lots of pilots in the area who are often new, and do not follow ATC, or respect traffic.

== Notes ==
* Callsigns can be a maximum of seven characters.
* You might want to check the [[#Known issues|Known issues]] section.

== Connecting to Multiplayer ==
=== Built-in launcher and in-sim dialog ===
[[File:Multiplayer settings dialog.jpg|thumb|Multiplayer settings dialog]]
The easiest way to get online is to use the [[FlightGear Qt launcher|built-in launcher]] or the in-sim Multiplayer dialog. All you need to do is enter a callsign and select a server from the menu. Press Connect to go online.

=== Using FGRun ===
==== From the main page ====
[[File:Multiplayer.jpg|thumb|Multiplayer settings in [[FGRun]]]]
# Select your [[aircraft]] and starting airport as normal in [[FGRun]].
# On the last screen, tick the "Multiplayer" box. Also make sure that the "AI models" box is checked or you will not be able to see the other pilots' aircraft.
# Enter the …
#* '''Callsign''' of your choice.
#* '''Hostname:''' Enter <code>mpserverXX.flightgear.org</code> (with <code>XX</code> being the [[#Servers|server number]]).
#* '''In/Out:''' Set both ports to 5000.
# Click {{button|Run}} to start FlightGear.

To confirm that it's working, you can go to the multiplayer map at http://mpmap02.flightgear.org/ (in Hong Kong). Once FlightGear has started, you will notice chat messages that say "Hello" indicating pilots that are online. They will also pop up when a pilot joins the MP network. You can change this message by add command line option, e.g.:

--prop:string:/sim/multiplay/chat="Greetings pilots"

You may wish to use a different server, especially one closer to you.

==== From Network Settings ====
[[File:FGRun Advanced dialog - Network.png|thumb|The <tt>Network</tt> tab of the Advanced Options dialog in [[FGRun]] (in [[Changelog 3.2|FlightGear 3.2.0]]).]]
You can also change multiplayer settings in the <tt>Network</tt> tab of FGRun's Advanced Options.

# On the last page, click {{button|Advanced}}.
# Click <tt>Network</tt> in the left column.
# In the <tt>Multiplayer Options</tt> area …
#* Type your desired callsign into the box.
#* Set the parameters for the two other boxes; see [[#Using multiplayer from the command line|below]] for correct syntax.
#* Click {{button|OK}}, then run FlightGear.

=== Using multiplayer from the command line ===
When running FlightGear from the [[command line]], you can specify multiplayer settings. The two arguments are as follows:
<syntaxhighlight lang="bash">
--multiplay=direction,10,ip.address,port
--callsign=anything
</syntaxhighlight>

Obviously, <code>--callsign</code> can be anything you wish but it must be limited to 7 (seven) characters in length counting any dashes. If your callsign is too long, it will be cut off in the various displays where it is shown. Generally speaking, callsigns are of the form X-XXXXX. Check [https://fgtracker.ml/ this page] to see whether your callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems! Please don't leave your callsign as "CALLSIG".

There are four arguments to <code>--multiplay</code>:
; direction
: Either <code>in</code> or <code>out</code>. <code>in</code> tells FlightGear to listen to packets of data coming in through the specified '''port'''. <code>out</code> tells FlightGear to send data out through the '''port'''.

; ip.address
: IP address of network interface being used by FlightGear. If left blank, FlightGear will listen to all network interfaces. If '''direction''' is set to <code>in</code>, FlightGear will listen to ''only'' this IP address.

; port
: Port that data is either being sent or received through. Usually set to <code>5000</code> and above.

== Advanced usage of multiplayer ==
=== Local setup for testing ===
It is possible to set up a local multiplayer network between two FlightGear instances ''without'' using a [[FGMS|multiplayer server]]. All you need to do is map each I/O port of one instance to the corresponding port(s) of the other instance:

{{Note|
{{FGCquote
|A socket connection requires not only an IP address, but also a port number for each side of the link - imagine a port number like a "mailbox" sitting at the address. This mailbox is used by the communicating processes to send out and receive "messages". Different processes (even when possibly identical programs) will need to use different port numbers when running. Because open ports ({{=}}mailboxes) cannot be shared.
Thus, you need to modify the client-side port settings for each additional instance that you are running on the same machine, and map the output port of one instance to the input port of the other instance (and vice versa).
|{{cite web |url={{forum url|p=83068}}
|title=<nowiki>Re: 2 FGFS instances / 1 win7 running same time with MP?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Jun 10</nowiki>
}}
}}
}}

Command line parameters for the first instance:
<syntaxhighlight lang="bash">
--multiplay=out,10,127.0.0.1,5000 --multiplay=in,10,127.0.0.1,5001 --callsign=Test1
</syntaxhighlight>

Command line parameters for the second instance:
<syntaxhighlight lang="bash">
--multiplay=out,10,127.0.0.1,5001 --multiplay=in,10,127.0.0.1,5000 --callsign=Test2
</syntaxhighlight>

You can use this kind of setup to test multiplayer related features or troubleshoot multiplayer related bug reports that may be otherwise hard to reproduce over MP. As you can't access the configuration of other people's FlightGear, this technique allows you to have complete control over FlightGear's settings.

[[File:Direct-p2p-multiplayer-setup.png|800px|Screenshot demonstrating a "peer-to-peer" setup between two FlightGear instances running on the same machine via localhost (127.0.0.1) without any multiplayer server.]]

You can add an arbitrary number of channels to mirror your flight onto other servers, e.g. to a private fgms (FlightGear Multiplayer Server) using
<syntaxhighlight lang="bash">
--multiplay=out,10,my.private.server.ip,5000
</syntaxhighlight>

Additionally, the <code>in</code> argument above tells FG to listen '''only''' on the loopback/local interface - it will not receive packets arriving on the other network interface(s). If you want to also bind to other interfaces, just omit the IP address by using
<syntaxhighlight lang="bash">
--multiplay=in,10,,5000
</syntaxhighlight>

Check [https://fgtracker.ml/ this page] to see whether your callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems!

==== Now, going more slowly for those who are completely lost... ====
{{Note|This section may contain out of date or inaccurate information.}}
This section ''ought'' to be unnecessary now with recent versions of the FG server. If you have problems though, it won't hurt to follow through.

First of all, you need to know the IP address of the network interface you'll be using for multiplayer FG.

If your Internet connection is via an ADSL modem that plugs directly into your computer, you should be able to find your IP address by visiting http://www.whatismyip.com.
{{Note|Your {{Abbr|ISP|Internet Service Provider}} might not give you the same IP address each time.}}

If your connection is via an Ethernet connector or by a wireless link.

* '''Linux:''' Log in as root and run <code>ifconfig</code> in the terminal. In the text that is returned, you should to look for an interface name such as <code>eth0</code> or <code>wlan0</code>. Finally, look in the text below the interface name for <code>inet addr:ip.address</code>. For example, this should read something like <code>inet addr:192.168.0.150</code>.
* '''Windows:'''
** '''Windows XP or later:''' Start Command Prompt and <code>ipconfig</code> into the terminal. Write the IP address down.
** '''Windows 98''', click start, run, and type "winipcfg" to get information about your IP address.

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

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

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

Finally, start FG using the command line given right at the start (if you're using the Windows launcher you will find entry boxes for Multiplayer arguments – insert the relevant details there). You will end up with something like this:
<syntaxhighlight lang="bash">
<other arguments> --callsign=test --multiplay=in,10,192.168.0.2,5000 --multiplay=out,10,mpserver05.flightgear.org,5000 --airport=KSFO --runway=28R --aircraft=hunter
</syntaxhighlight>

Choose your own callsign, but check [https://fgtracker.ml/ this page] first to see whether your desired callsign is already in use or not. Do not pick a callsign that is already used, as that will create problems!

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

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

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

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

If it's still just not working for you, ask nicely on the [[FlightGear IRC channel|IRC channel]] or the {{forum link|text=forum}} and someone should be able to assist.

=== Multiple connections per computer ===
It is possible to run multiple FlightGear instances on a single computer and connect them all to the multiplayer network. However, this requires some extras to keep in mind:
# Both instances use the same <code>out</code> port.
# One instance uses <code>in</code> port <code>5001</code>, the other port <code>5002</code>.
# Both instances have unique callsigns.

=== Optional collision detection in multiplayer ===

A patch has been added to FlightGear (since Version 3.5) to allow optional collision detection in multiplayer. To enable collision detection, start FlightGear with:

<syntaxhighlight>
--prop:bool:/sim/multiplay/hot=true
</syntaxhighlight>

Those who are able to patch FGData themselves, can download [http://sourceforge.net/p/flightgear/mailman/attachment/CAHs0wcrEwYZvXTddcUaH0ZMfmVNvEWRap8MXOrEoKybUDO58sQ%40mail.gmail.com/3/ mp-hot-fgdata.patch], which adds a checkbox to the Multiplayer Settings dialog to enable or disable the collision detection at runtime.

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

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

The shortcut for chatting is {{Key press|<nowiki>-</nowiki>}} (hyphen). This will bring up some text in the upper-left of the FlightGear window. By pressing the corresponding number keys, you can send pre-made messages. Pressing {{Key press|1}} will let you type in a custom message, which you can send by pressing enter. By default, other people's messages are displayed at the top of FlightGear's window for a few seconds, but it will appear for a much longer time in the window at <tt>Network > Chat</tt>. So if you think you have missed anything, go check there.

== Dealing with abusive behavior ==
Should you become victim of abusive or annoying behavior by any pilot, you have option to ignore him or her. To activate the ignore function open the <tt>Multiplayer > Pilot list</tt> dialog and click the <tt>ignore</tt> button next to the pilot's callsign. This will prevent chat messages from the ignored pilot appearing and prevent his aircraft from appearing.

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

There is a very nice online map which displays the location of online pilots at [http://mpmap02.flightgear.org mpmap02]. You will also find this useful to check that you are successfully connecting to the server, as well as looking up navaids, waypoints, airports, frequencies, weather, and more!

== Servers ==
The multiplayer servers are interconnected. With few exceptions you ''do not'' need to connect to a specific server in order to see other pilots who are on that server. For best performance, you should connect to the server that is either geographically closest to you, has the lowest latency (ping time), or is the least busy.
{{tip|Use [http://mpmap01.flightgear.org/mpstatus/ this link] to check if the MP servers are online. Page is automatically generated. The [[#In-sim Dialog|in-sim dialog]] will only display servers that are available.}}

{| class="wikitable sortable"
! Server address
! Status
! Location
! Tracked (by [http://fgtracker.ml fgtracker.ml] unless otherwise specified)
! Maintainer
! Maintainer's [[IRC]] name
! Maintainer's {{forum link|text=forum}} name
! Comments
|-
| mpserver01.flightgear.org
| {{yes|Up}}
| Germany
| {{yes}}
| Oliver Schröder
| os
| {{N/a}}
| {{N/a|None}}
|-
| mpserver02.flightgear.org
| {{yes|Up}}
| Los Angeles, USA
| {{N/a}}
| Lloyd Stevens
| ls4680
| ls4680
| {{N/a|None}}
|-
| mpserver03.flightgear.org
| {{yes|Up}}
| Germany
| {{yes}}
| Hergen
| {{N/a}}
| {{N/a}}
| [https://mpserver03.flightgear.org mpserver03.flightgear.org]
|-
| mpserver04.flightgear.org
| {{yes|Up}}
| UK
| {{no}}
| Jon Stockill
| Nav
| {{forum link|type=member|u=738|text=JonS}}
| {{N/a|None}}
|-
| mpserver05.flightgear.org
| {{no|Down}}
| Chicago, USA
| {{N/a}}
| Brant
| IonCannon218
| {{N/a}}
| {{N/a|None}}
|-
| mpserver06.flightgear.org
| {{no|Down}}
| Berlin, Germany
| {{N/a}}
| Sven Teichmann
| {{N/a}}
| {{forum link|type=member|u=11839|text=D-SAMI}}
| Unlimited traffic
|-
| mpserver07.flightgear.org
| {{no|Down}}
| Wisconsin, USA
| {{N/a}}
| Tom Betka
| TB
| {{N/a}}
| Offline
|-
| mpserver08.flightgear.org
| {{no|Down}}
| Frankfurt am Main, Germany
| {{N/a}}
| Roland
| Quix0r
| {{forum link|type=member|u=7512|text=Quix0r}}
| 10 TByte traffic, mostly short pings
|-
| mpserver09.flightgear.org
| {{no|Down}}
| Köln, Germany
| {{N/a}}
| Daniel Vigano
| Fauchi95
| {{N/a}}
| Offline
|-
| mpserver10.flightgear.org
| {{no|Down}}
| Montpellier, France
| {{N/a}}
| {{usr|Xiii|Alexis Bory}}
| xiii
| {{forum link|type=member|u=884|text=xiii}}
| {{N/a|None}}
|-
| mpserver11.flightgear.org
| {{no|Down}}
| Vilnius, Lithuania
| {{N/a}}
| Darius
| {{N/a}}
| {{forum link|type=member|u=1122|text=ffg}}
| {{N/a|None}}
|-
| mpserver12.org
| {{no}}
| Amsterdam, the Netherlands
| {{no}} ([http://mpserver12.org mpserver12.org])
| Rob
| evilslut
| {{N/a}}
| Formerly mpserver12.flightgear.org<ref>{{forum url|p=258435}}</ref>
|-
| mpserver13.flightgear.org
| {{yes|Up}}
| Beauvais, France
| {{N/a}}
| Charles Ingels
| charles
| {{forum link|type=member|u=1592|text=cbz-026}}
| {{N/a|None}}
|-
| mpserver14.flightgear.org
| {{yes|Up}}
| UK
| {{no}}
| Pete
| {{N/a}}
| {{N/a}}
| {{N/a|None}}
|-
| mpserver15.flightgear.org
| {{yes|Up}}
| North Point, Hong Kong
| {{yes}}
| Hazuki Amamiya
| Hazuki
| {{forum link|type=member|u=8400|text=Hazuki}}
| {{N/a|None}}
|-
| mpserver16.flightgear.org
| {{no|Down}}
| Kansas City, Missouri, USA
| {{N/a}}
| Rob Rozestraten
| truthsolo
| {{forum link|type=member|u=9926|text=truthsolo}}
| Offline
|-
| mpserver17.flightgear.org
| {{no|Down}}
| Cluj, Romania
| {{N/a}}
| Marius
| tuxum
| {{forum link|type=member|u=11636|text=tuxum}}
| Offline
|-
| mpserver18.flightgear.org
| {{no|Down}}
| Germany
| {{N/a}}
| {{N/a}}
| {{N/a}}
| {{N/a}}
| {{N/a}}
|-
| mpserver19.flightgear.org
| {{yes|Up}}
| London, UK
| {{yes}}
| Marisa Giancarla
| marisag
| {{forum link|type=member|u=21604|text=marisag}}
| flightgearuk.gameplayer.club
|-
| mpserver20.flightgear.org
| {{yes|Up}}
| South San Francisco, California, USA
| {{yes}}
| Marisa Giancarla
| marisag
| {{forum link|type=member|u=21604|text=marisag}}
| {{N/a|None}}
|-
| mpserver21.flightgear.org
| {{yes|Up}}
| Tokyo, Japan
| {{yes}}
| Marisa Giancarla
| marisag
| {{forum link|type=member|u=21604|text=marisag}}
| {{N/a|None}}
|-
| mpserver22.flightgear.org
| {{yes|Up}}
| Munich, Germany
| {{no}}
| Fabian Gilgen
| ivelischt
| ivelischt
| {{N/a|None}}
|-
| mpserver25.flightgear.org
| {{yes|Up}}
| Mumbai, India
| {{yes}}
| Marisa Giancarla
| marisag
| {{forum link|type=member|u=21604|text=marisag}}
| flightgearin.gameplayer.club
|-
| mpserver26.flightgear.org
| {{yes|Up}}
| Frankfurt, Germany
| {{yes}}
| Marisa Giancarla
| marisag
| {{forum link|type=member|u=21604|text=marisag}}
| flightgearde.gameplayer.club
|-
| mpserver51.flightgear.org
| {{yes|Up}}
| Atlanta, Georgia, USA
| {{yes}}
| Marisa Giancarla
| marisag
| {{forum link|type=member|u=21604|text=marisag}}
| flightgearat.gameplayer.club
|-
| mpserver87.flightgear.org
| {{yes|Up}}
| London, England
| {{yes}}
| Megaf
| Megaf
| {{forum link|type=member|u=21017|text=Megaf}}
| 2000 nmi Range and Radar Range.
|-
| mpcn01.fgprc.org
| {{yes|Up}}
| Shanghai, China
| {{no}}
| Weihao Lee
| {{N/a}}
| {{N/a}}
| 100 nm Range and 2000nm Radar Range.
|-
| mpcn02.fgprc.org
| {{yes|Up}}
| NewYork, US
| {{no}}
| Sidi Liang
| {{N/a}}
| {{forum link|type=member|u=19791|text=sidi762}}
| 200 nm Range and 2000nm Radar Range.
|}

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

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

== Known issues ==
=== Fibertel (Argentina) ===
In December 2014, it was reported that UDP connection through port 5000 was not possible for users whose ISP was {{Wikipedia|Fibertel}} (Argentina).

Fibertel Argentina apparently uses the port for setup purposes. "It should be open for the user but it might not be fully functional."

Port 5000 is a generic port, and neither FlightGear nor the {{Wikipedia|UPnP}} protocol are an "official" usage of the port.

A solution would be to spread the ports between the servers; e.g., mpserver01.flightgear.org → 5001, mpserver02.flightgear.org → 5002

See also the {{forum link|t=24754|text=forum thread}} and {{issue|1617}}.

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

{{Appendix}}

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

[[de:Howto: Multiplayer]]
[[es:Howto: Multijugador]]
[[fr:Howto: Multijoueur]]
[[it:Come fare:Multiplayer]]
[[nl:Howto: Multiplayer]]
[[pl:Konfiguracja trybu multiplayer]]
[[pt:Tutorial de Multiplayer]]

Howto:Clipboard access using Nasal

2024-11-16T20:24:13Z

Ranguli:

{{Delete|reason=This article either contains out of date information, and/or may not meet the quality standards of the wiki, potentially to the point of causing confusion or frustration to readers.|day=16|month=11|year=2024}}{{Stub}}

As of 08/2012 (i.e. in upcoming FlightGear 3.0), there's a "clipboard" hash in Nasal space which can be used to access the clipboard. There are two types of clipboards supported:

* CLIPBOARD: Standard clipboard like on almost everything operating system
* SELECTION: Primary X Selection like found on X11 based systems. On non-X11 platform this clipboard is only accessible from inside FlightGear.

<syntaxhighlight lang="php">
# Setting/getting the contents of the given type of clipboard. If
# no type is specified it defaults to the standard clipboard.
# The return value indicates whether the operation completed
# successfully.
clipboard.setText: func(text, type = clipboard.CLIPBOARD) : bool
clipboard.getText: func(type = clipboard.CLIPBOARD) : bool
</syntaxhighlight>

Some examples of using the clipboard:

<syntaxhighlight lang="php">
print("Clipboard contains: ", clipboard.getText() );
print("Selection contains: ", clipboard.getText(clipboard.SELECTION) );

if( !clipboard.setText("test") )
print("Failed to write to clipboard");
if( !clipboard.setText("test-selection", clipboard.SELECTION) )
print("Failed to write to selection");
</syntaxhighlight>

[[Category:Howto]]
[[Category:Nasal]]

Code cleanup

2024-11-16T20:22:08Z

Ranguli:

{{Delete|reason=This article either contains out of date information, and/or may not meet the quality standards of the wiki, potentially to the point of causing confusion or frustration to readers.|day=16|month=11|year=2024}}{{Out of date}}
The purpose of this page is to provide a todo-list or check-list for anyone that wants to help '''clean up the [[Flightgear]] code'''. In addition to this list, you also want to try running FlightGear in [http://freshmeat.net/projects/valgrind/ Valgrind], a very powerful memory debugger and profiler.

A list of articles related to code cleanup can be found in [[:Category:Code Cleanup]].

''Feel free to add additional items to this page!''

== Keyboard reorganisation ==
The input settings (especially the keyboard) need some TLC. Here are the major tasks (we need to work on the first one first):

* [[Keyboard function priority list]] — come up with a priority list of functions that need global keyboard assignments for ''all'' aircraft, without worrying about the specific keys.
* Local key block — decide on a block of keys to set aside for per-aircraft assignment.
* Global key bindings — decide what keys to assign to the functions from the opening list (not using the local key block).
* Refactor models — refactor all of the aircraft models so that they assign keys only from the local, per-aircraft key block.
* Add a GUI — add a GUI allowing users to reassign keys while the sim is running and save their changes.

== Major Task List ==
* Move code out of fgMainLoop() and into separate functions or source files.
* Replace system() calls in simgear/io/sg_binobj.cxx to `mkdir`
* Replace system() call in simgear/io/sg_binobj.cxx to `gzip`
* Allow aircraft to be reliably changed at runtime, without requiring a restart of FlightGear
* Implement scenery support for dynamic LOD configuration at runtime
* Optimize the 3D panel code and optionally support display list usage
* Add OpenGL bindings to the scripting language Nasal to support scripted creation of instruments like the HUD
* Encourage liberal use of SGSharedPointer whereever raw pointers are currently used
* Split up unnecessarily large files into several separate compilation units, which should eventually also speed up compilation

== Persistent Checklist ==
=== Carelessness ===
* Properly allocate and deallocate memory using malloc/new/new[] and free/delete/delete[]. Valgrind is helpful when looking for these.
* Close any open file streams when you're through with them. Take care to not write to or close streams that aren't open. Avoid this by initializing file pointers/handles with 0 before use and verify that it is not 0 before accessing/closing.

=== Compatibility ===
* Use the SG_LOG() facilities instead of cout and printf().
* Use the SG_USING_STD() facilities instead of explicitly using std::function.
* Use the STL_* variables defined in simgear/compiler.h when including STL headers.
* When including header files, only use double-quotes when the header is in the same directory.

=== Security ===
* Use C-string functions with fixed write buffers whenever possible to avoid buffer overflows.
* Perform range/bounds checks on all data received from remote that could cause problems, especially those that specify an amount of data to be handled.

For example, use snprintf() instead of sprintf() and strncpy() instead of strcpy().

And please do not forget that snprintf and strncpy does not necessarily add a trailing 0 byte.

[[Category:Code Cleanup| ]]
[[Category:Development]]

Cessna 172 cockpit elements

2024-11-16T20:20:28Z

Ranguli:

{{Delete|reason=This article either contains out of date information, and/or may not meet the quality standards of the wiki, potentially to the point of causing confusion or frustration to readers.|day=16|month=11|year=2024}}

Examples from the [[c172p|Cessna 172P]]
{| class="wikitable"
|-
|
''' Summary '''
Total: 316 Cockpit elements

{| class="wikitable"
|-
|Switches || 142
|-
| Rheostats with On/Off Switches || 7
|-
| Magnetic Encoders || 16
|-
| Incremental Encoders || 12
|-
| Indicator Movements || 32
|-
| Lighted Indicators || 38
|-
| Numbers || 57
|-
| Letters || 12
|}
''' Switches '''
Total: 142

{| class="wikitable"
|-
! Found in !! !! Description !!
|-
| rowspan="11" |Lower Panel Switches || rowspan="11" | 39

|-
| Six Rocker Switches for Lights and Pitot Heat || 6
|-
| Five Circuit Breakers for Radios || 5
|-
| Nine Circuit Breakers for instruments || 9
|-
| One Circuit Breaker for Air Conditioning || 1
|-
| One pull switch/Circuit Breaker for Alternators || 2
|-
| Two Rocker Switches for Alternator and Battery || 2
|-
| One Rotary 5 position Off, Magneto 1, 2, Both and Start Switch || 5
|-
| One 4 Position Lever Switch for Flaps || 4
|-
| One Toggle Switch for Avionics Power || 1
|-
| Fuel Selector || 4
|-
| rowspan="7" |Radio Stack || rowspan="7" | 100
|-
|-
| KMA20 Audio Control Panel & Marker Indicator Lights Three Position Rotary Switch – Com1, Com2, Extended (3) Eight Speaker/Off/Phones Switches (16) One Marker High, Lo, Test Switch (2)
| 21
|-
| rowspan="1" |Two KX165 Radios 
Push Button Switches for Frequency Swap (4) 
Power Switches (2) 
Pull Test Switches (4) 
Pull 25K Switches (2) 
Pull RAD Switches (2) 
| 14
|-
|DME
Three position switch (3) 
DME ON/Off (1) 
Push Button Selector Switch (1) 
|5

|-
| rowspan="1" |KR87 ADF 
Five Function Push Buttons (5) 
Power Switch (1)
| 6
|-
| rowspan="1" |KAP140 Autopilot 
Pushbutton Function Switches (10)
|10
|-
| rowspan="1" |KT76 Transponder 
Five Position switch (5) 
Eight Position Rotary Switches: 
- 1000s (8) 
- 100s (8) 
- 10s (8) 
- 1s (8) 
|37
|-
| rowspan="2" |Instruments||rowspan="2"| 3
| Attitude Indicator - Pull to Cage || 1
|-
| Gyrocompass - Push on adjustment Knobs || 2

|-
|}
|
''' Rheostats with On/Off Switches '''
Total: 7
{| class="wikitable"
|-
! Found in !! !! Description !!
|-
| Rowspan=2 | Radios || Rowspan=2| 5
| KX165 Radios Volume || 4
|-
| KR87 ADF Volume || 1
|-
| Rowspan=1 | Lower Panel || Rowspan=1| 2
| Panel and Radio Lighting || 2
|}

''' Magnetic Encoders '''
Total: 16
{| class="wikitable"
|-
! Found in !! !! Description !!
|-
| Rowspan=3 | Instruments || Rowspan=3 | 5
| Gyrocompass || 2
|-
| VOR indicators 1 & 2 || 2
|-
| KI225 ADF || 1
|-
| Rowspan=6 | Controls || Rowspan=6 | 13
| Primer, Throttle, Mixture & Carb Heat|| 4
|-
| Cabin Air & Cabin Heat || 2
|-
|Pedals - Rudder & Toe Brakes || 3
|-
|Yoke - Airelons & Elevator || 2
|-
|Trim Wheel || 1
|-
|Horizontal Trim || 1
|}
''' Incremental Encoders '''
Total: 12
{| class="wikitable"
|-
! Found in !! !! Description !!
|-
| Rowspan=5 | Radios || Rowspan=5 | 12
|-
| KX165 Radios Frequency Adjust || 8
|-
| KR87 ADF Frequency Adjust || 2
|-
| KAP140 Altitude/Baro Adjust|| 2
|}

''' Indicator Movements '''
Total: 32

{| class="wikitable"
|-
! Type !! !! Description !!
|-
| rowspan="7" |90 degree Meter Movements || rowspan="7" | 12
| Left and Right Fuel || 2
|-
| Oil Temp and Pressure || 2
|-
| Amps and Volts || 2
|-
| VOR 1 & VOR 2 || 4
|-
| EGT || 1
|-
| Atitude Indicator Pitch || 1
|-
| Turn Coordinator Indicator Ball || 1

|-
| rowspan="2" | 0 to 359 degree Center Pivot Needle Movement|| rowspan="2" | 5
| Airspeed Indicator Needle || 1
|-
| Tachometer Needle || 1

|-
| rowspan="1" | 0 to 189 & 0 to -189 degree Center Pivot Needle Movement|| rowspan="1" | 1
|Vertical Speed Needle || 1

|-
| rowspan="3" | 0 to 359 degree Dial Movement|| rowspan="3" | 3
| Altimiter Barometric Pressure || 1
|-
| Altimiter Ground Proximity Indicator || 1
|-
| Turn Coordinator Bank Indicator || 1

|-
| rowspan="3" | Continuous Center Pivot Needle Movement|| rowspan="3" | 6
| Altimiter (100's) (1000's) || 2
|-
| ADF Needle || 1
|-
| Clock Hands || 3

|-
| rowspan="4" | Continuous Outer Ring Compass or Indicator Movement|| rowspan="4" | 5
| Gyrocompass Compass Rose and Heading Bug ||2
|-
| VOR 1 & VOR 2 Compass Rose || 1
|-
| ADF Compass Rose || 1
|-
| Attitude Indicator Bank || 1
|}

|}
{| class="wikitable"
|-
|
''' Lighted Indicators '''
Total: 38

{| class="wikitable"
|-
! Found in !! Description !!
|-
| KMA20 || O,M, I Marker Indicators || 3

|-
| VOR 1 & VOR 2 || From, To, GS, NAV, OBS & OFF Indicators || 12

|-
| KR87 ADF || ANT ADF BFO FLT ET Indicators || 5

|-
| KAP140 Autopilot || To, From, AP, YD, ARM(1), ARM(2) ,PT, Up, Down, ALERT, HPA, FPM, IN, FT, HG, comma, Roll Axis || 17
|}
|
'''Letters & Numbers'''
Total: 57 Numbers, 12 Letters

{| class="wikitable"
|-
! Found in !! Description !!
|-
| KX165 Comm/Nav Radio || Digits with decimal point || 40
|-
| KR87 ADF || Digits || 6
|-
| DME|| Digits || 6
|-
| KAP140 Autopilot || Digits with comma || 5
|-
| KAP140 Autopilot || Letters || 12
|}
|}

[[Category:Aircraft documentation]]

FG Add-on FAQ

2024-11-16T20:19:57Z

Ranguli:

{{Delete|reason=This article either contains out of date information, and/or may not meet the quality standards of the wiki, potentially to the point of causing confusion or frustration to readers.|day=16|month=11|year=2024}}

This document attempts to answer some Frequently Asked Questions from aircraft/scenery [[Addon|add-on]] developers coming from other simulators. Click [[Frequently asked questions|here]] for general FlightGear FAQ!

It does not cover technical details, but rather describes the overall ethos of the project. As FlightGear is quite a different environment from that which most add-on developers are used to, this is quite important.

Hopefully, this document will help to avoid possible misunderstandings and mis-communications and help add-on developers to develop exciting new features for FlightGear.

== Why FlightGear? ==

So, why would you want to develop add-ons for FlightGear?

The main reasons are stability and innovation. FlightGear is developed by volunteers rather than a company, and due to being released under the GPL, isn't going to disappear. Issues such as those that hit Microsoft Flight Simulator in January 2009 are simply not possible.

FlightGear is also the most innovative desktop simulation available, again due to being released under the GPL. Recent developments include glider-towing and wild-fire simulation. Anything is possible! In recent months a developer has made an incredibly detailed model of the [[SpaceShuttle - Project Overview|Space Shuttle]], and the [[777]] and [[c172p|Cessna C172P SkyHawk]] have seen recent development..

== How is FlightGear developed? ==

FlightGear is developed by volunteers all over the world. The core development team (those writing the core code of the simulator) had 20-40 active contributors at one time. There are many more people developing new aircraft and scenery as well.

FlightGear is not a commercial product owned by a company. Instead it may be described as the collective responsibility of a wide group of people.

Development is coordinated on the flightgear-devel@lists.sourceforge.net mailing list, as well as to a limited extent, on the Official Forums [http://www.forums.flightgear.org here].

Releases are currently bi-yearly, based around the number 17. On January 17 and June 17 the repositories on SourceForge close to new features for a month of bug -fixing. On or around February 17th or 18th and ditto for July, the next version is officially released, and the cycle starts all over again!
== What's the GPL? ==

The GNU General Public License (GPL) is an open-source license that gives the user a wide variety of freedoms [http://www.gnu.org/licenses/old-licenses/gpl-2.0.html]. FlightGear and the core data used by it are released under the GPL v2.

Note that this is quite different from "freeware" as understood by many other simulation communities. Particular difference of note are:
* The source code of the simulator must be made available in a machine-readable form.
* The author cannot prohibit modification and subsequent distribution
* The end product may be used for commercial purposes.

You may be able to release your add-ons under the GPL, and the FlightGear community would encourage you to do so for a variety of reasons:
* It maximizes the freedoms that the community has to enhance and maintain your add-on. This can be particularly important as the pace of FlightGear development is very high, and you may no-longer want to support the add-on yourself.
* It can be maintained within the FlightGear source-code repository (Git), and included in subsequent FlightGear releases.
* It can easily be combined with other FlightGear GPL'd components, and made greater than the sum of its parts.
* Most core developers prefer to work on GPL's software, as they see it as being more beneficial to the community. They may work on GPL add-ons in preference to non-GPL add-ons.
* Having all add-ons released under the same license simplifies life.
* It's a nice thing to do, as it gives something back to FlightGear.

== I don't want to use the GPL - can I use another license? ==

Absolutely!

However:
* You need to be absolutely clear on what the GPL does, and does not allow you to do. To take an example of developing a new aircraft: you can reference a gauge elsewhere within the FG data repository, but you cannot copy it and modify it for your aircraft without releasing it under the GPL.
* You will need to make your own arrangements for hosting, code revisions etc.
* It will not be possible to including your add-on within the FlightGear release itself.

[[Category:FlightGear addons]]

Blender and BTG

2024-11-16T20:17:39Z

Ranguli:

{{Delete|reason=This article either contains out of date information, or may not meet the quality standards of the wiki, potentially to the point of causing confusion or frustration to readers.|day=16|month=11|year=2024}}{{Stub}}
{{Infobox Software
|title = Blender and BTG
|logo =
|image =
|developedby = Lauri Peltonen
|initialrelease =
|latestrelease = Export: 31 Jan 2009 Import: 07 Mar 2011
|writtenin = Python
|os =
|platform =
|developmentstatus =
|type =
|license =
|website =
}}
With the use of a special import&export script, '''[[BTG file format|BTG files]] can be opened in, and exported from [[Blender]]'''. This makes it possible to edit [[FlightGear]]'s terrain and specifically [[airport]]s in a visual editor.

== User documentation ==
=== Installation ===
Download the two scripts:
* [http://sourceforge.net/p/flightgear/fgscenery/tools/ci/master/tree/Blender/import_btg_v7.py?format=raw Import script]
* [http://sourceforge.net/p/flightgear/fgscenery/tools/ci/master/tree/Blender/export_btg.py?format=raw Export script]

Place both files in your Blender's <tt>.blender/scripts/</tt> directory. Common locations are:
* Windows: <tt>C:/Program Files/Blender Foundation/Blender/.blender/scripts</tt>

Make sure to correct the [[$FG_ROOT]] setting in the import file, if needed. Default setting is:
FG_ROOT = "/usr/local/share/flightgear/"

Scripts should work with '''Blender 2.4x''' (latest available is Blender 2.49b), they will not work with version Blender 2.6x.

=== Usage ===
==== Import ====
Import via <tt>File > Import > Simgear (.btg) v7</tt>.

'''Note:''' rename the <tt>[ICAO].btg.gz</tt> file of an airport, to its corresponding <tt>[tileid].btg.gz</tt>, in order to import it correctly. For importing [[KSFO]], we need to rename <tt>KSFO.btg.gz</tt> to <tt>942050.btg.gz</tt>, for example.

==== Export ====
Export to a file with a .btg.gz extension, via <tt>File > Export > Simgear (.btg)</tt>. Make sure to enter the correct coordinates and radius, as displayed in the console (you can copy&paste from that one) and/or screen on import.

== Known issues ==
* Textures are not applied automatically in Blender, altough they are loaded.
* Imported meshes are shrinked because Blender does/did not support huge enough models (they are loaded correctly, but you cannot zoom out enough to see the whole tile).
* Sometimes exported triangle has its texture coordinates in wrong order which leads to weird looking textures (e.g. on a runway).
* After exporting .btg files, polygon are not smooth anymore. This will result in weird looking mountains.

[[Category:Modeling]]
[[Category:Scenery enhancement]]

Programming resources

2024-11-16T20:17:21Z

Ranguli:

{{Delete|reason=This article either contains out of date information, or may not meet the quality standards of the wiki, potentially to the point of causing confusion or frustration to readers.|day=16|month=11|year=2024}}{{Out of date}}

Please note that as of 04/2009, the "aviation standards & information" section has been moved to a new page [[Aviation Standards & Information]].
This also applies to the "Free GIS data" section which can now be found at [[Scenery Development Resources]].

As of 09/2009, there's also a new section titled [[Ground Traffic Simulation Resources]] specifically dedicated to collecting resources related to improving FlightGear's support for modeling ground traffic. As of 03/2010 the section on Shaders has been moved to a dedicated page titled [[GLSL Shader Programming Resources]]

= Programming & Open Source =
* [https://www.youtube.com/playlist?list=PLhMnuBfGeCDNgVzLPxF9o5UNKG1b-LFY9 The Structure and Interpretation of Computer Programs (UC Berkeley CS 61A)]
* [https://www.youtube.com/playlist?list=PLgNUCz66KaWRSVzIeT_qB2yBgHocLmRWI Data Structures (UC Berkeley CS 61B)]
* [http://nongnu.askapache.com/pgubook/ProgrammingGroundUp-1-0-booksize.pdf Programming from the ground up] (PDF)
* [http://producingoss.com/ Producing OSS]
* [https://skillcombo.com/courses/development/programming-languages/ Programming online courses]

= Source Code Management =
* [http://www.ericsink.com/scm/source_control.html Intro to Source Control]
* [http://www-cs-students.stanford.edu/~blynn/gitmagic/ Git Magic - Introduction]
* http://git-scm.com/book
* http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

= Software Engineering =
* [https://www.youtube.com/playlist?list=PL_pbwdIyffslgxMVyXhnHiSn_EWTvx1G- Software Engineering Playlist]
* [http://www.gotw.ca/publications/index.htm Guru of the Week]
* [http://www.gotw.ca/publications/concurrency-ddj.htm The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software]
* [http://www.infoq.com/presentations/effective-api-design How to Design a Good API and Why it Matters] [http://lcsd05.cs.tamu.edu/slides/keynote.pdf]
* [http://decoy.iki.fi/texts/filefd/filefd A brief look at file format design]
* http://arstechnica.com/articles/paedia/cpu/valve-multicore.ars

== Scripting ==
* [http://www.tcl.tk/doc/scripting.html Scripting: Higher Level Programming for the 21st Century]
* [http://www.osnews.com/story/7038/On_Scripting_Languages On Scripting Languages]

== Pointer Basics ==
* [http://cslibrary.stanford.edu/104/ Binky Pointer Fun Video]
* [http://www.slideshare.net/emartinez.romero/first-look-at-pointers First Look at Pointers]
* [http://www.slideshare.net/emartinez.romero/general-talk-on-pointers-1317108 General Talk on Pointers]
* [http://www.slideshare.net/emartinez.romero/more-pointers-and-arrays Pointers and Arrays]
* [http://www.slideshare.net/udekel/introduction-to-pointers-and-memory-management-in-c Introduction to Pointers & Memory Managements]
* [http://andesengineering.com/OSG_ProducerArticles/RefPointers/RefPointers.html Using osg::ref_ptr]

== Optimization ==
* [http://www.agner.org/optimize/optimizing_cpp.pdf Optimizing C++] (http://www.agner.org/optimize/)
* [http://www.tantalon.com/pete/cppopt/main.htm C++ Optimization Strategies and Techniques]
* [http://www.crowl.org/Lawrence/programming/Bentley82.html Writing Efficient Programs]

= Programming - Background knowledge =
* [https://www.youtube.com/playlist?list=PLoCMsyE1cvdWiqgyzwAz_uGLSHsuYZlMX Programming Abstraction in C++ (CS106B Stanford University)](~ 27 videos teaching programming and C++)

== C++ Courses ==
* http://www.learncpp.com/
* http://www.cprogramming.com/
* http://www.cplusplus.com
* http://www.thefreecountry.com/documentation/onlinecpp.shtml
* http://www.cpp4u.com/
* C++ related presentations:
** [http://www.slideshare.net/reachanil/c-memory-management Memory Management in C++]
** http://www.slideshare.net/reachanil/static-and-dynamic-polymorphism-in-c/
** http://www.slideshare.net/emery/automatically-tolerating-and-correcting-memory-errors

* Youtube Contents:
** [https://www.youtube.com/playlist?list=PLlrATfBNZ98dudnM48yfGUldqGD0S4FFb C++ (Yan Chernikov)]
** [http://youtube.com/user/reconnetworks A number of introductory C++ Tutorials]
** [http://youtube.com/watch?v=mrvAqvtWYb4 Getting C++ Threads right]
** [http://youtube.com/watch?v=3JUXPaovfzw Advanced Topics in Programming Languages Series: C++ Threads]

== C++ eBooks ==
* http://www.mycplus.com/c.asp?ID=15
* [http://en.wikibooks.org/wiki/C%2B%2B C++ Wikibook]
* http://www.techbooksforfree.com/ccpp.shtml
* [http://www.pragsoft.com/books/CppEssentials.pdf C++ Essentials]

== C++ References ==
* [http://www.parashift.com/c%2B%2B-faq-lite/ C++ FAQ Lite]
* [http://yosefk.com/c++fqa/ C++ Frequently Questioned Answers]
* http://www-h.eng.cam.ac.uk/help/tpl/languages/C++.html
* [http://www.ericbrasseur.org/cppcen.html?i=1 C++ for C users]

== C++/STL ==
* [https://www.youtube.com/playlist?list=PLZ9NgFYEMxp5oH3mrr4IlFBn03rjS-gN1 C++ Standard Template Library by Example]
* http://www.yolinux.com/TUTORIALS/LinuxTutorialC++STL.html
* http://www.halpernwightsoftware.com/stdlib-scratch/quickref.html

== Graphics Programming ==
* [https://www.gamedev.net/reference/articles/article1698.asp Graphics Programming Black Book]

== Game Programming related ==
* [http://www.gpwiki.org Game Programming Wiki]
* [https://www.youtube.com/playlist?list=PLlrATfBNZ98dC-V-N3m0Go4deliWHPFwT Build a Game Engine in C++ (Yan Chernikov)]
* [https://lazyfoo.net/tutorials/SDL/ Beginning Game Programming with C & Simple DirectMedia Layer]
* http://www.gamedev.net/reference/list.asp?categoryid=45

== General [[OpenGL]] Resources ==
* [https://learnopengl.com Learn OpenGL Graphics Programming]
* [https://www.glprogramming.com/red/ OpenGL Programming Guide (Red Book)]
* [https://www.glprogramming.com/blue/ OpenGL Reference Manual (Blue Book)]
* [http://www.falloutsoftware.com/tutorials/gl/gl8.htm OpenGL Light and Polygon Surface Tutorials]
* http://en.wikibooks.org/wiki/Opengl
* Youtube Introductions to OpenGL:
** [https://www.youtube.com/playlist?list=PLlrATfBNZ98foTJPJ_Ev03o2oq3-GGOS2 OpenGL (Yan Chernikov)]
** [http://www.youtube.com/watch?v=apxdcHwBcZY Graphics Programming]
** [http://www.youtube.com/watch?v=lTN7bDyHrfE Graphics Programming Using OpenGL]
** http://youtube.com/watch?v=oVwH8KV1xnY
** [http://youtube.com/user/mittrekkie Various introductory OpenGL tutorials]
* Columns
** [http://www.sjbaker.org/steve/omniv/opengl_lighting.html OpenGL Lighting]
** [http://www.sjbaker.org/steve/omniv/alpha_sorting.html alpha sorting]
** [http://www.sjbaker.org/steve/omniv/eulers_are_evil.html Euler Angles are evil]
** [http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html Learning to Love your Z-Buffer]
** [http://www.sjbaker.org/steve/omniv/matrices_can_be_your_friends.html matrices can be your friend]

== 3D Maths ==

* http://home.clara.net/iancgbell/maths/index.htm
* [https://www.youtube.com/playlist?list=PLSMz_Hxrv-C2bh5UGOE8n3fYpviD9q2gx Linear Algebra]
* [https://www.youtube.com/playlist?list=PLW3Zl3wyJwWNWsJIPZrmY19urkYHXOH3N Math for Game Developers]

== OSG/[[OpenSceneGraph]] related ==
* https://www.openscenegraph.com/index.php/documentation/getting-started
* [https://joshuaburkholder.com/documents/OpenSceneGraph_2.0_Quick_Start_Guide.pdf OSG Quick Start Guide]
* http://thermalpixel.github.io/osg/2014/02/15/rtt-with-slave-cameras.html
* http://www.vis-sim.com/osg/osg_faq_1.htm
* http://andesengineering.com/OSG_ProducerArticles/RefPointers/RefPointers.html
* http://beefdev.blogspot.de/2012/01/render-to-texture-in-openscenegraph.html

== Communities ==
(Forums, Newsgroups, Mailing Lists & Chat rooms)
* https://www.gamedev.net/forums/
* https://www.reddit.com/r/gamedev/
* https://cboard.cprogramming.com/cplusplus-programming/

= Networking =
* [http://beej.us/guide/bgnet/ Beej's Guide to Network Programming]
* http://courses.cs.vt.edu/~cs4254/spring06/slides/IO_Multiplexing_4.pdf
* http://irl.eecs.umich.edu/jamin/courses/eecs494/fall06/lectures/lecture9-socket.pdf
* http://ece.ut.ac.ir/Classpages/S84/Network/unix/Npc13.ppt
* [https://www.isi.edu/~hussain/TEACH/Spring2014/notes/Steven00a.pdf TCP/IP Illustrated, Volume 1]
* [http://www.linuxhowtos.org/C_C++/socket.htm Sockets Tutorial]
== Unix Sockets ==
* [http://users.actcom.co.il/~choo/lupg/tutorials/internetworking/internet-theory.html Network Programming under Unix Systems]
* [http://www.kohala.com/start/unpv12e.html Unix Network Programming]
* [http://www.catb.org/esr/writings/taoup/html/ The Art of Unix Programming (HTML)]
* [https://nakamotoinstitute.org/static/docs/taoup.pdf The Art of Unix Programming (PDF)]
== Windows Sockets ==
* [http://www.tangentsoft.net/wskfaq/ Windosck Programmer's FAQ]

== Protocol Design ==
* [http://xmpp.org/extensions/xep-0134.html#guidelines Protocol Design Guidelines]
* [http://tools.ietf.org/html/rfc4101 Writing Protocol Models]

== Multiplayer Design & Programming ==
=== Basics ===
* [http://www.gamedev.net/reference/articles/article721.asp Introduction: Designing Multiplayer Games]
* [http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/ UDP vs. TCP]
* [http://www.gamedev.net/reference/articles/article1138.asp Networking for Games 101]
* [http://gafferongames.com/networking-for-game-programmers/ Networking for game programmers]
* [http://books.google.com/books?id=Zm8AtSWjLwkC&printsec=frontcover&source=gbs_summary_r&cad=0 Programming Multiplayer Games - ebook]

=== State Management & Prediction ===
* [http://www.gamedev.net/reference/articles/article914.asp Defeating Lag With Cubic Splines]
* [http://www.gamedev.net/reference/articles/article1948.asp Distributed Gaming]
* [http://www.gamedev.net/reference/articles/article876.asp Statistical Client Prediction]
* [http://gafferongames.com/game-physics/networked-physics/ Networked Physics]

=== Security ===
* [http://www.gamasutra.com/features/19970707/security.htm Security in Online Games]
* [http://www.gamedev.net/reference/articles/article2062.asp Security Issues of Online Gaming]
* [http://www.gamedev.net/reference/articles/article722.asp The Essentials of Multiplayer Games ]

=== Libraries ===
* https://wiki.ogre3d.org/Home

= See also =
* [[Aircraft Information Resources]]
* [[Modeling Resources]]

[[Category:Lists]]
[[Category:Resources]]
[[Category:Core developer documentation]]

Category:Articles considered for deletion as of November 2024

2024-11-16T20:13:37Z

Ranguli: Created blank page

FlightGear Interprocess Communication (IPC)

2024-11-16T20:08:15Z

Ranguli:

{{Delete|reason=This article either contains out of date information and/or may not meet the quality standards of the wiki.|day=16|month=11|year=2024}}{{Stub}}

The flightgear supports the following interprocess communication interfaces:

* [[Howto:Create a generic protocol|generic protocols]]
* [[Telnet usage|telnet/props]]
* [[Property Tree/Web Server|httpd/mongoose]] (Phi)
* [[Emesary]]
* custom hard-coded protocols (netfdm stuff, links)
* [[High-Level Architecture]] (WIP)

Aircraft metadata checklist

2024-11-16T20:07:22Z

Ranguli:

{{Delete|reason=This article either contains out of date information and/or may not meet the quality standards of the wiki.|day=16|month=11|year=2024}}

This list is various simple checks and modifications to improve user experience with aircraft.

(For each of these items, we need to show an example of the XML changes required)

== Metadata / -set.xml ==
Checking / fixing these items should take about 30 minutes per aircraft (maybe a little longer the first time)

For full description of each item, see [[Aircraft-set.xml|aircraft -set.xml description]]

* Ensure the aircraft ratings are set and not wildly inaccurate.
* Ensure any tags are from the official list of tags: {{fgmeta source|path=python3-flightgear/flightgear/meta/aircraft_catalogs/catalogTags.py|text=catalogTags.py}}
* Ensure the aircraft has a suitable name and description
* For multi-variant aircraft, ensure the primary aircraft is a sensible choice (for example not a copilot or floats/skis variant), and that other variants declare a 'variant-of' referencing the primary

In the primary (for example in <code>f16-block-52-set.xml</code>):

<syntaxhighlight lang="xml">
<sim>
<primary-set type="bool">true</primary-set>
</sim>
</syntaxhighlight>

In the variants: (for example in <code>f16-block-10-set.xml</code>):

<syntaxhighlight lang="xml">
<sim>
<variant-of>f16-block-52</variant-of>
</sim>
</syntaxhighlight>

* Add new-style preview images
* Ensure the thumbnail is the correct size and follows the guidelines (not a logo, not a photograph) (Insert the basic thumbnail size here)
* Set <code>minimum-fg-version</code> and <code>compatible-fg-version</code> values in the <code>-set.xml</code> if required
* Review the 'catalog generator' error messages for the aircraft (for example XML formatting errors)
* Ensure any development files are excluded from the generated <code>.zip</code> (for example XCF or PSD files)
* Examine the console log and resolve any reported aircraft issues (for example PNG bad color profile, missing files, etc.) (Need to document options to do this)
* Add an appropriate MP fallback model

== Code changes ==
* Ensure the aircraft uses the global property for enabling/disabling the pilot model.
* ?

[[Category:Aircraft enhancement]]

SGModule - standalone SGSubsystems

2024-11-16T20:04:50Z

Ranguli:

{{Delete|reason=This article either contains out of date information and/or may not meet the quality standards of the wiki.|day=16|month=11|year=2024}}{{Affected by HLA}}
{{Multicore}}

= Background =
Increasingly, FlightGear developers are talking about splitting up the FlightGear design such that it may use multiple processes or threads for particular subsystems (i.e. using the ongoing HLA work: [[FlightGear HLA support (High Level Architecture)]]), this requires a subsystem design such that certain subsystems can be optionally run as different threads or processes, possibly using different binaries or the same fgfs binary (started in a different startup mode), while still being 100% compatible with the standard way of being run in the sequential FG main loop, as a SGSubsystem.

The [[FGPanel]] project illustrates some of the issues and challenges related to duplicating parts of the FlightGear code base in order to run parts of FlightGear in a standalone fashion, with the [[Canvas]] subsystem being a more recent example of a subsystem that shall eventually support a standalone runtime mode:

<pre>
We need to find a clever system to come up with some interface class like SGSubsystem
that can be run in standalone mode, something like "SGStandalone" - which implements
the full SGSubsystem interface (subclass), but which can also be run directly
in a non-fgfs main loop, with just the subsystems required by the corresponding subsystem
- for the canvas, this would probably mean looking at the fgpanel code: XML processing
(private property tree) and a network connection to the main FG process, so that
properties can be exchanged and updated.
</pre>

Initially, it would probably be easier to introduce a specific command line argument (or even just a property like --prop:/startup-mode=foo) so that FlightGear doesn't run the main initialization, but just initializes a particular module which is designed to be run in a standalone fashion.

Basically, you would start FG using a specific switch like ./fgfs --startup-mode=canvas
Initially, this could be implemented with a custom property: ./fgfs --prop:/startup-mode=canvas

This is also the approach taken by the google chrome and firefox browsers: the same binary is used, but different startup modes are used.

The bootstrapping code (fg_init.cxx) would then need to be modified to disable all the unneeded stuff, and make FG start up without FDM, SOUND etc. and just run a single SGSubsystem (Canvas) in the main loop.

Ideally, it should be possible to also link subsystems as standalone binaries, so that the linking/library dependencies of the main fgfs executable are not automatically inherited to modules which may not need all of the FG libraries, so that modules like the FDM or the [[Canvas]] don't automatically link in OpenAL or OSG dependencies.

= Objective =
Establish the requirements to implement an abstract interface that satisfies the standard SGSubsystem interface, while allowing such subsystems to be run as different threads or processes, using the same code base, and supporting the code to be run as part of the same fgfs binary, while providing an option to create separate binaries for specific modules, so that these don't introduce any unneeded fgfs-related dependencies.

{{cquote|The trick is that each of these threads must be done in a way that you
can just compile that alternatively in a single standalone binary and run the
same component in a networked rti - the LinuxTag booth for example.|Mathias Fröhlich (FlightGear Devel mailing list)<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32973.html
|title=FlightGear Manager...|author=Mathias Fröhlich |date=25 June 2011 }}</ref>}}

{{Appendix}}

Model import and export

2024-11-16T20:03:38Z

Ranguli:

{{Delete|reason=This article either contains out of date information and/or may not meet the quality standards of the wiki.|day=16|month=11|year=2024}}{{Out of date}}

== The Problem ==
When you create an aircraft model, generally an object like a wing is composed of other parts. A wing may consist of the wing body, the aileron, the flap and perhaps a wingtip. There may be hardware such as stays, guidelines, actuators, etc. It is desirable to export the entire wing with all its parts intact and _independent_. Some export or import tools may not support independent 'sub-objects' and will merge all the parts of a wing into single object (or 'mesh' as objects consisting of polygons are generally called in the 3d world).

What happens if you export or import using a tool that does not support sub objects? You get a wing with all its parts 'welded' together so they cannot be individually manipulated. This is not a good thing.

== FlightGear Import/Export ==
In FlightGear, a utility called '3dconvert' is bundled with the source (Windows binary available [ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/old/3dconvert-win32.zip here]), which has the ability to convert a number of 3d file formats. Exporting and importing 3d files for FlightGear can involve using the bundled '3dconvert', although it does not have to, given there are a number of third-party converters and import/export tools for 3d modeling applications.

It depends on a library called PLIB for making conversions between formats. As of this writing, _3dconvert_ can only open or save in formats supported by PLIB with any restrictions PLIB places on them.

This utility is dependent on the PLIB library. If you dig deep enough into PLIB documentation, you may find in a very obscure page

Non-class Functions
http://plib.sourceforge.net/ssg/non_class.html
(subject to change)

containing a table of formats PLIB is capable of opening and saving. Not all features of certain formats are supported in a given version of the library. This chart explains which formats PLIB recognizes and what features it supports. It also can tell you which features some formats lack.

The problem to solve is getting an aircraft model from GMAX's proprietary binary 3d format into a format more in keeping with the FlightGear community. Moreover, it is desirable to store 3d models in a format that has some longevity and is human readable. Those are two good reasons to get your model out from GMAX's trap.

Two major 3d design applications are AC3D and Blender. AC3D is the format FlightGear uses 'natively' for aircraft models. It is good that FlightGear uses a non-binary format for aircraft models. The AC3D model files are in 'ac' format and have an '.ac' file extension. Blender is another popular 3d modeling application, its files are in Blender format and have a '.blend' extension. Blender can import or export a number of 3d formats using Python scripts (don't worry, the scripts are easy to use and bundled with the latest version of Blender).

This tutorial will focus on Blender, because I am currently using it for my modeling.

== Getting Your Model Out of GMAX ==

An intermediate format is needed to get our model from GMAX into Blender, because GMAX cannot export non-binary 3d files. This is our first problem to solve. Fortunately, others have found a workaround for this situation. Data can be extracted from GMAX objects by writing a Maxscript (the native scripting language used in GMAX) program that collects the data and prints it to the conveniently provided "script listener" which listens to the output of scripts and displays it in a text window. The clever person can then copy the data from the window and paste into a text editor, which can then save the data into a file.

(I will not go into using GMAX plugins. These are issued by game companies that partner with GMAX and distributed software you can plug in to GMAX to export to a particular 3d format used by the game. Feel free to search for these and use them if you can find them and get them to work.)

This file can then be fed into another conversion or import tool. Either directly into a 3d modeling application or another conversion tool.

I found only one workable script for GMAX, one that displays object data in Wavefront OBJ format in the listener window. It is called {NAME HERE} and you can possibly get it {HERE} before it disappears. (See below)

Or you can try my own script that displays AC3D data in in the window.

In any case, you must go through the tedious task of copying and pasting the data. The listener window has some limit on the number of characters you can copy to the clipboard, so you will need to carefully break up the copying into several small selections for large objects.

Sorry.

Note: You may encounter a problem where the script reports an error. This is typically caused by a "grouped" object. You need to select any compound grouped objects and "ungroup" them before export.

== SketchUp ==

'''See this page:''' [[Modelling - SketchUp]] for importing from SketchUp.

== Blender ==

=== Getting Your Objects into Blender ===

Now that you've got your objects into an intermediate format, you need to get them into your 3d modeling application. I will focus on Blender, but it applies to other applications as well.

If you have the latest version of Blender {version} you _should_ have at least one script for importing Wavefront (.obj) format files. The scripts can be found on the File --> Import or File --> Export menus. Any import or export scripts installed should show up on these menus. Naturally, you will want to look on the Import menu. There is another OBJ filter you may encounter. I found this one limited, so skipped it for the one that seemed more full featured. The one you want is called Wavefront (.obj) and is authored by {author}.

The only step left is to import the OBJ files created by your cutting and pasting into Blender.

Each independent object in your GMAX 'scene' should be there in Blender. Try selecting a part, say the aileron. It should be separately manipulable.

=== Getting your objects out of Blender and into Flightgear ===

Suppose your object was an entire aircraft (you have a strong constitution, doing all that copying and pasting, I disassembled by aircraft into parts, exported them and reassembled them to avoid too much copying at once) or you have created one in Blender from your imported parts.

To use the aircraft in FlightGear, you export in AC3D format. See here for main page about this subject: [[Blender AC3D import and export]]

== Exporting in AC from GMAX ==

This discusses a little script I wrote to export objects from GMAX into AC3D format.

[[gMax2AC]]

== Additional Issues ==

Suppose the scripts to import additional 3d file formats did not exist in Blender. It only natively recognizes three formats (at time of writing), VRML 1.0, DXF, Videoscape and STL. Most are not widely in use today for 3d modeling (in my experience). DXF is a widely used standard format for CAD, but it lacks sub-object support. As far as I know, you cannot use DXF as an intermediate format and have your parts survive unmerged. (According to PLIB chart).

Here are some failed attempts:

GMAX->AC3D->VRML 1.0
using _threedeconvert_ merges objects.

Of course, if you have the Blender AC3D importer, this is unnecessary and not an issue.

GMAX-OBJ->VRML 2.0

Here I used a third-party file converter. Unfortunately, it only outputs VRML 2.0 and vanilla Blender only imports VRML1.0, which meant this is not a good path.

It just makes clear that you must be careful about which conversion tool or import/export tool you use, be sure it supports sub-objects.

What happens if objects are merged? Have fun picking all the parts of of a complex landing gear out of a single merged object!

== Why Export from GMAX? ==

Several reasons:

* GMAX is a "dead end", an application developed as a "crippled" version of a high end 3d design suite, deployed for game modding. This year (2005) all support by its make has been dropped. GMAX will only be distributed and supported within individual game environments, if at all.

* GMAX 3d files are in a proprietary binary format, which means humans cannot read them, it makes it difficult to translate to other formats because the format is only known to the developer. This reduces the "longevity" and ability to share your files.

Both of these issues add up to a situation that can leave your files "orphaned." I put hundreds of hours into my models and do not want them trapped on a "sinking ship" platform that I cannot get them out again to work on.

The official gmax website now points to the parent company AutoDesk, which apparently has discontinued or dropped support for the application.

If you go to the Discreet website (the company that released and managed GMAX)

http://www.discreet.com/products/gmax/

it takes you to

http://usa.autodesk.com/adsk/servlet/index?id=5562445&siteID=123112

which states

"As of October 6, 2005, Autodesk will no longer offer Gmax® software as a stand-alone product. If you are interested in other 3D animation, modeling, and rendering applications from Autodesk please check out Autodesk® 3ds Max® software. You can download a free 30-day trial, view product demonstrations, read customer success stories, and get more information about this powerful, versatile product."

== Maxscript Resources ==

There appears very little Maxscript material online. No tutorials, instructions, specifications, other than the official 3ds Maxscript help file I got somewhere. Many of the Maxscript sites are down, gone, password protected or otherwise unavailable. There were several versions of GMAX released, I find that many plugins and scripts are incompatible. I just don't have the time or interest for such a scattered set of resources and community, when there exist strong communities around open source applications such as Blender.

I will not be responsible for the chaotic state of these resources or their applicability or availability, but here are some helpful ones if they still exist by the time you go to them.

Chris Cookson was the author of several important Maxscript import/export scripts, which are no longer easily available.

See this thread

http://www.turbosquid.com/Forum/Index.cfm/stgAct/PostList/intThreadID/16045

for current 2005 status.

The OBJ importers are

v1.1
http://www.turbosquid.com/Forum/Index.cfm/stgAct/PostList/intThreadID/16045

v1.1a
http://pages.videotron.com/browser/Downloads/GMAX/scripts/importobj.ms

http://tutorials.city-of-doors.com/gmax.html

Mentions the 10kb limit on cut and paste from script listener.

The script mentioned here for working around this for at least one file format is here

http://nwvault.ign.com/View.php?view=Other.Detail&id=148

and still available at the time of writing. It was last updated in 2003. Perhaps you can adapt it. Good luck.

* http://nwvault.ign.com/View.php?view=other.Detail&id=149

This is a GMax-compatible Maxscript which will import and export (via the listener) ASCII mdl files...

* http://nwvault.ign.com/View.php?view=other.Detail&id=290

This Maxscript © utility will import/export Bioware's © mdl model files for Neverwinter Nights ©.

* http://nwvault.ign.com/View.php?view=other.Detail&id=604
DLA presents 'Aurora Importer' by Joco. This maxscript utility serves one function: it imports an as...
==Notes==
https://github.com/majic79/Blender-AC3D

{{3d}}

[[Category:Modeling]]

Howto:Decrease the number of faces

2024-11-16T20:02:58Z

Ranguli:

{{Delete|reason=This article either contains out of date information and/or may not meet the quality standards of the wiki.|day=16|month=11|year=2024}}

This short article is designed to show you, the prospective modeller some very good tips when creating models for use within [[FlightGear]] or any other situation which is dependant on ''face count''.

Lets start with telling you why the face count is important. Every time you connect 3 or more lines together you get a what is known as a ''face''. Whenever you place your model in FlightGear the more faces a model has, the more bytes of memory that model will use up of your computer. The more memory that your computer uses to load a model, the less it has to keep the simulation at a good frame rate. So...

It stands to reason that the less faces we use within a model the better it will integrate with FlightGear when you eventually place it in the [[FlightGear Scenery Database|Objects Database]]. For this demonstration we will use some simple models, used in the [[Princess Juliana International Airport]] scenery.

{{FGCquote
|My new 3D model has significantly more (perhaps 4 to 5 times as many) polygons than the one I am replacing and I am seeing, at most, a 1 FPS difference in frame rate that I can attribute to the new 3D model. Fact is that the scenery with clouds and other features will tend to have way MORE polygons than any reasonable aircraft model and modern graphics cards can handle millions of polygons at any given time so the aircraft model's complexity, if with in reason, is only a minor part of what the graphics card has to handle. On modern hardware you don't see much difference in frame rates in an aircraft with 150K polygons than one with 10K if they are otherwise very similar feature wise.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213272#p213272
|title=<nowiki>Re: What to expect from FlightGear 3.2?</nowiki>
|author=<nowiki>hvengel</nowiki>
|date=<nowiki>Tue Jun 24</nowiki>
}}
}}

== Examples ==
Below you can see three beach umbrellas. Each of these is different in face count numbers, the one on the right having the most and the one to the far left the least.

I’m sure you will agree that they look to all intents and purpose as they are designed to look you can see just from the picture the face count is bound to be different, but lets look a bit closer at them. Here you can see them without a texture or paint applied

[[File:Decrease_the_number_of_faces_0.jpg|400px]]

Have a look at the number underlined in red in the image above. This tells us that there are 136 faces in the image. That’s quite a lot for an object that is 2 meters high and the average pilot will fly over at between 80 - 140 knots at over 100ft. Yes sure, most players will go to explore this beautiful scenery with [[helicopter]]s, cars or [[UFO]], but after a while most of them will perform “only” takeoffs and landings. Taking into consideration those facts I think, we can still model this umbrella with quite nice level of detail using only 20 triangles (left image). Or, if you really want to make your scenery to take as low resources as possible you can build it using only 12 triangles.

[[File:Decrease_the_number_of_faces_1.jpg|400px]] [[File:Decrease_the_number_of_faces_2.jpg|400px]]

The same goes for other models too. Take a look at the two recliners here. The one on the left has 68 faces the one on the right 20! and in my opinion the one on the right looks better.

[[File:Decrease_the_number_of_faces_3.jpg|400px]]

Heres how they all look in Flightgear from ground level.

[[File:Decrease_the_number_of_faces_4.jpg|400px]]

As you can see, you can achieve good result using only 15% of triangles to model umbrella (middle one), or even 9% by sacrificing some details (left one) and 29% in case of recliner.

== Decreasing the amount of faces (in SketchUp) ==
The main cause of such high number of faces in some models when using [[SketchUp]] and its simplified interface is the fact that this software was not produced with making low poly models for 3D games in mind. But you can still reduce the number of faces in models. Here is an example on how to make a low poly umbrella.

Let's start by making a pole for our umbrella. First, place a polygon on the ground. Before clicking, type the number of sides your polygon should have (six here) and press {{Key press|Enter}}.

[[File:Decrease_the_number_of_faces_5.jpg|400px]]

Then using the push/pull tool extrude the polygon to the desired height and delete the faces at both ends of your pole, we don’t need them as they wont be seen.

[[File:Decrease_the_number_of_faces_11.jpg|400px]]

Next we will smooth out the edges by first left clicking three times on the pole which highlights the whole object, then going to the Window menu at the top (or right clicking) select soften/smooth edges.

[[File:Decrease_the_number_of_faces_6.jpg|400px]]

A new pop up window will appear with a slider. This should be moved passed the 60 degree mark and you will see the pole soften considerably.
And that’s it for the pole. Let's make the actual umbrella.

We start with a polygon. Using the pencil tool we will connect the centre spot with it edges. Quick tip: to make your pencil go straight to the centre point run the tool around the outside of the polygon then move it towards the centre, it will snap straight to the centre point.

Connect all the hexagons “points” to make six nice triangles.

[[File:Decrease_the_number_of_faces_7.jpg|400px]]

Using the move tool grab the centre point and move it upwards to the desired height. Holding the shift key down whilst moving up on the axis will hold it on that axis.

Click on the umbrella three times again to highlight it all, and again using the move tool place it over the pole.

[[File:Decrease_the_number_of_faces_8.jpg|400px]]

As you can see the umbrella is showing the purple face to the outside. If we were to leave it like this we would not be able to see the outside of the umbrella from above. But if we want to see the underneath we would be able to do so. To reverse the faces simply highlight one face and right click. You will see the window appear again. Select reverse faces and the correct face is to the outside. Then right click again and select Orient faces. This brings all the faces to the correct way.

And that’s it, we have low poly umbrella made with (if I count correctly) only 18 triangles.

=== Placing the object on a surface ===
If you'd like to place the umbrella on some other surface within your model, make sure to create a group containing the umbrella first. You can do so by selecting the umbrella and pole and then choose <tt>Right mouseclick > Create group</tt>. To edit it again, double click the object to enter the group. Doing this will prevent SketchUp from connecting the umbrella with the floor (and adding extra vertices to do so!).

For instance when first making the beach area for TNCM, I simply made the beach and then placed the umbrella polygon on the beach and extruded it upwards. Do not make this mistake. As you can see in the picture on the left it makes the face count jump sky high. Placing the umbrella(s) in a group decrease the face count dramatically, as shown in the right image.

[[File:Decrease_the_number_of_faces_9.jpg|400px]] [[File:Decrease_the_number_of_faces_10.jpg|400px]]

=== Results? ===
Ok lets see what difference these few helpful hints can make to your model. For the first beach scene created in FlightGear up 13133 faces were used, making it around 1.93 MB, which is huge. After redoing the beach using these great tips it came out at 2421 faces!

Todays beach at TNCM? 4.95Kb That’s it. Use these tips and you will be pleased to find your face count drops enormously.

'''My greatest of thanks go to Robert ‘erobo’ Leda firstly for helping me with the above information and secondly for allowing me to use his information and images for this short tutorial.'''

[[Category:Howto|Decrease the number of faces]]
[[Category:Modeling|Decrease the number of faces]]
[[Category:Scenery enhancement|Decrease the number of faces]]

Howto:Canvas Troubleshooting

2024-11-16T20:02:07Z

Ranguli:

{{Delete|reason=This article either contains out of date information and/or may not meet the quality standards of the wiki.|day=16|month=11|year=2024}}{{Stub}}{{Canvas Navigation}}

== Event Handling ==
{{FGCquote
|please keep in mind that you need to set up your z-index properly, or the corresponding group may not even receive any events due to overlapping stuff.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=215395#p215395
|title=<nowiki>Re: Event Click Listener on SVG element</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Jul 26</nowiki>
}}
}}

== Using Online Imagery ==
{{FGCquote
| I'd try to troubleshoot this step-by-step, e.g.: 
 
<ul>
<li> use a static LOCAL raster image (on disk/in fgdata - e.g. a splash screen -if this doesn't work, your Canvas/Image isn't set up properly, check visibility and z-index)</li>
<li> use a http URL (e.g. the google/flightgear logo - if this doesn't work, check for errors/networking issues)</li>
<li> use a dynamically-built URL - if this doesn't work, check your URL building scheme</li>
</ul>

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=216309#p216309
|title=<nowiki>Re: Displaying Remote Images (from URL/API) on canvas/MapStr</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Aug 09</nowiki>
}}
}}

== Textures not shown properly ==
{{FGCquote
|For starters, I'd suggest to work with textures that can be more easily recognized, i.e. some checker pattern or red as a color, to see what could be going on - otherwise, there's too much guessing involved, which is tedious for us given that we don't have access to your aircraft. So if you are hoping for more specific advice, open the texture in GIMP/photoshop and use some pattern for each different face that we can more easliy identify to see what's going on
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218785#p218785
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 17</nowiki>
}}
}}

{{FGCquote
|I'd just copy the livery texture to a new file and fill each part with a separate pattern/color to see what's going on - that will tell us if we can work around the issue by editing the model, the texture, the Nasal code - or if we need to look at the C++ code 
So far, this could be just a simple matter of changing scale/transforming the texture a bit (hopefully)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218787#p218787
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 17</nowiki>
}}
}}
[[Category:Canvas]]
[[Category:Troubleshooting]]

NavDisplay Refactoring

2024-11-16T19:59:29Z

Ranguli:

{{Delete|reason=Article was created and left incomplete several years ago|day=16|month=11|year=2024}}{{Stub}}

== Background ==

{{See also|Howto:Prototyping a new NavDisplay Style}}

We need to clean up the ND code, this page is intended to keep a list of items pending.

== Switch handling ==
* move switches into the aircraft-specific style hash
* rename value to default_value
* add an optional values:[] vector
* add a UI hash to contain UI specific fields (legend/tooltip)
* also use the UI hash for placement info (top/bottom, i.e. above/below the ND)

Realism

2024-11-16T19:58:41Z

Ranguli:

{{Delete|reason=Article does not meet quality standards and is out of date.|day=16|month=11|year=2024}}{{cleanup}}

Many newcomers may wonder just how realistic [[FlightGear]]'s [[aircraft]] and environment are. Many novices may wonder what is needed to get more realism and immersion from the FlightGear environment.

== Aircraft ==

[[File:DR400_Dauphin_Rembrandt_02.jpg|800px|center|The [[DR400|DR400 Dauphin]].]]

The underlying instrumentation models are very accurate, with many physical effects accounted for.

* The heading indicator has a small delay when it is slewing to the desired heading.
* The artificial horizon can tumble.
* The magnetic compass will rotate in all three axes and get stuck if the aircraft is tilted.
* The altimeter uses air pressure to determine altitude; if the sea level air pressure is set incorrectly, it will display the wrong altitude as in real life.
* All of the instruments that need engine power in real life are tied to the virtual engine; if the engine is not running, all vacuum-powered instruments (such as the artificial horizon and the heading indicator) will not function properly.
* Some aircraft feature accurate electrical systems with batteries that will drain over time and instruments that need electricity.

Many aircraft have quite complete cockpits; several effects make cockpits look much better, including ALS shadows.
== Flight dynamics ==

Since FlightGear uses many [[FDM|flight dynamics models]] under the hood, including [[YASim]] and [[JSBSim]], the realism of an aircraft depends on its FDM. Both of these support winds and turbulence; YASim generally has more realistic ground interactions with different surfaces, while JSBSim FDMs are generally truer to the real-life aircraft. It's important to note that both of these can produce similar results if the FDM is worked on enough.

== Scenery==

<gallery mode="packed">
File:Southwest04.jpg
File:Kansas_Scenery_Two.jpg
</gallery>
* Many buildings, landmarks, windmills, chimneys, pylons, and skyscrspers represented where appropriate
* Over 20,000 real world airports included in the full [[scenery]] set. The recent world scenery version 2 brought many major improvements, including more detailed heightmaps and man-made features such as roads, rivers, and train tracks.
* Correct runway markings including skid marks, runway lighting, and approach lighting.
* Detailed taxiways available for many airports.
* Sloping runways.
* Airport beacon lights with rotating beacons.
* Accurate worldwide terrain based on the most recently released SRTM terrain data. 3 arc second resolution (about 90m spacing) for North and South America, Europe, Asia, Africa, and Australia. United States used the more accurate 1 arc second (30m) data.
* Roads, rivers, and train tracks.
* Realistic night lighting with lit urban areas and headlights on roads.

Real world tower registration data was used to locate towers in the United States. The data was sourced from the United States Federal Communications Commission tower registration database.

Over one million objects have been added to the [http://scenemodels.flightgear.org/ FlightGear Scenery Database].

To download scenery for the entire world as you fly over it, open the File > Scenery Download menu and check "Enable automatic download/update".

== Weather ==

[[File:Local_weather_1.00_06.jpg|center|[[Advanced weather]].|800px]]

With [[Advanced weather]], cloud patterns and winds will change throughout the day. With [[atmospheric light scattering]] enabled, fog and clouds are more realistic, and lighting changes throughout the day and during overcast periods. Advanced weather can be driven with live [[METAR]] data or manually configured for specific weather scenarios.

Enable advanced weather in the Environment > Weather dialog.

<gallery mode="packed">
File:Cloud patterns with ALS lighting.png|Advanced weather creates realistic cloud patterns that mimic the real world weather
File:Moist air and haze seen from a Boeing 707 cockpit.png|Haze and dust particles with realistic blue color in distance
File:Morning flight.jpg|Few remaining clouds in morning sunlight, looks like it will be a nice flying day!
</gallery>

== Rendering ==

[[Atmospheric light scattering]], or ALS, features a realistic skydome and properly lit terrain, in addition to detailed terrain texturing and trees swaying in the wind. With advanced weather enabled as well, cloud shadows and volumetric fog are also fully supported. It can be enabled via the View > Rendering Options menu. Be sure to check out the quality slider, and if you're adventurous, enable custom settings.

[[Rembrandt]] is FlightGear's shadow and lighting engine; with Rembrandt enabled, realistic shadows and lighting are possible. Note that not all aircraft support Rembrandt yet. In addition, it's not possible to use Rembrandt in conjunction with ALS. Rembrant is enabled with the <tt>--enable-rembrandt</tt> [[Command line options|command line option]].

== Sky ==

<gallery mode="packed">
File:Southwest09.jpg
File:Water-sky01.jpg
File:Rayleigh_blue.jpg
File:Tree02.jpg
</gallery>

FlightGear's night sky features accurate placement and lighting of stars, planets, and the moon.

Atmospheric light scattering features accurate lighting of the sky and terrain; in addition, oceans and rivers are realistically shaded with ripples and sun reflections. Rayleigh scattering of distant terrain is supported, tinting the ground blue or red depending on the sun angle. With random trees, tree shadows are available; experimental aircraft ground shadows are also available.

The sun is quite realisticslly textured in the sky, and has such effects as sun dogs and rings.

== Properties ==

James Turner at one point started creating some properties under /sim/realism (mostly booleans for the moment), with the expectation that at some point we could create a GUI, and also use some Nasal to batch-configure the individual settings for different applications - flight trainer, game mode, kiosk, etc, etc. He remarked that he would be happy to add a /sim/realism/start-parked and /sim/realism/start-dark (though the latter involves aircraft designer help to hook the optional autostart functions of each aircraft). One concern relsting to this matter is touching the dreaded position init code, which is already baroque and complex. There's also the question of guessing a parking position when we don't have parking stand data - eg picking a point some distance away from the runway centerline (runway width * 5, maybe?), level with the threshold - but like all heuristics, this one has problems.
<ref>{{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/24944091/
| title = <nowiki>Re: [Flightgear-devel] Issue with default starting scenario</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Apr 6th, 2010
| added = Apr 6th, 2010
| script_version = 0.25
}}

Nvidia Windows

2024-11-16T19:42:12Z

Ranguli:

{{Delete|reason=Article is incomplete and contains out of date information|day=16|month=11|year=2024}}{{Stub}}

==Introduction==
The goal of this article is to document which settings in the [https://www.nvidia.dk/ NVIDIA] Control Panel seem to work best for [[Osm2city.py|osm2city]] with Atmosperic Light Scattering ([[Atmospheric_light_scattering|ALS]]) on Windows.

The configuration has been tested on:
* Windows 10 Home 64bit
* NVIDIA GeForce GTX 1060 6GB
* Driver version 385.69 (note that it is highly recommended to use NVIDIA drivers and to use recent versions)
* FlightGear 2017.3.1

The configuration and configuration choices might differ for different NVIDIA cards etc.

==Accessing the NVIDIA Control Panel==
The settings discussed in this article relate to Tab "Program Settings" in "Manage 3D Settings" in the NVIDIA Control Panel. The NVIDIA control Panel can be started by right-clicking on the Windows Desktop.

It requires to select or add a program to customize. You have to point to "bin\fgfs.exe".

[[File:Nvidia Control Panel on Windows 10.png|thumb|NVIDIA Control Panel on Windows 10 showing program specific 3D settings]]

==Tested Settings==
{| class="wikitable"
! Feature !! Setting !! Remarks
|-
| Anisotropic filtering || Application-controlled || There does not seem to be any difference to "Off"
|-
| Antialiasing - FXAA || Off || Setting this to "On" gives odd results. E.g. transparent parts of tree textures are green, antialiasing of thin lines gets broken
|-
| Antialiasing - Gamma correction || Off ||
|-
| Antialiasing - Mode || Application-controlled ||
|-
| Antialiasing - Setting || Application-controlled ||
|-
| Antialiasing - Transparency || Off || There does not seem to be any difference to "On"
|-
| CUDO - GPUs || Use global setting (All) ||
|-
| Low Latency Mode || Off ||
|-
| Multi-Frame Sampled AA (MFAA) || Off ||
|-
| OpenGL rendering GPU || GeForce GTX 1060 6GB ||
|-
| Power management mode || Prefer maximum performance ||
|-
| Shader Cache || On ||
|-
| Texture filtering - Anisotropic sample optimization || Off || There does not seem to be any difference to "On"
|-
| Texture filtering - Negative LOD bias || Allow || There does not seem to be any difference to "CLAMP"
|-
| Texture filtering - Quality || Quality ||
|-
| Texture filtering - Trilinear optimization || On || There does not seem to be any difference to "Off"
|-
| Threaded optimization || Auto ||
|-
| Triple buffering || Off ||
|-
| Vertical sync || Use the 3D application setting ||
|-
| Veritual Reality pre-rendered frames || 1 ||
|}

==Antialias Settings in FlightGear==
You might want to use the following properties to get antialias in FlightGear:

<code>--prop:/sim/rendering/multi-sample-buffers=true</code>

<code>--prop:/sim/rendering/multi-samples=4</code>

[[Category:Hardware]]
[[Category:Troubleshooting]]

FlightGear and OpenGL Core Profile

2024-11-16T19:40:58Z

Ranguli:

{{Out of date}}{{Stub}}

{{infobox subsystem
|image =
|name = OpenGL ES compatible subset of FlightGear
|started = 04/2020
|description = identify, patch and build a subset of FlightGear compatible with GLES
|status = RFC
|developers = talks
}}

{{Portability Navbar}}
{{See also|Howto:Build and run FlightGear on Raspberry Pi 4}}

Some FG users are very interested in seeing how FlightGear runs on lower end/embedded hardware (think RPi-style) using {{Wikipedia|OpenGL ES}}.

With other contributors, and core developers, wanting to use a more recent version of OpenGL to make use of more modern OpenGL features (e.g. in effects and shaders).
To do so, this entails porting FlightGear to OpenGL Core Profile.

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 Compatability mode.

I *believe* the new open-source Intel-Mesa drivers on Linux (which are supposed to decent quality, and even fast) might be in the same situation.<ref>https://sourceforge.net/p/flightgear/mailman/message/36341578/</ref>

Probably to do it initially, GLES1 would have to be used - I think GLES2 has no fixed function - and simgear/flightgear would have to be patched to use only OSG calls (if possible), e.g. by excluding features/subsystems that still use legacy OpenGL code incompatible with GLES.

OSG can have GLES{1,2} support without windowing compiled in.

OpenGL 1 and 2 can be mixed but OpenGL ES 1 and OpenGL ES 2 can't. There is a performance price to pay for this backward compatibility. For this reason, we should get rid of PLib because this (old) code is all OpenGL 1 that may slowdown the all rendering pipeline.

For historical reasons, Flightgear and Simgear are mixing OpenGL 1
(old code) and OpenGL 2 (more recent code).<ref>https://sourceforge.net/p/flightgear/mailman/message/36980923/</ref>

== Background ==
{{Main article|Howto:Optimizing FlightGear for mobile devices}}

The OpenSceneGraph port initiated in 2006 has never been fully completed, so that there is a certain amount of code making use of legacy OpenGL calls, which complicates modernizing the renderer.

In particular, this means that [[Supporting multiple renderers]] is unnecessarily complicated, [[Unifying the 2D rendering backend via canvas|unifying the 2D rendering back-end]] is a long standing challenge. It's only since just very recently, that supporting different renderers is being worked on thanks to the [[Compositor]] effort.

But even then, phasing out legacy code or porting it, still needs to be addressed sooner or later.

Being able to run fgfs on such, comparatively low-powered, systems using OpenGL ES can actually be a good thing for fgfs as a whole - it can help us understand bottlenecks that are hardly visible on typical gaming/developer rigs, but that may still show up over time (think leaking listeners/memory) - this sort of thing can also be considered the prerequisite for people wanting to target/build/run fgfs on other embedded hardware, such as thin clients with integrated GPUs or even mobile phones/tablets (think Android)

we need to remove PUI and change the Canvas not to use Shiva, to be ES2 compatible or Core-profile compatible.<ref>https://sourceforge.net/p/flightgear/mailman/message/36194973/</ref>

In other words, if the right people were to team up to specifically target such hardware, this could also mean significant performance improvements for people on powerful gaming rigs.

== Approach ==
{{See also|Unifying the 2D rendering backend via canvas}}

For starters, we can try the [[FlightGear Headless]] option to build a fgfs version without showing any graphics at all.

The next step will be identifying and excluding problematic sources (those containing legacy/raw OpenGL code, e.g. using <code>glBegin()</code> or <code>glEnable()</code> respectively):

https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Cockpit/render_area_2d.cxx
<syntaxhighlight lang="cpp">
void RenderArea2D::RenderQuad( const SGVec2f *p) {
glBegin(GL_QUADS);
glNormal3f(0.0f, 0.0f, 0.0f);
glVertex2fv( p[0].data() );
glVertex2fv( p[1].data() );
glVertex2fv( p[2].data() );
glVertex2fv( p[3].data() );
glEnd();
}
</syntaxhighlight>

Whenever FlightGear sources contain such or similar code, it is pretty safe to assume that we will need to port/exclude such modules from compilation to ensure that no legacy OpenGL code is executed at runtime.

<syntaxhighlight>
Instrumentation/HUD/HUD_runway.cxx
Instrumentation/HUD/HUD_tbi.cxx
Instrumentation/HUD/HUD.hxx
Instrumentation/HUD/HUD_instrument.cxx
Instrumentation/HUD/HUD_ladder.cxx
Instrumentation/HUD/HUD_dial.cxx
Instrumentation/HUD/HUD_tape.cxx
Cockpit/render_area_2d.cxx
Cockpit/panel.cxx
GUI/WaypointList.cxx
GUI/CanvasWidget.cxx
GUI/MapWidget.cxx
</syntaxhighlight>

This means, we'll need to review/disable the compilation of the following folders in $FG_SRC and patch up all hard-coded references to these systems:
* Instrumentation/HUD
* Cockpit
* GUI

In addition, there's Viewer/PUICamera.cxx which references glEnable()

== Example: Disabling PUI ==
{{Main article|Developing using CMake}}

We should add separate build options to explicitly disable certain features individually.

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 Compatability mode.<ref>https://sourceforge.net/p/flightgear/mailman/message/36341578/</ref>

Knowing that [[PUI]] contains legacy OpenGL code and knowing it's scheduled to be removed anyway because it isn't compatible with modern OpenGL, we will disable it completely without
reviewing/porting individual PUI files. This means opening $FG_SRC/CMakeLists.txt to add a new option to disable PUI.

Successfully disabling a feature means primarily:
* adding a corresponding new build option to the top-level CMakeLists.txt (e.g. DISABLE_PUI)
* opening fg_init.cxx and navigating to the lines where the feature/subsystem is initialized
* wrapping the corresponding code in between <code>#ifdef...#endif</code> blocks
* locating any remaining references to the subsystem in question and repeating the last step there to ensure that removed subsystems are not accessed at runtime

https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/CMakeLists.txt
<syntaxhighlight lang="cmake">
option(SYSTEM_CPPUNIT "Set to ON to build Flightgear with the system's CppUnit library")
option(DISABLE_PUI "Set to ON to build Flightgear without PUI support")

if(DISABLE_PUI)
add_definitions(-DDISABLE_PUI)
endif(DISABLE_PUI)

</syntaxhighlight>

We will be adding <code>#ifdef</code> macros to the sources in question, and update CMakeLists.txt accordingly.

Ideally, in conjunction with a feature-specific build option to disable the corresponding feature (think [[PUI]] or the [[HUD]]).

Thus, after editing CMakeLists.txt, we need to open fg_init.cxx to prevent initalization of PUI.

https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Main/fg_init.cxx#l1043
<syntaxhighlight lang="cpp">
////////////////////////////////////////////////////////////////////
// Create and register the XML GUI.
////////////////////////////////////////////////////////////////////
#ifndef DISABLE_PUI
globals->add_subsystem("gui", new NewGUI, SGSubsystemMgr::INIT);
#endif
</syntaxhighlight>

So, after editing fg_init.cxx to prevent the PUI GUI from getting initialized by FlightGear, we will need to find remaining hard-coded references to it, to fix those up and deal with PUI not being available. This means grepping $FG_SRC for any references to <code>"pui"</code> to locate remaining get_subsystem() calls. (FIXME: new subsystem lookups use templates), this will include code in unrelated modules, e.g. fgcommands (think menu bindings) accessing the GUI via something like <code>get_subsystem("gui");</code>

https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Main/fg_scene_commands.cxx#l277
<syntaxhighlight lang="cpp">
NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
if (!gui) {
return false;
}

</syntaxhighlight>

Thus, it makes sense to intercept registration of these fgcommands at the bottom of the file by wrapping these inside ifdef macros:

https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Main/fg_scene_commands.cxx#l497
<syntaxhighlight lang="cpp">
/**
* Table of built-in commands.
*
* New commands do not have to be added here; any module in the application
* can add a new command using globals->get_commands()->addCommand(...).
*/
static struct {
const char * name;
SGCommandMgr::command_t command;
} built_ins [] = {
{ "exit", do_exit },
{ "reset", do_reset },
{ "reposition", do_reposition },
{ "switch-aircraft", do_switch_aircraft },
{ "panel-load", do_panel_load },
{ "preferences-load", do_preferences_load },
{ "toggle-fullscreen", do_toggle_fullscreen },
{ "screen-capture", do_screen_capture },
{ "hires-screen-capture", do_hires_screen_capture },
{ "tile-cache-reload", do_tile_cache_reload },
#ifndef DISABLE_PUI
{ "dialog-new", do_dialog_new },
{ "dialog-show", do_dialog_show },
{ "dialog-close", do_dialog_close },
{ "dialog-update", do_dialog_update },
{ "dialog-apply", do_dialog_apply },
{ "open-browser", do_open_browser },
{ "gui-redraw", do_gui_redraw },
#endif
{ "add-model", do_add_model },
{ "presets-commit", do_presets_commit },
{ "press-cockpit-button", do_press_cockpit_button },
{ "release-cockpit-button", do_release_cockpit_button },
{ "dump-scenegraph", do_dump_scene_graph },
{ "dump-terrainbranch", do_dump_terrain_branch },
{ "print-visible-scene", do_print_visible_scene_info },
{ "reload-shaders", do_reload_shaders },
{ "reload-materials", do_materials_reload },
{ "open-launcher", do_open_launcher },
{ 0, 0 } // zero-terminated
};

</syntaxhighlight>

This will ensure that fgcommands that are PUI related won't be available in a non-PUI build.

We will also need to look for other files accessing the "NewGUI" subsystem <code>grep -nr "NewGUI" -l</code>:
<syntaxhighlight>
Main/subsystemFactory.cxx
Main/fg_scene_commands.cxx
ATC/atcdialog.cxx
ATC/atcdialog.hxx
Autopilot/route_mgr.cxx
</syntaxhighlight>

Since we have excluded $FG_ROOT/GUI from the build and updated fg_init.cxx, we will only need to review/patch these files to ensure that there are no hard-coded references to PUI if it's not available, using the same ifdef based approach.

Obviously, fgdata level resources like menu bindings and/or Nasal code may still try to execute such bindings.

Finally, there may still be other PUI specific references in the source tree ($FG_SRC), so that it does help to check the other folders next: <code>grep -nr "PUI" -l
</code>

Since we have excluded $FG_SRC/GUI from the compilation, we can safely ignore any references to that folder, with the remaining ones being:
<syntaxhighlight>
Input/FGMouseInput.cxx
Main/fg_os.hxx
Main/bootstrap.cxx
Viewer/renderer_compositor.hxx
Viewer/PUICamera.cxx
Viewer/renderer_legacy.cxx
Viewer/CMakeLists.txt
Viewer/PUICamera.hxx
Viewer/renderer_compositor.cxx
Viewer/renderer_legacy.hxx
Viewer/GraphicsWindowQt5.cpp
Canvas/canvas_mgr.hxx
</syntaxhighlight>

The renderer is basically just referencing the PUI camera so that the GUI can be drawn, whereas canvas_mgr merely acccesses the PUI subsystem to be able to render canvas based textures. In other words, both references can be easily removed for testing purposes.

== Affected features and sources ==

{| class="wikitable"
|-
! Feature !! Directory !! Notes !! Status
|-
| [[HUD]] || $FG_SRC/HUD || One of the longterm development items we have is to [[Unifying_the_2D_rendering_backend_via_canvas#HUD|replace the hardcoded HUD with one built on canvas]]. As well as allowing us to remove anothe piece of plib, it would allow simple overlays like this as well. So I think the answer here is to do that work, and then implement a canvas HUD for this overlay.<ref>https://sourceforge.net/p/flightgear/mailman/message/37606344/</ref> || {{Progressbar|10}}

|-
| [[PUI]] || $FG_SRC/GUI || trivial to disable, can be replaced via [[Phi]]. Is in the process of being replaced by a Canvas based UI || {{Progressbar|70}}
|-
| [[Post_FlightGear_2020.2_LTS_changes#2D_Panels|2D Panels]] || $FG_SRC/Cockpit || see {{Merge-request|project=flightgear|id=217|text=Populate /canvas property tree for the 2D panel}}

There's also a [https://sourceforge.net/p/flightgear/flightgear/ci/topics/panel-hacking/~/tree/ branch] (which is a few of years old) contains WIP on implementing 2D panels as canvas. It uses the same loading / updating logic in C++ (for 100% compatibility), but rather than building custom rendering, it builds up a Canvas element hierarchy in C++.<ref>https://sourceforge.net/p/flightgear/mailman/message/36980724/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37042351/</ref>
|| {{Progressbar|80}}
|-
| [[Canvas Path]] (Shiva) || $SG_SRC/canvas || see [[Shiva Alternatives]], and Scott's and James' comments: {{See also|2022.X Release Plan#Rendering}} || {{Progressbar|20}} (02/2022)
|-
| [[Effects]] || $FG_ROOT/Effects || will include [[Shader]]s and probably involve a custom [[Compositor]] pipeline, for current Status refer to [[OpenGL#Status]] || {{Progressbar|70}}

|}

In addition, [[SimGear]] needs special treatment, too <ref>https://sourceforge.net/p/flightgear/mailman/message/36978098/</ref>.
Using the same heuristics as before (based on grepping [[$SG_SRC]] for <code>glBegin</code> and <code>glEnable</code>, we end up with the following sources (ignoring [[Canvas Path ]]/shivavg, which is dealt with already above):

<syntaxhighlight>
simgear/scene/tgdb/SGVasiDrawable.cxx:42: glBegin(GL_POINTS);
simgear/scene/model/shadanim.cxx
</syntaxhighlight>

{| class="wikitable"
|-
! Feature !! Directory !! Notes !! Status
|-
|}

== Porting ==
{{Wikipedia|OpenGL ES}}

=== Vertex buffer objects ===
{{See also|Uniform Buffer Objects}}

=== Canvas.Path (OpenVG) ===
{{Main article|Canvas Path}}
{{Note|For the patch adding explicit Canvas.Path level synchronization, refer to this forum thread from 08/2021<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&hilit=path+osg+canvas&start=60#p390834</ref>}}



Will likely need to replace shiva vg with an OpenGL 2.0 based implementation like nanovg <ref>https://github.com/memononen/nanovg</ref>.

As part of the Core profile migration, we need to replace ShivaVG (which is the functional guts of Path.cxx) with a shader based implementation, ideally NanoVG, although Scott has indicated this might not be as easy as originally hoped. <ref>https://sourceforge.net/p/flightgear/mailman/message/37605458/</ref>

Furthermore, there are segfaults/race conditions that are reportedly related to Canvas Path: Based on what we've seen and discussed so far, I still think that it's primarily Canvas.Path (specifically ShivaVG) that we need to look at - aggressive OSG threading is ... aggressive. <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&hilit=path+osg+canvas&start=30#p390529</ref>

Which is to say, the Canvas.Path element is not even using native OSG code, and the flickering shown in the screen shots, suggests that it's something related to Canvas.Path handling.

Inside a gdb session, you'll probably see something related to $SG_SRC/canvas/elements/shiva - which is where the 3rd party sources related to ShivaVG reside:
<pre>
https://github.com/ileben/ShivaVG/blob/master/README
No multi-threading support has been implemented yet.

This also pointed out in the Qt 4 docs, when shiva was used:

https://doc.qt.io/archives/qt-4.8/openvg.html
The paint engine is not yet thread-safe, so it is not recommended for use in threaded Qt applications that draw from multiple threads. Drawing should be limited to the main GUI thread.
</pre>
i.e. the shiva stuff is called by C++ code from multiple threads - otherwise, seeing flickering specific to map elements implemented via OpenVG (Canvas.Path) would not make sense

Shiva itself cannot be considered thread-safe, but may be invoked from multiple threads in fgfs, once fgfs is being used in conjunction with compositeviewer:

So, what the OP in 08/2021 was probably seeing is this:

# setting up multiple windows (using CV or not, probably irrelevant, since both options share the same CameraGroup back-end)
# using OSG multi-threading (i.e. no Singlethreaded)
# OSG will implicitly try to run some stuff asynchronously using worker threads
# this is why shiva gets called from multiple OSG threads, despite shiva itself not being thread-safe

This is neither specific to the Canvas ND, nor to the CompositeViewer mode.

As far as I can tell right now, it's due to ShivaVG - which some core devs have been wanting to replace/update for years anyway, see for example James' comments on "Skia": [[Canvas_news#Skia_talks]].

{{Note|It's important to highlight that the issue is apprently not specific to Qt5 and neither to the CompositeViewer or the Compositor - it's a bug that people can probably also trigger when using aggressive OSG threading and a single window, since the shiva back-end may get called from multiple OSG threads.
People using single-threaded mode, will still have the same issue built into the binary, but won't trigger it.
People using multi-screen setups or the CompositeViewer mode, will use additional OSG threads which will run into the ShivaVG related issue.

For the time being, the workaround is using single-threaded.
A "fix" would be porting/fixing Canvas.Path to get rid of Shiva or use a different back-end.

An interim solution would be using explicit synchronization (locks/mutexes) to tell OSG not to use threading for Canvas.Path based drawables - according to the docs, that should be possible by setting the data variance to osg::Object::DYNAMIC - but for the drawable itself that is already being done, thus CanvasPath.cxx will probably need a review to add explicit OSG/OpenThread based synchronization (which is probably something best discussed with Fernando, Richard and James on the devel list/issue tracker).
<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&hilit=path+osg+canvas&start=45#p390657</ref>}}

it does make sense that the OP can trigger this issue reliably, because he happens to be creating 3 different windows (=threads) - whereas I have been testing with a single additional window, which is why the issue probably takes time to show up. With multiple concurrent threads, the shiva code may get called from different threads, so that it will probably segfault rather "reliably".

In the meantime, there is no "fix" per se - the workaround is to use single-threaded mode when using canvas/shiva related features.

Alternatively, we could look at reworking the CanvasPath drawable implementation so that it's using explicit synchronization, to ensure it never gets called from multiple OSG threads.<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&hilit=path+osg+canvas&start=45#p390533</ref>

It seems, the current analysis is spot-on, and seems to be in line with comments found in the osg-users archives:
<pre>
https://groups.google.com/g/osg-users/c/nH-73NNFw4A

when using DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext threading models the StateSet and Drawable DataVariance is used to prevent dynamic leaves of the scene graph being updated and rendered at the same time - the draw traversal holds back the main thread till all the dynamic objects have been dispatched.

https://groups.google.com/g/osg-users/c ... CkzY9geHEJ
The thread safety provided by the OSG isn't quite what you are
assuming, just setting the DataVariance to DYNAMIC only affects
whether the update, event and cull traversals of the current frame can
be run multi-thread the draw traversal of the previous frame, and this
hint is only applicable to StateSet and Drawable and is used to
prevent multi-threading where objects are that are being modified by
the update or event traversals running concurrently with the draw
thread that is reading from them. This threading model is
light-weight in that it avoids the need to large numbers of mutex
locks or multi-buffering, but it doesn't provide an means for general
multi-threading. The OSG's multi-threading also can handle running
cull or draw threads on multiple contexts in parallel, and with
database paging, again this is done a light-weight manner than scales
well and has a small overhead. The design is very much geared towards
the needs of high performance graphics applications rather than
general purpose multi-threading.

So... you'll need to take a step back and work on how to work best
with the design of the OSG. The OSG is designed to allow single
threaded updates of the scene graph during the update and event
traversals. If you do wish to do some work multi-thread preparing new
scene graph elements these can be done as a separate subgraph in a
separate thread then merged with the main scene graph during the
update phase - this is how the osgDB::DatabasePager works.

https://groups.google.com/g/osg-users/c ... YJEx_jcAYJ
Modifying the scene graph outside of the frame call is safe in
SingleThreader, and CullDrawThreadPerCamera threading models as they
don't leave any threads active after the end of the
renderingTraversals() method (called from frame()).

With DrawThreadPerContext and CullThreadPerCamewraDrawThreadPerContext
the draw threads will still be active on completion of the
renderingTraversals(), so if you modifying drawables and state that
the thread is still reading from in the draw traversal you will end up
with problems - and potential crashes. There is a standard mechanism
to deal with this issue - and that is the renderingTraversals() method
to block till all dynamic objects in the draw traversals have been
dispatched. The way you tell the draw traversal that an drawable or
stateset will be modified dynamically is to set its data variance to
DYNAMIC.

drawable->setDataVariance(osg::Object::DYNAMIC);
stateset->setDataVariance(osg::Object::DYNAMIC);

This is mentioned in the "Quick Start Guide" book, as well as many
times on the osg-users mailing list so have a look through the
archives if you want more background reading.
</pre>

OBJECT::DYNAMIC is already being set on the drawable itself (via the interface of sc::Element), but probably not yet on the StateSet (?) - so that might be worth trying next, but other than that, there's probably no "real fix", other than telling OSG not to execute shiva code from multiple threads - short of fixing Shiva, which seems unlikely since a number of core devs have been wanting to get rid of it anyway

So far however everything points at canvas, and looking at canvas code, it seems that there's a lot of stuff going on in update and
cull callbacks that looks to me like it shouldn't. I don't really understand the architecture well enough to tell for sure though, or to
figure out how to fix it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37605328/</ref>

From a quick eyeball just now, the code in CanvasPath.cxx looks /mostly/ to me:

* all setXYZ methods set a dirty flag
* there is an OSG updateCallback which updates the custom drawable
* drawImplementation calls the rendering commands, with some extra work to synchronise the current OSG state with the Shiva use of state.

Importantly, the vgPath is created inside update, but this /should/ only touch CPU state. Whereas if the attributes are dirty for say fill or colour or opacity, the vgPaint is re-created, and this likely touches OpenGL commands inside Shiva, so it’s done inside drawImplementation.

So, I don’t see anything grossly incorrect here, with my understanding of what OSG expects, and what Shiva does. Importantly, I don’t see anything special related to culling at all. My recollection is that even in the most aggressive threading modes, OSG won’t update a node at the same time as drawing it, which is why there’s no internal locking: if this guarantee did not hold, I think almost every OSG Group/Node would need to internally lock its state, with enormous overhead.

(There is a complication here around STATIC vs DYNAMIC nodes, but the Path node is tagged DYNAMIC, so the above guarantee should still be correct)<ref>https://sourceforge.net/p/flightgear/mailman/message/37605758/</ref>

== Community talks ==
* [https://forum.flightgear.org/viewtopic.php?f=45&t=36922&p=364937#p364937 Download_and_compile.sh & Raspberry Pi4]
* [https://sourceforge.net/p/flightgear/mailman/search/?q=%22opengl+es%22 OpenGL ES (devel list)]

== References ==
{{Appendix}}

== Related content ==
* [[FlightGear Headless]]
* [[Howto:Optimizing FlightGear for mobile devices]]
* [[Graphics card profiles]]
* [[Canvas and OpenGL ES]]
* [[FlightGear and old Hardware]]
* [[Compositor]]

[[Category:Rendering roadblocks]]

FG Int Objects Modules

2024-11-16T19:39:27Z

Ranguli: Propose merge

{{Merge|FG interface}}{{FG Int Objects Modules sidebar}}
Modules in FG interface are Object Class , as like a map, to build a new object. You have learned about '''HT16K33''' and '''MCP23017''' classes, they are Modules, special Modules named in FG Interface world '''Devices'''. I made this difference to split and make the difference between switch , displays .. etc and the hardware driver chip. 
All Modules Classes are loaded into the interface, ready to be used and can be requested with the '''getModule()''' Interface Method.

To be loaded, the module need to be declared.
For memory, the main config file :
<syntaxhighlight lang="ini">
[INT]
intname=RADIOPANEL
deviceconf=/opt/fgint/Config/RadioPanel/devices.cfg

[MODULES]
module01=FGIntHT16K33,HT16K33
module02=FGIntMCP23017,MCP23017
module03=FGIntSegDisplay,SegDisplay
module04=FGIntSwDisplay,SwitchLight
module05=FGIntSwitch,Switch
module06=FGIntSwitch,ToogleSwitch
module07=RotaryEncoder,RotaryEncoder

[AUXCONF]
displays=/opt/fgint/Config/RadioPanel/displays.cfg
swlights=/opt/fgint/Config/RadioPanel/swlights.cfg
switches=/opt/fgint/Config/RadioPanel/switches.cfg
tglswitches=/opt/fgint/Config/RadioPanel/tglswitches.cfg
encoders=/opt/fgint/Config/RadioPanel/rotenc.cfg
</syntaxhighlight>

In the '''MODULES''' section, you can see all modules that will be loaded.
Here We are loading '''HT16K33''' from module file '''FGIntHT16K33.py'''. Same thing for the '''MCP23017''' Module in the '''FGIntMCP23017.py''', '''FGIntSegDisplay.py''' with the '''SegDisplay''' Class

Some Module file can handle more than one Class, as like '''FGIntSwitch.py''' where you can find different Class for different switch types.
'''FGIntSwitch.py''' own the folling classes :
* '''Switch''' : Single switch 2 states
* '''DoubleSwitch''' : Single switch 3 states
* '''RotarySwitch''' : Use to manage a rotary switch (variable nb position)
* '''ToogleSwitch''' : Single Push button that will switch between 2 states at each push

[[Category:FG Interface]]

Howto:Developing a DSL interpreter in Nasal

2024-11-16T19:35:59Z

Ranguli: Propose deletion

{{Delete|reason=This is a work-in-progress article created several years ago that was never written.|day=16|month=11|year=2024}}{{Template:Nasal Navigation}}

== Objective ==
Document how to develop a [http://en.wikipedia.org/wiki/Domain-specific_language Domain Specific Language] in Nasal, i.e. for creating scripted pilots, scripted ATC controllers <ref>www.rvs.uni-bielefeld.de/publications/Papers/ATC-grammar.ps</ref><ref>www.rvs.uni-bielefeld.de/publications/Papers/hillermann-parser.pdf</ref> or scripted weather patterns.

* "[Callsign]: MAINTAIN PRESENT SPEED."
* "[Callsign]: DO NOT EXCEED 250 KNOTS"
* "[Callsign]: turn left heading 185"
* "[Callsign]: Climb and maintain 5000"
* "[Callsign]: hold north-west of the SFO VOR on the 330 degrees radial, left turns, maintain 8000 feet"

{{#ev:youtube|QEZVpY_PCOY}}

== Todo ==
* tokens
* lexing
* parsing
* code generation
* [[Howto talk:Implementing a simple bytecode interpreter in Nasal|code execution]]

= Resources =
* http://www.theenterprisearchitect.eu/archive/2009/05/06/dsl-development-7-recommendations-for-domain-specific-language-design-based-on-domain-driven-design
* http://www.mailsend-online.com/blog/a-dsl-in-javascript.html

Changelog 2024.1

2024-11-08T18:54:59Z

Ranguli:

{{Draft}}

{{WIP}}

== World Scenery 3.0 ==

== Translations ==

* Improve translations for the following languages:
** French
** Spanish
** Polish
** Italian
** German
** Dutch
** Slovak
** Georgian
** Russian

== Hardware Device Support ==
Support for the following hardware devices has been added or updated:

* Honeycomb Alpha Flight Controls
* Honeycomb Bravo Throttle Quadrant
* Saitek Pro Flight Rudder Pedals
* Saitek Pro Flight Switch Panel
* CH Combatstick
* Logitech G25 Racing Wheel
* Thrustmaster T-Flight Rudder Pedals

== AI Traffic & Liveries ==
Traffic and/or liveries have been added for the following airlines:

* Delta Airlines
* United Airlines
* AeroUnion Mexico
* AeroMexico
* AeroMexicoConnect
* Amerijet Cargo
* Airest Cargo
* Air Caraibes
* DHL
* Amazon Air
* EuroWings
* Polar Air Cargo
* Northern Air Cargo
* Eastern Airways UK
* ANA Wings
* Ibex Japan
* Solaseed Japan
* AirHongKong
* AirHongKong Cargo
* AirChina
* UNI Air Japan
* Southern Air Cargo
* SATA Air Acores
* Azores Airlines
* European Air Transport Leipzig
* SykyLeaseCargo
* Blue Air
* Cyprus Airways
* DirectFlight Airtask Shetland
*
* Corsair
* LOT Polish Airlines
* Braethens
* Transavia NL
* Transavia France
* Tunisair Group

Traffic and/or liveries have been removed for the following airlines:

* GermanWings (defunct)

== Canvas ==
fc16b827a Fix OSM imagery in the canvas map (fixes #2912)**

<nowiki>**</nowiki>f0a740333 Remove OpenAIP map support from Canvas Map (see #2913)**

== FG1000 ==

== Nasal ==

== Phi ==
<nowiki>**</nowiki>7b36d498f Fix a variety of broken or unsupported maps in Phi

725ce7d3f Phi: Add map option to disable repositioning own aircraft by dragging

fc3b7b8b5 Phi: Highlight "follow aircraft" button if enabled

5626dc51f Phi: Remove unused css rule

88788dc6a Fix attributes for multiplayer and AI airplanes in Phi (fix #2274)

660fda829 Phi: automatically use latest AIRAC cycle for OpenFlightMaps

57483a999 Phi: fix midnight time offset

== Aircraft Carriers ==
The following [[Aircraft carrier|Aircraft carriers]] have been added:

* Admiral Kuznetsov
* Liaoning

== Misc. ==
f9ad4124f Route manager add total dist, dist remaining, ete, flight time

== Legacy ==

* Remove [[Rembrandt]] command-line options

Changelog 2024.1

2024-11-08T18:13:54Z

Ranguli: Create page skeleton

{{Draft}}

{{WIP}}

== World Scenery 3.0 ==

== Translations ==

* Improve translations for the following languages:
** French
** Polish
** Italian
** German
** Dutch
** Slovak
** Georgian

== Canvas ==

== FG1000 ==

== Nasal ==

== Phi ==

User:Ranguli

2024-11-06T15:05:52Z

Ranguli:

User:Ranguli

2024-11-06T15:05:06Z

Ranguli:

Hi there,

I'm a fan of Flight Gear and have joined the Wiki to tidy things up as I come across them. If I don't fix them then and there on the spot, they'll go into the list below.

Cheers,

[[User:Ranguli|Ranguli]] ([[User talk:Ranguli|talk]]) 10:30, 20 August 2020 (EDT)

This is a list of pull requests and bug reports / code tickets I've filed in order to keep track of what I'm working on as well as the status of bugs.

== Merge Requests ==
{| class="wikitable"
|+
!Progress
!Merge Request
!Date Created
!Repository
!Ticket
!Title
!Status
|-
|{{Progressbar|percentage=100}}
|#331
|Sept. 6th 2024
|FGData
|{{Ticket|2913}}
|Fix OSM imagery in the canvas map (fixes #2912)
|Merged without changes
|-
|{{Progressbar|percentage=80}}
|#332
|Sept. 6th 2024
|FGData
|{{Ticket|2913}}
|Remove OpenAIP map support from Canvas Map
|Blocked, awaiting review from FG1000 maintainer
|-
|{{Progressbar|percentage=100}}
|#333
|Sept. 7th 2024
|FGData
|{{Ticket|2913}}
|Fix or remove broken Phi map layers
|Merged without changes
|}

== Bug Reports ==
{| class="wikitable"
|+
!Bug Report
!Date Created
!Title
!Status
!Remarks
!Assignee
|-
|{{Issue|2917}}
|Sept. 7th 2024
|Saitek Pro rudder pedals not working on next branch
|Limbo (Sept. 16th 2024)
|
|No-one, waiting for a reply from<code>jsb1658</code>
|-
|{{Issue|2916}}
|Sept. 7th 2024
|Missing Qt dependency should be caught at compile-time instead of run-time
|
|
|
|-
|{{Ticket|2914}}
|Sept. 5th 2024
|Auto-hide menu bar requires mouse click to hide
|Unacknowledged. This may become irrelevant with the migration away from PUI.
|
|No-one
|-
|{{Ticket|2913}}
|Sept. 5th 2024
|Breaking OpenAIP API changes causing issues in Canvas Map and Phi
|I made PRs to fix the bugs. Two are merged, one is blocked awaiting review from the FG1000 maintainer.
|
|
|}

== Plan ==
Some hypothetical or experimental development ideas for improving flightgear:

- Port the launcher to Qt 6

- Work on Nasal intepreter, Nasal specification, grammar, and tooling

- Migrate simgear and flightgear to use vcpkg instead of dlls from a repo

== Wikipedia Contributions ==
=== House-keeping ===

# {{progressbar|100}} Update the article on the [[AC3D_file_format]]
# {{progressbar|100}} Mark [[FG_Interface_schematics_and_PCBs]] incomplete
# {{progressbar|100}} Mark [[Deperdussin_Monocoque]] as stub
# {{progressbar|100}} Mark [[Schleicher_ASK_13]] as stub
# {{progressbar|100}} Cleanup [[Technik_Museum_Speyer]]
# {{progressbar|100}} Cleanup [[ATR_72-500]]
# {{progressbar|100}} Cleanup [[Blender]]
# {{progressbar|70}} Cleanup [[AC3D]] needs software infobox
# {{progressbar|50}} Cleanup of [[Flying_Warbirds]]
# {{progressbar|50}} Cleanup [[Altitude]]
# {{progressbar|10}} Flesh out [[QNH]]
# {{progressbar|0}} Mark [[KFreeFlight]] as abandoned/old
# {{progressbar|0}} Cleanup of [[Flight_rules]]
# {{progressbar|0}} Cleanup [[Aircraft_information_resources]]
# {{progressbar|0}} Cleanup [[Avionics_Development_Resources]]
# {{progressbar|0}} Cleanup [[Aircraft_Manuals]]
# {{progressbar|0}} [[SVG]] fix quote syntax
# {{progressbar|0}} [[Kelpie_Flight_Planner]] needs software infobox

=== Screenshot Improvements ===
Quite a number of articles have screenshots which are 10 years old or more! While their historical staying power is impressive, their lower resolution and old graphics don't quite live up to modern expectations. Here are some articles I intend to take better screenshots for:

# {{progressbar|0}} [[Flying_Warbirds]]

== Larger Projects ==
# {{progressbar|100}} Rewrite [[Mailing lists]] article
# {{progressbar|50}} [[Howto:Working_with_the_AC3D_file_format_in_Blender]] This article needs new sections about exporting, saving, caveats, etc.
# {{progressbar|0}} [[User:Ranguli/List of file formats]] This article needs a good deal of cleanup, but could also be a ton of work depending on how far I'd want to take documenting file formats used by FlightGear.
# {{progressbar|0}} [[Howto:Edit_a_livery]] unfortunately this article is really a "How to draw an owl" type of tutorial, and was of no use to me while trying to learn how to work with liveries. Once I get a better understanding of the concepts personally I'd like to redo this from the ground up.
# FlightGear Academy articles that need heavy reformatting:
## {{progressbar|100}} [[Normal_Landing]]
## {{progressbar|0}} [[Emergency_Approach]]
## {{progressbar|0}} [[Emergency_Descent]]
## {{progressbar|0}} [[S-Turns]]
## {{progressbar|0}} [[Go_Around]]
## {{progressbar|0}} [[Rectangular_Course]]
## {{progressbar|0}} [[Turns_About_a_Point]]
## {{progressbar|0}} [[Take_Off]]
## {{progressbar|0}} [[Stalls_and_Spin_Awareness]]
## {{progressbar|0}} [[Soft_Field_Landing]]
## {{progressbar|0}} [[Slow_Flight_(Minimum_Controllable_Airspeed)]]
## {{progressbar|0}} [[Short_Field_Landing]]
# {{progressbar|0}} [[JSBSim_Commander]] add software infobox and mark as abandoned
# {{progressbar|0}} [[Conversion]] add some tables, formulas, rename to Aeronautical conversions
# {{progressbar|0}} [[Airports.txt]]
# {{progressbar|0}} [[Howto:Create_WebPanel_instrument]]

== Building FlightGear (WIP Article) ==

== Why this article exists (and why good build documentation is paramount) ==
The long-term health and growth of open-source projects is directly tied to the size and quality of the community that is built around it. One of the most important groups of people within these communities are developers. Developers are like the worker bees of a bee colony, and are the lifeblood of a project. Much like the world-wide shortage of bees, there are more open-source projects needing help than there are developers to help them. So it stands to reason that it is in any open-source projects best interest to retain the developers that take an interest in the project. The art of making developers lives easier is called '''developer experience''' (DX), and projects may live or die by it, with or without knowing it was a factor. Quite simply, developers who have a bad experience with a project will not contribute. Can you blame them?

The first place a developer is liable to have a bad experience with a project (and then move on) is when they first come face to face with documentation. The first impression a developer will get of a project will be from its README or equivalent documentation, particularly, the instructions for '''building the software'''. Many a developer has been eager to contribute to a project only to find a lack of documentation, and (rightfully so), moved on to other, less frustrating pursuits in the open-source world.

There are three guiding principles for not sending developers for the hills:

# There is '''one''' way to build the project, using '''one''' build system, following '''one''' set of instructions, that are easy to follow and consist of only a few steps
# The build process, code quality, and quality of documentation all work together to provide a '''low-friction''', '''low barrier to entry''' for '''new contributors'''.
# If a developer has a bad experience, '''that is a bug.'''

== Building FlightGear on Ubuntu and derivatives ==
FlightGear requires a large number of dependencies to build. In a terminal, you can install all necessary dependencies by using the following command:

== Building SimGear ==
{| class="wikitable"
|+
!Dependency
!Ubuntu 22.04
!Ubuntu 24.04
|-
|Boost
|libboost1.74-dev
|libboost1.83-dev
|-
|Open Audio Library (OpenAL)
|libopenal-dev
| -
|-
|OpenSceneGraph (OSG)
|libopenscenegraph-dev
| -
|-
|liblzma
|liblzma-dev
| -
|}

cmake

git

build-essential

pkg-config

make

gcc

g++

libboost1.74-dev

libopenal-dev

libopenscenegraph-dev

libcurl4-openssl-dev

24.04LTS
sudo apt install git gcc g++ build-essential cmake

22.04LTSFlightGear also has a dependency on another part of the FlightGear project, [[SimGear]]. So in order to build FlightGear we must first build SimGear.

Obtain the SimGear source code by cloning from [[Git]]:
git clone <nowiki>https://git.code.sf.net/p/flightgear/simgear</nowiki> flightgear-simgear
Next, follow the standard procedure for building a CMake project:
cd flightgear-simgear

mkdir build && cd build

cmake .. -DCMAKE_BUILD_TYPE=Release

make -jX # Where X is the number of cores on your system

sudo make install

== Building FlightGear ==
DRAFT
{| class="wikitable"
!Dependency
!Hard dependency?
!Required for
!Ubuntu 22.04
!Ubuntu 24.04
|-
|libplib
|Yes
|Legacy joystick support
|<code>libplib-dev</code>
| -
|-
|libudev
|Yes
|Peripheral / input support
|<code>libudev-dev</code>
| -
|-
|Qt 5 Base
|Yes
|Building FlightGear GUI launcher
|<code>qtbase5-dev</code>
| -
|-
|Qt 5 SVG
|Yes
|Building FlightGear GUI launcher
|<code>libqt5svg5-dev</code>
| -
|-
|Qt 5 Declarative
|Yes
|Building FlightGear GUI launcher
|<code>qtdeclarative5-dev</code>
|
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev-tools, qttools5-dev</code>
| -
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev</code>
|
|-
|Qt 5 Quick
|Maybe
|Building FlightGear GUI launcher
|<code>qtquickcontrols2-5-dev</code>, <code>qml-module-qtquick2</code>
|
|-
|Qt 5 QML
|Maybe
|Building FlightGear GUI launcher
|<code>qml-module-qtquick-controls2</code>
|
|-
|libevent
|No
|[https://swift-project.org/# Swift] client support
|libevent-dev
| -
|-
|zlib
|Yes
|File compression/decompression
|<code>zlib1g-dev</code>
|
|-
|dbus
|No
|[https://swift-project.org/# Swift] client support
|<code>libdbus-1-dev</code>
| -
|-
|OpenXR
|No
|Virtual Reality (VR) support
|<code>libopenxr-dev</code>
| -
|}

<code>sudo apt installlibplib-dev qtbase5-dev libqt5svg5-dev qtdeclarative5-dev qttools5-dev-tools qttools5-dev libevent-dev libdbus-1-dev libudev-dev qml-module-qtquick2-controls2 libavformat-dev libavutil-dev libswscale-dev libavfilter-dev libavdevice-dev libavcodec-dev libopenxr-dev</code>
== Other notes ==
# [https://web.archive.org/web/20170118212558/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Checklist/TM_1-1520-240-CL.pdf Chinook Operators Checklist TM 1-1520-240-CL]
# Incredibly useful, Chinook CH-47D manual: [https://web.archive.org/web/20170118213215/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Manual/TM_1-1520-240-10.pdf Chinook Operators Manual TM 1-1520-240-10]
# [https://web.archive.org/web/20170118215340/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Maintenance_Test_Flight_Manual/TM_1-1520-240-MTF.pdf Chinook Maintenance Test Flight Manual TM 1-1520-240-MTF]

Changelog 2020.3

2024-10-22T21:29:40Z

Ranguli: Update "Next changelog" link to 2024.1

{{changelogs|prev=2020.1|next=2024.1}}

Available in: [[Changelog_2020.3|English]], [[Pl/Changelog_2020.3|Polish]], [[Zh/2020.3|Chinese]]

Please help us translate into other languages!

----
The FlightGear development team is delighted to announce the v2020.3 LTS release of FlightGear, the free, open-source flight simulator. This is the second Long Term Support release for FlightGear, since the project changed to offering both Long Term Support releases, and more cutting-edge Preview releases. This release represents the culmination of two years of development effort by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

Major enhancements since the v2020.3 LTS include:
* a developer preview of the upcoming Compositor graphical rendering framework as a separate pre-built binary,
* enhancements to both the JSBSim and YASim flight dynamics models
* DDS texture caching to reduce load times
* faster loading and more memory efficient buildings
* improved aircraft carrier support

Additionally 30 completely new aircraft have been added to the official hangar, and a further 71 have received major updates.

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

Founded in 1997, FlightGear features more than 700 aircraft, a worldwide scenery database, a multiplayer environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language, and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

FlightGear - Fly Free!

----

== Launcher ==
* Addition of a welcome screen on first launch, providing helpful information to first time users.
* Aircraft can now be marked as Favourites, and filtered, making it easier to see find your favourite aircraft out of the hundreds available.
* The launcher now supports aircraft carriers, including selecting a carrier and setting a start position.
* {{key press|Ctrl|F}} shortcut for when you just want to Fly!
* Improved support for helipads and seaports, including detection of current aircraft type.
* Numerous bugfixes and stability improvements, in particular for the aircraft and addons tabs.

== Graphics ==
* To provide a developer preview, the [[Compositor]] renderer is included as part of this release. It provides a fully XML-configurable multi-pass rendering pipeline that is compatible with ALS and includes clustered shading.
* Support for DDS Texture Cache, improving loading times for texture files.
* Star visibility is configurable based on magnitude of star and atmospheric conditions.
* Use of non-directional point sprites as a fallback for drivers that do not support triangles of point sprites is now supported by setting <code>/rendering/triangle-directional-lights=false</code>.
* A new Tower AGL view has been added. This is similar to Tower View, except that it keeps both the aircraft and the ground immediately below the aircraft in view, zooming and panning smoothly as the aircraft moves. Good for viewing landings.
* Improved airport grass textures
* Implemented tidal movement for littoral areas.
* Updated regional material definitions for California, Asia, Northern Brazil, Iceland, Jan Mayen island.
* Active volcanoes - Katla, Eyjafjallajokull, Surtsey.
* Instanced-based random and OpenStreetMap buildings, improving performance and graphical quality significantly.
* Improvements to the Wingflex Shader.
* Users may enable/disable the pilot model from the View Options dialog.

== JSBSim ==
* Added the ability to set up the starter and acceleration times of a turbine (parameters <code><n1spinup></code>, <code><n2spinup></code>, <code><n1startrate></code>, <code><n2startrate></code>).
* The <code><integrator></code> filter can now be reset to 0.0 by setting its <code><trigger></code> property to a negative value.
* The integration scheme of the <code><integrator></code> filter can now be chosen among <code>rect</code> (Euler), <code>trap</code> (Trapezoidal), <code>ab2</code> (2nd order Adams-BashForth) and <code>ab3</code> (3rd order Adams-Bashforth)
* The following functions can now be used in <code><function></code>: <code>floor</code>, <code>ceil</code> and <code>fmod</code>. Their functionalities are the same than the corresponding C/C++ functions.
* <code><function></code> now checks the number of its arguments.
* New system component linear_actuator
* Export the fuel density to the property tree
* Added cyclic clipping for FCS components
* Added the ability to control the turbine engines spin down factor
* [Backward compatibility breakage] Gyros are now measuring rotation rates instead of rotational accelerations. Gyros that measure rotational accelerations do not exist in the real world.
* Output properties of flight control elements are no longer tied. This saves a lot of spurious warning messages and allows direct references of the same properties among several flight controls.
* Water vapor in the atmosphere is now managed through its mass fraction rather than its partial pressure. The former being the physical quantity that is conserved when pressure and temperature vary.
* Check that there are at least 3 contacts before trying to trim on ground.
* Added optional transmission of the simulation time for FG UDP interface
* The existence of the property that is used for table independent vars is now checked during execution rather than when the XML definition is parsed. This relaxes the order in which filters, table and more generally flight controls need to be declared in the XML definition files.
* Electric engines RPM is now exported in UDP sockets.
* The parameter <code><ignitionn2></code> now affects N2 rather than N1.
* A warning is now given when max < min in a <code><clipto></code> rather than throwing an exception
* Added the ability to log properties in a CSV file with the new fgfs executable argument <code>--jsbsim-output-directive-file</code>

== YASim ==
* Ground friction (stiction) changes
* Support for transonic flow effects.
* Control initial gear state directly by setting <code>/fdm/yasim/respect-external-gear-state=true</code>, rather then YASim settings this depending on whether the aircraft is in the air or on the ground.
* Electric engines are now supported.

== Weather and Environment ==
* Increased turbulence will be encountered near active volcanoes.
* Configurable METAR URL.
* METAR strings are decoded and displayed in a human-readable form in the weather dialog.

== Carriers ==
* Two new carrier-specific starting options are supported in the launcher: <code>carrier-takeoff</code> and <code>carrier-approach</code>.
* A new <code>--carrier-position</code> command-line argument has been added. This can be used to select the aircraft start position on an aircraft carrier. Either a catapult (e.g. <code>cat-1</code>), a parking position (e.g. <code>park-1</code>), on final approach on the FLOLS (<code>flols</code>) or abeam the carrier (<code>abeam</code>).
* MPCarrier can now be detected by the GUI even if not available on startup. To enable this feature set <code>/sim/mp-carriers/auto-attach=true</code>.

== AI ==
* New fgcommands <code>add-aiobject</code> and <code>remove-aiobject</code> for adding/removing objects to the AI subsystem.
* New AI aircraft, including 747 Freighter, CRJ900, SR-71, Saab 340.
* Numerous updates to AI traffic schedules and airline liveries.
* Space Shuttle TAEM and approach at KEDW scenario.
* Accurate Britten-Norman Islander performance data, from an Islander pilot.

== Multiplayer ==
* Connection to VATSIM via swift is now available via the GUI.
* FGCom now supports both COM1 and COM2, as well as volume settings.
* The views defined by the user's aircraft (Pilot view, Helicopter view, Tower view etc) can now be used with multiplayer aircraft. Viewing a particular multiplayer aircraft is done by clicking in the Pilot List dialogue's "view' column (see the "Multiplayer/Pilot List" menu).
* <code>--disable-hold-short</code> option which allows the user to force a start on the runway when multiplayer is enabled. This option should be used with caution - it can give other pilots and ATC a nasty fright to find an aircraft materialize on the runway!
* Support for recording multiplayer data

== Nasal Scripting ==
* Configurable load order for core Nasal modules.
* Improvements and bug fixes to Emesary, the messaging interface.
* Improvements to the core libraries.
* Garbage collection improvements to reduce frame stuttering
* Re-loadable Nasal modules
* Canvas EFIS framework
* New methods in Canvas Image to set colors of pixels in the image.

== Aircraft ==
* FG1000 Glass Panel improvements include user-configurable VFR transponder codes, volume controls, new fascia, UI is now resizeable, support for custom SVG files (e.g. for a G500). The FG1000 is now available on the Cessna 182T, J3 Cub, Diamond DA40.
* Improved glider vario instrument.
* New Aircraft:
** Airbus A320 - airliner
** Alisport Silent2Electro - glider with electric sustainer motor
** Bombardier Q400 DHC8-402 - shorthaul turboprop airliner
** Breguet Atlantic BR 1150 - long-range maritime patrol aircraft
** Cessna 140 - GA aircraft
** Cessna 208B Caravan - short range passenger, freighter and utility aircraft
** Cirrus SR22T - GA aircraft
** Diamond DA40 NG - GA aircraft, including FG1000 glass panel cockpit
** Diamond DA62 Twinstar- Twin engine GA aircraft
** Diamond HK36 Super Dimona - motorglider
** Dornier DO 28 Skyservant - Twin engine STOL utility aircraft
** Douglas TBD Devastator - WWII Torpedo bomber
** Draco Wilga - turboprop taildragger bush plane
** Fokker T.V - twin engine bomber
** Glasfluegel H201B Standard Libelle - glider
** Grumman F11-Tiger - carrier-based fighter
** Grumman HU-16A Albatross - twin engine amphibian
** McDonnell Douglas MD-11 - a glass-cockpit widebody trijet
** Petliakov PE-8 (Ant-42/TB-7) - WWII bomber
** Piper PA28-161 Warrior II - GA aircraft
** Pipistrel Alpha Electro - electric training aircraft
** Pipistrel Taurus Electro G2.5 - glider with electric sustainer motor
** Rolladen Schneider LS8sc neo - standard glider with electric sustainer motor
** Robin DR400 Ecoflyer - GA Aircraft
** Scheibe Bergfalke II/55 - training glider
** Schempp-Hirth Arcus S - high performance glider
** Schleicher Ka6(CR) "Rhoensegler" - training glider
** SEPECAT Jaguar GR.1 - jet attack aircraft
** SUMPAC - Human powered airplane
** Supermarine Swift - jet fighter
** Yak 52 - training aircraft
* Major updates to over 70 aircraft. Including 737-100, 737-300, 777, A-26-Invader, AR-234, ASG29, ASK13, ASK21, Aero-Commander, Aichi-D3A, B-17, B-24-Liberator, B-25, Bombardier-415, CH750STOL, CRJ700-family, Cessna-208-Caravan, Cessna Citation II, Cessna-L19, Cirrus-SR22, Concorde, DO-228, DO-335, Diamond-Da40, Diamond-Da42, Dragonfly, Embraer-ERJ-145, F-15, Fairchild-Metroliner, Falcon-50, Fokker-S-11, Fw200, H4-Hercules, Harrier-GR3, Horten-Ho-IX, Hughes-XF11, J3Cub, JA37, JAS39-Gripen, Jaguar, LS4, Lancair-235, Lionceau, Lockheed-NF104A, Lockheed-P38, ME-262, Mirage-2000, MirageIV, Northrop-xb35, PC-12, Piaggio-P166, Piper-PA-28, Potez-630, R44, Ryan-Navion, SIAI-Marchetti-SF.260, Socata-ST10, SpaceShuttle, Starship, Tecnam-P2006T, UH-1, Yak-18T, Zlin-50lx, an24b, bluebird, c182s, dhc1, f-14b, f16.

== Miscellaneous ==
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Map dialog displays heliports and allows configurable cursor key panning
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* Change screenshot filename to have date and time
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.1=
Changes since the 2020.1 preview release include:
* Various launcher improvements including a Welcome screen and a keyboard shortcut ({{key press|Ctrl|F}}) to Fly!
* Improved regional definitions for California, Iceland and Northern Brazil and better grass textures.
* Implemented tidal movement for littoral areas.
* New AI model for the 747 Freighter, and numerous AI livery and traffic updates.
* Updates to the FG1000 glass panel display including configurable VFR transponder codes, volume controls, a new fascia, resizeable UI and support for custom SVG files.
* A hangar full of new aircraft: HU-16A-Albatross, LS8, Embraer-ERJ-145, Cessna 208B Caravan, PZL 104 wilga 2000 Draco, Scheibe Bergfalke, Taurus, f16, Dornier Do 28 Skyservant, Petliakov Pe 8 (Ant 42/DB 7), Grumman F.11 Tiger
* Updates to a large number of aircraft including CRJ700, Dragonfly, Mirage 2000, Jaguar GR1, H4 Hercules, JA37, Supermarine Swift, A320, Cirrus-SR22, Cessna Citation, J3Cub
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.3.0=

As 2020.3 is a long term supported release, there are ongoing bug-fixes and small improvements happening, based on user feedback and automatic reporting of crashes and issues. Significant fixes are listed below:

==2020.3.1==
* Add help page to the launcher
* Fix handling of helipads at heliports
* Migrate installed aircraft packages, when migrating to the new stable catalog
* TerraSync: improve startup performance on Windows

==2020.3.2==
* TerraSync waits for Models to be completely sync-ed, to avoid missing models when starting
* First-run screen: add a 'scroll to the bottom' hint icon
* Tides fixes from Erik Hofman
* Use nicer scrollbar for the launcher, fixes some issue with long aircraft lists
* Support Apt.dat v1000 comm frequencies
* Fix an ATC crash when repositioning
* Many translations fixes identified by Michael Danilov
* Greatly improve the Brazilian cerradio areas (near SBMQ)
* Russian translation updates
* Iceland materials fixes

==2020.3.3==
* Fix accidental mouse picks while using a right-mouse-drag to look around
* Fix the download location we recommend in the 'setup root' dialog

==2020.3.4==
* Handle more METAR strings correctly, including wind sensor failures
* Fix airmass velocity being applied to sub-models twice (eg, when dropping payloads in a cross-wind)
* Fix crash on shutdown in the properties code
* Spanish translation updates
* Disable flights to EGEL to avoid crashes in traffic code

==2020.3.5==
* Change default Windows download location to %USERS%\FlightGear\Downloads, to avoid problems with Windows Defender blocking un-trusted applications from writing to Documents, which was the previous location.
* Fix a crash when returning to FlightGear from another application and scrolling or clicking
* Avoid crashing with UIUC-based aircraft such as the Wright Flyer
* Fix a crash on macOS when a joystick failed to open
* Update the macOS application icon
* Fix Nasal crash on reset
* Canvas: allow anisotropic filtering
* Larger, improved moon texture
* UFO speed goes to 11
* Fix taxiway markings disappearing in specific graphics settings

==2020.3.6==
* Fixed crash downloading the default aircraft catalog
* Fix a hang starting at scenery in the ocean
* Fix incorrect sky & cockpit rendering with certain METAR values
* Add getting-started hints to the launcher (English only for now)
* Fix Shuttle AI scenarios
* Improvements to flight-planning mode
* Sun / moon scaling fixes
* Fix initial position of submodels
* macOS: warn if running with app translocation
* Windows: detect missing OpenGL drivers
* Fix UIUC FDM crashes
* Fix crash with invalid view numbers
* Catch FDM NaN errors more gracefully
* KAP-140 approach mode improvements
* Traffic+AI livery updates

== 2020.3.7 ==
* Enable OSM2City buildings via TerraSync for the whole planet
* C172 bug-fixes and updates
* Improved regional material definitions for Europe, California
* Allow chat box to be re-positioned
* Fix crashes related to particle systems
* Fix selection of time-zone around Beijing
* Fix display of non-Latin1 strings in Canvas displays
* Fix Multi-player mode runway-start logic to select hold-short position correctly
* macOS: fix crash on text with certain fonts
* Fix launcher language selection when the UI language include a script specifier (eg zh-Hans-CN)
* Fix aircraft-id property when loading from a hangar ( https://sourceforge.net/p/flightgear/codetickets/2502/ )
* Improve checks for out-of-date Intel Graphics drivers on Windows

== 2020.3.8 ==
* Fix behaviour of <code><local></code> particle systems
* Fix autumn tree appearance

== 2020.3.9 ==
* Fix crash in Swift
* Corrections to MP protocol timing
* Correct URL to FGData
* Fix bug in cache reload dialog
* Improvements to ATC dialog to display frequencies with 3 decimal places correctly
* Improve material definitions for Africa, Mediterranean regions
* Add updated ocean and water visual effects

== 2020.3.10 ==
* Transponder: make standby mode work
* Launcher: pick up scenery and aircraft paths from the command line
* Launcher: store locations differently, to avoid problems when running multiple FlightGear versions and switching between them.
* Launcher: add 'restart on quit' option
* Fix NavCache errors loading ShapeFile data
* Fix NavCache errors when running multiple copies of FlightGear

== 2020.3.11 ==
* Fix a crash introduced in 2020.3.10
* Improve error message when no aircraft search paths are available
* Fix a crash with misconfigured traffic taxi routes
* Update AI traffic schedules

== 2020.3.12 ==
* Add aircraft directory name validation
* Add an extra step of antialiasing (8x)
* Add feature allowing aircraft to define custom fonts for osg::Text
* Add generic combined ALS procedural lights and Compositor lights
* Add new regional materials for Australia
* Fix Basic Weather producing invalid pressure altitudes
* Fix bug in path searching for previews
* Fix bug in sound system when approaching max-dist range
* Fix crashes after reset
* Fix crash when AI aircraft has invalid destination runway
* Fix Mapstructure error in RTE layer
* Fix <code>--view-offset</code> to use the correct property
* HUD: make vertical gauges look the same as horizontal ones
* Improved Russian and Spanish translations
* Miscellaneous improvements to weather dialog
* Property browser: display values for folders in verbose mode
* Route manager: select correct waypoint when duplicate waypoints exist
* Update AI traffic schedules and add new AI models

== 2020.3.13 ==
* Fix for the disappearing MP pilot list
* Fix JSBsim linear actuators behaving badly in certain conditions

== 2020.3.14 ==
* Support for add-on paths
* Instant audio queue
* Allow canvas dialogs to not grab focus away from FG (more like how focus in PUI dialogs behaves)

== 2020.3.15 ==
* Fix radio audio morse issue.

== 2020.3.16 ==
* Fix audio indent issue.

== 2020.3.17 ==
* Navradio: disable low-pass filter when changing selected freq or leaving GPS slave mode. When the selected frequency is changed or when leaving GPS slave mode, disable the low-pass filter applied to signal quality.
* Navradio: fix regression and optimize older code. Fix a little regression introduced in previous commit. Add: changing the standby frequency disabled the low-pass filter for the next call to updateReceiver(); this must happen when the selected frequency is changed but not when the standby frequency is changed.
* AP input: add property-path support to Inputs. Allow making the AP source indirect (via a string property), so that the actual source property can be configured or adjusted from a -set.xml, or at runtime.
* Replace displaying in Launcher `--on-ground=false` to `--in-air` for on final. The option`--on-ground=false` doesn't exist which can be misleading.

== 2020.3.18 ==

* Added photoscenery capability.
* New basic autopilot system.
* Fix crash with a 'between' type constraint in Navigraph procedure files

== 2020.3.19 ==
* Add AI submodel collision
* Fix crash with invalid METAR strings
* Fix rendering bug where OSM buildings appeared blue under certain graphics settings

== References ==
{{Appendix}}

[[Category:FlightGear changelogs‎]]
[[pl:Changelog_2020.3]]
[[Zh:2020.3]]

User:Ranguli

2024-09-22T11:41:10Z

Ranguli:

Hi there,

I'm a fan of Flight Gear and have joined the Wiki to tidy things up as I come across them. If I don't fix them then and there on the spot, they'll go into the list below.

Cheers,

[[User:Ranguli|Ranguli]] ([[User talk:Ranguli|talk]]) 10:30, 20 August 2020 (EDT)

This is a list of pull requests and bug reports / code tickets I've filed in order to keep track of what I'm working on as well as the status of bugs.

== Merge Requests ==
{| class="wikitable"
|+
!Progress
!Merge Request
!Date Created
!Repository
!Ticket
!Title
!Status
|-
|{{Progressbar|percentage=100}}
|#331
|Sept. 6th 2024
|FGData
|{{Ticket|2913}}
|Fix OSM imagery in the canvas map (fixes #2912)
|Merged without changes
|-
|{{Progressbar|percentage=80}}
|#332
|Sept. 6th 2024
|FGData
|{{Ticket|2913}}
|Remove OpenAIP map support from Canvas Map
|Blocked, awaiting review from FG1000 maintainer
|-
|{{Progressbar|percentage=100}}
|#333
|Sept. 7th 2024
|FGData
|{{Ticket|2913}}
|Fix or remove broken Phi map layers
|Merged without changes
|}

== Bug Reports ==
{| class="wikitable"
|+
!Bug Report
!Date Created
!Title
!Status
!Remarks
!Assignee
|-
|{{Issue|2917}}
|Sept. 7th 2024
|Saitek Pro rudder pedals not working on next branch
|Limbo (Sept. 16th 2024)
|
|No-one, waiting for a reply from<code>jsb1658</code>
|-
|{{Issue|2916}}
|Sept. 7th 2024
|Missing Qt dependency should be caught at compile-time instead of run-time
|
|
|
|-
|{{Ticket|2914}}
|Sept. 5th 2024
|Auto-hide menu bar requires mouse click to hide
|Unacknowledged. This may become irrelevant with the migration away from PUI.
|
|No-one
|-
|{{Ticket|2913}}
|Sept. 5th 2024
|Breaking OpenAIP API changes causing issues in Canvas Map and Phi
|I made PRs to fix the bugs. Two are merged, one is blocked awaiting review from the FG1000 maintainer.
|
|
|}

== Plan ==
Some hypothetical or experimental development ideas for improving flightgear:

- Port the launcher to Qt 6

- Work on Nasal intepreter, Nasal specification, grammar, and tooling

- Migrate simgear and flightgear to use vcpkg instead of dlls from a repo

== Wikipedia Contributions ==
=== House-keeping ===

# {{progressbar|100}} Update the article on the [[AC3D_file_format]]
# {{progressbar|100}} Mark [[FG_Interface_schematics_and_PCBs]] incomplete
# {{progressbar|100}} Mark [[Deperdussin_Monocoque]] as stub
# {{progressbar|100}} Mark [[Schleicher_ASK_13]] as stub
# {{progressbar|100}} Cleanup [[Technik_Museum_Speyer]]
# {{progressbar|100}} Cleanup [[ATR_72-500]]
# {{progressbar|100}} Cleanup [[Blender]]
# {{progressbar|70}} Cleanup [[AC3D]] needs software infobox
# {{progressbar|50}} Cleanup of [[Flying_Warbirds]]
# {{progressbar|50}} Cleanup [[Altitude]]
# {{progressbar|10}} Flesh out [[QNH]]
# {{progressbar|0}} Mark [[KFreeFlight]] as abandoned/old
# {{progressbar|0}} Cleanup of [[Flight_rules]]
# {{progressbar|0}} Cleanup [[Aircraft_information_resources]]
# {{progressbar|0}} Cleanup [[Avionics_Development_Resources]]
# {{progressbar|0}} Cleanup [[Aircraft_Manuals]]
# {{progressbar|0}} [[SVG]] fix quote syntax
# {{progressbar|0}} [[Kelpie_Flight_Planner]] needs software infobox

=== Screenshot Improvements ===
Quite a number of articles have screenshots which are 10 years old or more! While their historical staying power is impressive, their lower resolution and old graphics don't quite live up to modern expectations. Here are some articles I intend to take better screenshots for:

# {{progressbar|0}} [[Flying_Warbirds]]

== Larger Projects ==
# {{progressbar|100}} Rewrite [[Mailing lists]] article
# {{progressbar|50}} [[Howto:Working_with_the_AC3D_file_format_in_Blender]] This article needs new sections about exporting, saving, caveats, etc.
# {{progressbar|0}} [[User:Ranguli/List of file formats]] This article needs a good deal of cleanup, but could also be a ton of work depending on how far I'd want to take documenting file formats used by FlightGear.
# {{progressbar|0}} [[Howto:Edit_a_livery]] unfortunately this article is really a "How to draw an owl" type of tutorial, and was of no use to me while trying to learn how to work with liveries. Once I get a better understanding of the concepts personally I'd like to redo this from the ground up.
# FlightGear Academy articles that need heavy reformatting:
## {{progressbar|100}} [[Normal_Landing]]
## {{progressbar|0}} [[Emergency_Approach]]
## {{progressbar|0}} [[Emergency_Descent]]
## {{progressbar|0}} [[S-Turns]]
## {{progressbar|0}} [[Go_Around]]
## {{progressbar|0}} [[Rectangular_Course]]
## {{progressbar|0}} [[Turns_About_a_Point]]
## {{progressbar|0}} [[Take_Off]]
## {{progressbar|0}} [[Stalls_and_Spin_Awareness]]
## {{progressbar|0}} [[Soft_Field_Landing]]
## {{progressbar|0}} [[Slow_Flight_(Minimum_Controllable_Airspeed)]]
## {{progressbar|0}} [[Short_Field_Landing]]
# {{progressbar|0}} [[JSBSim_Commander]] add software infobox and mark as abandoned
# {{progressbar|0}} [[Conversion]] add some tables, formulas, rename to Aeronautical conversions
# {{progressbar|0}} [[Airports.txt]]
# {{progressbar|0}} [[Howto:Create_WebPanel_instrument]]

== Building FlightGear (WIP Article) ==

== Why this article exists (and why good build documentation is paramount) ==
The long-term health and growth of open-source projects is directly tied to the size and quality of the community that is built around it. One of the most important groups of people within these communities are developers. Developers are like the worker bees of a bee colony, and are the lifeblood of a project. Much like the world-wide shortage of bees, there are more open-source projects needing help than there are developers to help them. So it stands to reason that it is in any open-source projects best interest to retain the developers that take an interest in the project. The art of making developers lives easier is called '''developer experience''' (DX), and projects may live or die by it, with or without knowing it was a factor. Quite simply, developers who have a bad experience with a project will not contribute. Can you blame them?

The first place a developer is liable to have a bad experience with a project (and then move on) is when they first come face to face with documentation. The first impression a developer will get of a project will be from its README or equivalent documentation, particularly, the instructions for '''building the software'''. Many a developer has been eager to contribute to a project only to find a lack of documentation, and (rightfully so), moved on to other, less frustrating pursuits in the open-source world.

There are three guiding principles for not sending developers for the hills:

# There is '''one''' way to build the project, using '''one''' build system, following '''one''' set of instructions, that are easy to follow and consist of only a few steps
# The build process, code quality, and quality of documentation all work together to provide a '''low-friction''', '''low barrier to entry''' for '''new contributors'''.
# If a developer has a bad experience, '''that is a bug.'''

== Building FlightGear on Ubuntu and derivatives ==
FlightGear requires a large number of dependencies to build. In a terminal, you can install all necessary dependencies by using the following command:

== Building SimGear ==
{| class="wikitable"
|+
!Dependency
!Ubuntu 22.04
!Ubuntu 24.04
|-
|Boost
|libboost1.74-dev
|libboost1.83-dev
|-
|Open Audio Library (OpenAL)
|libopenal-dev
| -
|-
|OpenSceneGraph (OSG)
|libopenscenegraph-dev
| -
|-
|liblzma
|liblzma-dev
| -
|}

24.04LTS
sudo apt install git gcc g++ build-essential cmake

22.04LTSFlightGear also has a dependency on another part of the FlightGear project, [[SimGear]]. So in order to build FlightGear we must first build SimGear.

Obtain the SimGear source code by cloning from [[Git]]:
git clone <nowiki>https://git.code.sf.net/p/flightgear/simgear</nowiki> flightgear-simgear
Next, follow the standard procedure for building a CMake project:
cd flightgear-simgear

mkdir build && cd build

cmake .. -DCMAKE_BUILD_TYPE=Release

make -jX # Where X is the number of cores on your system

sudo make install

== Building FlightGear ==
DRAFT
{| class="wikitable"
!Dependency
!Hard dependency?
!Required for
!Ubuntu 22.04
!Ubuntu 24.04
|-
|libplib
|Yes
|Legacy joystick support
|<code>libplib-dev</code>
| -
|-
|libudev
|Yes
|Peripheral / input support
|<code>libudev-dev</code>
| -
|-
|Qt 5 Base
|Yes
|Building FlightGear GUI launcher
|<code>qtbase5-dev</code>
| -
|-
|Qt 5 SVG
|Yes
|Building FlightGear GUI launcher
|<code>libqt5svg5-dev</code>
| -
|-
|Qt 5 Declarative
|Yes
|Building FlightGear GUI launcher
|<code>qtdeclarative5-dev</code>
|
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev-tools, qttools5-dev</code>
| -
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev</code>
|
|-
|Qt 5 Quick
|Maybe
|Building FlightGear GUI launcher
|<code>qtquickcontrols2-5-dev</code>, <code>qml-module-qtquick2</code>
|
|-
|Qt 5 QML
|Maybe
|Building FlightGear GUI launcher
|<code>qml-module-qtquick-controls2</code>
|
|-
|libevent
|No
|[https://swift-project.org/# Swift] client support
|libevent-dev
| -
|-
|zlib
|Yes
|File compression/decompression
|<code>zlib1g-dev</code>
|
|-
|dbus
|No
|[https://swift-project.org/# Swift] client support
|<code>libdbus-1-dev</code>
| -
|-
|OpenXR
|No
|Virtual Reality (VR) support
|<code>libopenxr-dev</code>
| -
|}

qml-module-qtquick2

<code>sudo apt install libplib-dev libudev-dev qtbase5-dev libqt5svg5-dev qtdeclarative5-dev qttools5-dev-tools qttools5-dev libevent-devlibdbus-1-dev libopenxr-dev</code>

libavformat-dev libavutil-dev libswscale-dev libavfilter-dev libavdevice-dev

libcurl4-openssl-dev libavcodec-dev

== Other notes ==
# [https://web.archive.org/web/20170118212558/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Checklist/TM_1-1520-240-CL.pdf Chinook Operators Checklist TM 1-1520-240-CL]
# Incredibly useful, Chinook CH-47D manual: [https://web.archive.org/web/20170118213215/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Manual/TM_1-1520-240-10.pdf Chinook Operators Manual TM 1-1520-240-10]
# [https://web.archive.org/web/20170118215340/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Maintenance_Test_Flight_Manual/TM_1-1520-240-MTF.pdf Chinook Maintenance Test Flight Manual TM 1-1520-240-MTF]

Ranguli/Nasal Linter

2024-09-16T13:58:40Z

Ranguli: Created page with "== List of things that a Nasal linter should address: == - Global variables that could be locally scoped insteadh <code>return</code> statement outside of a code block - Empty code blocks inside of <code>if</code>, <code>elsif</code> <code>else,</code> <code>while,</code> <code>for</code> statements, as well as empty functions. - Certain statements that don't actually do anything: x; x == x; - Variables that are re-declared in the same scope - Variables that..."

== List of things that a Nasal linter should address: ==

- Global variables that could be locally scoped insteadh

<code>return</code> statement outside of a code block

- Empty code blocks inside of <code>if</code>, <code>elsif</code> <code>else,</code> <code>while,</code> <code>for</code> statements, as well as empty functions.

- Certain statements that don't actually do anything:
x;
x == x;

- Variables that are re-declared in the same scope

- Variables that are unused

- Variables that are used but not declared.

- Disallow automatic semi-colon insertion:
x = func(y) {
y = y + 1;
return # It's legal but bug-prone to leave a semi-colon off of the last line in a code block
}
- Too many function arguments

User:Ranguli

2024-09-16T13:36:45Z

Ranguli:

Hi there,

I'm a fan of Flight Gear and have joined the Wiki to tidy things up as I come across them. If I don't fix them then and there on the spot, they'll go into the list below.

Cheers,

[[User:Ranguli|Ranguli]] ([[User talk:Ranguli|talk]]) 10:30, 20 August 2020 (EDT)

This is a list of pull requests and bug reports / code tickets I've filed in order to keep track of what I'm working on as well as the status of bugs.

== Merge Requests ==
{| class="wikitable"
|+
!Progress
!Merge Request
!Date Created
!Repository
!Ticket
!Title
!Status
|-
|{{Progressbar|percentage=100}}
|#331
|Sept. 6th 2024
|FGData
|{{Ticket|2913}}
|Fix OSM imagery in the canvas map (fixes #2912)
|Merged without changes
|-
|{{Progressbar|percentage=80}}
|#332
|Sept. 6th 2024
|FGData
|{{Ticket|2913}}
|Remove OpenAIP map support from Canvas Map
|Blocked, awaiting review from FG1000 maintainer
|-
|{{Progressbar|percentage=100}}
|#333
|Sept. 7th 2024
|FGData
|{{Ticket|2913}}
|Fix or remove broken Phi map layers
|Merged without changes
|}

== Bug Reports ==
{| class="wikitable"
|+
!Bug Report
!Date Created
!Title
!Status
!Remarks
!Assignee
|-
|{{Issue|2917}}
|Sept. 7th 2024
|Saitek Pro rudder pedals not working on next branch
|Limbo (Sept. 16th 2024)
|
|No-one, waiting for a reply from<code>jsb1658</code>
|-
|{{Issue|2916}}
|Sept. 7th 2024
|Missing Qt dependency should be caught at compile-time instead of run-time
|
|
|
|-
|{{Ticket|2914}}
|Sept. 5th 2024
|Auto-hide menu bar requires mouse click to hide
|Unacknowledged. This may become irrelevant with the migration away from PUI.
|
|No-one
|-
|{{Ticket|2913}}
|Sept. 5th 2024
|Breaking OpenAIP API changes causing issues in Canvas Map and Phi
|I made PRs to fix the bugs. Two are merged, one is blocked awaiting review from the FG1000 maintainer.
|
|
|}

== Plan ==
Some hypothetical or experimental development ideas for improving flightgear:

- Port the launcher to Qt 6

- Work on Nasal intepreter, Nasal specification, grammar, and tooling

- Migrate simgear and flightgear to use vcpkg instead of dlls from a repo

== Wikipedia Contributions ==
=== House-keeping ===

# {{progressbar|100}} Update the article on the [[AC3D_file_format]]
# {{progressbar|100}} Mark [[FG_Interface_schematics_and_PCBs]] incomplete
# {{progressbar|100}} Mark [[Deperdussin_Monocoque]] as stub
# {{progressbar|100}} Mark [[Schleicher_ASK_13]] as stub
# {{progressbar|100}} Cleanup [[Technik_Museum_Speyer]]
# {{progressbar|100}} Cleanup [[ATR_72-500]]
# {{progressbar|100}} Cleanup [[Blender]]
# {{progressbar|70}} Cleanup [[AC3D]] needs software infobox
# {{progressbar|50}} Cleanup of [[Flying_Warbirds]]
# {{progressbar|50}} Cleanup [[Altitude]]
# {{progressbar|10}} Flesh out [[QNH]]
# {{progressbar|0}} Mark [[KFreeFlight]] as abandoned/old
# {{progressbar|0}} Cleanup of [[Flight_rules]]
# {{progressbar|0}} Cleanup [[Aircraft_information_resources]]
# {{progressbar|0}} Cleanup [[Avionics_Development_Resources]]
# {{progressbar|0}} Cleanup [[Aircraft_Manuals]]
# {{progressbar|0}} [[SVG]] fix quote syntax
# {{progressbar|0}} [[Kelpie_Flight_Planner]] needs software infobox

=== Screenshot Improvements ===
Quite a number of articles have screenshots which are 10 years old or more! While their historical staying power is impressive, their lower resolution and old graphics don't quite live up to modern expectations. Here are some articles I intend to take better screenshots for:

# {{progressbar|0}} [[Flying_Warbirds]]

== Larger Projects ==
# {{progressbar|100}} Rewrite [[Mailing lists]] article
# {{progressbar|50}} [[Howto:Working_with_the_AC3D_file_format_in_Blender]] This article needs new sections about exporting, saving, caveats, etc.
# {{progressbar|0}} [[User:Ranguli/List of file formats]] This article needs a good deal of cleanup, but could also be a ton of work depending on how far I'd want to take documenting file formats used by FlightGear.
# {{progressbar|0}} [[Howto:Edit_a_livery]] unfortunately this article is really a "How to draw an owl" type of tutorial, and was of no use to me while trying to learn how to work with liveries. Once I get a better understanding of the concepts personally I'd like to redo this from the ground up.
# FlightGear Academy articles that need heavy reformatting:
## {{progressbar|100}} [[Normal_Landing]]
## {{progressbar|0}} [[Emergency_Approach]]
## {{progressbar|0}} [[Emergency_Descent]]
## {{progressbar|0}} [[S-Turns]]
## {{progressbar|0}} [[Go_Around]]
## {{progressbar|0}} [[Rectangular_Course]]
## {{progressbar|0}} [[Turns_About_a_Point]]
## {{progressbar|0}} [[Take_Off]]
## {{progressbar|0}} [[Stalls_and_Spin_Awareness]]
## {{progressbar|0}} [[Soft_Field_Landing]]
## {{progressbar|0}} [[Slow_Flight_(Minimum_Controllable_Airspeed)]]
## {{progressbar|0}} [[Short_Field_Landing]]
# {{progressbar|0}} [[JSBSim_Commander]] add software infobox and mark as abandoned
# {{progressbar|0}} [[Conversion]] add some tables, formulas, rename to Aeronautical conversions
# {{progressbar|0}} [[Airports.txt]]
# {{progressbar|0}} [[Howto:Create_WebPanel_instrument]]

== Building FlightGear (WIP Article) ==

== Why this article exists (and why good build documentation is paramount) ==
The long-term health and growth of open-source projects is directly tied to the size and quality of the community that is built around it. One of the most important groups of people within these communities are developers. Developers are like the worker bees of a bee colony, and are the lifeblood of a project. Much like the world-wide shortage of bees, there are more open-source projects needing help than there are developers to help them. So it stands to reason that it is in any open-source projects best interest to retain the developers that take an interest in the project. The art of making developers lives easier is called '''developer experience''' (DX), and projects may live or die by it, with or without knowing it was a factor. Quite simply, developers who have a bad experience with a project will not contribute. Can you blame them?

The first place a developer is liable to have a bad experience with a project (and then move on) is when they first come face to face with documentation. The first impression a developer will get of a project will be from its README or equivalent documentation, particularly, the instructions for '''building the software'''. Many a developer has been eager to contribute to a project only to find a lack of documentation, and (rightfully so), moved on to other, less frustrating pursuits in the open-source world.

There are three guiding principles for not sending developers for the hills:

# There is '''one''' way to build the project, using '''one''' build system, following '''one''' set of instructions, that are easy to follow and consist of only a few steps
# The build process, code quality, and quality of documentation all work together to provide a '''low-friction''', '''low barrier to entry''' for '''new contributors'''.
# If a developer has a bad experience, '''that is a bug.'''

== Building FlightGear on Ubuntu and derivatives ==
FlightGear requires a large number of dependencies to build. In a terminal, you can install all necessary dependencies by using the following command:

== Building SimGear ==
{| class="wikitable"
|+
!Dependency
!Ubuntu 22.04
!Ubuntu 24.04
|-
|Boost
|libboost1.74-dev
|libboost1.83-dev
|-
|Open Audio Library (OpenAL)
|libopenal-dev
| -
|-
|OpenSceneGraph (OSG)
|libopenscenegraph-dev
| -
|-
|liblzma
|liblzma-dev
| -
|}

24.04LTS
sudo apt install git gcc g++ build-essential cmake

22.04LTSFlightGear also has a dependency on another part of the FlightGear project, [[SimGear]]. So in order to build FlightGear we must first build SimGear.

Obtain the SimGear source code by cloning from [[Git]]:
git clone <nowiki>https://git.code.sf.net/p/flightgear/simgear</nowiki> flightgear-simgear
Next, follow the standard procedure for building a CMake project:
cd flightgear-simgear

mkdir build && cd build

cmake .. -DCMAKE_BUILD_TYPE=Release

make -jX # Where X is the number of cores on your system

sudo make install

== Building FlightGear ==
DRAFT
{| class="wikitable"
!Dependency
!Hard dependency?
!Required for
!Ubuntu 22.04
!Ubuntu 24.04
|-
|libplib
|Yes
|Legacy joystick support
|<code>libplib-dev</code>
| -
|-
|libudev
|Yes
|Peripheral / input support
|<code>libudev-dev</code>
| -
|-
|Qt 5 Base
|Yes
|Building FlightGear GUI launcher
|<code>qtbase5-dev</code>
| -
|-
|Qt 5 SVG
|Yes
|Building FlightGear GUI launcher
|<code>libqt5svg5-dev</code>
| -
|-
|Qt 5 Declarative
|Yes
|Building FlightGear GUI launcher
|<code>qtdeclarative5-dev</code>
|
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev-tools, qttools5-dev</code>
| -
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev</code>
|
|-
|Qt 5 Quick
|Maybe
|Building FlightGear GUI launcher
|<code>qtquickcontrols2-5-dev</code>
|
|-
|Qt 5 QML
|Maybe
|Building FlightGear GUI launcher
|<code>qml-module-qtquick-controls2</code>
|
|-
|libevent
|No
|[https://swift-project.org/# Swift] client support
|libevent-dev
| -
|-
|zlib
|Yes
|File compression/decompression
|<code>zlib1g-dev</code>
|
|-
|dbus
|No
|[https://swift-project.org/# Swift] client support
|<code>libdbus-1-dev</code>
| -
|-
|OpenXR
|No
|Virtual Reality (VR) support
|<code>libopenxr-dev</code>
| -
|}

<code>sudo apt install libplib-dev libudev-dev qtbase5-dev libqt5svg5-dev qtdeclarative5-dev qttools5-dev-tools qttools5-dev libevent-devlibdbus-1-dev libopenxr-dev</code>

libavformat-dev libavutil-dev libswscale-dev libavfilter-dev libavdevice-dev

libcurl4-openssl-dev libavcodec-dev

== Other notes ==
# [https://web.archive.org/web/20170118212558/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Checklist/TM_1-1520-240-CL.pdf Chinook Operators Checklist TM 1-1520-240-CL]
# Incredibly useful, Chinook CH-47D manual: [https://web.archive.org/web/20170118213215/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Manual/TM_1-1520-240-10.pdf Chinook Operators Manual TM 1-1520-240-10]
# [https://web.archive.org/web/20170118215340/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Maintenance_Test_Flight_Manual/TM_1-1520-240-MTF.pdf Chinook Maintenance Test Flight Manual TM 1-1520-240-MTF]

User:Ranguli

2024-09-15T16:20:42Z

Ranguli:

Hi there,

I'm a fan of Flight Gear and have joined the Wiki to tidy things up as I come across them. If I don't fix them then and there on the spot, they'll go into the list below.

Cheers,

[[User:Ranguli|Ranguli]] ([[User talk:Ranguli|talk]]) 10:30, 20 August 2020 (EDT)

== Plan ==
Some hypothetical or experimental development ideas for improving flightgear:

- Port the launcher to Qt 6

- Work on Nasal intepreter, Nasal specification, grammar, and tooling

- Migrate simgear and flightgear to use vcpkg instead of dlls from a repo

== Small Projects ==
=== House-keeping ===

# {{progressbar|100}} Update the article on the [[AC3D_file_format]]
# {{progressbar|100}} Mark [[FG_Interface_schematics_and_PCBs]] incomplete
# {{progressbar|100}} Mark [[Deperdussin_Monocoque]] as stub
# {{progressbar|100}} Mark [[Schleicher_ASK_13]] as stub
# {{progressbar|100}} Cleanup [[Technik_Museum_Speyer]]
# {{progressbar|100}} Cleanup [[ATR_72-500]]
# {{progressbar|100}} Cleanup [[Blender]]
# {{progressbar|70}} Cleanup [[AC3D]] needs software infobox
# {{progressbar|50}} Cleanup of [[Flying_Warbirds]]
# {{progressbar|50}} Cleanup [[Altitude]]
# {{progressbar|10}} Flesh out [[QNH]]
# {{progressbar|0}} Mark [[KFreeFlight]] as abandoned/old
# {{progressbar|0}} Cleanup of [[Flight_rules]]
# {{progressbar|0}} Cleanup [[Aircraft_information_resources]]
# {{progressbar|0}} Cleanup [[Avionics_Development_Resources]]
# {{progressbar|0}} Cleanup [[Aircraft_Manuals]]
# {{progressbar|0}} [[SVG]] fix quote syntax
# {{progressbar|0}} [[Kelpie_Flight_Planner]] needs software infobox

=== Screenshot Improvements ===
Quite a number of articles have screenshots which are 10 years old or more! While their historical staying power is impressive, their lower resolution and old graphics don't quite live up to modern expectations. Here are some articles I intend to take better screenshots for:

# {{progressbar|0}} [[Flying_Warbirds]]

== Larger Projects ==
# {{progressbar|100}} Rewrite [[Mailing lists]] article
# {{progressbar|50}} [[Howto:Working_with_the_AC3D_file_format_in_Blender]] This article needs new sections about exporting, saving, caveats, etc.
# {{progressbar|0}} [[User:Ranguli/List of file formats]] This article needs a good deal of cleanup, but could also be a ton of work depending on how far I'd want to take documenting file formats used by FlightGear.
# {{progressbar|0}} [[Howto:Edit_a_livery]] unfortunately this article is really a "How to draw an owl" type of tutorial, and was of no use to me while trying to learn how to work with liveries. Once I get a better understanding of the concepts personally I'd like to redo this from the ground up.
# FlightGear Academy articles that need heavy reformatting:
## {{progressbar|100}} [[Normal_Landing]]
## {{progressbar|0}} [[Emergency_Approach]]
## {{progressbar|0}} [[Emergency_Descent]]
## {{progressbar|0}} [[S-Turns]]
## {{progressbar|0}} [[Go_Around]]
## {{progressbar|0}} [[Rectangular_Course]]
## {{progressbar|0}} [[Turns_About_a_Point]]
## {{progressbar|0}} [[Take_Off]]
## {{progressbar|0}} [[Stalls_and_Spin_Awareness]]
## {{progressbar|0}} [[Soft_Field_Landing]]
## {{progressbar|0}} [[Slow_Flight_(Minimum_Controllable_Airspeed)]]
## {{progressbar|0}} [[Short_Field_Landing]]
# {{progressbar|0}} [[JSBSim_Commander]] add software infobox and mark as abandoned
# {{progressbar|0}} [[Conversion]] add some tables, formulas, rename to Aeronautical conversions
# {{progressbar|0}} [[Airports.txt]]
# {{progressbar|0}} [[Howto:Create_WebPanel_instrument]]

== Building FlightGear (WIP Article) ==

== Why this article exists (and why good build documentation is paramount) ==
The long-term health and growth of open-source projects is directly tied to the size and quality of the community that is built around it. One of the most important groups of people within these communities are developers. Developers are like the worker bees of a bee colony, and are the lifeblood of a project. Much like the world-wide shortage of bees, there are more open-source projects needing help than there are developers to help them. So it stands to reason that it is in any open-source projects best interest to retain the developers that take an interest in the project. The art of making developers lives easier is called '''developer experience''' (DX), and projects may live or die by it, with or without knowing it was a factor. Quite simply, developers who have a bad experience with a project will not contribute. Can you blame them?

The first place a developer is liable to have a bad experience with a project (and then move on) is when they first come face to face with documentation. The first impression a developer will get of a project will be from its README or equivalent documentation, particularly, the instructions for '''building the software'''. Many a developer has been eager to contribute to a project only to find a lack of documentation, and (rightfully so), moved on to other, less frustrating pursuits in the open-source world.

There are three guiding principles for not sending developers for the hills:

# There is '''one''' way to build the project, using '''one''' build system, following '''one''' set of instructions, that are easy to follow and consist of only a few steps
# The build process, code quality, and quality of documentation all work together to provide a '''low-friction''', '''low barrier to entry''' for '''new contributors'''.
# If a developer has a bad experience, '''that is a bug.'''

== Building FlightGear on Ubuntu and derivatives ==
FlightGear requires a large number of dependencies to build. In a terminal, you can install all necessary dependencies by using the following command:

== Building SimGear ==
{| class="wikitable"
|+
!Dependency
!Ubuntu 22.04
!Ubuntu 24.04
|-
|Boost
|libboost1.74-dev
|libboost1.83-dev
|-
|Open Audio Library (OpenAL)
|libopenal-dev
| -
|-
|OpenSceneGraph (OSG)
|libopenscenegraph-dev
| -
|-
|liblzma
|liblzma-dev
| -
|}

24.04LTS
sudo apt install git gcc g++ build-essential cmake

22.04LTSFlightGear also has a dependency on another part of the FlightGear project, [[SimGear]]. So in order to build FlightGear we must first build SimGear.

Obtain the SimGear source code by cloning from [[Git]]:
git clone <nowiki>https://git.code.sf.net/p/flightgear/simgear</nowiki> flightgear-simgear
Next, follow the standard procedure for building a CMake project:
cd flightgear-simgear

mkdir build && cd build

cmake .. -DCMAKE_BUILD_TYPE=Release

make -jX # Where X is the number of cores on your system

sudo make install

== Building FlightGear ==
DRAFT
{| class="wikitable"
!Dependency
!Hard dependency?
!Required for
!Ubuntu 22.04
!Ubuntu 24.04
|-
|libplib
|Yes
|Legacy joystick support
|<code>libplib-dev</code>
| -
|-
|libudev
|Yes
|Peripheral / input support
|<code>libudev-dev</code>
| -
|-
|Qt 5 Base
|Yes
|Building FlightGear GUI launcher
|<code>qtbase5-dev</code>
| -
|-
|Qt 5 SVG
|Yes
|Building FlightGear GUI launcher
|<code>libqt5svg5-dev</code>
| -
|-
|Qt 5 Declarative
|Yes
|Building FlightGear GUI launcher
|<code>qtdeclarative5-dev</code>
|
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev-tools, qttools5-dev</code>
| -
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev</code>
|
|-
|Qt 5 Quick
|Maybe
|Building FlightGear GUI launcher
|<code>qtquickcontrols2-5-dev</code>
|
|-
|Qt 5 QML
|Maybe
|Building FlightGear GUI launcher
|<code>qml-module-qtquick-controls2</code>
|
|-
|libevent
|No
|[https://swift-project.org/# Swift] client support
|libevent-dev
| -
|-
|zlib
|Yes
|File compression/decompression
|<code>zlib1g-dev</code>
|
|-
|dbus
|No
|[https://swift-project.org/# Swift] client support
|<code>libdbus-1-dev</code>
| -
|-
|OpenXR
|No
|Virtual Reality (VR) support
|<code>libopenxr-dev</code>
| -
|}

<code>sudo apt install libplib-dev libudev-dev qtbase5-dev libqt5svg5-dev qtdeclarative5-dev qttools5-dev-tools qttools5-dev libevent-devlibdbus-1-dev libopenxr-dev</code>

libavformat-dev libavutil-dev libswscale-dev libavfilter-dev libavdevice-dev

libcurl4-openssl-dev libavcodec-dev

== Other notes ==
# [https://web.archive.org/web/20170118212558/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Checklist/TM_1-1520-240-CL.pdf Chinook Operators Checklist TM 1-1520-240-CL]
# Incredibly useful, Chinook CH-47D manual: [https://web.archive.org/web/20170118213215/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Manual/TM_1-1520-240-10.pdf Chinook Operators Manual TM 1-1520-240-10]
# [https://web.archive.org/web/20170118215340/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Maintenance_Test_Flight_Manual/TM_1-1520-240-MTF.pdf Chinook Maintenance Test Flight Manual TM 1-1520-240-MTF]

Ranguli/Buildling FlightGear on Windows

2024-09-15T15:25:35Z

Ranguli:

{{Draft}}

== Deficiencies in the current build workflow==
- Reliance on 3rd-party code bundled within the repository (sometimes this is useful for small libraries, especially if they aren't packaged elsewhere, but can quickly get out of hand).

- A major downside of this is that years go by without anyone copy and pasting the new library code into the repository, and the project is built with exceedingly old and likely insecure version of these libraries.

- Reliance on a git repository containing <code>.lib</code> and <code>.dll</code> files (this is icky and makes me cry).

- This has the same downsides as discussed above, but is also a uniquely gross solution given that we're tracking pre-compiled binary objects in a version control system, and using it for distribution and a very weak form of dependency management.

- Reliance on <code>.bat</code> scripts to orchestrate the build system. This really shouldn't be necessary in the large majority of cases if we're doing things correctly.

==What the new vcpkg-based approach solves==
- Developers don't need to clone or install the <code>windows-3rd-party</code> repo, nor do maintainers need to copy/paste new source code and <code>.dll</code> files into that repository periodically

-

==The state of dependencies==
{| class="wikitable"
|+Software dependencies required by SimGear
!
!Available in vcpkg?
!Currently source location on Windows builds
!Currently source location on Linux builds
!Assessment
|-
|boost
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|crashrpt
|Yes, but only for Windows
|From FlightGear's <code>windows-3rd-party</code> repository.
|N/A - Windows-only dependency
|This should be added to vcpkg. We can use a <code>platform</code> constraint so it's only pulled in and built on Windows, as it's a Windows-only library.
|-
|curl
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|dbus
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|easyxml
|No
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|'''Why do we have two XML parsing libraries, neither of which are particularly popular or widely used?'''
|-
|expat
|Yes, for Windows, Linux, and macOS
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|'''Why do we have two XML parsing libraries, neither of which are particularly popular or widely used?'''
|-
|ffmpeg
|Yes, for Windows, Linux, and macOS
|
|System package manager
|Get from vcpkg instead.
|-
|freeglut
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|freetype
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|gexttext-libintl
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|libudns
|Yes, but only for Linux
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|Keep in the SimGear repository
|-
|libevent
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|libjpeg-turbo
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|liblzma
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|libpng
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|libtiff
|No
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Can't migrate to vcpkg
|-
|nlohmann-json
|Yes, for Windows, Linux, and macOS
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|Only used by tinygtlf. We don't need to include or manage this dependency if we migrate tinygltf to vcpkg.
|-
|openal-soft
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|osg
|Yes, for Windows, Linux, and macOS
|
|System package manager
|Get from vcpkg instead.
|-
|plib
|Yes, but only for Windows and Linux
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead. MacOS users will not benefit from this change, but Linux and Windows users will.
|-
|tinygltf
|Yes, for Windows, Linux, and macOS
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|Get from vcpkg instead.
|-
|zlib
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|
|}

==Installing WinGet==
Traditionally, installing software on Windows has required a lot of manual steps (going to a URL, downloading an installer, clicking through all the steps, etc). There are much more modern and ergonomic alternatives available. One of these is WinGet.

==Installing Microsoft Visual Studio 2022==

Lastly, you will prompted to sign in with a Visual Studio account, and then personalize Visual Studio. These options are purely personal preference and won't have a bearing on the build process.

==Installing CMake==
https://cmake.org/download/

Version 3.30.3

Windows will prompt you to confirm you would like to allow the CMake Installation to proceed. Select Yes.

==Installing Qt6==
https://www.qt.io/download-qt-installer-oss

===Selecting components===
- Ensure that CMake is not selected, as we will download CMake ourselves instead of using the bundled version.

Ranguli/Buildling FlightGear on Windows

2024-09-15T14:33:57Z

Ranguli:

{{Draft}}

== Deficiencies in the current build workflow==
- Reliance on 3rd-party code bundled within the repository (sometimes this is useful for small libraries, especially if they aren't packaged elsewhere, but can quickly get out of hand).

- A major downside of this is that years go by without anyone copy and pasting the new library code into the repository, and the project is built with exceedingly old and likely insecure version of these libraries.

- Reliance on a git repository containing <code>.lib</code> and <code>.dll</code> files (this is icky and makes me cry).

- This has the same downsides as discussed above, but is also a uniquely gross solution given that we're tracking pre-compiled binary objects in a version control system, and using it for distribution and a very weak form of dependency management.

- Reliance on <code>.bat</code> scripts to orchestrate the build system. This really shouldn't be necessary in the large majority of cases if we're doing things correctly.

==Advantages of the vcpkg approach==
- The <code>3rd-party-deps</code> repo becomes unnecessary.

- Developers don't have to clone this repo.

- Developers don't have to run any commands or scripts to do the 'installation' of the <code>.dll</code> and <code>.lib</code> files from <code>3rd-party-deps</code>

==The state of dependencies==
{| class="wikitable"
|+Software dependencies required by SimGear
!
!Available in vcpkg?
!Currently source location on Windows builds
!Currently source location on Linux builds
!Assessment
|-
|boost
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|crashrpt
|Yes, but only for Windows
|From FlightGear's <code>windows-3rd-party</code> repository.
|N/A - Windows-only dependency
|This should be added to vcpkg. We can use a <code>platform</code> constraint so it's only pulled in and built on Windows, as it's a Windows-only library.
|-
|curl
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|dbus
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|easyxml
|No
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|'''Why do we have two XML parsing libraries, neither of which are particularly popular or widely used?'''
|-
|expat
|Yes, for Windows, Linux, and macOS
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|'''Why do we have two XML parsing libraries, neither of which are particularly popular or widely used?'''
|-
|ffmpeg
|Yes, for Windows, Linux, and macOS
|
|System package manager
|Get from vcpkg instead.
|-
|freeglut
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|freetype
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|gexttext-libintl
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|libudns
|Yes, but only for Linux
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|Keep in the SimGear repository
|-
|libevent
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|libjpeg-turbo
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|liblzma
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|libpng
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|libtiff
|No
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Can't migrate to vcpkg
|-
|nlohmann-json
|Yes, for Windows, Linux, and macOS
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|Only used by tinygtlf. We don't need to include or manage this dependency if we migrate tinygltf to vcpkg.
|-
|openal-soft
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead.
|-
|osg
|Yes, for Windows, Linux, and macOS
|
|System package manager
|Get from vcpkg instead.
|-
|plib
|Yes, but only for Windows and Linux
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|Get from vcpkg instead. MacOS users will not benefit from this change, but Linux and Windows users will.
|-
|tinygltf
|Yes, for Windows, Linux, and macOS
|Embedded in the <code>SimGear</code> repository
|Embedded in the <code>SimGear</code> repository
|Get from vcpkg instead.
|-
|zlib
|Yes, for Windows, Linux, and macOS
|From FlightGear's <code>windows-3rd-party</code> repository.
|System package manager
|
|}

==Installing WinGet==
Traditionally, installing software on Windows has required a lot of manual steps (going to a URL, downloading an installer, clicking through all the steps, etc). There are much more modern and ergonomic alternatives available. One of these is WinGet.

==Installing Microsoft Visual Studio 2022==

Lastly, you will prompted to sign in with a Visual Studio account, and then personalize Visual Studio. These options are purely personal preference and won't have a bearing on the build process.

==Installing CMake==
https://cmake.org/download/

Version 3.30.3

Windows will prompt you to confirm you would like to allow the CMake Installation to proceed. Select Yes.

==Installing Qt6==
https://www.qt.io/download-qt-installer-oss

===Selecting components===
- Ensure that CMake is not selected, as we will download CMake ourselves instead of using the bundled version.

Ranguli/Buildling FlightGear on Windows

2024-09-15T13:40:35Z

Ranguli:

Ranguli/Buildling FlightGear on Windows

2024-09-14T14:25:45Z

Ranguli: Created page with "{{Draft}} == Installing WinGet == Traditionally, installing software on Windows has required a lot of manual steps (going to a URL, downloading an installer, clicking through all the steps, etc). There are much more modern and ergonomic alternatives available. One of these is WinGet. == Installing Microsoft Visual Studio 2022 == Lastly, you will prompted to sign in with a Visual Studio account, and then personalize Visual Studio. These options are purely personal pre..."

{{Draft}}

== Installing WinGet ==
Traditionally, installing software on Windows has required a lot of manual steps (going to a URL, downloading an installer, clicking through all the steps, etc). There are much more modern and ergonomic alternatives available. One of these is WinGet.

== Installing Microsoft Visual Studio 2022 ==

Lastly, you will prompted to sign in with a Visual Studio account, and then personalize Visual Studio. These options are purely personal preference and won't have a bearing on the build process.

== Installing CMake ==
https://cmake.org/download/

Version 3.30.3

Windows will prompt you to confirm you would like to allow the CMake Installation to proceed. Select Yes.

== Installing Qt6 ==
https://www.qt.io/download-qt-installer-oss

=== Selecting components ===
- Ensure that CMake is not selected, as we will download CMake ourselves instead of using the bundled version.

User:Ranguli

2024-09-07T17:06:47Z

Ranguli:

Hi there,

I'm a fan of Flight Gear and have joined the Wiki to tidy things up as I come across them. If I don't fix them then and there on the spot, they'll go into the list below.

Cheers,

[[User:Ranguli|Ranguli]] ([[User talk:Ranguli|talk]]) 10:30, 20 August 2020 (EDT)

== Small Projects ==
=== House-keeping ===

# {{progressbar|100}} Update the article on the [[AC3D_file_format]]
# {{progressbar|100}} Mark [[FG_Interface_schematics_and_PCBs]] incomplete
# {{progressbar|100}} Mark [[Deperdussin_Monocoque]] as stub
# {{progressbar|100}} Mark [[Schleicher_ASK_13]] as stub
# {{progressbar|100}} Cleanup [[Technik_Museum_Speyer]]
# {{progressbar|100}} Cleanup [[ATR_72-500]]
# {{progressbar|100}} Cleanup [[Blender]]
# {{progressbar|70}} Cleanup [[AC3D]] needs software infobox
# {{progressbar|50}} Cleanup of [[Flying_Warbirds]]
# {{progressbar|50}} Cleanup [[Altitude]]
# {{progressbar|10}} Flesh out [[QNH]]
# {{progressbar|0}} Mark [[KFreeFlight]] as abandoned/old
# {{progressbar|0}} Cleanup of [[Flight_rules]]
# {{progressbar|0}} Cleanup [[Aircraft_information_resources]]
# {{progressbar|0}} Cleanup [[Avionics_Development_Resources]]
# {{progressbar|0}} Cleanup [[Aircraft_Manuals]]
# {{progressbar|0}} [[SVG]] fix quote syntax
# {{progressbar|0}} [[Kelpie_Flight_Planner]] needs software infobox

=== Screenshot Improvements ===
Quite a number of articles have screenshots which are 10 years old or more! While their historical staying power is impressive, their lower resolution and old graphics don't quite live up to modern expectations. Here are some articles I intend to take better screenshots for:

# {{progressbar|0}} [[Flying_Warbirds]]

== Larger Projects ==
# {{progressbar|100}} Rewrite [[Mailing lists]] article
# {{progressbar|50}} [[Howto:Working_with_the_AC3D_file_format_in_Blender]] This article needs new sections about exporting, saving, caveats, etc.
# {{progressbar|0}} [[User:Ranguli/List of file formats]] This article needs a good deal of cleanup, but could also be a ton of work depending on how far I'd want to take documenting file formats used by FlightGear.
# {{progressbar|0}} [[Howto:Edit_a_livery]] unfortunately this article is really a "How to draw an owl" type of tutorial, and was of no use to me while trying to learn how to work with liveries. Once I get a better understanding of the concepts personally I'd like to redo this from the ground up.
# FlightGear Academy articles that need heavy reformatting:
## {{progressbar|100}} [[Normal_Landing]]
## {{progressbar|0}} [[Emergency_Approach]]
## {{progressbar|0}} [[Emergency_Descent]]
## {{progressbar|0}} [[S-Turns]]
## {{progressbar|0}} [[Go_Around]]
## {{progressbar|0}} [[Rectangular_Course]]
## {{progressbar|0}} [[Turns_About_a_Point]]
## {{progressbar|0}} [[Take_Off]]
## {{progressbar|0}} [[Stalls_and_Spin_Awareness]]
## {{progressbar|0}} [[Soft_Field_Landing]]
## {{progressbar|0}} [[Slow_Flight_(Minimum_Controllable_Airspeed)]]
## {{progressbar|0}} [[Short_Field_Landing]]
# {{progressbar|0}} [[JSBSim_Commander]] add software infobox and mark as abandoned
# {{progressbar|0}} [[Conversion]] add some tables, formulas, rename to Aeronautical conversions
# {{progressbar|0}} [[Airports.txt]]
# {{progressbar|0}} [[Howto:Create_WebPanel_instrument]]

== Building FlightGear (WIP Article) ==

== Why this article exists (and why good build documentation is paramount) ==
The long-term health and growth of open-source projects is directly tied to the size and quality of the community that is built around it. One of the most important groups of people within these communities are developers. Developers are like the worker bees of a bee colony, and are the lifeblood of a project. Much like the world-wide shortage of bees, there are more open-source projects needing help than there are developers to help them. So it stands to reason that it is in any open-source projects best interest to retain the developers that take an interest in the project. The art of making developers lives easier is called '''developer experience''' (DX), and projects may live or die by it, with or without knowing it was a factor. Quite simply, developers who have a bad experience with a project will not contribute. Can you blame them?

The first place a developer is liable to have a bad experience with a project (and then move on) is when they first come face to face with documentation. The first impression a developer will get of a project will be from its README or equivalent documentation, particularly, the instructions for '''building the software'''. Many a developer has been eager to contribute to a project only to find a lack of documentation, and (rightfully so), moved on to other, less frustrating pursuits in the open-source world.

There are three guiding principles for not sending developers for the hills:

# There is '''one''' way to build the project, using '''one''' build system, following '''one''' set of instructions, that are easy to follow and consist of only a few steps
# The build process, code quality, and quality of documentation all work together to provide a '''low-friction''', '''low barrier to entry''' for '''new contributors'''.
# If a developer has a bad experience, '''that is a bug.'''

== Building FlightGear on Ubuntu and derivatives ==
FlightGear requires a large number of dependencies to build. In a terminal, you can install all necessary dependencies by using the following command:

== Building SimGear ==
{| class="wikitable"
|+
!Dependency
!Ubuntu 22.04
!Ubuntu 24.04
|-
|Boost
|libboost1.74-dev
|libboost1.83-dev
|-
|Open Audio Library (OpenAL)
|libopenal-dev
| -
|-
|OpenSceneGraph (OSG)
|libopenscenegraph-dev
| -
|-
|liblzma
|liblzma-dev
| -
|}

24.04LTS
sudo apt install git gcc g++ build-essential cmake

22.04LTSFlightGear also has a dependency on another part of the FlightGear project, [[SimGear]]. So in order to build FlightGear we must first build SimGear.

Obtain the SimGear source code by cloning from [[Git]]:
git clone <nowiki>https://git.code.sf.net/p/flightgear/simgear</nowiki> flightgear-simgear
Next, follow the standard procedure for building a CMake project:
cd flightgear-simgear

mkdir build && cd build

cmake .. -DCMAKE_BUILD_TYPE=Release

make -jX # Where X is the number of cores on your system

sudo make install

== Building FlightGear ==
DRAFT
{| class="wikitable"
!Dependency
!Hard dependency?
!Required for
!Ubuntu 22.04
!Ubuntu 24.04
|-
|libplib
|Yes
|Legacy joystick support
|<code>libplib-dev</code>
| -
|-
|libudev
|Yes
|Peripheral / input support
|<code>libudev-dev</code>
| -
|-
|Qt 5 Base
|Yes
|Building FlightGear GUI launcher
|<code>qtbase5-dev</code>
| -
|-
|Qt 5 SVG
|Yes
|Building FlightGear GUI launcher
|<code>libqt5svg5-dev</code>
| -
|-
|Qt 5 Declarative
|Yes
|Building FlightGear GUI launcher
|<code>qtdeclarative5-dev</code>
|
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev-tools, qttools5-dev</code>
| -
|-
|Qt 5 Tools
|Yes
|Building FlightGear GUI launcher
|<code>qttools5-dev</code>
|
|-
|Qt 5 Quick
|Maybe
|Building FlightGear GUI launcher
|<code>qtquickcontrols2-5-dev</code>
|
|-
|Qt 5 QML
|Maybe
|Building FlightGear GUI launcher
|<code>qml-module-qtquick-controls2</code>
|
|-
|libevent
|No
|[https://swift-project.org/# Swift] client support
|libevent-dev
| -
|-
|zlib
|Yes
|File compression/decompression
|<code>zlib1g-dev</code>
|
|-
|dbus
|No
|[https://swift-project.org/# Swift] client support
|<code>libdbus-1-dev</code>
| -
|-
|OpenXR
|No
|Virtual Reality (VR) support
|<code>libopenxr-dev</code>
| -
|}

<code>sudo apt install libplib-dev libudev-dev qtbase5-dev libqt5svg5-dev qtdeclarative5-dev qttools5-dev-tools qttools5-dev libevent-devlibdbus-1-dev libopenxr-dev</code>

libavformat-dev libavutil-dev libswscale-dev libavfilter-dev libavdevice-dev

libcurl4-openssl-dev libavcodec-dev

== Other notes ==
# [https://web.archive.org/web/20170118212558/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Checklist/TM_1-1520-240-CL.pdf Chinook Operators Checklist TM 1-1520-240-CL]
# Incredibly useful, Chinook CH-47D manual: [https://web.archive.org/web/20170118213215/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Operators_Manual/TM_1-1520-240-10.pdf Chinook Operators Manual TM 1-1520-240-10]
# [https://web.archive.org/web/20170118215340/http://www.chinook-helicopter.com/Publications/CH-47D_Technical_Publications/Maintenance_Test_Flight_Manual/TM_1-1520-240-MTF.pdf Chinook Maintenance Test Flight Manual TM 1-1520-240-MTF]

User:Ranguli

2024-09-05T22:25:02Z

Ranguli:

User:Ranguli

2024-09-05T20:34:05Z

Ranguli:

Howto:Working with FlightGear models in Blender

2024-09-04T17:23:40Z

Ranguli:

{{Stub}}{{WIP|In progress as of Sept 4th, 2024}}
FlightGear uses the [[AC3D file format]] for its models. AC3D files are denoted by the <code>.ac</code> file extension. It is a niche legacy format native to the [[AC3D]] modelling software, and its adoption is not widespread in computer graphics (being used mainly by X-Plane<ref>[https://en.wikipedia.org/wiki/AC3D]</ref> and FlightGear). This lead to support for the format eventually being removed from Blender. In order to work with models in the AC3D format in Blender, and thus do any modelling work for the FlightGear project, the use of an add-on is required.

== Installing the Blender add-on for AC3D models ==
{{Warning|While Blender offers an "Install From File" option to simplify the installation of add-ons, it is not supported by Blender-AC3D and should not be used.}}
The [https://github.com/NikolaiVChr/Blender-AC3D Blender-AC3D] add-on is one such add-on that allows AC3D models to be used in Blender. It is an open-source project licensed under the [[GNU GPL]]. It is hosted on [[Github|GitHub]], and it can be accessed here: [https://github.com/NikolaiVChr/Blender-AC3D Blender-AC3D].
To install the Blender-AC3D add-on, you must complete the following steps:

# Identify the version of Blender you are using. This can be done by simply opening Blender, and checking the version number in the top-right corner of the startup / splash screen:[[File:Blender_Startup_Screen.png|alt=Determining Blender version from the splash screen|none|frame|Determining Blender version from the splash screen]]
# Close Blender.
# Download the correct version of the Blender add-on for your version of Blender. You can download the add-on at: https://github.com/NikolaiVChr/Blender-AC3D
# Once you have downloaded the Blender add-on, extract the <code>.zip</code> file so that you have a folder called <code>io_scene_ac3d</code>.
# Next, you will need to place the add-on (the <code>io_scene_ac3d</code> folder) in the correct directory in order for Blender to be able to load it. It will vary based on platform, where <code>x.x</code> is the version of Blender you are using.
#* For Linux users, the location may be in one of two places. If you installed it through your package manager, it will be the first path. If you installed Blender as a Flatpak, it will be the second path. <code>~/.blender/x.x/scripts/addons</code> <code>~/.var/app/org.blender.Blender/config/blender/x.x/scripts/addons</code>.
#* For Windows users, the location is: <code>C:\Users\yourusername\AppData\Roaming\Blender Foundation\Blender\x.x\scripts\addons</code>
#* For macOS users, the location is: <code>Macintosh HD/Users/yourusername/Library/Application Support/Blender/x.x/scripts/addons</code>
# Re-open Blender.
# Navigate to '''Edit > Preferences''', and select '''Add-ons''' from the side-bar. If you downloaded the correct version of the add-on, and place it in the right location, you should see it in the list of available add-ons.
# Select the checkbox next to '''AC3D (.ac) format''' to enable the plugin. This step is critical, otherwise the add-on won't actually become active.{{Note|The add-on will not be active after installing, you must manually enable it.}}[[File:Enable Blender-AC3D.png|thumb|Selecting Blender-AC3D from the add-ons menu|alt=Selecting Blender-AC3D from the add-ons menu|none|680x680px]]
# Once you have enabled the Blender add-on, restart Blender.

If you have completed the above steps and encountered no error messages, the Blender-AC3D add-on should be correctly installed and enabled, and is ready for use.

== Importing models ==

# Once the add-on is installed, AC3D models can be imported in the same fashion as any model format supported by Blender. To import a model, navigate to '''File > Import > AC3D (.ac)'''{{Note|If you do not see the option to import AC3D models, the add-on either has not been correctly installed, or enabled.}} [[File:Blender AC3D import dialog.png|frameless|546x546px]]
# A file chooser dialog will appear. Select your AC3D (<code>.ac</code> ) file and select '''Import AC3D'''.

{{WIP}}

==Editing models==
Once the model has been successfully imported into Blender using the add-on, the

{{WIP}}

== Configuring accurate model previews ==
{{WIP}}

==Viewing liveries==

Blender can be used as a 'livery viewer' for your FlightGear models.

{{WIP}}

== Exporting models ==
{{Warning|To ensure that models exported from Blender are displayed and function correctly in FlightGear, special steps must be followed.}}[[File:Cessna 172P Model in Blender.png|thumb|Example screenshot demonstrating a Cessna model taken from FlightGear and opened in Blender]]{{WIP}}{{Appendix}}
{{3d}}
[[Category:Modeling]]

File:Enable Blender-AC3D.png

2024-09-04T17:05:48Z

Ranguli: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Screenshot showing Blender-AC3D in the Blender add-ons menu}}
|date=2024-09-04
|source={{own}}
|author=[[User:Ranguli|Ranguli]]
|permission=
|other versions=
}}

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

[[Category:Blender screenshots]]

File:Blender Startup Screen.png

2024-09-04T14:59:46Z

Ranguli: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=The Blender startup screen. The version of Blender is indicated in the top-right corner.}}
|date=2024-09-04
|source={{own}}
|author=[[User:Ranguli|Ranguli]]
|permission=
|other versions=
}}

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

[[Category:Blender screenshots]]

Howto:Working with FlightGear models in Blender

2024-09-04T11:50:56Z

Ranguli: Flesh out article structure

Howto talk:Work with AC3D files in Blender

2024-09-04T11:03:18Z

Ranguli: /* Merging with Howto:Working with FlightGear models in Blender */ new section

== Blender 2.83 LTS support ==
Blender 2.83 LTS is declared to not be supported. What is the issue? I'm using Blender 2.90 successfully.

{{unsigned|19:50, 17 July 2020‎|Scttgs}}

: Correct, i just retried AC3D import with 2.83.2 LTS and indeed it works. Must have been a mistake on my side when setting everything up.
: I've just corrected the page.
: {{unsigned|20:18, 17 July 2020‎|Sfrsfr}}

== Merging with Howto:Working with FlightGear models in Blender ==

I think this article would be good as section under a larger article. It is currently a stub, and would logically fit in an article about part of a larger Howto tutorial that encompasses the entirety of the workflow in Blender. I think it would also be useful to have this information in a single place with one source of truth in order to make it easier to keep the information up to date as Blender versions change. [[User:Ranguli|Ranguli]] ([[User talk:Ranguli|talk]]) 11:03, 4 September 2024 (UTC)

Howto:Working with FlightGear models in Blender

2024-09-04T11:01:26Z

Ranguli: Mark as WIP/stub, as the article is about to be worked on.

{{Stub}}{{WIP|In progress as of Sept 4th, 2024}}

== Importing and exporting models ==

== Editing models ==

== Viewing liveries ==

Blender can be used as a 'livery viewer' for your FlightGear models.

[[File:Cessna 172P Model in Blender.png|thumb|Example screenshot demonstrating a Cessna model taken from FlightGear and opened in Blender]]
[[Category:Howto]]

Howto:Work with AC3D files in Blender

2024-09-04T11:00:26Z

Ranguli: Mark as stub.

{{Stub}}
{{Merge|Howto:Working with FlightGear models in Blender}}

Many [[FlightGear]] [[aircraft]] modellers prefer [[Blender]] as their 3D-modelling editor. Blender is a powerful, robust and open-source 3D modelling suite. FlightGear primarily uses the [[AC3D_file_format|AC3D file format]] (<code>.ac</code>) to model aircraft, [[scenery]] models, and many other things. With the AC3D file format first released in 1996<ref>http://fileformats.archiveteam.org/wiki/AC3D_Model</ref>, modern versions of Blender do not bother maintaining support for the format. However, add-ons exist to extend Blender's functionality in order to allow the import and export of these files.

{{TOC limit|3}}

== Importing and exporting AC3D files ==
{{note| Modern versions of Blender (2.5+) require an add-on to work with AC3D (<code>.ac</code>) files.}}
=== Addons ===

The prominent add-on for using AC3D files in Blender is called ''Blender-AC3D''. It has been forked from its original to provide support for Blender 2.8.

{| class="wikitable"
|-
! Blender version !! Addon !! Remarks
|-
| 4.0 ONLY || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=4.0|text=NikolaiVChr/Blender-AC3D (GitHub)}}. || NikolaiVChr's fork of majic79's add-on, with a special branch for Blender 4.0+
⚠️ WARNING ⚠️ THIS ONLY WORKS FOR BLENDER 4.0 (https://download.blender.org/release/Blender4.0/)
|-
| 3.2 || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=3.2|text=NikolaiVChr/Blender-AC3D (GitHub)}}. || NikolaiVChr's fork of majic79's add-on, with a special branch for Blender 3.2
|-
| 2.80 - 2.90 || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=2.80|text=NikolaiVChr/Blender-AC3D (GitHub)}}. || NikolaiVChr's fork of majic79's add-on, with a special branch for Blender 2.80
|-
| 2.63 - 2.7a || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=master|text=NikolaiVChr/Blender-AC3D (GitHub)}} || NikolaiVChr's fork of majic79's add-on. For more information read {{forum link|t=13442|title=Blender 2.6 AC3D Importer & Exporter}}
|-
| 2.62 || {{github source|proj=majic79|repo=Blender-AC3D|branch=BL2.62|text=majic79/Blender-AC3D (GitHub)}} || Branch of majic79's plugin targeting Blender 2.62 (Abandoned)
|-
| 2.60 || {{github source|proj=majic79|repo=Blender-AC3D|branch=BL2.60|text=majic79/Blender-AC3D (GitHub)}} || Branch of majic79's plugin targeting Blender 2.60 (Abandoned)
|-
| 2.59 || {{github source|proj=majic79|repo=Blender-AC3D|branch=BL2.59|text=majic79/Blender-AC3D (GitHub)}} || Branch of majic79's plugin targeting Blender 2.59 (Abandoned)
|-
| <2.5 || N/A || Versions of Blender below 2.5 include out of the box support for the AC3D file format, simply enable the add-on in <code>Preferences > Addons</code>
|}

==== Notes ====
* Before you export a model with this addon, make sure that you set the UV map and texture inside the material, not just inside the UV editor. See the video tutorial [https://www.youtube.com/watch?v=URMjoFSm5pk here].
* Before you export make sure to exit ''Edit Mode'' or some of your last changes won't be exported.
* Inside Blender when you want to see the textures, be sure to set the shader to GLSL (or for 2.7+ just set view mode to materials). Alternatively set textured solid in solid view.
* To see textured surfaces as they will be shown in FlightGear, go into the material texture and set the blend type to ''Multiply'' instead of the default ''Mix'' (the importer will also do this automatically). An example plane that will look very different if this is not done is the FGAddon aircraft {{fgaddon source|path=Aircraft/ASK13|commit=1363|text=ASK-13}}, notice the wingtips.
* The final model might display color mismatches (Texture color vs Material color) when viewed in Flightgear. Hand editing the [[AC files: Basic changes to textures and colors#Materials|materials]] section of the exported AC3D file might fix this.
* If you wonder where to put the scripts you could open blender's user preferences ({{Key press|Ctrl|Alt|U}}, or ''File > User Preferences'') tick for example Import/Export and extent the information concerning an existing script. Usually this throws the path. For for example Ubuntu 14.04LTS/Blender 2.79b it is: <code>/usr/share/blender/scripts/addons/</code>. In recent Ubuntu versions blender is distributed as a snap image. In such cases blender addon scripts are placed in: <code>$HOME/.config/blender/X.YY/scripts/addons/</code> (where X.YY is blender version, for example 2.82).
* Be aware that Blender only has greyscale for emission and ambient colors. If you want to export/import a color for those, import/export options gives you capability to choose to use Blenders mirror color for that.
* The importer will not fail if it does not locate a texture, instead it will issue warnings. Pull down the top bar to see if there was any, they will be orange lines.
* The exporter will not fail if it tries to save a texture without data, instead it will issue warnings. Pull down the top bar to see if there was any, they will be orange lines. Notice that since AC3D only support 1 texture per object, if multiple textures are attached to an object in Blender the last of the textures that has any data, if any, will be the one that get exported, but it will still warn about the missing data in the others, so take care.
* Orientation: The default settings in the plugin correspond to the FlightGear coordinate system (-X forward and Z up, also see: [[Howto:3D_Aircraft_Models]]). The default settings are: Forward -Z and Up Y.

You can report bugs with the addon [https://github.com/NikolaiVChr/Blender-AC3D/issues here], but please include problematic <code>.ac</code>/<code>.blend</code> files and their textures.

=== Importing ===

{{main article|Working with FlightGear models in Blender}}
{{note|If you do not see the option for <code>AC3D (.ac)</code> under <code>File > Import</code>, your add-on is either not installed, not enabled, or not working correctly.}}
Once the add-on is installed, AC3D models can be imported in the same manner as any other model foramat into Blender by using the <code> File > Import > AC3D (.ac)</code> dialog.
[[File:Blender AC3D import dialog.png|thumb|This figure demonstrates how to import an AC3D model in Blender using a third-party addon.]]

{{Appendix}}
{{3d}}
[[Category:Modeling]]

Howto:Work with AC3D files in Blender

2024-09-04T10:59:18Z

Ranguli: Suggest we merge this article with one main parent article about using Blender with flightgear models

{{Merge|Howto:Working with FlightGear models in Blender}}

Many [[FlightGear]] [[aircraft]] modellers prefer [[Blender]] as their 3D-modelling editor. Blender is a powerful, robust and open-source 3D modelling suite. FlightGear primarily uses the [[AC3D_file_format|AC3D file format]] (<code>.ac</code>) to model aircraft, [[scenery]] models, and many other things. With the AC3D file format first released in 1996<ref>http://fileformats.archiveteam.org/wiki/AC3D_Model</ref>, modern versions of Blender do not bother maintaining support for the format. However, add-ons exist to extend Blender's functionality in order to allow the import and export of these files.

{{TOC limit|3}}

== Importing and exporting AC3D files ==
{{note| Modern versions of Blender (2.5+) require an add-on to work with AC3D (<code>.ac</code>) files.}}
=== Addons ===

The prominent add-on for using AC3D files in Blender is called ''Blender-AC3D''. It has been forked from its original to provide support for Blender 2.8.

{| class="wikitable"
|-
! Blender version !! Addon !! Remarks
|-
| 4.0 ONLY || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=4.0|text=NikolaiVChr/Blender-AC3D (GitHub)}}. || NikolaiVChr's fork of majic79's add-on, with a special branch for Blender 4.0+
⚠️ WARNING ⚠️ THIS ONLY WORKS FOR BLENDER 4.0 (https://download.blender.org/release/Blender4.0/)
|-
| 3.2 || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=3.2|text=NikolaiVChr/Blender-AC3D (GitHub)}}. || NikolaiVChr's fork of majic79's add-on, with a special branch for Blender 3.2
|-
| 2.80 - 2.90 || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=2.80|text=NikolaiVChr/Blender-AC3D (GitHub)}}. || NikolaiVChr's fork of majic79's add-on, with a special branch for Blender 2.80
|-
| 2.63 - 2.7a || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=master|text=NikolaiVChr/Blender-AC3D (GitHub)}} || NikolaiVChr's fork of majic79's add-on. For more information read {{forum link|t=13442|title=Blender 2.6 AC3D Importer & Exporter}}
|-
| 2.62 || {{github source|proj=majic79|repo=Blender-AC3D|branch=BL2.62|text=majic79/Blender-AC3D (GitHub)}} || Branch of majic79's plugin targeting Blender 2.62 (Abandoned)
|-
| 2.60 || {{github source|proj=majic79|repo=Blender-AC3D|branch=BL2.60|text=majic79/Blender-AC3D (GitHub)}} || Branch of majic79's plugin targeting Blender 2.60 (Abandoned)
|-
| 2.59 || {{github source|proj=majic79|repo=Blender-AC3D|branch=BL2.59|text=majic79/Blender-AC3D (GitHub)}} || Branch of majic79's plugin targeting Blender 2.59 (Abandoned)
|-
| <2.5 || N/A || Versions of Blender below 2.5 include out of the box support for the AC3D file format, simply enable the add-on in <code>Preferences > Addons</code>
|}

==== Notes ====
* Before you export a model with this addon, make sure that you set the UV map and texture inside the material, not just inside the UV editor. See the video tutorial [https://www.youtube.com/watch?v=URMjoFSm5pk here].
* Before you export make sure to exit ''Edit Mode'' or some of your last changes won't be exported.
* Inside Blender when you want to see the textures, be sure to set the shader to GLSL (or for 2.7+ just set view mode to materials). Alternatively set textured solid in solid view.
* To see textured surfaces as they will be shown in FlightGear, go into the material texture and set the blend type to ''Multiply'' instead of the default ''Mix'' (the importer will also do this automatically). An example plane that will look very different if this is not done is the FGAddon aircraft {{fgaddon source|path=Aircraft/ASK13|commit=1363|text=ASK-13}}, notice the wingtips.
* The final model might display color mismatches (Texture color vs Material color) when viewed in Flightgear. Hand editing the [[AC files: Basic changes to textures and colors#Materials|materials]] section of the exported AC3D file might fix this.
* If you wonder where to put the scripts you could open blender's user preferences ({{Key press|Ctrl|Alt|U}}, or ''File > User Preferences'') tick for example Import/Export and extent the information concerning an existing script. Usually this throws the path. For for example Ubuntu 14.04LTS/Blender 2.79b it is: <code>/usr/share/blender/scripts/addons/</code>. In recent Ubuntu versions blender is distributed as a snap image. In such cases blender addon scripts are placed in: <code>$HOME/.config/blender/X.YY/scripts/addons/</code> (where X.YY is blender version, for example 2.82).
* Be aware that Blender only has greyscale for emission and ambient colors. If you want to export/import a color for those, import/export options gives you capability to choose to use Blenders mirror color for that.
* The importer will not fail if it does not locate a texture, instead it will issue warnings. Pull down the top bar to see if there was any, they will be orange lines.
* The exporter will not fail if it tries to save a texture without data, instead it will issue warnings. Pull down the top bar to see if there was any, they will be orange lines. Notice that since AC3D only support 1 texture per object, if multiple textures are attached to an object in Blender the last of the textures that has any data, if any, will be the one that get exported, but it will still warn about the missing data in the others, so take care.
* Orientation: The default settings in the plugin correspond to the FlightGear coordinate system (-X forward and Z up, also see: [[Howto:3D_Aircraft_Models]]). The default settings are: Forward -Z and Up Y.

You can report bugs with the addon [https://github.com/NikolaiVChr/Blender-AC3D/issues here], but please include problematic <code>.ac</code>/<code>.blend</code> files and their textures.

=== Importing ===

{{main article|Working with FlightGear models in Blender}}
{{note|If you do not see the option for <code>AC3D (.ac)</code> under <code>File > Import</code>, your add-on is either not installed, not enabled, or not working correctly.}}
Once the add-on is installed, AC3D models can be imported in the same manner as any other model foramat into Blender by using the <code> File > Import > AC3D (.ac)</code> dialog.
[[File:Blender AC3D import dialog.png|thumb|This figure demonstrates how to import an AC3D model in Blender using a third-party addon.]]

{{Appendix}}
{{3d}}
[[Category:Modeling]]

Howto talk:Working with FlightGear models in Blender

2024-09-04T10:54:41Z

Ranguli:

I agree that this can be deleted. [[User:Scttgs|xDraconian]] ([[User talk:Scttgs|talk]]) 15:45, 6 July 2024 (UTC)
 

: As the post stands now it definitely isn't working keeping, however I think an article of this kind is sorely needed, so I'm going to try and work on it in the coming days (I clearly had the notion to start it in 2020 but not to finish it). If it's alright I'm going to remove the delete template and replace it with a work in progress one while I finish the article. [[User:Ranguli|Ranguli]] ([[User talk:Ranguli|talk]]) 10:54, 4 September 2024 (UTC)

Superbuild

2024-09-02T18:26:03Z

Ranguli: Mark as out of date

{{Out of date|details=This article makes reference to long-deprecated version of development tools.}}

== Requirements ==
According to some recent reports, you should make sure to upgrade your cmake binary to 2.12.1 if you encounter any errors [http://forum.flightgear.org/viewtopic.php?f=37&t=21579&p=196700#p196670].

The superbuild is currently bit-rotted but could be resurrect, however with the build script (.bat) in fg-meta it’s less needed, especially now we have the windows-3rdparty-repo better organised.
<ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/35020034/
| title = <nowiki>Re: [Flightgear-devel] MSVC 2012 or 2013 support?</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Apr 17th, 2016
| added = Apr 17th, 2016
| script_version = 0.26
}}
</ref> ('''note the quote context: ''' for MSVC 2015 and higher support)

==Building via the superbuild==

A CMake super-build is a project which downloads, configures and builds other projects. Download can be from a web server, or via Git or SVN. Most normal CMake options apply - you can use different generators (Makefiles, VisualStudio, XCode) and pass in options.

===Getting the source===

In all cases, you should get the superbuild by doing a clean clone (from Git) of fgmeta, with the <code>--recursive</code> option:

{{#tag:source
| {{fgmeta clone
| opt = --recursive
| post = fgmeta
}}
| lang=sh
}}

This tells Git to clone submodules, which we need since both flightgear and simgear are submodules of fgmeta. The source repository is {{fgmeta source|text=fgmeta}}.
Note that providing you cloned with <code>--recursive</code>, git pull will also update submodules automatically; some documentation and pages may tell you to manually run <code>git submodule update</code> but providing you do the initial clone with <code>--recursive</code> option, it should not be needed.

Note the superbuild does not include any data repository or base files - you should separately download these or clone fgdata, and pass the location to fgfs when running in your preferred way, eg via the <code>--fg-root</code> command line argument.

Once the clone is complete, check out the <code>next</code> branch of fgmeta; the superbuild is not supported on the release branches.

<source lang=sh>
cd fgmeta
git checkout next
</source>


===Superbuild on Windows===
{{Main article|Superbuild on Windows}}

Using VisualStudio / msbuild:

Requirements:
* CMake for Windows
* SVN (see [[Tools of the Trade#Source Code Management / Revision Control Systems|here]].)
* VisualStudio 2010 or 2012 (it should works, otherwise please report it)
* Optional: [http://www.microsoft.com/en-us/download/details.aspx?id=8279 Microsoft Windows SDK] (only required for 64-bit builds)
: If you get an error during the installation of the SDK, try uninstalling MSVC redist packages first, then installing the SDK without compilers and then finally re-installing MSVC.
* Optional: [http://www.microsoft.com/en-au/download/details.aspx?id=23691 Visual Studio 2010 SP1] (recommend you install this if you use the 2010 version; overcomes various issues users have had according to the forums.)

We assume you have cloned fgmeta in C:\FGFS\fgmeta. All the example paths below work just fine if you replace C:\FGFS with G:\MyAwesomeDir\AnySubDir.
(Spaces in the paths are untested and might cause issues, but might work fine)

The steps are as follows:
* Make a build dir beside fgmeta - for example C:\FGFS\metabuild
* Run the CMake GUI, and select C:\FGFS\fgmeta as the source dir, and C:\FGFS\metabuild as the build dir
* Run 'Configure' once, and set CMAKE_INSTALL_PREFIX to C:\FGFS\metabuild\install (this step will be automated soon)
: If Subversion_SVN_EXECUTABLE is marked red, look for svn.exe in the folders under where SVN is installed and set it to point at that.
* Run 'Configure' again, and then 'Generate'. This step creates the ''FlightGear-Meta'' solution (.sln) in C:\FGFS\metabuild
* Build the FlightGear-Meta solution in C:\FGFS\metabuild 
:This build step creates ''FlightGear.sln'' in C:\FGFS\metabuild\fgbuild 

: You can build the -Meta solution from a Visual Studio command prompt using msbuild, or open up the .sln in the IDE and hit build. To avoid build errors in the IDE, perform your first build using the 'Release' build configuration rather than a 'Debug' configuration. Building in 'Debug' configuration can fail if some release-mode files (such as for OpenSceneGraph) are not already present in their folders. 

: The first time will be slow - OpenSceneGraph and Boost will be downloaded and compiled, followed by all of simgear and finally flightgear. If the build fails due to a "hash mismatch" in the OpenSceneGraph file, it could be because the source site itself is inaccessible or having temporary issues. To confirm this, check the presence and size of the downloaded OpenSceneGraph-x.x.x.zip file in C:\FGFS\metabuild\src . You might also try and obtain the file directly. To determine where SuperBuild is trying to get the file from, look for the OSG_SOURCE setting defined in C:\FGFS\fgmeta\CMakeLists.txt 

: Once the -Meta build completes, you will already have a flyable executable in either C:\FGFS\metabuild\install\msvc100-64\FlightGear\bin or C:\FGFS\metabuild\install\msvc100\FlightGear\bin depending on whether it's 64 or 32 bit. Other files such as fgrun.exe can be found and copied from the nearby folders under \install if required. (If you build with VS2012, you would rather get a msvc110 directory) 

 It is easier to run FlightGear by closing the -Meta solution, and instead opening the FlightGear.sln in C:\FGFS\metabuild\fgbuild. From here you can set 'fgfs' as the startup project, enter any command line options, and debug / hack / run the code as normal.

Note you will need to add the OpenSceneGraph install directory to the PATH variables in the 'fgfs' target properties; the dir will be something like C:\FGFS\metabuild\install\msvc100\OpenSceneGraph\bin. Again this step will hopefully go away soon, but for the moment is still required.

Using other generators / IDEs: untested, but quite likely to work if they already work with CMake. Try it out.

===Superbuild on Linux===

Requirements:

* compiler (probably GCC)
* CMake - available on all distros
* Boost - available on all distros
* development packages for your distribution. (For OpenGL, OpenAL and OpenSceneGraph dependencies such as FreeType)

See [[Linux distribution required packages|here]] for some lists of packages names for distributions, but be aware these change or go out of date.

(The follow assumes regular 'make' generator, other generators may work, testing welcome)

* make <code>build</code> dir next to your fgmeta clone
* cd into the <code>build</code> dir
* run <code>cmake ../fgmeta -DCMAKE_INSTALL_PREFIX=$PWD/install -DCMAKE_BUILD_TYPE=Release</code> (or Debug for a debug configuration)
* run <code>make -jN</code> (where N is as large a number as your system can support)
* make some coffee
* <code>fgfs</code> should be in <code>install/bin</code> directory

===Superbuild on Mac===

Make-based build works, XCode is more interesting. Probably only for the brave,

==Maintenance ==
{{FGCquote
|the Superbuild script isn't very well documented for people interested in maintaining/extending it - on the other hand, cmake itself is relatively straightforward, and we should be able to work out what is needed to also build your osgEarth branch using the Superbuild. The main thing that the Superbuild is built around is the '''ExternalProject''' notion, which is included at the top of the file: [http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/CMakeLists.txt#l3 http://sourceforge.net/p/flightgear/fgm ... sts.txt#l3]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238199#p238199
|title=<nowiki>Re: Buildings in OsgEarth</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

{{FGCquote
|the main directive is '''ExternalProject_Add()''' - e.g. see the section which builds boost: [http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/CMakeLists.txt#l26 http://sourceforge.net/p/flightgear/fgm ... ts.txt#l26] 
 
This directive is highly flexible and supports a huge variety of options (e.g. downloading options etc) - which are extensively covered at: [http://www.cmake.org/cmake/help/v3.0/module/ExternalProject.html http://www.cmake.org/cmake/help/v3.0/mo ... oject.html] 
 
An introduction can be found at: [http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html http://www.kitware.com/media/html/Build ... ke2.8.html]
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=238199#p238199
|title=<nowiki>Re: Buildings in OsgEarth</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Apr 09</nowiki>
}}
}}

[[Category:Core development projects]]
[[Category:Building from source]]

Robin DR400 Ecoflyer

2024-09-02T18:23:31Z

Ranguli: Mark as stub.

{{Stub}}
{{:{{PAGENAME}}/info}}
The '''Robin DR400-135cdi Ecoflyer''' is a single-engine four-seater aircraft built by the French company [[:Category:Robin Aircraft|Robin Aircraft]]. This variant of the DR400 family features a diesel engine built by Thielert/Continental and was one of the first general aviation aircraft to have a diesel engine instead of the conventional AVGAS engines. This means that the aircraft can fly using automotive-grade diesel fuel or JET-A1 fuel as typically used in commercial aviation.

The FlightGear simulation of this aircraft was created using references, measurements and photos from a real DR400-135cdi aircraft, D-EAJZ.

== Autopilot ==
The aircraft includes a simulation of the S-TEC Thirty autopilot which is controlled using two switches, two buttons on the control stick (currently not modelled) and the turn coordinator.

The autopilot is simulated to work in detail like the real thing described in the [https://genesys-aerosystems.com/wp-content/uploads/2023/11/System-Twenty_Thirty_-ThirtyALT.pdf manual available online].

=== Available Modes<ref>[https://genesys-aerosystems.com/wp-content/uploads/2023/11/System-Twenty_Thirty_-ThirtyALT.pdf Autopilot Manual, p. 1-3]</ref> ===

==== Lateral (Roll) ====

* '''ST:''' Stabilizer Mode: Hold Wings Level
* '''HD:''' Heading Mode: Turn to and Hold Heading (as selected on the directional gyro, to the right of the Turn Coordinator/Roll Computer)
* '''TRK:''' Track a Navigation beacon
** '''TRK LO:''' Track using small corrections, typically for following a '''VOR'''
** '''TRK HI:''' Track using larger corrections, typically for following a '''LOC'''

==== Vertical (Pitch) ====
There is only one pitch mode available, altitude hold ('''ALT'''). It holds the altitude that it is engaged at. This is accomplished by holding the absolute pressure as measured by its own altitude transducer connected to the aircraft's static pressure line.

=== Tutorial ===
'''Please note:''' The following tutorial assumes that you're in stable flight, the engine and avionics are switched on and without malfunction.
[[File:DR400-Ecoflyer Autopilot Control Elements.jpg|alt=Control Elements for the S-TEC Thirty Autopilot System|frameless|800x800px]]

==== Switching on the Autopilot ====

# Switch on the Autopilot Master Switch
# The autopilot performs a self-test. Wait until the test is done, indicated by the green "RDY" (Ready) light on the Turn Coordinator.
# Use the Mode Button to select one of the lateral (roll) modes.
# (Optionally) Engage the Altitude Hold mode by pressing the 'makeshift' altitude click spot next to the the altitude indicator light (use Ctrl-c to spot it).

==== Trim Functionality ====
The autopilot is '''not connected''' to the aircraft's elevator trim, but can generate commands to the pilot to trim the aircraft up or down in order to relieve load from the pitch servos and improve aerodynamics. To use this functionality, switch on the '''Trim Switch''' next to the Autopilot Master Switch and engage the Altitude Hold mode. When the autopilot detects an out-of-trim condition, the '''TRIM UP''' or '''TRIM DN''' indicator lights will illuminate. Trim the aircraft to the commanded direction using the elevator trim wheel until the indicator light extinguishes.

== External Links ==
* [https://www.vliegclubseppe.nl/bestanden/2016-poh-robins.pdf Pilot's Operating Handbook Supplement] (for Continental CD-135 engine)
* [https://mfgo.ch/wp-content/uploads/HB-KLM_AFM.pdf DR400-140B Pilot's Operating Handbook] ''[broken link as of 08/2024]''
* [http://www.tmg-service.de/doc-download/manuals/OM-02-02_4-6_EASA_Version.pdf Engine Operating Manual] (CD-135 and CD-155)
* [https://www.easa.europa.eu/sites/default/files/dfu/TCDS_P094_issue03_20150319_1.0.pdf Propeller Type-Certificate Data Sheet]
* [http://www.tmg-service.de/doc-download/manuals/AMM-60-02_1-5s.pdf Airplane Maintenance Manual Supplement] (for Continental CD-135 engine)
* [https://genesys-aerosystems.com/wp-content/uploads/2023/11/System-Twenty_Thirty_-ThirtyALT.pdf S-TEC Thirty Autopilot Manual]

Boeing 767-300

2024-09-02T18:23:12Z

Ranguli: Mark as stub.

{{Stub}}
{{:{{PAGENAME}}/info}}
The '''Boeing 767-300''' is a long-range civil [[aircraft]], built by [[Boeing]]. It was first flown in 1986, and is still operated by many major airlines. The '''767-300''' is expected to be replaced gradually by the new [[Boeing 787]], in the future. It has a Freight version (767-300F), aswell as an Extended Range (Boeing 767-300ER) version, which has a longer service range and fuel capacity.

The 767-300's direct competitor from [[Airbus]] is the [[Airbus A330-200|A330-200]]. The 767-300 is expected to be replaced by the [[Boeing 787|787-8]] in Boeing's lineup. As of August 2009, total orders for the 767-300/300ER/300F stand at 749 with 690 delivered. This includes 104 orders (all delivered) for the -300, 563 orders for the -300ER (535 delivered), and 82 orders for the -300F (51 delivered). A total of 661 Boeing 767-300/-300ER/-300F aircraft were in airline service as of July 2009.

Stretched 269-passenger version, with 3.07 m (10 ft 1 in) plug forward of wing and 3.35 m (11 ft) plug aft, and same gross weight as 767-200; strengthened landing gear and thicker metal in parts of fuselage and underwing skin; same flight deck and systems as other 767s; same engine options as 767-200ER; first ordered (by Japan Airlines) 29 September 1983. First flight with JT9D-7R4D engines 30 January 1986; certified with JT9D-7R4D and CF6-80A2 22 September 1986. First delivery (Japan Airlines) 25 September 1986. British Airways ordered 11 in August 1987, later increased to total 25, with Rolls-Royce RB211-524H engines; delivered from 8 February 1990. No longer available; weight and performance data in 2000-01 and previous Jane's.

=== Key features ===

- The 767-300 typically cruises at 530mph, at a ceiling of 35,000ft.
- The 767-300 variant has 230 seats in standard 3 class configuration.

* YASim FDM.
* Autostart control.
* Followme vehicle and other airport operations. Follow-me vehicle turns with aircraft and rotates on an axis when aircraft rudder is turned.
* Lights on automatically on autostart. to be switchable in future.
* Wing view/Tail view/Gear view.
* Livery Selection Dialog.
* Tyre smoke on landing.
* 3D cockpit with some panels and instruments modelled (PFD, SFD, Yoke, Pedals etc). (subject to future enhancements).
* Autopilot does work using autopilot menu's, not cockpit buttons as of yet.
* 2 General Electric CF6-80C2B6 engines.
* Vapour trails/Contrails and take-off engine moisture.
* Cabin SFX (Seatbelt alarm, various atmospheric cabin announcements).
* Pushback (Goldhofer).
* Many animations complete, including flaps, ailerons, both v/h stabilizers, landing gear and speed-brakes. Gear doors to be animated.

== References ==
* [http://en.wikipedia.org/wiki/Boeing_767 Wikipedia Boeing 767]
* [http://www.janes.com/aerospace/civil/news/jawa/boeing_767.shtml Jane's All The World's Aircraft Entry - Boeing 767]

{{Boeing}}
[[Category:Red Griffin ATC compatible aircraft]]

Beechcraft 35 Bonanza

2024-09-02T16:47:49Z

Ranguli: Mark that development is stalled

{{Stalled|date=October 2014<ref name="Github">https://github.com/flyingfisch/beech-v35/commits/master/</ref>}}{{infobox Aircraft
|image = Bonanza retracting gears.png
|name = Beech B35 Bonanza
|livery =
|type = Civil utility aircraft
|fdm = YASim
|status = Alpha
|authors = flyingfisch, bitwisetech (dood)
|fgname = beech-v35
|download = https://github.com/flyingfisch/beech-v35
| status-fdm = 2
| status-systems = 2
| status-cockpit = 3
| status-model = 2
}}
[[File:Beech bonanza with panel lights on.png|thumb|Beech Bonanza with panel lights on.]]
The Beechcraft Bonanza is an American general aviation aircraft introduced in 1947 by Beech Aircraft Corporation of Wichita, Kansas. This 6 seater single engine aircraft is still being produced by Beechcraft, and has been in continuous production longer than any other airplane in history. More than 17,000 Bonanzas of all variants have been built.<ref name="Wikipedia">[https://en.wikipedia.org/wiki/Beechcraft_Bonanza]Wikipedia</ref> The Flightgear model is an A35.

==Aircraft Help==
[[File:Bonanza rbf.png|thumb|Remove Before Flight flag on the Bonanza's pitot tube.]]
[[File:Bonanza cockpit.png|thumb|Beech bonanza cockpit.]]

===Notes ===
*Most of the panel buttons have tooltips, if you are unsure of what something does just hover over it.

===Startup===
#Remove pitot cover and intake plugs (click on them). You can use the walker, or just an external view to do this.
#Throttle 30%.
#Master switch (located on chrome center piece) to 'on'.
#Parking brake on (located below dash on right, colored white-ish. Hover to make sure.)
#Cowl flaps open (located below dash on left, colored white-ish. Hover to make sure.)
#Press '}' three times, or click the piece of chrome that the yoke tube goes into to hide the yoke and use the key.
#Press 's' or click the key.

==To do==
https://github.com/flyingfisch/beech-v35/blob/master/TODO.md

==Photo Gallery ==
<gallery mode="packed">
Bonanza_at_KAKR_sunrise.png | Beech Bonanza and sunrise. @FlightGear, @ALS: Sky coloring++
Bonanza at sunrise.png|The Beech Bonanza just before sunrise
Bonanza sunrise kakr.png|The Beech Bonanza at KAKR. The [[Akron-Fulton_International_Airport#Goodyear_Airdock | Goodyear Airdock]] is visible behind the plane.
Bonanza sunrise kakr 2.png|Another shot of the Beech Bonanza at KAKR.
Standing next to the bonanza kakr.png|Standing next to the beech bonanza at KAKR
Bonanza from side sunrise.png|Looking at the interior and instrument panel right after sunrise.
Bonanza interior at sunrise.png|The interior of the Bonanza at sunrise.
</gallery>

==References==
<references />

{{Beechcraft}}

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]