<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.flightgear.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Alfozavr</id>
	<title>FlightGear wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.flightgear.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Alfozavr"/>
	<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/Special:Contributions/Alfozavr"/>
	<updated>2026-04-30T07:27:30Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.39.6</generator>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3583</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3583"/>
		<updated>2007-06-17T11:38:06Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
** What kind of error?&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has no shadow&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Shadow can be enabled through the &amp;quot;Rendering&amp;quot; dialog right during the flight.&lt;br /&gt;
* landing, taxi and strobe lights are not implemented yet in Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
&lt;br /&gt;
3D cockpit:&lt;br /&gt;
&lt;br /&gt;
* only cockpit instruments light at night, no cockpit and panel light available yet&lt;br /&gt;
* no rudder control pedals visible&lt;br /&gt;
** Rudder position indicator could be a better addition.&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
*** They can be heard being clicked, if the camera is inside the cockpit.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly aircraft, not to sit in the cockpit and look around.&lt;br /&gt;
* &amp;lt;strike&amp;gt;one of the levers has an error, it looks like a square and it is not round like the lever should be&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
** It's a waste of polygons, not everyone has a hi-end PC. You can always turn on your imagination!&lt;br /&gt;
* &amp;lt;strike&amp;gt;cockpit window has no windscreen wipers&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers [http://skyhawk.cessna.com/].&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
** What is the expected performance according to your estimation?&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
Explanation required:&lt;br /&gt;
&lt;br /&gt;
There are '''3 c172 downloads available''' at the FlightGear official site ([http://flightgear.org/Downloads/aircraft/index.shtml]):&lt;br /&gt;
* '''c172-le''' (doesn't even appear on the list of airplanes),&lt;br /&gt;
* '''c172p''' (2 versions: with 2D-cockpit and with 3D-cockpit, seems to be the most complete of the 3),&lt;br /&gt;
* '''and c172r''' (seems to be a work-in-progress).&lt;br /&gt;
&lt;br /&gt;
Moreover, FlightGear 0.9.10 comes bundled with a '''folder c172''' together with a folder c172p. It's not clear what is the c172 folder for? (it seems to me, that at least c172p model uses some files from there)&lt;br /&gt;
&lt;br /&gt;
Dear developers, please, explain how do these 3 models correlate, if they depend on each other, do they share models, sounds, etc. '''Maybe separate wiki-pages should be created for each version.'''&lt;br /&gt;
&lt;br /&gt;
'''The list at the top of this page includes many various models, but only 3 are actually available. What's wrong?'''&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3582</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3582"/>
		<updated>2007-06-17T11:30:59Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
** What kind of error?&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has no shadow&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Shadow can be enabled through the &amp;quot;Rendering&amp;quot; dialog right during the flight.&lt;br /&gt;
* landing, taxi and strobe lights are not implemented yet in Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
&lt;br /&gt;
3D cockpit:&lt;br /&gt;
&lt;br /&gt;
* only cockpit instruments light at night, no cockpit and panel light available yet&lt;br /&gt;
* no rudder control pedals visible&lt;br /&gt;
** Rudder position indicator could be a better addition.&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
*** They can be heard being clicked, if the camera is inside the cockpit.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly aircraft, not to sit in the cockpit and look around.&lt;br /&gt;
* &amp;lt;strike&amp;gt;one of the levers has an error, it looks like a square and it is not round like the lever should be&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
** It's a waste of polygons, not everyone has a hi-end PC. You can always turn on your imagination!&lt;br /&gt;
* &amp;lt;strike&amp;gt;cockpit window has no windscreen wipers&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers [http://skyhawk.cessna.com/].&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
** What is the expected performance according to your estimation?&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
'''There are 3 c172 downloads available at the FlightGear official site ([http://flightgear.org/Downloads/aircraft/index.shtml]):'''&lt;br /&gt;
* '''c172-le (doesn't even appear on the list of airplanes),'''&lt;br /&gt;
* '''c172p (2 versions: with 2D-cockpit and with 3D-cockpit),'''&lt;br /&gt;
* '''and c172r (seems to be a work-in-progress).'''&lt;br /&gt;
&lt;br /&gt;
'''Moreover, FlightGear 0.9.10 comes bundled with a folder c172 together with a folder c172p. It's not clear what is the c172 folder for?'''&lt;br /&gt;
&lt;br /&gt;
'''Dear developers, please, explain how do these 3 models correlate, if they depend on each other, do they share models, sounds, etc. Maybe separate wiki-pages should be created for each version.'''&lt;br /&gt;
&lt;br /&gt;
'''The list at the top of this page includes many various models, but only 3 are actually available. What's wrong?'''&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3581</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3581"/>
		<updated>2007-06-17T11:25:29Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
** What kind of error?&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has no shadow&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Shadow can be enabled through the &amp;quot;Rendering&amp;quot; dialog right during the flight.&lt;br /&gt;
* landing, taxi and strobe lights are not implemented yet in Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
&lt;br /&gt;
3D cockpit:&lt;br /&gt;
&lt;br /&gt;
* only cockpit instruments light at night, no cockpit and panel light available yet&lt;br /&gt;
* no rudder control pedals visible&lt;br /&gt;
** Rudder position indicator could be a better addition.&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
*** They can be heard being clicked, if the camera is inside the cockpit.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly aircraft, not to sit in the cockpit and look around.&lt;br /&gt;
* &amp;lt;strike&amp;gt;one of the levers has an error, it looks like a square and it is not round like the lever should be&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
** It's a waste of polygons, not everyone has a hi-end PC. You can always turn on your imagination!&lt;br /&gt;
* &amp;lt;strike&amp;gt;cockpit window has no windscreen wipers&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers [http://skyhawk.cessna.com/].&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
** What is the expected performance according to your estimation?&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
'''There are 3 c172 downloads available at the FlightGear official site ([http://flightgear.org/Downloads/aircraft/index.shtml]):'''&lt;br /&gt;
* '''c172-le (doesn't even appear on the list of airplanes),'''&lt;br /&gt;
* '''c172p (2 versions: with 2D-cockpit and with 3D-cockpit),'''&lt;br /&gt;
* '''and c172r.'''&lt;br /&gt;
'''Moreover, FlightGear 0.9.10 comes bundled with a folder c172 together with a folder c172p. It's not clear what is the c172 folder for?'''&lt;br /&gt;
'''Dear developers, please, explain how do these 3 models correlate, if they depend on each other, do they share models, sounds, etc. Maybe separate wiki-pages could be created for each version.'''&lt;br /&gt;
'''The list at the top of this page includes many various models, but only 3 are actually available. What's wrong?'''&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:Main_Page/Archive/2006-2011&amp;diff=3580</id>
		<title>Talk:Main Page/Archive/2006-2011</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:Main_Page/Archive/2006-2011&amp;diff=3580"/>
		<updated>2007-06-17T10:59:56Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Sorry, I don't want to junk up the main page with someone's opinion on &amp;quot;the manual&amp;quot; and the wiki documentation.  [[User:Hellosimon|Hellosimon]] 10:41, 5 June 2006 (PDT)&lt;br /&gt;
&lt;br /&gt;
I too think that the Main Page shouldn't get too verbose.  I don't understand the need for that little comment in the User Documentation section, but if someone insists on having it placed on the wiki, then a compromise should be reached somehow.  I suggest moving it to some other articles. --[[User:64.229.232.249|64.229.232.249]] 16:14, 5 June 2006 (PDT)&lt;br /&gt;
&lt;br /&gt;
I agree: Simon, while you have definitely done some nice job here, you need to realize that you can achieve much more by collaborating constructively with other contributors rather than by simply opposing contributions of people who have in fact contributed significant amounts of work to the project for quite some time. &lt;br /&gt;
I think, the corresponding paragraph wasn't an &amp;quot;opinion&amp;quot; on the manual or the wiki and it certainly wasn't meant to reflect badly upon your efforts, rather it was merely meant to complement the wiki. &lt;br /&gt;
There's simply a very clear relationship between &amp;quot;The Manual&amp;quot; and &amp;quot;the wiki&amp;quot;, if you fail to recognize this, your contribution (that is, this wiki) -even though very much needed and extremely worthwhile- is condemned to fail eventually. &lt;br /&gt;
&lt;br /&gt;
On the other hand, I would recommend to also look into making &amp;quot;The Manual&amp;quot; editable via some sort of web based frontend, this would also ensure that people are able to easily contribute modifications to the manual, which is really the ultimate source for flightgear users. &lt;br /&gt;
A possible approach might be to import the underlying LaTex sources in docbook format into some sort of docbook based wiki (i.e. http://sourceforge.net/projects/doc-book/).&lt;br /&gt;
&lt;br /&gt;
Also, I feel there are some sections covered in the wiki that aren't really optimally handled by a wiki: most notably the &amp;quot;FAQ&amp;quot; section should preferably be implemented via some sort of dynamic FAQ system (i.e. http://www.phpmyfaq.de), likewise the sections titled &amp;quot;Bugs&amp;quot;, &amp;quot;TODO&amp;quot;, &amp;quot;Feature Requests&amp;quot;, &amp;quot;ideas&amp;quot; etc. could probably all be handled far more effectively by using a real bug tracker such as bugzilla (http://www.bugzilla.org/), phpbugtracker (http://phpbt.sourceforge.net/) or mantis (http://www.mantisbt.org).&lt;br /&gt;
&lt;br /&gt;
Concerning database backups: you should preferably set up a cron job to upload a  compresed SQL dump to the flightgear FTP server on a regular (daily?) basis, I am sure you'll be granted write access to a corresponding directory, this would ensure that everything will in fact be backed up regularly and possibly even mirrored.&lt;br /&gt;
&lt;br /&gt;
[&amp;quot;I think, the corresponding paragraph wasn't an &amp;quot;opinion&amp;quot; on the manual or the wiki and it certainly wasn't meant to reflect badly upon your efforts, rather it was merely meant to complement the wiki.&amp;quot;]&lt;br /&gt;
This assumption is correct. The manual is the center piece of the FlightGear user documentation, so does anyone have a suggestion (one that makes sense) on how to deal with my comments aside from &amp;quot;removing it&amp;quot; or &amp;quot;moving it into negligence/insignificance&amp;quot; ?&lt;br /&gt;
Martin.&lt;br /&gt;
&lt;br /&gt;
Martin's text has been placed (not by me) in the paragraphs at the top.  I rather like this compromise and hope it works for everyone.  I agree a bugtracker would be ideal - didn't someone start one?  Also, if anyone wants to grant ftp access to a server, I'll gladly cron a script to upload the backup tarball.  I have it backed up to multiple locations in the meantime. &lt;br /&gt;
- [[User:Hellosimon|Hellosimon]] 11:36, 11 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
A couple of days ago I started setting up a local test bugZilla installation, while I am currently unable to provide reliable hosting, I would really not mind installing it on whatever webspace is available, likewise I can provide the preconfigured database dump if someone else wants to use the preconfigured Flightgear specific categories.--[[User:FlightZilla|FlightZilla]] 17:59, 17 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
Regarding the manual: isn't there a possibility to export wikimedia pages to PDF format? That way, we could maintain the whole manual via this wiki. Any thoughts?--[[User:FlightZilla|FlightZilla]] 18:10, 17 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
If you check out the following links, you'll see that there are extensions available that would make it possible to easily provide PDF exports for all contents stored here, that way it would also become feasible to consider migrating the entire manual over to this wiki, so that it would also become more maintainble in the end:&lt;br /&gt;
http://meta.wikimedia.org/wiki/WikiPDF&lt;br /&gt;
http://meta.wikimedia.org/wiki/PDF_Export&lt;br /&gt;
--[[User:FlightZilla|FlightZilla]] 17:21, 19 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
Hello, guys. If I get it right, you're discussing various documentation types here.&lt;br /&gt;
&lt;br /&gt;
I think, this wiki is a lot more convenient than any other form of keeping documentation and at the same time communicating. It can be edited fast and easily and maintained up-to-date. However, the following questions need be solved:&lt;br /&gt;
* how to convert it to an offline version (maybe .pdf) so that it could be bundled with the FlightGear base package?&lt;br /&gt;
* how to define and limit editing rights for certain users?&lt;br /&gt;
&lt;br /&gt;
It's better to have one consolidated source of information for both bugs and descriptions. For now, user has to search through mailing lists, forums, user manuals (even not a single user manual, but several) and this wiki. It's absolutely not convinient for both users (they spend lot's of time searching required information) and developers (they spend lot's of time updating and syncronizing certain information in various sources).&lt;br /&gt;
&lt;br /&gt;
This wiki is suitable for bug tracking too. Users can provide feedback in a convinient form. They just open the corresponding page and add their bug to the list. Developers can respond to the posted bugs right away. Mailing lists are a lot less user-friendly and effective and a lot less popular among users (not developers) in this regard, this is the reason why some bugs may stay unreported and why many users forget about FlightGear as soon as they run into a problem.&lt;br /&gt;
&lt;br /&gt;
Unfortunately, it seems to me, this wiki is not popular among developers and users. -- [[User:Alfozavr|Alfozavr]] 06:59, 17 June 2007 (EDT)&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:Main_Page/Archive/2006-2011&amp;diff=3579</id>
		<title>Talk:Main Page/Archive/2006-2011</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:Main_Page/Archive/2006-2011&amp;diff=3579"/>
		<updated>2007-06-17T10:59:19Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Sorry, I don't want to junk up the main page with someone's opinion on &amp;quot;the manual&amp;quot; and the wiki documentation.  [[User:Hellosimon|Hellosimon]] 10:41, 5 June 2006 (PDT)&lt;br /&gt;
&lt;br /&gt;
I too think that the Main Page shouldn't get too verbose.  I don't understand the need for that little comment in the User Documentation section, but if someone insists on having it placed on the wiki, then a compromise should be reached somehow.  I suggest moving it to some other articles. --[[User:64.229.232.249|64.229.232.249]] 16:14, 5 June 2006 (PDT)&lt;br /&gt;
&lt;br /&gt;
I agree: Simon, while you have definitely done some nice job here, you need to realize that you can achieve much more by collaborating constructively with other contributors rather than by simply opposing contributions of people who have in fact contributed significant amounts of work to the project for quite some time. &lt;br /&gt;
I think, the corresponding paragraph wasn't an &amp;quot;opinion&amp;quot; on the manual or the wiki and it certainly wasn't meant to reflect badly upon your efforts, rather it was merely meant to complement the wiki. &lt;br /&gt;
There's simply a very clear relationship between &amp;quot;The Manual&amp;quot; and &amp;quot;the wiki&amp;quot;, if you fail to recognize this, your contribution (that is, this wiki) -even though very much needed and extremely worthwhile- is condemned to fail eventually. &lt;br /&gt;
&lt;br /&gt;
On the other hand, I would recommend to also look into making &amp;quot;The Manual&amp;quot; editable via some sort of web based frontend, this would also ensure that people are able to easily contribute modifications to the manual, which is really the ultimate source for flightgear users. &lt;br /&gt;
A possible approach might be to import the underlying LaTex sources in docbook format into some sort of docbook based wiki (i.e. http://sourceforge.net/projects/doc-book/).&lt;br /&gt;
&lt;br /&gt;
Also, I feel there are some sections covered in the wiki that aren't really optimally handled by a wiki: most notably the &amp;quot;FAQ&amp;quot; section should preferably be implemented via some sort of dynamic FAQ system (i.e. http://www.phpmyfaq.de), likewise the sections titled &amp;quot;Bugs&amp;quot;, &amp;quot;TODO&amp;quot;, &amp;quot;Feature Requests&amp;quot;, &amp;quot;ideas&amp;quot; etc. could probably all be handled far more effectively by using a real bug tracker such as bugzilla (http://www.bugzilla.org/), phpbugtracker (http://phpbt.sourceforge.net/) or mantis (http://www.mantisbt.org).&lt;br /&gt;
&lt;br /&gt;
Concerning database backups: you should preferably set up a cron job to upload a  compresed SQL dump to the flightgear FTP server on a regular (daily?) basis, I am sure you'll be granted write access to a corresponding directory, this would ensure that everything will in fact be backed up regularly and possibly even mirrored.&lt;br /&gt;
&lt;br /&gt;
[&amp;quot;I think, the corresponding paragraph wasn't an &amp;quot;opinion&amp;quot; on the manual or the wiki and it certainly wasn't meant to reflect badly upon your efforts, rather it was merely meant to complement the wiki.&amp;quot;]&lt;br /&gt;
This assumption is correct. The manual is the center piece of the FlightGear user documentation, so does anyone have a suggestion (one that makes sense) on how to deal with my comments aside from &amp;quot;removing it&amp;quot; or &amp;quot;moving it into negligence/insignificance&amp;quot; ?&lt;br /&gt;
Martin.&lt;br /&gt;
&lt;br /&gt;
Martin's text has been placed (not by me) in the paragraphs at the top.  I rather like this compromise and hope it works for everyone.  I agree a bugtracker would be ideal - didn't someone start one?  Also, if anyone wants to grant ftp access to a server, I'll gladly cron a script to upload the backup tarball.  I have it backed up to multiple locations in the meantime. &lt;br /&gt;
- [[User:Hellosimon|Hellosimon]] 11:36, 11 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
A couple of days ago I started setting up a local test bugZilla installation, while I am currently unable to provide reliable hosting, I would really not mind installing it on whatever webspace is available, likewise I can provide the preconfigured database dump if someone else wants to use the preconfigured Flightgear specific categories.--[[User:FlightZilla|FlightZilla]] 17:59, 17 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
Regarding the manual: isn't there a possibility to export wikimedia pages to PDF format? That way, we could maintain the whole manual via this wiki. Any thoughts?--[[User:FlightZilla|FlightZilla]] 18:10, 17 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
If you check out the following links, you'll see that there are extensions available that would make it possible to easily provide PDF exports for all contents stored here, that way it would also become feasible to consider migrating the entire manual over to this wiki, so that it would also become more maintainble in the end:&lt;br /&gt;
http://meta.wikimedia.org/wiki/WikiPDF&lt;br /&gt;
http://meta.wikimedia.org/wiki/PDF_Export&lt;br /&gt;
--[[User:FlightZilla|FlightZilla]] 17:21, 19 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
Hello, guys. If I get it right, you're discussing various documentation types here.&lt;br /&gt;
&lt;br /&gt;
I think, this wiki is a lot more convenient than any other form of keeping documentation and at the same time communicating. It can be edited fast and easily and maintained up-to-date. However, the following questions need be solved:&lt;br /&gt;
* how to convert it to an offline version (maybe .pdf) so that it could be bundled with the FlightGear base package?&lt;br /&gt;
* how to define and limit editing rights for certain users?&lt;br /&gt;
&lt;br /&gt;
It's better to have one consolidated source of information for both bugs and descriptions. For now, user has to search through mailing lists, forums, user manuals (even not a single user manual, but several) and this wiki. It's absolutely not convinient for both users (they spend lot's of time searching required information) and developers (they spend lot's of time updating and syncronizing certain information in various sources).&lt;br /&gt;
&lt;br /&gt;
This wiki is suitable for bug tracking too. Users can provide feedback in a convinient form. They just open the corresponding page and add their bug to the list. Developers can respond to the posted bugs right away. Mailing lists are a lot less user-friendly and effective and a lot less popular among users (not developers) in this regard, this is the reason why some bugs may stay unreported and why many users forget about FlightGear as soon as they run into a problem.&lt;br /&gt;
&lt;br /&gt;
Unfortunately, it seems to me, this wiki is not popular among developers and users. ([[User:Alfozavr|Alfozavr]] 06:59, 17 June 2007 (EDT))&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:Main_Page/Archive/2006-2011&amp;diff=3578</id>
		<title>Talk:Main Page/Archive/2006-2011</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:Main_Page/Archive/2006-2011&amp;diff=3578"/>
		<updated>2007-06-17T10:57:55Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Sorry, I don't want to junk up the main page with someone's opinion on &amp;quot;the manual&amp;quot; and the wiki documentation.  [[User:Hellosimon|Hellosimon]] 10:41, 5 June 2006 (PDT)&lt;br /&gt;
&lt;br /&gt;
I too think that the Main Page shouldn't get too verbose.  I don't understand the need for that little comment in the User Documentation section, but if someone insists on having it placed on the wiki, then a compromise should be reached somehow.  I suggest moving it to some other articles. --[[User:64.229.232.249|64.229.232.249]] 16:14, 5 June 2006 (PDT)&lt;br /&gt;
&lt;br /&gt;
I agree: Simon, while you have definitely done some nice job here, you need to realize that you can achieve much more by collaborating constructively with other contributors rather than by simply opposing contributions of people who have in fact contributed significant amounts of work to the project for quite some time. &lt;br /&gt;
I think, the corresponding paragraph wasn't an &amp;quot;opinion&amp;quot; on the manual or the wiki and it certainly wasn't meant to reflect badly upon your efforts, rather it was merely meant to complement the wiki. &lt;br /&gt;
There's simply a very clear relationship between &amp;quot;The Manual&amp;quot; and &amp;quot;the wiki&amp;quot;, if you fail to recognize this, your contribution (that is, this wiki) -even though very much needed and extremely worthwhile- is condemned to fail eventually. &lt;br /&gt;
&lt;br /&gt;
On the other hand, I would recommend to also look into making &amp;quot;The Manual&amp;quot; editable via some sort of web based frontend, this would also ensure that people are able to easily contribute modifications to the manual, which is really the ultimate source for flightgear users. &lt;br /&gt;
A possible approach might be to import the underlying LaTex sources in docbook format into some sort of docbook based wiki (i.e. http://sourceforge.net/projects/doc-book/).&lt;br /&gt;
&lt;br /&gt;
Also, I feel there are some sections covered in the wiki that aren't really optimally handled by a wiki: most notably the &amp;quot;FAQ&amp;quot; section should preferably be implemented via some sort of dynamic FAQ system (i.e. http://www.phpmyfaq.de), likewise the sections titled &amp;quot;Bugs&amp;quot;, &amp;quot;TODO&amp;quot;, &amp;quot;Feature Requests&amp;quot;, &amp;quot;ideas&amp;quot; etc. could probably all be handled far more effectively by using a real bug tracker such as bugzilla (http://www.bugzilla.org/), phpbugtracker (http://phpbt.sourceforge.net/) or mantis (http://www.mantisbt.org).&lt;br /&gt;
&lt;br /&gt;
Concerning database backups: you should preferably set up a cron job to upload a  compresed SQL dump to the flightgear FTP server on a regular (daily?) basis, I am sure you'll be granted write access to a corresponding directory, this would ensure that everything will in fact be backed up regularly and possibly even mirrored.&lt;br /&gt;
&lt;br /&gt;
[&amp;quot;I think, the corresponding paragraph wasn't an &amp;quot;opinion&amp;quot; on the manual or the wiki and it certainly wasn't meant to reflect badly upon your efforts, rather it was merely meant to complement the wiki.&amp;quot;]&lt;br /&gt;
This assumption is correct. The manual is the center piece of the FlightGear user documentation, so does anyone have a suggestion (one that makes sense) on how to deal with my comments aside from &amp;quot;removing it&amp;quot; or &amp;quot;moving it into negligence/insignificance&amp;quot; ?&lt;br /&gt;
Martin.&lt;br /&gt;
&lt;br /&gt;
Martin's text has been placed (not by me) in the paragraphs at the top.  I rather like this compromise and hope it works for everyone.  I agree a bugtracker would be ideal - didn't someone start one?  Also, if anyone wants to grant ftp access to a server, I'll gladly cron a script to upload the backup tarball.  I have it backed up to multiple locations in the meantime. &lt;br /&gt;
- [[User:Hellosimon|Hellosimon]] 11:36, 11 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
A couple of days ago I started setting up a local test bugZilla installation, while I am currently unable to provide reliable hosting, I would really not mind installing it on whatever webspace is available, likewise I can provide the preconfigured database dump if someone else wants to use the preconfigured Flightgear specific categories.--[[User:FlightZilla|FlightZilla]] 17:59, 17 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
Regarding the manual: isn't there a possibility to export wikimedia pages to PDF format? That way, we could maintain the whole manual via this wiki. Any thoughts?--[[User:FlightZilla|FlightZilla]] 18:10, 17 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
If you check out the following links, you'll see that there are extensions available that would make it possible to easily provide PDF exports for all contents stored here, that way it would also become feasible to consider migrating the entire manual over to this wiki, so that it would also become more maintainble in the end:&lt;br /&gt;
http://meta.wikimedia.org/wiki/WikiPDF&lt;br /&gt;
http://meta.wikimedia.org/wiki/PDF_Export&lt;br /&gt;
--[[User:FlightZilla|FlightZilla]] 17:21, 19 June 2006 (EDT)&lt;br /&gt;
&lt;br /&gt;
Hello, guys. If I get it right, you're discussing various documentation types here.&lt;br /&gt;
&lt;br /&gt;
I think, this wiki is a lot more convenient than any other form of keeping documentation and at the same time communicating. It can be edited fast and easily and maintained up-to-date. However, the following questions need be solved:&lt;br /&gt;
* how to convert it to an offline version (maybe .pdf) so that it could be bundled with the FlightGear base package?&lt;br /&gt;
* how to define and limit editing rights for certain users?&lt;br /&gt;
&lt;br /&gt;
It's better to have one consolidated source of information for both bugs and descriptions. For now, user has to search through mailing lists, forums, user manuals (even not a single user manual, but several) and this wiki. It's absolutely not convinient for both users (they spend lot's of time searching required information) and developers (they spend lot's of time updating and syncronizing certain information in various sources).&lt;br /&gt;
&lt;br /&gt;
This wiki is suitable for bug tracking too. Users can provide feedback in a convinient form. They just open the corresponding page and add their bug to the list. Developers can respond to the posted bugs right away. Mailing lists are a lot less user-friendly and effective and a lot less popular among users (not developers) in this regard, this is the reason why some bugs may stay unreported and why many users forget about FlightGear as soon as they run into a problem.&lt;br /&gt;
&lt;br /&gt;
Unfortunately, it seems to me, this wiki is not popular among developers and users.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3577</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3577"/>
		<updated>2007-06-17T10:34:28Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
** What kind of error?&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has no shadow&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Shadow can be enabled through the &amp;quot;Rendering&amp;quot; dialog right during the flight.&lt;br /&gt;
* landing, taxi and strobe lights are not implemented yet in Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
&lt;br /&gt;
3D cockpit:&lt;br /&gt;
&lt;br /&gt;
* only cockpit instruments light at night, no cockpit and panel light available yet&lt;br /&gt;
* no rudder control pedals visible&lt;br /&gt;
** Rudder position indicator could be a better addition.&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
*** They can be heard being clicked, if the camera is inside the cockpit.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly aircraft, not to sit in the cockpit and look around.&lt;br /&gt;
* &amp;lt;strike&amp;gt;one of the levers has an error, it looks like a square and it is not round like the lever should be&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
** It's a waste of polygons, not everyone has a hi-end PC. You can always turn on your imagination!&lt;br /&gt;
* &amp;lt;strike&amp;gt;cockpit window has no windscreen wipers&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers [http://skyhawk.cessna.com/].&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
** What is the expected performance according to your estimation?&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
'''There are 3 c172 downloads available at the FlightGear official site ([http://flightgear.org/Downloads/aircraft/index.shtml]):'''&lt;br /&gt;
* '''c172-le,'''&lt;br /&gt;
* '''c172p,'''&lt;br /&gt;
* '''and c172r.'''&lt;br /&gt;
'''Dear developers, please, explain how do these 3 models correlate, if they depend on each other, do they share models, sounds, etc. Maybe separate wiki-pages could be created for each version.'''&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3576</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3576"/>
		<updated>2007-06-17T10:33:57Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
** What kind of error?&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has no shadow&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Shadow can be enabled through the &amp;quot;Rendering&amp;quot; dialog right during the flight.&lt;br /&gt;
* landing, taxi and strobe lights are not implemented yet in Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
&lt;br /&gt;
3D cockpit:&lt;br /&gt;
&lt;br /&gt;
* only cockpit instruments light at night, no cockpit and panel light available yet&lt;br /&gt;
* no rudder control pedals visible&lt;br /&gt;
** Rudder position indicator could be a better addition.&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
*** They can be heard being clicked, if the camera is inside the cockpit.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly aircraft, not to sit in the cockpit and look around.&lt;br /&gt;
* &amp;lt;strike&amp;gt;one of the levers has an error, it looks like a square and it is not round like the lever should be&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
** It's a waste of polygons, not everyone has a hi-end PC. You can always turn on your imagination!&lt;br /&gt;
* &amp;lt;strike&amp;gt;cockpit window has no windscreen wipers&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers [http://skyhawk.cessna.com/].&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
** What is the expected performance according to your estimation?&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
'''There are 3 c172 downloads available at the FlightGear official site ([http://flightgear.org/Downloads/aircraft/index.shtml]):'''&lt;br /&gt;
* '''c172-le,'''&lt;br /&gt;
* '''c172p,'''&lt;br /&gt;
* '''and c172r.'''&lt;br /&gt;
'''Dear developers, please, explain how do these 3 models correlate, if they depend on each other, do they share models, sounds, etc.&lt;br /&gt;
Maybe separate wiki-pages could be created for each version.'''&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3575</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3575"/>
		<updated>2007-06-17T10:33:10Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
** What kind of error?&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has no shadow&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Shadow can be enabled through the &amp;quot;Rendering&amp;quot; dialog right during the flight.&lt;br /&gt;
* landing, taxi and strobe lights are not implemented yet in Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
&lt;br /&gt;
3D cockpit:&lt;br /&gt;
&lt;br /&gt;
* only cockpit instruments light at night, no cockpit and panel light available yet&lt;br /&gt;
* no rudder control pedals visible&lt;br /&gt;
** Rudder position indicator could be a better addition.&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
*** They can be heard being clicked, if the camera is inside the cockpit.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly aircraft, not to sit in the cockpit and look around.&lt;br /&gt;
* &amp;lt;strike&amp;gt;one of the levers has an error, it looks like a square and it is not round like the lever should be&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
** It's a waste of polygons, not everyone has a hi-end PC. You can always turn on your imagination!&lt;br /&gt;
* &amp;lt;strike&amp;gt;cockpit window has no windscreen wipers&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers [http://skyhawk.cessna.com/].&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
** What is the expected performance according to your estimation?&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
'''There are 3 c172 downloads available at the FlightGear official site ([http://flightgear.org/Downloads/aircraft/index.shtml]):&lt;br /&gt;
* c172-le,&lt;br /&gt;
* c172p,&lt;br /&gt;
* and c172r.&lt;br /&gt;
Dear developers, please, explain how do these 3 models correlate, if they depend on each other, do they share models, sounds, etc.&lt;br /&gt;
Maybe separate wiki-pages could be created for each version.'''&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3574</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3574"/>
		<updated>2007-06-17T10:24:54Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
** What kind of error?&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has no shadow&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Shadow can be enabled through the &amp;quot;Rendering&amp;quot; dialog right during the flight.&lt;br /&gt;
* landing, taxi and strobe lights are not implemented yet in Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
&lt;br /&gt;
3D cockpit:&lt;br /&gt;
&lt;br /&gt;
* only cockpit instruments light at night, no cockpit and panel light available yet&lt;br /&gt;
* no rudder control pedals visible&lt;br /&gt;
** Rudder position indicator could be a better addition.&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
*** They can be heard being clicked, if the camera is inside the cockpit.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly aircraft, not to sit in the cockpit and look around.&lt;br /&gt;
* &amp;lt;strike&amp;gt;one of the levers has an error, it looks like a square and it is not round like the lever should be&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
** It's a waste of polygons, not everyone has a hi-end PC. You can always turn on your imagination!&lt;br /&gt;
* &amp;lt;strike&amp;gt;cockpit window has no windscreen wipers&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers [http://skyhawk.cessna.com/].&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
** What is the expected performance according to your estimation?&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
There are 3 c172 downloads available at the FlightGear official site ([http://flightgear.org/Downloads/aircraft/index.shtml]) now.&lt;br /&gt;
Can the developers, please, explain in detail how this three models correlate, do they depend on each other etc. Maybe separate pages are necessary for each version.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3573</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3573"/>
		<updated>2007-06-17T10:22:03Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
** What kind of error?&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has no shadow&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Shadow can be enabled through a &amp;quot;Rendering&amp;quot; dialog right during the flight.&lt;br /&gt;
* landing, taxi and strobe lights are not implemented yet in Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
&lt;br /&gt;
3D cockpit:&lt;br /&gt;
&lt;br /&gt;
* only cockpit instruments light at night, no cockpit and panel light available yet&lt;br /&gt;
* no rudder control pedals visible&lt;br /&gt;
** Rudder position indicator could be a better addition.&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
*** They can be heard being clicked, if the camera is inside the cockpit.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly aircraft, not to sit in the cockpit and look around.&lt;br /&gt;
* &amp;lt;strike&amp;gt;one of the levers has an error, it looks like a square and it is not round like the lever should be&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
** It's a waste of polygons, not everyone has a hi-end PC. You can always turn on your imagination!&lt;br /&gt;
* &amp;lt;strike&amp;gt;cockpit window has no windscreen wipers&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers [http://skyhawk.cessna.com/].&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
There are 3 c172 downloads available at the FlightGear official site ([http://flightgear.org/Downloads/aircraft/index.shtml]) now.&lt;br /&gt;
Can the developers, please, explain in detail how this three models correlate, do they depend on each other etc. Maybe separate pages are necessary for each version.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3572</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3572"/>
		<updated>2007-06-17T10:19:36Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
** What kind of error?&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has no shadow&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Shadow can be enabled through a &amp;quot;Rendering&amp;quot; dialog right during the flight.&lt;br /&gt;
* landing, taxi and strobe lights are not implemented yet&lt;br /&gt;
&lt;br /&gt;
3D cockpit:&lt;br /&gt;
&lt;br /&gt;
* only cockpit instruments light at night, no cockpit and panel light available yet&lt;br /&gt;
* no rudder control pedals visible&lt;br /&gt;
** Rudder position indicator could be a better addition.&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
*** They can be heard being clicked, if the camera is inside the cockpit.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly aircraft, not to sit in the cockpit and look around.&lt;br /&gt;
* &amp;lt;strike&amp;gt;one of the levers has an error, it looks like a square and it is not round like the lever should be&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
** It's a waste of polygons, not everyone has a hi-end PC. You can always turn on your imagination!&lt;br /&gt;
* &amp;lt;strike&amp;gt;cockpit window has no windscreen wipers&amp;lt;/strike&amp;gt;&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers [http://skyhawk.cessna.com/].&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
There are 3 c172 downloads available at the FlightGear official site ([http://flightgear.org/Downloads/aircraft/index.shtml]) now.&lt;br /&gt;
Can the developers, please, explain in detail how this three models correlate, do they depend on each other etc. Maybe separate pages are necessary for each version.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3571</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3571"/>
		<updated>2007-06-17T09:48:32Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
* no cockpit light at night visible&lt;br /&gt;
* no pilot and co pilot visible&lt;br /&gt;
* aircraft has no shadow&lt;br /&gt;
* strobe lights barley available (the ones of the b0105 helictopter look much better)&lt;br /&gt;
** Strobes not yet implemented. Anti-collision light blinks to the front but currently shows constant red aft.&lt;br /&gt;
* landing lights are missing&lt;br /&gt;
&lt;br /&gt;
3d Cockpit:&lt;br /&gt;
&lt;br /&gt;
* cockpit instruments do light at night, but the cockpit itself stays dark&lt;br /&gt;
* no rudder control pedals available&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly the aircraft, not to sit inside the cockpit and look around.&lt;br /&gt;
* one of the levers has an error, it looks like a square and it is not round like the lever should be&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
* cockpit window has no windscreen wipers&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers.&lt;br /&gt;
* no trim postion indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* no flaps position indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
* light switches are hard to access in the 3D-cockpit of Cessna c172p Skyhawk 1981, it's difficult to read their names either&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3570</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3570"/>
		<updated>2007-06-17T09:42:36Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
* no cockpit light at night visible&lt;br /&gt;
* no pilot and co pilot visible&lt;br /&gt;
* aircraft has no shadow&lt;br /&gt;
* strobe lights barley available (the ones of the b0105 helictopter look much better)&lt;br /&gt;
** Strobes not yet implemented. Anti-collision light blinks to the front but currently shows constant red aft.&lt;br /&gt;
* landing lights are missing&lt;br /&gt;
&lt;br /&gt;
3d Cockpit:&lt;br /&gt;
&lt;br /&gt;
* cockpit instruments do light at night, but the cockpit itself stays dark&lt;br /&gt;
* no rudder control pedals available&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly the aircraft, not to sit inside the cockpit and look around.&lt;br /&gt;
* one of the levers has an error, it looks like a square and it is not round like the lever should be&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
* cockpit window has no windscreen wipers&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers.&lt;br /&gt;
* no trim indicators, no flaps indicators in the 3D-cockpit of Cessna c172p Skyhawk 1981&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3569</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3569"/>
		<updated>2007-06-17T09:24:07Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
* no cockpit light at night visible&lt;br /&gt;
* no pilot and co pilot visible&lt;br /&gt;
* aircraft has no shadow&lt;br /&gt;
* strobe lights barley available (the ones of the b0105 helictopter look much better)&lt;br /&gt;
** Strobes not yet implemented. Anti-collision light blinks to the front but currently shows constant red aft.&lt;br /&gt;
* landing lights are missing&lt;br /&gt;
&lt;br /&gt;
3d Cockpit:&lt;br /&gt;
&lt;br /&gt;
* cockpit instruments do light at night, but the cockpit itself stays dark&lt;br /&gt;
* no rudder control pedals available&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly the aircraft, not to sit inside the cockpit and look around.&lt;br /&gt;
* one of the levers has an error, it looks like a square and it is not round like the lever should be&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
* cockpit window has no windscreen wipers&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers.&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* &amp;lt;strike&amp;gt;hud is not available&amp;lt;/strike&amp;gt;&lt;br /&gt;
** A generic HUD is available for Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3568</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3568"/>
		<updated>2007-06-17T09:21:48Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
* no cockpit light at night visible&lt;br /&gt;
* no pilot and co pilot visible&lt;br /&gt;
* aircraft has no shadow&lt;br /&gt;
* strobe lights barley available (the ones of the b0105 helictopter look much better)&lt;br /&gt;
** Strobes not yet implemented. Anti-collision light blinks to the front but currently shows constant red aft.&lt;br /&gt;
* landing lights are missing&lt;br /&gt;
&lt;br /&gt;
3d Cockpit:&lt;br /&gt;
&lt;br /&gt;
* cockpit instruments do light at night, but the cockpit itself stays dark&lt;br /&gt;
* no rudder control pedals available&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly the aircraft, not to sit inside the cockpit and look around.&lt;br /&gt;
* one of the levers has an error, it looks like a square and it is not round like the lever should be&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
* cockpit window has no windscreen wipers&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers.&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear has different engine sound for outside/inside views.&lt;br /&gt;
* hud is not available&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft is flipped when pressing the reset button&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear doesn't get flipped after reset.&lt;br /&gt;
* &amp;lt;strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground, even after being reset.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3567</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3567"/>
		<updated>2007-06-17T09:15:41Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
* no cockpit light at night visible&lt;br /&gt;
* no pilot and co pilot visible&lt;br /&gt;
* aircraft has no shadow&lt;br /&gt;
* strobe lights barley available (the ones of the b0105 helictopter look much better)&lt;br /&gt;
** Strobes not yet implemented. Anti-collision light blinks to the front but currently shows constant red aft.&lt;br /&gt;
* landing lights are missing&lt;br /&gt;
&lt;br /&gt;
3d Cockpit:&lt;br /&gt;
&lt;br /&gt;
* cockpit instruments do light at night, but the cockpit itself stays dark&lt;br /&gt;
* no rudder control pedals available&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly the aircraft, not to sit inside the cockpit and look around.&lt;br /&gt;
* one of the levers has an error, it looks like a square and it is not round like the lever should be&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
* cockpit window has no windscreen wipers&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers.&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
* &amp;lt;strike&amp;gt;engine sound in cockpit does not differ from outside engine sound&amp;lt;/strike&amp;gt;&lt;br /&gt;
** It does at least in the Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear&lt;br /&gt;
* hud is not available&lt;br /&gt;
* aircraft is flipped when pressing the reset button&lt;br /&gt;
* &amp;lt;/strike&amp;gt;aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&amp;lt;/strike&amp;gt;&lt;br /&gt;
** Cessna c172p Skyhawk 1981 with 3D-cockpit that is bundled with the 0.9.10 version of FlightGear stands right on the ground.&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=North_American_OV-10A_Bronco&amp;diff=3566</id>
		<title>North American OV-10A Bronco</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=North_American_OV-10A_Bronco&amp;diff=3566"/>
		<updated>2007-06-17T08:57:17Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/ToDo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;The North American Rockwell OV-10 Bronco is a turboprop-driven light attack and cargo aircraft. Although it is a fixed-wing aircraft, its mission capabilities resemble a fast, long-range, inexpensive and reliable ultra-heavy attack helicopter. It flies at 244 knots (452 kilometers/hour), carries 3 tons of external munitions, and easily loiters for 3 or more hours. It is prized for its versatility, redundancy, load, wide field of view, short-field ability, low operational costs and ease of maintenance.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;The OV-10 has been used by the United States' Air Force, Marines and Navy, the military forces of several other nations, and the U.S. Customs Service, Bureau of Land Management, NASA and California Department of Forestry.  There is at least one airplane in private hands as well.  The OV-10 package for FlightGear contains three versions of the airplane:  A U.S. Air Forces Europe version, which models an OV-10A assigned to the 601st Tactical Control Wing at Sembach Airbase, Germany;  A California Department of Forestry version, used for fire fighting command and control; and a NASA version, used for atmospheric and aerodynamic research.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
{{infobox Aircraft&lt;br /&gt;
|image =[[Image:OV-10A2.jpg|320px]]&lt;br /&gt;
|caption =OV-10A USAFE&lt;br /&gt;
|name =North American OV-10A Bronco&lt;br /&gt;
|type =Military Aircraft&lt;br /&gt;
|authors =Capt. Slug, David Culp, Jens Thoms Toerring, Julien Pierru, Vivian Meazza&lt;br /&gt;
|fdm =JSBSim&lt;br /&gt;
|status =Production&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
{|&lt;br /&gt;
|__TOC__&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== User's Manual ==&lt;br /&gt;
&lt;br /&gt;
The FlightGear OV-10 features a user-selectable &amp;quot;easy mode&amp;quot;.  By default the airplane starts in &amp;quot;easy mode&amp;quot;. &lt;br /&gt;
&lt;br /&gt;
=== Starting procedure ===&lt;br /&gt;
[[Image:engine-panel.jpg|thumb|Engine Panel]]&lt;br /&gt;
To start the engines (not necessary in the easy mode) switch the current view to the engine panel view and:&lt;br /&gt;
&lt;br /&gt;
*switch on the Engine 1 start switch&lt;br /&gt;
*switch on the Engine 2 start switch&lt;br /&gt;
&lt;br /&gt;
Once they are started the switches fall back to the RUN position and you can hear the engines RPM go up. When the RPM stabilizes the engines are at idle and ready for take off.&lt;br /&gt;
&lt;br /&gt;
=== Armament procedure ===&lt;br /&gt;
To charge the guns (not required when in &amp;quot;easy mode&amp;quot;):&lt;br /&gt;
*Guns LH and RH switches .......... READY&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Trigger .......................... Squeeze&lt;br /&gt;
*Master Arm switch ................ OFF&lt;br /&gt;
&lt;br /&gt;
To fire the guns:&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Trigger .......................... Squeeze&lt;br /&gt;
&lt;br /&gt;
WARNING:  The Master Arm switch should be set to the OFF position bewteen firing passes.&lt;br /&gt;
&lt;br /&gt;
To Fire a rocket:&lt;br /&gt;
*Appropriate station switch ....... FIRE&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Weapons release button ........... Push&lt;br /&gt;
&lt;br /&gt;
CAUTION:  The rocket pod may be set for SINGLE or RIPPLE fire, and is not selectable from within the cockpit.&lt;br /&gt;
CAUTION:  If the station switch is mistakenly set to DROP, the entire rocket pod will be dropped.&lt;br /&gt;
&lt;br /&gt;
To drop a bomb:&lt;br /&gt;
*Appropriate station switch ....... DROP&lt;br /&gt;
*Fuse switch ...................... Select NOSE or TAIL&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Weapons release button ........... Push&lt;br /&gt;
&lt;br /&gt;
== Dimensions ==&lt;br /&gt;
[[Image:ov10a_3view.gif|thumb|OV-10A 3view|right]]&lt;br /&gt;
* Span: 40 feet (12.2 meters)&lt;br /&gt;
* Length: 41 feet, 7 inches (12.7 meters)&lt;br /&gt;
* Height: 15 feet, 1 inch (4.6 meters)&lt;br /&gt;
* Weight: Empty: 7,190 pounds (3,261 kilograms)&lt;br /&gt;
* Maximum take-off gross weight: 14,444 pounds (6,552 kilograms)&lt;br /&gt;
&lt;br /&gt;
Note that the sponsons (the small winglets attached to the fuselage) can be removed, as the CDF did with their OV-10's.  The fuselage rear cargo door could also be removed, as was necessary when dropping paratroopers.  The Air Force models did not carry the mid-wing weapons racks, and although the AIM-9 control box remained in the cockpit, the AIM-9 system was deactivated.&lt;br /&gt;
&lt;br /&gt;
== Performance ==&lt;br /&gt;
* MAXIMUM SPEED AT SEA LEVEL: 244 knots (452 kilometers/hour).  This published number may be for a very light airplane with sponsons removed.  In a more standard configuration, with a 230 gal. external fuel tank, the OV-10A would do about 180 knots indicated on a very hot day, and 220 knots on a very cold day.&lt;br /&gt;
* SERVICE CEILING: 28,800 feet (8,778 meters), but regulations limited the ceiling to 25,000 feet due to lack of cockpit pressurization.&lt;br /&gt;
* CREW: One pilot and optionally one observer (removable rear seat for greater fuselage cargo capacity).&lt;br /&gt;
* FUEL: Five self-sealing fuel tanks in wing: 252-gallon capacity (954 liters) 150-, 230-, or 300-gallon (568-, 871-, or 1,136-liter) external tank.&lt;br /&gt;
* RANGE: 700 nautical miles (1,297 kilometers) with internal fuel 1200 nautical miles (2224 kilometers) with 150-gallon (568-liter) drop tank.&lt;br /&gt;
* MISSION PERFORMANCE: 5.5 hours loiter time with 150-gallon (568-liter) drop tank50 nautical miles (93 kilometers) and 2 hours loiter time with full ordnance load.&lt;br /&gt;
* MAXIMUM DIVING SPEED:  350 knots.&lt;br /&gt;
&lt;br /&gt;
== Special Features ==&lt;br /&gt;
[[Image:OV10A-loaded.jpg|thumb|OV-10A USAFE]]&lt;br /&gt;
=== Fuel System ===&lt;br /&gt;
==== Internal Fuel System ====&lt;br /&gt;
* 5 wing stored tanks gravity fed to the engines (fuel cutoff after 15 consecutive seconds of negative G flight).&lt;br /&gt;
* default tanks if external is empty or not used.&lt;br /&gt;
&lt;br /&gt;
==== External Fuel System ====&lt;br /&gt;
* 1 230 gallons external tank fixed to external station 3, pump fed. If the pump is still activated and the tank is empty or has been dropped the pump will fail after 15 minutes, an orange light turns on on the upper right corner of the panel when pump output pressure is low .&lt;br /&gt;
[[Image:OV10A-CDF.jpg|thumb|OV-10A CDF]]&lt;br /&gt;
&lt;br /&gt;
=== Armament ===&lt;br /&gt;
(Read the armament procedure in the User's Manual section)&lt;br /&gt;
* 4 M60C 7.62mm machine guns, two in each sponson (shoot tracers, 500 rounds).&lt;br /&gt;
* 2 Mk82 500lbs bomb, with either nose or tail (delayed) fuse.&lt;br /&gt;
* 2 LAU68 2.75in rocket pods, with single or multiple fire sequence (7 rockets in each pod).&lt;br /&gt;
&lt;br /&gt;
Station Load:&lt;br /&gt;
* Station 1: LAU68 (single fire mode).&lt;br /&gt;
* Station 2: Mk82.&lt;br /&gt;
* Station 3: External Fuel tank.&lt;br /&gt;
* Station 4: Mk82.&lt;br /&gt;
* Station 5: LAU68 (ripple fire mode).&lt;br /&gt;
&lt;br /&gt;
The weight of each weapon is figured into the Flight Dynamics Model, however drag effects are not yet modeled.  The gunsight is fixed at present.  We hope to add adjustable sight depression in the future.  Note that the weapons, when released, are AI models, and as such do not know the terrain elevation.  This means it is not yet possible to mark the point of impact.  This ability may be added to FlightGear in the future.&lt;br /&gt;
&lt;br /&gt;
The trigger on your joystick is not set up to be a trigger if you are using the default FlightGear joystick bindings.  The OV-10 model will automatically re-bind your keyboard &amp;quot;space&amp;quot; key for use as a weapons release button.&lt;br /&gt;
&lt;br /&gt;
=== Radar Detector ===&lt;br /&gt;
* 1 AN/ALR 46 Radar detection system&lt;br /&gt;
&lt;br /&gt;
=== Misc. ===&lt;br /&gt;
* right engine smoke created by mixing oil into fuel thus making a white smoke (s to trigger, S to stop).&lt;br /&gt;
[[Image:OV10A-NASA-in-action.jpg|thumb|OV-10A NASA]]&lt;br /&gt;
* Parachutists:  in the Air Force version press the 'j' key to drop five parachutists from the rear of the airplane.&lt;br /&gt;
&lt;br /&gt;
* Ejection Seat:  in the Air Force version press the 'e' key to eject.&lt;br /&gt;
&lt;br /&gt;
=== Available Versions ===&lt;br /&gt;
* US Air Force Europe (USAFE), from the 601st Tactical Control Wing, based at Sembach Airbase, Germany from about 1976 to 1984, used as forward air control, light attack, observation and utility roles.&lt;br /&gt;
* California Department of Forestry (CDF), used for fire detection and combat.&lt;br /&gt;
* NASA, used for atmospheric research.&lt;br /&gt;
&lt;br /&gt;
== Development status/ToDo ==&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* full 3D model complete&lt;br /&gt;
* fully animated&lt;br /&gt;
* fully textured&lt;br /&gt;
* external models: 230gal fuel tank, Mk82 bomb, rockets, parachuters, ejection seat/parachute&lt;br /&gt;
&lt;br /&gt;
[[Image:OV10A-cockpit.jpg|thumb|OV-10A cockpit|right]]&lt;br /&gt;
&lt;br /&gt;
Cockpit:&lt;br /&gt;
&lt;br /&gt;
* All versions now have a 3D cockpit&lt;br /&gt;
* most instruments present&lt;br /&gt;
* realistic fuel system implemented&lt;br /&gt;
* working weapons and external stations release&lt;br /&gt;
&lt;br /&gt;
TODO:&lt;br /&gt;
&lt;br /&gt;
* finish 3D cockpit&lt;br /&gt;
* add ignition sequence&lt;br /&gt;
* add radar detection system (AN/ALR-46)&lt;br /&gt;
&lt;br /&gt;
(!) all the 3 versions in the new release have the same name in the aircraft selection list (US airforce 0V-10 etc.)&lt;br /&gt;
&lt;br /&gt;
(!) landing gear hangs in the air, when aircraft is on the ground&lt;br /&gt;
&lt;br /&gt;
(!) please, add the navigation and communication systems description to this operating manual&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
[http://flamebunny.homelinux.net/OV10A.php OV10A Bronco development project]&lt;br /&gt;
&lt;br /&gt;
[http://www.ov-10bronco.net/techspecs-ov10a.cfm OV10A Bronco technical specifications]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/OV-10 Wikipedia's article on OV-10 Bronco]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Military aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3565</id>
		<title>Bugs</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3565"/>
		<updated>2007-06-17T07:37:33Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Airport lighting in poor weather. */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Known Bugs ==&lt;br /&gt;
&lt;br /&gt;
This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.&lt;br /&gt;
&lt;br /&gt;
==== Incorrect altimetry. ====&lt;br /&gt;
&lt;br /&gt;
There is evidently at least one serious misconception in the&lt;br /&gt;
code that calculates atmospheric pressure, altimeter settings, &lt;br /&gt;
et cetera.  This can be easily demonstrated:&lt;br /&gt;
&lt;br /&gt;
Park at or near the threshold of runway 33 at Aspen (KASE).&lt;br /&gt;
Under standard conditions, observe that the altimeter reads&lt;br /&gt;
7820 feet MSL, as it should.&lt;br /&gt;
&lt;br /&gt;
Use the Weather : Weather Conditions dialog popup to&lt;br /&gt;
look at the ground-level altimeter setting (QNH).&lt;br /&gt;
This is bottom row in the &amp;quot;Alt (inHg)&amp;quot; column of the popup.&lt;br /&gt;
Verify that it is 29.92.&lt;br /&gt;
&lt;br /&gt;
Now use the dialog box to change this property.  Change it&lt;br /&gt;
to 30.92, a one-inch difference.&lt;br /&gt;
&lt;br /&gt;
Go to your altimeter instrument and enter the new altimeter&lt;br /&gt;
setting in the Kollsman window.  Ideally, this '''should'''&lt;br /&gt;
cause the instrument to read the correct altitude once&lt;br /&gt;
again, namely 7820 feet MSL.&lt;br /&gt;
&lt;br /&gt;
However, due to bugs, it is likely that you will observe&lt;br /&gt;
something closer to 8120.  This means the airplane is 300 &lt;br /&gt;
feet lower than the altimeter says it is.&lt;br /&gt;
&lt;br /&gt;
In case it wasn't obvious, when flying around near Aspen,&lt;br /&gt;
being 300 feet lower than you think you are can be very&lt;br /&gt;
bad for your health.&lt;br /&gt;
&lt;br /&gt;
The absolutely correct formulas for computing the altimeter &lt;br /&gt;
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
A patch to fix the altimeter has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Altimetry misnomers and misconceptions. ====&lt;br /&gt;
&lt;br /&gt;
Both the Weather Conditions popup and the atis.cxx code&lt;br /&gt;
rely on the &amp;quot;pressure-sea-level-inhg&amp;quot; property and use&lt;br /&gt;
it in ways that the altimeter setting should be used.&lt;br /&gt;
&lt;br /&gt;
For some people this may be merely a misnomer, but for&lt;br /&gt;
others it is clearly a misconception, as recent events&lt;br /&gt;
have shown.&lt;br /&gt;
&lt;br /&gt;
The fact is, the altimeter setting is '''not''' the same &lt;br /&gt;
thing as the pressure at sea level (Psl), especially when &lt;br /&gt;
the airmass has a non-standard temperature profile.&lt;br /&gt;
The altimeter setting is something&lt;br /&gt;
else;  it is properly called the altimeter setting.  It&lt;br /&gt;
is also properly called the QNH, although private pilots&lt;br /&gt;
who fly only in the US may be unfamiliar with the QNH&lt;br /&gt;
terminology.&lt;br /&gt;
&lt;br /&gt;
In the Remarks section of a METAR, you can sometimes&lt;br /&gt;
find the ''Reduced'' Sea Level Pressure, which is&lt;br /&gt;
unfortunately denoted SLP.  This METAR SLP serves&lt;br /&gt;
the same function as the altimeter setting.  Despite&lt;br /&gt;
its name, the METAR SLP is not equal to the honest-to-goodness&lt;br /&gt;
pressure at honest-to-goodness sea level (Psl), as&lt;br /&gt;
discussed in more detail on&lt;br /&gt;
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
There needs to be a facility whereby routines that need&lt;br /&gt;
the altimeter setting can obtain the altimeter setting.&lt;br /&gt;
&lt;br /&gt;
Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
Existing code sometimes treads the &amp;quot;pressure-sea-level-inhg&amp;quot; &lt;br /&gt;
property as if it were Psl, and sometimes as if it were &lt;br /&gt;
METAR SLP.  All this needs to be vetted.&lt;br /&gt;
&lt;br /&gt;
==== Newton's laws violated by environment.cxx ====&lt;br /&gt;
&lt;br /&gt;
Consider the following results of an experiment using fgfs:&lt;br /&gt;
&lt;br /&gt;
  alt:  662  mM: 0.0288  P: 99000.8462  T: 286.8563  rho: 1.1975&lt;br /&gt;
  alt: 3462  mM: 0.0288  P: 89341.6721  T: 281.3920  rho: 1.1009&lt;br /&gt;
  &lt;br /&gt;
  alt:  662  mM: 0.0289  P: 99000.8422  T: 256.9910  rho: 1.3404&lt;br /&gt;
  alt: 3462  mM: 0.0289  P: 89341.6740  T: 252.0956  rho: 1.2333&lt;br /&gt;
&lt;br /&gt;
The first pair of lines represent before and after a simple&lt;br /&gt;
flight from one airport to another, with a net gain in altitude of&lt;br /&gt;
2800 feet, under standard conditions.  So far so good.&lt;br /&gt;
&lt;br /&gt;
The second pair of lines represent exactly the same flight, &lt;br /&gt;
except that the ambient temperature was 30 degrees colder&lt;br /&gt;
than before.  You can see that the density (rho) is greater,&lt;br /&gt;
in accordance with the ideal gas law.&lt;br /&gt;
&lt;br /&gt;
The problem is that the delta_P is exactly the same for the two&lt;br /&gt;
flights.  This is a problem because P is connected to the weight&lt;br /&gt;
of the air column.  If the air is 12% denser, the laws of physics &lt;br /&gt;
require it to have a 12% steeper pressure gradient dP/dh ... but &lt;br /&gt;
alas this is not observed.&lt;br /&gt;
&lt;br /&gt;
This incorrect pressure profile P(h) has many consequences affecting&lt;br /&gt;
engine performance, airfoil performance, altimetry, et cetera.&lt;br /&gt;
&lt;br /&gt;
==== Z-buffer burn-through. ====&lt;br /&gt;
&lt;br /&gt;
Sometimes distant objects can be seen through nearer objects that&lt;br /&gt;
are not supposed to be transparent.  For example:  Runway lights &lt;br /&gt;
sometimes burn through a solid cloud layer.  Also runway lights&lt;br /&gt;
sometimes burn through aircraft structure.  Some instruments&lt;br /&gt;
burn through the yoke.&lt;br /&gt;
&lt;br /&gt;
It seems that so-called &amp;quot;2D&amp;quot; objects in the&lt;br /&gt;
background are likely to burn through &amp;quot;3D&amp;quot; objects in the&lt;br /&gt;
foreground.  This is particularly noticeable in aircraft&lt;br /&gt;
that have a mixture of 2D and 3D instruments.&lt;br /&gt;
&lt;br /&gt;
The ''position'' in space of the offending objects is OK, as&lt;br /&gt;
you can verify by shifting your PoV to get a little bit of&lt;br /&gt;
a side view.  The obvious hypothesis is that the Z-order&lt;br /&gt;
is being mishandled in a Z-buffer somewhere.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak. ====&lt;br /&gt;
&lt;br /&gt;
The simulator will gobble up about 3 gigabytes&lt;br /&gt;
of virtual memory overnight, while paused.  &lt;br /&gt;
Without the&lt;br /&gt;
leak, the memory footprint would be less than 300 meg.  The&lt;br /&gt;
difference between 300 meg and 3 gig is quite &lt;br /&gt;
significant on machines that have only 1 or 2 gig&lt;br /&gt;
of main memory.&lt;br /&gt;
&lt;br /&gt;
A rather steady leak of 2 meg per minute is observed&lt;br /&gt;
during pause, no matter whether the aircraft is aloft&lt;br /&gt;
or parked on the ground.  '''Vastly less leakage''' (two&lt;br /&gt;
orders of magnitude less, possibly zero) is observed&lt;br /&gt;
when the simulator is not paused, and the aircraft&lt;br /&gt;
is simply sitting on the ground with the parking&lt;br /&gt;
brake set.&lt;br /&gt;
&lt;br /&gt;
This bug has been observed in multiple versions of fgfs,&lt;br /&gt;
including one compiled back in May, 2006 as well as&lt;br /&gt;
the most current CVS version.&lt;br /&gt;
&lt;br /&gt;
This is 100% reproducible with a &lt;br /&gt;
ATI RV350 [Mobility Radeon 9600 M10] chipset&lt;br /&gt;
and the ati-fglrx driver.&lt;br /&gt;
The leak is observed whether or not &lt;br /&gt;
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.&lt;br /&gt;
&lt;br /&gt;
==== Numerous bugs in ATIS feature. ====&lt;br /&gt;
&lt;br /&gt;
1) The ATIS is supposed to change whenever there is a&lt;br /&gt;
significant change in the weather.  The comments mention&lt;br /&gt;
this, but the code makes no attempt to implement this.&lt;br /&gt;
&lt;br /&gt;
2) The code assumes that ATIS is prepared on the hour.&lt;br /&gt;
In practice this is virtually never the case;  a new&lt;br /&gt;
ATIS is prepared hourly, but not on the hour.  Also&lt;br /&gt;
this assumption is inconsistent with ATIS changes&lt;br /&gt;
based on the weather.&lt;br /&gt;
&lt;br /&gt;
3) The code attempts to issue a station identifier, but&lt;br /&gt;
none is heard.&lt;br /&gt;
&lt;br /&gt;
4) Multiple departures from standard phraseology.&lt;br /&gt;
&lt;br /&gt;
5) The volume is too low;  ATIS is not readable over engine noise.&lt;br /&gt;
This defeats much of the purpose of ATIS.  The volume does&lt;br /&gt;
not respond to the /instrumentation/comm[N]/volume property.&lt;br /&gt;
&lt;br /&gt;
6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.&lt;br /&gt;
&lt;br /&gt;
x) Et cetera.&lt;br /&gt;
&lt;br /&gt;
A patch to fix a few dozen ATIS bugs is available, but has not been&lt;br /&gt;
incorporated into FG CVS.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --altitude option. ====&lt;br /&gt;
&lt;br /&gt;
When the aircraft is initialzed aloft using the &lt;br /&gt;
command-line --altitude=6000&lt;br /&gt;
option, 0.9.10 is observed to put up a blank screen &lt;br /&gt;
(no scenery, no panel) and to spew on the console &lt;br /&gt;
page after page like this:&lt;br /&gt;
&lt;br /&gt;
  Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..&lt;br /&gt;
  altitude         = -1.69132e-41&lt;br /&gt;
  sea level radius = -6.54575e-42&lt;br /&gt;
  latitude         = 6.9874e-316&lt;br /&gt;
  longitude        = 6.79737e-313&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_pitch&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_volume&lt;br /&gt;
&lt;br /&gt;
==== Multiple bugs in the location-in-air popup. ====&lt;br /&gt;
&lt;br /&gt;
The location-in-air popup turns off the magnetos and extends&lt;br /&gt;
the landing gear.  Some pilots and flight instructors &lt;br /&gt;
deem this to be undesirable behavior, especially if all&lt;br /&gt;
they are trying to do is relocate from one airborne position to&lt;br /&gt;
another.&lt;br /&gt;
&lt;br /&gt;
Similarly, it strongly perturbs the throttle setting, &lt;br /&gt;
aileron trim, elevator trim, rudder trim, &lt;br /&gt;
view angles, PoV position, and who-knows-what else.  &lt;br /&gt;
Again, people who know about airplanes consider this to&lt;br /&gt;
be undesirable behavior.&lt;br /&gt;
&lt;br /&gt;
There is also a tendency to place the aircraft into &lt;br /&gt;
dangerous unusual attitudes, and other bugs too numerous &lt;br /&gt;
to mention.&lt;br /&gt;
&lt;br /&gt;
Evidently, though, there is at least one person who likes&lt;br /&gt;
things the way they are.  Code that would have fixed these&lt;br /&gt;
bugs was rejected.  Neither specific nor constructive criticism&lt;br /&gt;
of the code was offered.  For details see the flightgear-devel&lt;br /&gt;
mailing list archives.&lt;br /&gt;
&lt;br /&gt;
==== Nearest fix. ====&lt;br /&gt;
&lt;br /&gt;
Did you know that there are 8 different BRAVO intersections&lt;br /&gt;
in the database?&lt;br /&gt;
&lt;br /&gt;
Until now there was no support in the code for this;  all but&lt;br /&gt;
one of the entries was thrown away at the lowest level. There&lt;br /&gt;
is a comment in the code saying that fixing this is on the&lt;br /&gt;
TODO list.&lt;br /&gt;
&lt;br /&gt;
As for navaids (as opposed to waypoints), the low-level code&lt;br /&gt;
already provides support for ambiguous IDs, but the information&lt;br /&gt;
is not being used very wisely by the higher layers.&lt;br /&gt;
&lt;br /&gt;
Code to fix these problems was offered to the community.&lt;br /&gt;
So far it has been completely ignored.&lt;br /&gt;
&lt;br /&gt;
==== HSI instrument failure. ====&lt;br /&gt;
&lt;br /&gt;
If you use the &amp;quot;heading indicator&amp;quot; checkbox on the&lt;br /&gt;
&amp;quot;instrument failure&amp;quot; popup to command a failure,&lt;br /&gt;
it has no effect on the HSI instrument used by&lt;br /&gt;
many aircraft in the simulator fleet.&lt;br /&gt;
&lt;br /&gt;
This is because of wrong code in hsi.xml.  &lt;br /&gt;
&lt;br /&gt;
Backend code to handle this correctly exists, but has&lt;br /&gt;
apparently never been used.  It needs one small fix,&lt;br /&gt;
followed by recompilation.  A patchset to take care&lt;br /&gt;
of all this was offered to the community, but has&lt;br /&gt;
not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Flux gate not really a flux gate. ====&lt;br /&gt;
&lt;br /&gt;
In the Instrumentation director, there are three heading-related&lt;br /&gt;
.cxx files.&lt;br /&gt;
* heading_indicator.cxx : vacuum driven, with drift&lt;br /&gt;
* heading_indicator_dg.cxx : electrically driven, with drift&lt;br /&gt;
* heading_indicator_fg.cxx : electrically driven, no drift&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;fg&amp;quot; in &amp;quot;heading_indicator_fg&amp;quot; is documented to stand for&lt;br /&gt;
&amp;quot;flux gate&amp;quot;, as if the heading were slaved to a flux-gate&lt;br /&gt;
compass ... but the code does not implement any such thing.&lt;br /&gt;
All it really does is initialize the indicated heading to &lt;br /&gt;
the correct magnetic heading value, and then implement a &lt;br /&gt;
no-drift policy.  This is incorrect behavior, as can be&lt;br /&gt;
seen by flying to an area where the magnetic variation is&lt;br /&gt;
different from what it was at the start of the flight.  A&lt;br /&gt;
true slaved heading indicator would gradually accommodate&lt;br /&gt;
the new magvar.&lt;br /&gt;
&lt;br /&gt;
The correct behavior ought to be easy to implement.&lt;br /&gt;
&lt;br /&gt;
==== Weird noises during initialization. ====&lt;br /&gt;
&lt;br /&gt;
It is observed that sometimes while the simulator is starting&lt;br /&gt;
up, before things are fully operational, weird noises are&lt;br /&gt;
produced.  For example, in the c182rg, gear-in-transit&lt;br /&gt;
noises are produced for several seconds before the first&lt;br /&gt;
display becomes visible.  (According to a dump of the&lt;br /&gt;
relevant variables, there is no evidence that the gear is&lt;br /&gt;
actually in transit, and no reason why it should be.)&lt;br /&gt;
&lt;br /&gt;
Code to fix this was submitted.  So far it has been&lt;br /&gt;
ignored.&lt;br /&gt;
&lt;br /&gt;
==== Weird displays during fullscreen initialization. ====&lt;br /&gt;
&lt;br /&gt;
If the --enable-fullscreen command-line option is used, &lt;br /&gt;
the window is enlarged to full-screen size at a time&lt;br /&gt;
when initialization is only half-complete.  From this&lt;br /&gt;
time until the end of initialization, the display &lt;br /&gt;
contains weird combinations of leftover graphic objects&lt;br /&gt;
and other junk.&lt;br /&gt;
&lt;br /&gt;
This is observed no matter whether the splash-screen feature&lt;br /&gt;
is enabled or disabled.&lt;br /&gt;
&lt;br /&gt;
==== Fullscreen window sometimes misplaced. ====&lt;br /&gt;
&lt;br /&gt;
About 20% of the time, when the --enable-fullscreen command-line&lt;br /&gt;
option is used, it opens a window of the correct size, but &lt;br /&gt;
badly misplaced relative to the screen, such that only one half&lt;br /&gt;
or one quarter of the window is on-screen.&lt;br /&gt;
&lt;br /&gt;
==== Navigation databases out-of-date ====&lt;br /&gt;
&lt;br /&gt;
The database of navigation waypoints and fixes has an internal&lt;br /&gt;
date of early 2005.  It is missing quite a few useful fixes.  &lt;br /&gt;
The FAA has defined quite a few new approaches in recent years,&lt;br /&gt;
and has revised others.&lt;br /&gt;
&lt;br /&gt;
An updated version, based on a pull of the much more&lt;br /&gt;
current x-plane database, was made available.  So far&lt;br /&gt;
it has been ignored.&lt;br /&gt;
&lt;br /&gt;
Similar remarks apply to the ''navaids'' database.&lt;br /&gt;
&lt;br /&gt;
==== Ident from phantom DME. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, some VOR stations and even some localizers&lt;br /&gt;
have a colocated DME station ... but there are plenty that&lt;br /&gt;
don't.&lt;br /&gt;
&lt;br /&gt;
The DME has its own Morse ident, with a distinctive higher pitch.&lt;br /&gt;
&lt;br /&gt;
In the simulator, due to a bug in the code, all stations&lt;br /&gt;
transmit the DME Morse ident ... even stations where no&lt;br /&gt;
DME is present.&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx finds the nearest VOR or LOC on the&lt;br /&gt;
frequency, and checks to see if it is in range.  It also asks&lt;br /&gt;
for the &amp;quot;nearest&amp;quot; DME on the frequency, but makes no attempt&lt;br /&gt;
to check that it is in range.  To say the same thing the&lt;br /&gt;
other way, there is no attempt to check that the aircraft is&lt;br /&gt;
within the service volume of the DME.  Since there is almost always&lt;br /&gt;
a DME /somewhere/ on the frequency, the has_dme variable will&lt;br /&gt;
always be set true.&lt;br /&gt;
&lt;br /&gt;
For a demonstration of this bug, park at KAOO airport and &lt;br /&gt;
tune up the AOO VOR (which has no DME).  Or park at almost&lt;br /&gt;
any airport and tune up the localizer (since relatively few&lt;br /&gt;
localizers have DME).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Airport lighting in poor weather. ====&lt;br /&gt;
&lt;br /&gt;
The code in tileentry.cxx turns on airport lights according to&lt;br /&gt;
the position of the sun relative to the horizon. &amp;lt;strike&amp;gt;One consequence&lt;br /&gt;
is that the lights are off during the day.&amp;lt;/strike&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In real life, there are many circumstances where airport lights,&lt;br /&gt;
including approach lights, are turned on during the day.  At tower airports, the lights are turned on during bad weather, including weather that &lt;br /&gt;
is only slightly bad, and also turned on if requested by the pilot.  For&lt;br /&gt;
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].&lt;br /&gt;
&lt;br /&gt;
At non-towered airports, the lights are usually pilot-controlled,&lt;br /&gt;
via radio.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strike&amp;gt;The absence of lighting during daytime in poor weather detracts &lt;br /&gt;
significantly from the realism, because it affects both the&lt;br /&gt;
legality and the practicality of performing instrument approaches&lt;br /&gt;
under such conditions.&amp;lt;/strike&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* In version 0.9.10 runway lights are turned on automatically in day time if visibility is low.&lt;br /&gt;
* I agree that '''pilot controlled lights''' could be a nice feature, but it's not a bug, it's more like a wish list entry, I suppose. ([[User:Alfozavr|Alfozavr]])&lt;br /&gt;
&lt;br /&gt;
==== Holes in the ground. ====&lt;br /&gt;
&lt;br /&gt;
Ever since the first win32-build of FG-OSG, there are at least two huge &lt;br /&gt;
ground scenery holes in the the Rhine/Main/Neckar-region in Germany. &lt;br /&gt;
The first one gapes at &lt;br /&gt;
the place which was formerly known as the city of Mannheim (near the &lt;br /&gt;
airport EDFM, which is still there), the second one has swallowed up a &lt;br /&gt;
big piece of Frankfurt am Main (near EDDF) and surrounding land. &lt;br /&gt;
&lt;br /&gt;
First posted to the flightgear-devel list in November, 2006.&lt;br /&gt;
&lt;br /&gt;
==== Mixture versus Altitude. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that at&lt;br /&gt;
high altitude airports (e.g. KGCN or KASE), to obtain max&lt;br /&gt;
static RPM, it suffices to move the mixture control only a&lt;br /&gt;
few mm aft of the full-forward (full-rich) position.&lt;br /&gt;
&lt;br /&gt;
This is unrealistic.  In a real aircraft under such conditions,&lt;br /&gt;
it would be necessary to pull the mixture control back about&lt;br /&gt;
an inch to obtain max RPM.&lt;br /&gt;
&lt;br /&gt;
It's hard to say whether the carburetor is underreacting to the&lt;br /&gt;
altitude, or overreacting to the mixture control.&lt;br /&gt;
&lt;br /&gt;
==== EGT reads high. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that the&lt;br /&gt;
EGT reads toward the high end of the scale under all conditions,&lt;br /&gt;
including idle.  This is unrealistic.&lt;br /&gt;
&lt;br /&gt;
Also, the EGT reads ''off-scale'' high under high-power conditions.&lt;br /&gt;
&lt;br /&gt;
==== Flags missing from instruments. ====&lt;br /&gt;
&lt;br /&gt;
Some of the standard instruments lack status flags.  For example,&lt;br /&gt;
the GS needle goes to  mid-scale if there is no valid signal.  That'll kill you for sure.  Reportedly the hi-res instruments implement flags, but the lo-res ones don't.  Many aircraft are using the lo-res instruments.&lt;br /&gt;
&lt;br /&gt;
Either the aircraft should be upgraded to use instruments that&lt;br /&gt;
display flags, or the instruments should be upgraded to be&lt;br /&gt;
display flags.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --model-hz option. ====&lt;br /&gt;
&lt;br /&gt;
Specifying the --model-hz=10 command-line option results in the&lt;br /&gt;
following mess:&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml&lt;br /&gt;
  Sorry, wdot doesn't appear to be trimmable&lt;br /&gt;
 Trim Failed&lt;br /&gt;
  Trim Results: &lt;br /&gt;
       Angle of Attack:   7.50  wdot:  3.21e+01 Tolerance: 1e-03  Failed&lt;br /&gt;
              Throttle:   0.50  udot:  0.00e+00 Tolerance: 1e-03  Passed&lt;br /&gt;
            Pitch Trim:   0.00  qdot: -5.44e-11 Tolerance: 1e-04  Passed&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 WWarning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
     [many repeats]&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 altitude         = 9&lt;br /&gt;
 sea level radius = 4.62829e-268&lt;br /&gt;
 latitude         = 1.52075e-314&lt;br /&gt;
 longitude        = -0.0967923&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = nan&lt;br /&gt;
 sea level radius = nan&lt;br /&gt;
 latitude         = nan&lt;br /&gt;
 longitude        = nan&lt;br /&gt;
&lt;br /&gt;
and so forth.&lt;br /&gt;
&lt;br /&gt;
* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.&lt;br /&gt;
&lt;br /&gt;
==== CPU hogging. ====&lt;br /&gt;
&lt;br /&gt;
The fsgs program will happily eat up &amp;gt;98% of the cpu cycles,&lt;br /&gt;
even when the simulator is paused.  That seems excessive,&lt;br /&gt;
particularly during pause.  This is on a 2GHz machine&lt;br /&gt;
with hardware acceleration.  As a point of reference, &lt;br /&gt;
glxgears uses only a fraction of one percent of the cpu.&lt;br /&gt;
&lt;br /&gt;
* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result  if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)&lt;br /&gt;
&lt;br /&gt;
==== Out-of-bounds array reference in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the interpolation table code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the &amp;quot;message&amp;quot; handling code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Glideslope service volume. ====&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx appears to assume the glideslope&lt;br /&gt;
service volume is the same as the localizer service&lt;br /&gt;
volume.  This is quite unrealistic.&lt;br /&gt;
&lt;br /&gt;
==== Extended service volume. ====&lt;br /&gt;
&lt;br /&gt;
In some parts of the world, a goodly fraction of the&lt;br /&gt;
localizers have an expanded service volume (ESV),&lt;br /&gt;
often quite a bit larger than the standard service&lt;br /&gt;
volume you see in the AIM.  The code in navradio.cxx&lt;br /&gt;
was ignoring the service volume information in the&lt;br /&gt;
database and wrongly assuming the default values&lt;br /&gt;
applied everywhere.  Code to fix the range-related&lt;br /&gt;
part of the problem has been offered&lt;br /&gt;
but not yet incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Other service volume issues. ====&lt;br /&gt;
&lt;br /&gt;
The code  in navradio.cxx has no understanding of how &lt;br /&gt;
'''azimuth''' affects the&lt;br /&gt;
localizer.  There is more to the story than reception range.&lt;br /&gt;
It is perfectly possible to be outside the LOC service volume &lt;br /&gt;
for reasons having to do with azimuth, not range.  &lt;br /&gt;
&lt;br /&gt;
Good ident will be heard, but false localizer courses will &lt;br /&gt;
cause serious trouble for the unwary pilot.&lt;br /&gt;
&lt;br /&gt;
A patch to fix this (along with the ESV issue) has been &lt;br /&gt;
offered, but ignored.&lt;br /&gt;
&lt;br /&gt;
There are also azimuthal issues with the /glideslope/&lt;br /&gt;
service volume.  This has not yet been patched.&lt;br /&gt;
&lt;br /&gt;
==== Menu buttons having a get-together. ====&lt;br /&gt;
&lt;br /&gt;
This concerns &amp;quot;radio buttons&amp;quot; on menus, such as on the &lt;br /&gt;
location-in-air popup and elsewhere.  By definition, it should be &lt;br /&gt;
impossible to have more than one radio button pushed down at a time.&lt;br /&gt;
However, illegal situations of this sort can be created&lt;br /&gt;
using a click-and-drag gesture.  Aim at&lt;br /&gt;
a radio button, hold the mouse-button down, and drag ...&lt;br /&gt;
as if you wanted to drag the radio button to a new location.&lt;br /&gt;
This allows you to set a radio button without the others&lt;br /&gt;
being unset.  If you persist, you can have every one of&lt;br /&gt;
the buttons in the pushed-down state at the same time.&lt;br /&gt;
&lt;br /&gt;
Before you say, &amp;quot;well, don't do that then&amp;quot; or &amp;quot;garbage in,&lt;br /&gt;
garbage out&amp;quot;, let me point out that it is possible for&lt;br /&gt;
a pilot to inadvertently make a tiny dragging gesture&lt;br /&gt;
when intending only a click.  Also, when the desired&lt;br /&gt;
button is in the pushed-down state, it is easy to not&lt;br /&gt;
notice that other buttons are in the undesired state.&lt;br /&gt;
&lt;br /&gt;
==== Altimeter setting unreadable. ====&lt;br /&gt;
&lt;br /&gt;
The standard altimeter (used by the default c172p aircraft&lt;br /&gt;
and many others) had been using an unhappy hodgepodge of&lt;br /&gt;
layers.  The analog Kollsman window was unusable, because&lt;br /&gt;
it was unlabeled, and the digital altimeter setting was&lt;br /&gt;
unusable, especially at altitudes near 2500 feet, partly &lt;br /&gt;
from being behind the needle.  On a real altimeter, things&lt;br /&gt;
are positioned so that cannot happen.&lt;br /&gt;
&lt;br /&gt;
Fixing this requires using a more suitable font, moving&lt;br /&gt;
the digits over, and getting rid of conflicting extraneous&lt;br /&gt;
markings.&lt;br /&gt;
&lt;br /&gt;
A patch to implement this fix has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Memory mismanagement in subsystem_mgr. ====&lt;br /&gt;
&lt;br /&gt;
It is bad luck to apply &amp;quot;delete&amp;quot; to an object that was not&lt;br /&gt;
created with &amp;quot;new&amp;quot; ... as in line 219 of subsystem_mgr.cxx&lt;br /&gt;
&lt;br /&gt;
A patch is available, but has not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Yet more memory mismanagement. ====&lt;br /&gt;
&lt;br /&gt;
When FG is trying to exit, it is very likely to abort&lt;br /&gt;
with a message such as&lt;br /&gt;
&lt;br /&gt;
  *** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***&lt;br /&gt;
&lt;br /&gt;
There are at least three different instances of this bug,&lt;br /&gt;
each producing a different traceback.  Here is one such&lt;br /&gt;
traceback:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
#0  0xb7573947 in raise () from /lib/tls/libc.so.6&lt;br /&gt;
#1  0xb75750c9 in abort () from /lib/tls/libc.so.6&lt;br /&gt;
#2  0xb75a908a in __libc_message () from /lib/tls/libc.so.6&lt;br /&gt;
#3  0xb75b094f in _int_free () from /lib/tls/libc.so.6&lt;br /&gt;
#4  0xb75b09f2 in free () from /lib/tls/libc.so.6&lt;br /&gt;
#5  0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6&lt;br /&gt;
#6  0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766&lt;br /&gt;
#7  0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#8  0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#9  0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105&lt;br /&gt;
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237&lt;br /&gt;
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6&lt;br /&gt;
#12 0x080919c7 in fgExit (status=0) at util.cxx:120&lt;br /&gt;
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Missing Features and Traps for the Unwary ==&lt;br /&gt;
&lt;br /&gt;
==== Version number, please. ====&lt;br /&gt;
&lt;br /&gt;
It would be helpful to have an easy, documented way to ascertain the&lt;br /&gt;
version number.  A --version option on the command line would be&lt;br /&gt;
nice.  Maybe also a help::about menu item, for use while fgfs is&lt;br /&gt;
already running.&lt;br /&gt;
&lt;br /&gt;
One could imagine that info about key libraries would also be&lt;br /&gt;
helpful.&lt;br /&gt;
&lt;br /&gt;
==== Rabbits extinct. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, many airports have '''sequenced flashers''' &lt;br /&gt;
(aka the rabbit) as part of the approach-light system.&lt;br /&gt;
&lt;br /&gt;
In the FlightGear world, the sequenced flashers are inoperative&lt;br /&gt;
everywhere.  Grepping through the code suggests that no attempt&lt;br /&gt;
has been made to implement this.&lt;br /&gt;
&lt;br /&gt;
==== No comm volume control. ====&lt;br /&gt;
&lt;br /&gt;
In many aircraft including the default c172p, the comm&lt;br /&gt;
radios have no volume control knob.  In other aircraft&lt;br /&gt;
including the pa24-250, there is such a knob, but it&lt;br /&gt;
apparently isn't clickable and apparently doesn't do &lt;br /&gt;
anything.  &lt;br /&gt;
&lt;br /&gt;
In contrast, the SenecaII exemplifies the ''desired'' behavior: &lt;br /&gt;
the knob rotates when clicked and &lt;br /&gt;
correctly controls the /instrumentation/comm[N]/volume&lt;br /&gt;
property.  (This alas has no effect on the volume of ATIS&lt;br /&gt;
audio, but that must be considered an ATIS bug not a&lt;br /&gt;
Seneca bug.)&lt;br /&gt;
&lt;br /&gt;
==== Incomplete Scenery. ====&lt;br /&gt;
&lt;br /&gt;
Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ]  without installing the shared models, will get you messages such as the following:&lt;br /&gt;
&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/localizer.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml&lt;br /&gt;
&lt;br /&gt;
You might get only a few such messages, or you might get &lt;br /&gt;
screenful after screenful.&lt;br /&gt;
&lt;br /&gt;
So, make sure you download all scenery files that are needed for fgfs.&lt;br /&gt;
&lt;br /&gt;
This obviously counts as a trap for the unwary.&lt;br /&gt;
&lt;br /&gt;
- This is patently not a bug and should be moved to a &amp;quot;tips&amp;quot; section or similar.  The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...&lt;br /&gt;
&lt;br /&gt;
==== ASOS and AWOS are AWOL. ====&lt;br /&gt;
&lt;br /&gt;
At many non-tower airports (and even some tower airports) there&lt;br /&gt;
is automatic weather reporting of some kind.&lt;br /&gt;
&lt;br /&gt;
It ought to be straightforward to implement this, as a slight&lt;br /&gt;
variation on the existing ATIS feature.&lt;br /&gt;
&lt;br /&gt;
==== Roundoff problems with textranslate step and scroll. ====&lt;br /&gt;
&lt;br /&gt;
The textranslate animation is delightful for 3D animation&lt;br /&gt;
of mechanical drum-type displays as on old-fashioned&lt;br /&gt;
odometers and Hobbs meters.&lt;br /&gt;
&lt;br /&gt;
It is not, however, a convenient way to implement digital&lt;br /&gt;
readouts.  It works OK for integers, but the code in &lt;br /&gt;
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the &amp;quot;.1&amp;quot; in 122.1 MHz, particularly when the scroll-value is zero.&lt;br /&gt;
* One workaround is to stick to integers, e.g. integer kHz &lt;br /&gt;
rather than fractional MHz.&lt;br /&gt;
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.&lt;br /&gt;
* A final option (with CVS) is to use the bias tag to let the code know how to&lt;br /&gt;
handle round-off.  Use a bias value of 1/2 your smallest step value, and &lt;br /&gt;
use the same bias value on all digits.&lt;br /&gt;
&lt;br /&gt;
What we really need is a whole new support routine for dealing&lt;br /&gt;
with 3D digital displays, something at least as nice as the&lt;br /&gt;
support for 2D instruments.&lt;br /&gt;
&lt;br /&gt;
==== Broken startup banner. ====&lt;br /&gt;
&lt;br /&gt;
On startup, the simulator prints Author: Unknown and prints a bogus Date.&lt;br /&gt;
&lt;br /&gt;
The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.&lt;br /&gt;
&lt;br /&gt;
== Fixed Bugs ==&lt;br /&gt;
&lt;br /&gt;
If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).&lt;br /&gt;
&lt;br /&gt;
==== Wild accelerations at low speeds. ====&lt;br /&gt;
&lt;br /&gt;
Improper inclinometer ball indications have been observed:&lt;br /&gt;
* When parked, the ball was pegged to one side.&lt;br /&gt;
* When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.&lt;br /&gt;
&lt;br /&gt;
This was observed in the c182 model and in the default c172 model.&lt;br /&gt;
&lt;br /&gt;
Tracing indicates that the problem is not within the slip_skid_ball.cxx&lt;br /&gt;
code, but rather upstream of there, in the flight dynamics.  Tracing&lt;br /&gt;
shows that the y-accel-fps_sec values are wildly fluctuating in&lt;br /&gt;
direction, and enormous in magnitude.&lt;br /&gt;
&lt;br /&gt;
Additional evidence pointing to the FDM comes from the fact that&lt;br /&gt;
the problem is observed with JSBSim and not with larcsim (although&lt;br /&gt;
larcsim has other problems, such as drifting slowly sideways while&lt;br /&gt;
parked).&lt;br /&gt;
&lt;br /&gt;
This is important from a procedures training point of view.  &lt;br /&gt;
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi.  In a real aircraft, a pilot who found the &lt;br /&gt;
inclinometer pegged would cancel the flight before even starting&lt;br /&gt;
the engine.&lt;br /&gt;
&lt;br /&gt;
Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:&lt;br /&gt;
&lt;br /&gt;
*velocities/vdot-fps&lt;br /&gt;
*velocities/a-pilot-y-ft sec2&lt;br /&gt;
*velocities/n-pilot-y-norm&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Misdirected diagnostic in JSBSim.cxx ====&lt;br /&gt;
&lt;br /&gt;
The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout.  This made both the log and the console record hard to interpret.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====&lt;br /&gt;
&lt;br /&gt;
The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.&lt;br /&gt;
&lt;br /&gt;
Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)&lt;br /&gt;
&lt;br /&gt;
* '''This bug has not been observed in 0.9.10.'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting &amp;quot;Could not gen source&amp;quot; ====&lt;br /&gt;
&lt;br /&gt;
Any further reports or stacktraces on this bug would be appreciated.&lt;br /&gt;
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.&lt;br /&gt;
Update your sound card drivers.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed in 0.9.8a'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.7 - ? Linux - Joystick crash with correct config files ====&lt;br /&gt;
&lt;br /&gt;
Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.&lt;br /&gt;
&lt;br /&gt;
* ''' This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
==== Individual Aircraft ====&lt;br /&gt;
&lt;br /&gt;
Bugs associated with a particular aircraft should be listed&lt;br /&gt;
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.&lt;br /&gt;
&lt;br /&gt;
==== OpenSceneGraph ====&lt;br /&gt;
&lt;br /&gt;
There is a separate page for issues related to [[OpenSceneGraph]].&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3564</id>
		<title>Bugs</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3564"/>
		<updated>2007-06-17T07:36:45Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Airport lighting in poor weather. */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Known Bugs ==&lt;br /&gt;
&lt;br /&gt;
This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.&lt;br /&gt;
&lt;br /&gt;
==== Incorrect altimetry. ====&lt;br /&gt;
&lt;br /&gt;
There is evidently at least one serious misconception in the&lt;br /&gt;
code that calculates atmospheric pressure, altimeter settings, &lt;br /&gt;
et cetera.  This can be easily demonstrated:&lt;br /&gt;
&lt;br /&gt;
Park at or near the threshold of runway 33 at Aspen (KASE).&lt;br /&gt;
Under standard conditions, observe that the altimeter reads&lt;br /&gt;
7820 feet MSL, as it should.&lt;br /&gt;
&lt;br /&gt;
Use the Weather : Weather Conditions dialog popup to&lt;br /&gt;
look at the ground-level altimeter setting (QNH).&lt;br /&gt;
This is bottom row in the &amp;quot;Alt (inHg)&amp;quot; column of the popup.&lt;br /&gt;
Verify that it is 29.92.&lt;br /&gt;
&lt;br /&gt;
Now use the dialog box to change this property.  Change it&lt;br /&gt;
to 30.92, a one-inch difference.&lt;br /&gt;
&lt;br /&gt;
Go to your altimeter instrument and enter the new altimeter&lt;br /&gt;
setting in the Kollsman window.  Ideally, this '''should'''&lt;br /&gt;
cause the instrument to read the correct altitude once&lt;br /&gt;
again, namely 7820 feet MSL.&lt;br /&gt;
&lt;br /&gt;
However, due to bugs, it is likely that you will observe&lt;br /&gt;
something closer to 8120.  This means the airplane is 300 &lt;br /&gt;
feet lower than the altimeter says it is.&lt;br /&gt;
&lt;br /&gt;
In case it wasn't obvious, when flying around near Aspen,&lt;br /&gt;
being 300 feet lower than you think you are can be very&lt;br /&gt;
bad for your health.&lt;br /&gt;
&lt;br /&gt;
The absolutely correct formulas for computing the altimeter &lt;br /&gt;
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
A patch to fix the altimeter has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Altimetry misnomers and misconceptions. ====&lt;br /&gt;
&lt;br /&gt;
Both the Weather Conditions popup and the atis.cxx code&lt;br /&gt;
rely on the &amp;quot;pressure-sea-level-inhg&amp;quot; property and use&lt;br /&gt;
it in ways that the altimeter setting should be used.&lt;br /&gt;
&lt;br /&gt;
For some people this may be merely a misnomer, but for&lt;br /&gt;
others it is clearly a misconception, as recent events&lt;br /&gt;
have shown.&lt;br /&gt;
&lt;br /&gt;
The fact is, the altimeter setting is '''not''' the same &lt;br /&gt;
thing as the pressure at sea level (Psl), especially when &lt;br /&gt;
the airmass has a non-standard temperature profile.&lt;br /&gt;
The altimeter setting is something&lt;br /&gt;
else;  it is properly called the altimeter setting.  It&lt;br /&gt;
is also properly called the QNH, although private pilots&lt;br /&gt;
who fly only in the US may be unfamiliar with the QNH&lt;br /&gt;
terminology.&lt;br /&gt;
&lt;br /&gt;
In the Remarks section of a METAR, you can sometimes&lt;br /&gt;
find the ''Reduced'' Sea Level Pressure, which is&lt;br /&gt;
unfortunately denoted SLP.  This METAR SLP serves&lt;br /&gt;
the same function as the altimeter setting.  Despite&lt;br /&gt;
its name, the METAR SLP is not equal to the honest-to-goodness&lt;br /&gt;
pressure at honest-to-goodness sea level (Psl), as&lt;br /&gt;
discussed in more detail on&lt;br /&gt;
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
There needs to be a facility whereby routines that need&lt;br /&gt;
the altimeter setting can obtain the altimeter setting.&lt;br /&gt;
&lt;br /&gt;
Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
Existing code sometimes treads the &amp;quot;pressure-sea-level-inhg&amp;quot; &lt;br /&gt;
property as if it were Psl, and sometimes as if it were &lt;br /&gt;
METAR SLP.  All this needs to be vetted.&lt;br /&gt;
&lt;br /&gt;
==== Newton's laws violated by environment.cxx ====&lt;br /&gt;
&lt;br /&gt;
Consider the following results of an experiment using fgfs:&lt;br /&gt;
&lt;br /&gt;
  alt:  662  mM: 0.0288  P: 99000.8462  T: 286.8563  rho: 1.1975&lt;br /&gt;
  alt: 3462  mM: 0.0288  P: 89341.6721  T: 281.3920  rho: 1.1009&lt;br /&gt;
  &lt;br /&gt;
  alt:  662  mM: 0.0289  P: 99000.8422  T: 256.9910  rho: 1.3404&lt;br /&gt;
  alt: 3462  mM: 0.0289  P: 89341.6740  T: 252.0956  rho: 1.2333&lt;br /&gt;
&lt;br /&gt;
The first pair of lines represent before and after a simple&lt;br /&gt;
flight from one airport to another, with a net gain in altitude of&lt;br /&gt;
2800 feet, under standard conditions.  So far so good.&lt;br /&gt;
&lt;br /&gt;
The second pair of lines represent exactly the same flight, &lt;br /&gt;
except that the ambient temperature was 30 degrees colder&lt;br /&gt;
than before.  You can see that the density (rho) is greater,&lt;br /&gt;
in accordance with the ideal gas law.&lt;br /&gt;
&lt;br /&gt;
The problem is that the delta_P is exactly the same for the two&lt;br /&gt;
flights.  This is a problem because P is connected to the weight&lt;br /&gt;
of the air column.  If the air is 12% denser, the laws of physics &lt;br /&gt;
require it to have a 12% steeper pressure gradient dP/dh ... but &lt;br /&gt;
alas this is not observed.&lt;br /&gt;
&lt;br /&gt;
This incorrect pressure profile P(h) has many consequences affecting&lt;br /&gt;
engine performance, airfoil performance, altimetry, et cetera.&lt;br /&gt;
&lt;br /&gt;
==== Z-buffer burn-through. ====&lt;br /&gt;
&lt;br /&gt;
Sometimes distant objects can be seen through nearer objects that&lt;br /&gt;
are not supposed to be transparent.  For example:  Runway lights &lt;br /&gt;
sometimes burn through a solid cloud layer.  Also runway lights&lt;br /&gt;
sometimes burn through aircraft structure.  Some instruments&lt;br /&gt;
burn through the yoke.&lt;br /&gt;
&lt;br /&gt;
It seems that so-called &amp;quot;2D&amp;quot; objects in the&lt;br /&gt;
background are likely to burn through &amp;quot;3D&amp;quot; objects in the&lt;br /&gt;
foreground.  This is particularly noticeable in aircraft&lt;br /&gt;
that have a mixture of 2D and 3D instruments.&lt;br /&gt;
&lt;br /&gt;
The ''position'' in space of the offending objects is OK, as&lt;br /&gt;
you can verify by shifting your PoV to get a little bit of&lt;br /&gt;
a side view.  The obvious hypothesis is that the Z-order&lt;br /&gt;
is being mishandled in a Z-buffer somewhere.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak. ====&lt;br /&gt;
&lt;br /&gt;
The simulator will gobble up about 3 gigabytes&lt;br /&gt;
of virtual memory overnight, while paused.  &lt;br /&gt;
Without the&lt;br /&gt;
leak, the memory footprint would be less than 300 meg.  The&lt;br /&gt;
difference between 300 meg and 3 gig is quite &lt;br /&gt;
significant on machines that have only 1 or 2 gig&lt;br /&gt;
of main memory.&lt;br /&gt;
&lt;br /&gt;
A rather steady leak of 2 meg per minute is observed&lt;br /&gt;
during pause, no matter whether the aircraft is aloft&lt;br /&gt;
or parked on the ground.  '''Vastly less leakage''' (two&lt;br /&gt;
orders of magnitude less, possibly zero) is observed&lt;br /&gt;
when the simulator is not paused, and the aircraft&lt;br /&gt;
is simply sitting on the ground with the parking&lt;br /&gt;
brake set.&lt;br /&gt;
&lt;br /&gt;
This bug has been observed in multiple versions of fgfs,&lt;br /&gt;
including one compiled back in May, 2006 as well as&lt;br /&gt;
the most current CVS version.&lt;br /&gt;
&lt;br /&gt;
This is 100% reproducible with a &lt;br /&gt;
ATI RV350 [Mobility Radeon 9600 M10] chipset&lt;br /&gt;
and the ati-fglrx driver.&lt;br /&gt;
The leak is observed whether or not &lt;br /&gt;
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.&lt;br /&gt;
&lt;br /&gt;
==== Numerous bugs in ATIS feature. ====&lt;br /&gt;
&lt;br /&gt;
1) The ATIS is supposed to change whenever there is a&lt;br /&gt;
significant change in the weather.  The comments mention&lt;br /&gt;
this, but the code makes no attempt to implement this.&lt;br /&gt;
&lt;br /&gt;
2) The code assumes that ATIS is prepared on the hour.&lt;br /&gt;
In practice this is virtually never the case;  a new&lt;br /&gt;
ATIS is prepared hourly, but not on the hour.  Also&lt;br /&gt;
this assumption is inconsistent with ATIS changes&lt;br /&gt;
based on the weather.&lt;br /&gt;
&lt;br /&gt;
3) The code attempts to issue a station identifier, but&lt;br /&gt;
none is heard.&lt;br /&gt;
&lt;br /&gt;
4) Multiple departures from standard phraseology.&lt;br /&gt;
&lt;br /&gt;
5) The volume is too low;  ATIS is not readable over engine noise.&lt;br /&gt;
This defeats much of the purpose of ATIS.  The volume does&lt;br /&gt;
not respond to the /instrumentation/comm[N]/volume property.&lt;br /&gt;
&lt;br /&gt;
6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.&lt;br /&gt;
&lt;br /&gt;
x) Et cetera.&lt;br /&gt;
&lt;br /&gt;
A patch to fix a few dozen ATIS bugs is available, but has not been&lt;br /&gt;
incorporated into FG CVS.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --altitude option. ====&lt;br /&gt;
&lt;br /&gt;
When the aircraft is initialzed aloft using the &lt;br /&gt;
command-line --altitude=6000&lt;br /&gt;
option, 0.9.10 is observed to put up a blank screen &lt;br /&gt;
(no scenery, no panel) and to spew on the console &lt;br /&gt;
page after page like this:&lt;br /&gt;
&lt;br /&gt;
  Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..&lt;br /&gt;
  altitude         = -1.69132e-41&lt;br /&gt;
  sea level radius = -6.54575e-42&lt;br /&gt;
  latitude         = 6.9874e-316&lt;br /&gt;
  longitude        = 6.79737e-313&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_pitch&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_volume&lt;br /&gt;
&lt;br /&gt;
==== Multiple bugs in the location-in-air popup. ====&lt;br /&gt;
&lt;br /&gt;
The location-in-air popup turns off the magnetos and extends&lt;br /&gt;
the landing gear.  Some pilots and flight instructors &lt;br /&gt;
deem this to be undesirable behavior, especially if all&lt;br /&gt;
they are trying to do is relocate from one airborne position to&lt;br /&gt;
another.&lt;br /&gt;
&lt;br /&gt;
Similarly, it strongly perturbs the throttle setting, &lt;br /&gt;
aileron trim, elevator trim, rudder trim, &lt;br /&gt;
view angles, PoV position, and who-knows-what else.  &lt;br /&gt;
Again, people who know about airplanes consider this to&lt;br /&gt;
be undesirable behavior.&lt;br /&gt;
&lt;br /&gt;
There is also a tendency to place the aircraft into &lt;br /&gt;
dangerous unusual attitudes, and other bugs too numerous &lt;br /&gt;
to mention.&lt;br /&gt;
&lt;br /&gt;
Evidently, though, there is at least one person who likes&lt;br /&gt;
things the way they are.  Code that would have fixed these&lt;br /&gt;
bugs was rejected.  Neither specific nor constructive criticism&lt;br /&gt;
of the code was offered.  For details see the flightgear-devel&lt;br /&gt;
mailing list archives.&lt;br /&gt;
&lt;br /&gt;
==== Nearest fix. ====&lt;br /&gt;
&lt;br /&gt;
Did you know that there are 8 different BRAVO intersections&lt;br /&gt;
in the database?&lt;br /&gt;
&lt;br /&gt;
Until now there was no support in the code for this;  all but&lt;br /&gt;
one of the entries was thrown away at the lowest level. There&lt;br /&gt;
is a comment in the code saying that fixing this is on the&lt;br /&gt;
TODO list.&lt;br /&gt;
&lt;br /&gt;
As for navaids (as opposed to waypoints), the low-level code&lt;br /&gt;
already provides support for ambiguous IDs, but the information&lt;br /&gt;
is not being used very wisely by the higher layers.&lt;br /&gt;
&lt;br /&gt;
Code to fix these problems was offered to the community.&lt;br /&gt;
So far it has been completely ignored.&lt;br /&gt;
&lt;br /&gt;
==== HSI instrument failure. ====&lt;br /&gt;
&lt;br /&gt;
If you use the &amp;quot;heading indicator&amp;quot; checkbox on the&lt;br /&gt;
&amp;quot;instrument failure&amp;quot; popup to command a failure,&lt;br /&gt;
it has no effect on the HSI instrument used by&lt;br /&gt;
many aircraft in the simulator fleet.&lt;br /&gt;
&lt;br /&gt;
This is because of wrong code in hsi.xml.  &lt;br /&gt;
&lt;br /&gt;
Backend code to handle this correctly exists, but has&lt;br /&gt;
apparently never been used.  It needs one small fix,&lt;br /&gt;
followed by recompilation.  A patchset to take care&lt;br /&gt;
of all this was offered to the community, but has&lt;br /&gt;
not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Flux gate not really a flux gate. ====&lt;br /&gt;
&lt;br /&gt;
In the Instrumentation director, there are three heading-related&lt;br /&gt;
.cxx files.&lt;br /&gt;
* heading_indicator.cxx : vacuum driven, with drift&lt;br /&gt;
* heading_indicator_dg.cxx : electrically driven, with drift&lt;br /&gt;
* heading_indicator_fg.cxx : electrically driven, no drift&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;fg&amp;quot; in &amp;quot;heading_indicator_fg&amp;quot; is documented to stand for&lt;br /&gt;
&amp;quot;flux gate&amp;quot;, as if the heading were slaved to a flux-gate&lt;br /&gt;
compass ... but the code does not implement any such thing.&lt;br /&gt;
All it really does is initialize the indicated heading to &lt;br /&gt;
the correct magnetic heading value, and then implement a &lt;br /&gt;
no-drift policy.  This is incorrect behavior, as can be&lt;br /&gt;
seen by flying to an area where the magnetic variation is&lt;br /&gt;
different from what it was at the start of the flight.  A&lt;br /&gt;
true slaved heading indicator would gradually accommodate&lt;br /&gt;
the new magvar.&lt;br /&gt;
&lt;br /&gt;
The correct behavior ought to be easy to implement.&lt;br /&gt;
&lt;br /&gt;
==== Weird noises during initialization. ====&lt;br /&gt;
&lt;br /&gt;
It is observed that sometimes while the simulator is starting&lt;br /&gt;
up, before things are fully operational, weird noises are&lt;br /&gt;
produced.  For example, in the c182rg, gear-in-transit&lt;br /&gt;
noises are produced for several seconds before the first&lt;br /&gt;
display becomes visible.  (According to a dump of the&lt;br /&gt;
relevant variables, there is no evidence that the gear is&lt;br /&gt;
actually in transit, and no reason why it should be.)&lt;br /&gt;
&lt;br /&gt;
Code to fix this was submitted.  So far it has been&lt;br /&gt;
ignored.&lt;br /&gt;
&lt;br /&gt;
==== Weird displays during fullscreen initialization. ====&lt;br /&gt;
&lt;br /&gt;
If the --enable-fullscreen command-line option is used, &lt;br /&gt;
the window is enlarged to full-screen size at a time&lt;br /&gt;
when initialization is only half-complete.  From this&lt;br /&gt;
time until the end of initialization, the display &lt;br /&gt;
contains weird combinations of leftover graphic objects&lt;br /&gt;
and other junk.&lt;br /&gt;
&lt;br /&gt;
This is observed no matter whether the splash-screen feature&lt;br /&gt;
is enabled or disabled.&lt;br /&gt;
&lt;br /&gt;
==== Fullscreen window sometimes misplaced. ====&lt;br /&gt;
&lt;br /&gt;
About 20% of the time, when the --enable-fullscreen command-line&lt;br /&gt;
option is used, it opens a window of the correct size, but &lt;br /&gt;
badly misplaced relative to the screen, such that only one half&lt;br /&gt;
or one quarter of the window is on-screen.&lt;br /&gt;
&lt;br /&gt;
==== Navigation databases out-of-date ====&lt;br /&gt;
&lt;br /&gt;
The database of navigation waypoints and fixes has an internal&lt;br /&gt;
date of early 2005.  It is missing quite a few useful fixes.  &lt;br /&gt;
The FAA has defined quite a few new approaches in recent years,&lt;br /&gt;
and has revised others.&lt;br /&gt;
&lt;br /&gt;
An updated version, based on a pull of the much more&lt;br /&gt;
current x-plane database, was made available.  So far&lt;br /&gt;
it has been ignored.&lt;br /&gt;
&lt;br /&gt;
Similar remarks apply to the ''navaids'' database.&lt;br /&gt;
&lt;br /&gt;
==== Ident from phantom DME. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, some VOR stations and even some localizers&lt;br /&gt;
have a colocated DME station ... but there are plenty that&lt;br /&gt;
don't.&lt;br /&gt;
&lt;br /&gt;
The DME has its own Morse ident, with a distinctive higher pitch.&lt;br /&gt;
&lt;br /&gt;
In the simulator, due to a bug in the code, all stations&lt;br /&gt;
transmit the DME Morse ident ... even stations where no&lt;br /&gt;
DME is present.&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx finds the nearest VOR or LOC on the&lt;br /&gt;
frequency, and checks to see if it is in range.  It also asks&lt;br /&gt;
for the &amp;quot;nearest&amp;quot; DME on the frequency, but makes no attempt&lt;br /&gt;
to check that it is in range.  To say the same thing the&lt;br /&gt;
other way, there is no attempt to check that the aircraft is&lt;br /&gt;
within the service volume of the DME.  Since there is almost always&lt;br /&gt;
a DME /somewhere/ on the frequency, the has_dme variable will&lt;br /&gt;
always be set true.&lt;br /&gt;
&lt;br /&gt;
For a demonstration of this bug, park at KAOO airport and &lt;br /&gt;
tune up the AOO VOR (which has no DME).  Or park at almost&lt;br /&gt;
any airport and tune up the localizer (since relatively few&lt;br /&gt;
localizers have DME).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Airport lighting in poor weather. ====&lt;br /&gt;
&lt;br /&gt;
The code in tileentry.cxx turns on airport lights according to&lt;br /&gt;
the position of the sun relative to the horizon. &amp;lt;strike&amp;gt;One consequence&lt;br /&gt;
is that the lights are off during the day.&amp;lt;/strike&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In real life, there are many circumstances where airport lights,&lt;br /&gt;
including approach lights, are turned on during the day.  At tower airports, the lights are turned on during bad weather, including weather that &lt;br /&gt;
is only slightly bad, and also turned on if requested by the pilot.  For&lt;br /&gt;
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].&lt;br /&gt;
&lt;br /&gt;
At non-towered airports, the lights are usually pilot-controlled,&lt;br /&gt;
via radio.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strike&amp;gt;The absence of lighting during daytime in poor weather detracts &lt;br /&gt;
significantly from the realism, because it affects both the&lt;br /&gt;
legality and the practicality of performing instrument approaches&lt;br /&gt;
under such conditions.&amp;lt;/strike&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* In version 0.9.10 runway lights are turned on automatically in day time if visibility is low.&lt;br /&gt;
* I agree that '''pilot controlled lights''' could be a nice feature, but it's not a bug, it's more like a wish list entry, I suppose.&lt;br /&gt;
([[User:Alfozavr|Alfozavr]])&lt;br /&gt;
&lt;br /&gt;
==== Holes in the ground. ====&lt;br /&gt;
&lt;br /&gt;
Ever since the first win32-build of FG-OSG, there are at least two huge &lt;br /&gt;
ground scenery holes in the the Rhine/Main/Neckar-region in Germany. &lt;br /&gt;
The first one gapes at &lt;br /&gt;
the place which was formerly known as the city of Mannheim (near the &lt;br /&gt;
airport EDFM, which is still there), the second one has swallowed up a &lt;br /&gt;
big piece of Frankfurt am Main (near EDDF) and surrounding land. &lt;br /&gt;
&lt;br /&gt;
First posted to the flightgear-devel list in November, 2006.&lt;br /&gt;
&lt;br /&gt;
==== Mixture versus Altitude. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that at&lt;br /&gt;
high altitude airports (e.g. KGCN or KASE), to obtain max&lt;br /&gt;
static RPM, it suffices to move the mixture control only a&lt;br /&gt;
few mm aft of the full-forward (full-rich) position.&lt;br /&gt;
&lt;br /&gt;
This is unrealistic.  In a real aircraft under such conditions,&lt;br /&gt;
it would be necessary to pull the mixture control back about&lt;br /&gt;
an inch to obtain max RPM.&lt;br /&gt;
&lt;br /&gt;
It's hard to say whether the carburetor is underreacting to the&lt;br /&gt;
altitude, or overreacting to the mixture control.&lt;br /&gt;
&lt;br /&gt;
==== EGT reads high. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that the&lt;br /&gt;
EGT reads toward the high end of the scale under all conditions,&lt;br /&gt;
including idle.  This is unrealistic.&lt;br /&gt;
&lt;br /&gt;
Also, the EGT reads ''off-scale'' high under high-power conditions.&lt;br /&gt;
&lt;br /&gt;
==== Flags missing from instruments. ====&lt;br /&gt;
&lt;br /&gt;
Some of the standard instruments lack status flags.  For example,&lt;br /&gt;
the GS needle goes to  mid-scale if there is no valid signal.  That'll kill you for sure.  Reportedly the hi-res instruments implement flags, but the lo-res ones don't.  Many aircraft are using the lo-res instruments.&lt;br /&gt;
&lt;br /&gt;
Either the aircraft should be upgraded to use instruments that&lt;br /&gt;
display flags, or the instruments should be upgraded to be&lt;br /&gt;
display flags.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --model-hz option. ====&lt;br /&gt;
&lt;br /&gt;
Specifying the --model-hz=10 command-line option results in the&lt;br /&gt;
following mess:&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml&lt;br /&gt;
  Sorry, wdot doesn't appear to be trimmable&lt;br /&gt;
 Trim Failed&lt;br /&gt;
  Trim Results: &lt;br /&gt;
       Angle of Attack:   7.50  wdot:  3.21e+01 Tolerance: 1e-03  Failed&lt;br /&gt;
              Throttle:   0.50  udot:  0.00e+00 Tolerance: 1e-03  Passed&lt;br /&gt;
            Pitch Trim:   0.00  qdot: -5.44e-11 Tolerance: 1e-04  Passed&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 WWarning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
     [many repeats]&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 altitude         = 9&lt;br /&gt;
 sea level radius = 4.62829e-268&lt;br /&gt;
 latitude         = 1.52075e-314&lt;br /&gt;
 longitude        = -0.0967923&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = nan&lt;br /&gt;
 sea level radius = nan&lt;br /&gt;
 latitude         = nan&lt;br /&gt;
 longitude        = nan&lt;br /&gt;
&lt;br /&gt;
and so forth.&lt;br /&gt;
&lt;br /&gt;
* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.&lt;br /&gt;
&lt;br /&gt;
==== CPU hogging. ====&lt;br /&gt;
&lt;br /&gt;
The fsgs program will happily eat up &amp;gt;98% of the cpu cycles,&lt;br /&gt;
even when the simulator is paused.  That seems excessive,&lt;br /&gt;
particularly during pause.  This is on a 2GHz machine&lt;br /&gt;
with hardware acceleration.  As a point of reference, &lt;br /&gt;
glxgears uses only a fraction of one percent of the cpu.&lt;br /&gt;
&lt;br /&gt;
* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result  if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)&lt;br /&gt;
&lt;br /&gt;
==== Out-of-bounds array reference in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the interpolation table code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the &amp;quot;message&amp;quot; handling code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Glideslope service volume. ====&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx appears to assume the glideslope&lt;br /&gt;
service volume is the same as the localizer service&lt;br /&gt;
volume.  This is quite unrealistic.&lt;br /&gt;
&lt;br /&gt;
==== Extended service volume. ====&lt;br /&gt;
&lt;br /&gt;
In some parts of the world, a goodly fraction of the&lt;br /&gt;
localizers have an expanded service volume (ESV),&lt;br /&gt;
often quite a bit larger than the standard service&lt;br /&gt;
volume you see in the AIM.  The code in navradio.cxx&lt;br /&gt;
was ignoring the service volume information in the&lt;br /&gt;
database and wrongly assuming the default values&lt;br /&gt;
applied everywhere.  Code to fix the range-related&lt;br /&gt;
part of the problem has been offered&lt;br /&gt;
but not yet incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Other service volume issues. ====&lt;br /&gt;
&lt;br /&gt;
The code  in navradio.cxx has no understanding of how &lt;br /&gt;
'''azimuth''' affects the&lt;br /&gt;
localizer.  There is more to the story than reception range.&lt;br /&gt;
It is perfectly possible to be outside the LOC service volume &lt;br /&gt;
for reasons having to do with azimuth, not range.  &lt;br /&gt;
&lt;br /&gt;
Good ident will be heard, but false localizer courses will &lt;br /&gt;
cause serious trouble for the unwary pilot.&lt;br /&gt;
&lt;br /&gt;
A patch to fix this (along with the ESV issue) has been &lt;br /&gt;
offered, but ignored.&lt;br /&gt;
&lt;br /&gt;
There are also azimuthal issues with the /glideslope/&lt;br /&gt;
service volume.  This has not yet been patched.&lt;br /&gt;
&lt;br /&gt;
==== Menu buttons having a get-together. ====&lt;br /&gt;
&lt;br /&gt;
This concerns &amp;quot;radio buttons&amp;quot; on menus, such as on the &lt;br /&gt;
location-in-air popup and elsewhere.  By definition, it should be &lt;br /&gt;
impossible to have more than one radio button pushed down at a time.&lt;br /&gt;
However, illegal situations of this sort can be created&lt;br /&gt;
using a click-and-drag gesture.  Aim at&lt;br /&gt;
a radio button, hold the mouse-button down, and drag ...&lt;br /&gt;
as if you wanted to drag the radio button to a new location.&lt;br /&gt;
This allows you to set a radio button without the others&lt;br /&gt;
being unset.  If you persist, you can have every one of&lt;br /&gt;
the buttons in the pushed-down state at the same time.&lt;br /&gt;
&lt;br /&gt;
Before you say, &amp;quot;well, don't do that then&amp;quot; or &amp;quot;garbage in,&lt;br /&gt;
garbage out&amp;quot;, let me point out that it is possible for&lt;br /&gt;
a pilot to inadvertently make a tiny dragging gesture&lt;br /&gt;
when intending only a click.  Also, when the desired&lt;br /&gt;
button is in the pushed-down state, it is easy to not&lt;br /&gt;
notice that other buttons are in the undesired state.&lt;br /&gt;
&lt;br /&gt;
==== Altimeter setting unreadable. ====&lt;br /&gt;
&lt;br /&gt;
The standard altimeter (used by the default c172p aircraft&lt;br /&gt;
and many others) had been using an unhappy hodgepodge of&lt;br /&gt;
layers.  The analog Kollsman window was unusable, because&lt;br /&gt;
it was unlabeled, and the digital altimeter setting was&lt;br /&gt;
unusable, especially at altitudes near 2500 feet, partly &lt;br /&gt;
from being behind the needle.  On a real altimeter, things&lt;br /&gt;
are positioned so that cannot happen.&lt;br /&gt;
&lt;br /&gt;
Fixing this requires using a more suitable font, moving&lt;br /&gt;
the digits over, and getting rid of conflicting extraneous&lt;br /&gt;
markings.&lt;br /&gt;
&lt;br /&gt;
A patch to implement this fix has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Memory mismanagement in subsystem_mgr. ====&lt;br /&gt;
&lt;br /&gt;
It is bad luck to apply &amp;quot;delete&amp;quot; to an object that was not&lt;br /&gt;
created with &amp;quot;new&amp;quot; ... as in line 219 of subsystem_mgr.cxx&lt;br /&gt;
&lt;br /&gt;
A patch is available, but has not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Yet more memory mismanagement. ====&lt;br /&gt;
&lt;br /&gt;
When FG is trying to exit, it is very likely to abort&lt;br /&gt;
with a message such as&lt;br /&gt;
&lt;br /&gt;
  *** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***&lt;br /&gt;
&lt;br /&gt;
There are at least three different instances of this bug,&lt;br /&gt;
each producing a different traceback.  Here is one such&lt;br /&gt;
traceback:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
#0  0xb7573947 in raise () from /lib/tls/libc.so.6&lt;br /&gt;
#1  0xb75750c9 in abort () from /lib/tls/libc.so.6&lt;br /&gt;
#2  0xb75a908a in __libc_message () from /lib/tls/libc.so.6&lt;br /&gt;
#3  0xb75b094f in _int_free () from /lib/tls/libc.so.6&lt;br /&gt;
#4  0xb75b09f2 in free () from /lib/tls/libc.so.6&lt;br /&gt;
#5  0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6&lt;br /&gt;
#6  0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766&lt;br /&gt;
#7  0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#8  0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#9  0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105&lt;br /&gt;
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237&lt;br /&gt;
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6&lt;br /&gt;
#12 0x080919c7 in fgExit (status=0) at util.cxx:120&lt;br /&gt;
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Missing Features and Traps for the Unwary ==&lt;br /&gt;
&lt;br /&gt;
==== Version number, please. ====&lt;br /&gt;
&lt;br /&gt;
It would be helpful to have an easy, documented way to ascertain the&lt;br /&gt;
version number.  A --version option on the command line would be&lt;br /&gt;
nice.  Maybe also a help::about menu item, for use while fgfs is&lt;br /&gt;
already running.&lt;br /&gt;
&lt;br /&gt;
One could imagine that info about key libraries would also be&lt;br /&gt;
helpful.&lt;br /&gt;
&lt;br /&gt;
==== Rabbits extinct. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, many airports have '''sequenced flashers''' &lt;br /&gt;
(aka the rabbit) as part of the approach-light system.&lt;br /&gt;
&lt;br /&gt;
In the FlightGear world, the sequenced flashers are inoperative&lt;br /&gt;
everywhere.  Grepping through the code suggests that no attempt&lt;br /&gt;
has been made to implement this.&lt;br /&gt;
&lt;br /&gt;
==== No comm volume control. ====&lt;br /&gt;
&lt;br /&gt;
In many aircraft including the default c172p, the comm&lt;br /&gt;
radios have no volume control knob.  In other aircraft&lt;br /&gt;
including the pa24-250, there is such a knob, but it&lt;br /&gt;
apparently isn't clickable and apparently doesn't do &lt;br /&gt;
anything.  &lt;br /&gt;
&lt;br /&gt;
In contrast, the SenecaII exemplifies the ''desired'' behavior: &lt;br /&gt;
the knob rotates when clicked and &lt;br /&gt;
correctly controls the /instrumentation/comm[N]/volume&lt;br /&gt;
property.  (This alas has no effect on the volume of ATIS&lt;br /&gt;
audio, but that must be considered an ATIS bug not a&lt;br /&gt;
Seneca bug.)&lt;br /&gt;
&lt;br /&gt;
==== Incomplete Scenery. ====&lt;br /&gt;
&lt;br /&gt;
Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ]  without installing the shared models, will get you messages such as the following:&lt;br /&gt;
&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/localizer.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml&lt;br /&gt;
&lt;br /&gt;
You might get only a few such messages, or you might get &lt;br /&gt;
screenful after screenful.&lt;br /&gt;
&lt;br /&gt;
So, make sure you download all scenery files that are needed for fgfs.&lt;br /&gt;
&lt;br /&gt;
This obviously counts as a trap for the unwary.&lt;br /&gt;
&lt;br /&gt;
- This is patently not a bug and should be moved to a &amp;quot;tips&amp;quot; section or similar.  The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...&lt;br /&gt;
&lt;br /&gt;
==== ASOS and AWOS are AWOL. ====&lt;br /&gt;
&lt;br /&gt;
At many non-tower airports (and even some tower airports) there&lt;br /&gt;
is automatic weather reporting of some kind.&lt;br /&gt;
&lt;br /&gt;
It ought to be straightforward to implement this, as a slight&lt;br /&gt;
variation on the existing ATIS feature.&lt;br /&gt;
&lt;br /&gt;
==== Roundoff problems with textranslate step and scroll. ====&lt;br /&gt;
&lt;br /&gt;
The textranslate animation is delightful for 3D animation&lt;br /&gt;
of mechanical drum-type displays as on old-fashioned&lt;br /&gt;
odometers and Hobbs meters.&lt;br /&gt;
&lt;br /&gt;
It is not, however, a convenient way to implement digital&lt;br /&gt;
readouts.  It works OK for integers, but the code in &lt;br /&gt;
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the &amp;quot;.1&amp;quot; in 122.1 MHz, particularly when the scroll-value is zero.&lt;br /&gt;
* One workaround is to stick to integers, e.g. integer kHz &lt;br /&gt;
rather than fractional MHz.&lt;br /&gt;
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.&lt;br /&gt;
* A final option (with CVS) is to use the bias tag to let the code know how to&lt;br /&gt;
handle round-off.  Use a bias value of 1/2 your smallest step value, and &lt;br /&gt;
use the same bias value on all digits.&lt;br /&gt;
&lt;br /&gt;
What we really need is a whole new support routine for dealing&lt;br /&gt;
with 3D digital displays, something at least as nice as the&lt;br /&gt;
support for 2D instruments.&lt;br /&gt;
&lt;br /&gt;
==== Broken startup banner. ====&lt;br /&gt;
&lt;br /&gt;
On startup, the simulator prints Author: Unknown and prints a bogus Date.&lt;br /&gt;
&lt;br /&gt;
The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.&lt;br /&gt;
&lt;br /&gt;
== Fixed Bugs ==&lt;br /&gt;
&lt;br /&gt;
If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).&lt;br /&gt;
&lt;br /&gt;
==== Wild accelerations at low speeds. ====&lt;br /&gt;
&lt;br /&gt;
Improper inclinometer ball indications have been observed:&lt;br /&gt;
* When parked, the ball was pegged to one side.&lt;br /&gt;
* When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.&lt;br /&gt;
&lt;br /&gt;
This was observed in the c182 model and in the default c172 model.&lt;br /&gt;
&lt;br /&gt;
Tracing indicates that the problem is not within the slip_skid_ball.cxx&lt;br /&gt;
code, but rather upstream of there, in the flight dynamics.  Tracing&lt;br /&gt;
shows that the y-accel-fps_sec values are wildly fluctuating in&lt;br /&gt;
direction, and enormous in magnitude.&lt;br /&gt;
&lt;br /&gt;
Additional evidence pointing to the FDM comes from the fact that&lt;br /&gt;
the problem is observed with JSBSim and not with larcsim (although&lt;br /&gt;
larcsim has other problems, such as drifting slowly sideways while&lt;br /&gt;
parked).&lt;br /&gt;
&lt;br /&gt;
This is important from a procedures training point of view.  &lt;br /&gt;
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi.  In a real aircraft, a pilot who found the &lt;br /&gt;
inclinometer pegged would cancel the flight before even starting&lt;br /&gt;
the engine.&lt;br /&gt;
&lt;br /&gt;
Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:&lt;br /&gt;
&lt;br /&gt;
*velocities/vdot-fps&lt;br /&gt;
*velocities/a-pilot-y-ft sec2&lt;br /&gt;
*velocities/n-pilot-y-norm&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Misdirected diagnostic in JSBSim.cxx ====&lt;br /&gt;
&lt;br /&gt;
The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout.  This made both the log and the console record hard to interpret.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====&lt;br /&gt;
&lt;br /&gt;
The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.&lt;br /&gt;
&lt;br /&gt;
Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)&lt;br /&gt;
&lt;br /&gt;
* '''This bug has not been observed in 0.9.10.'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting &amp;quot;Could not gen source&amp;quot; ====&lt;br /&gt;
&lt;br /&gt;
Any further reports or stacktraces on this bug would be appreciated.&lt;br /&gt;
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.&lt;br /&gt;
Update your sound card drivers.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed in 0.9.8a'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.7 - ? Linux - Joystick crash with correct config files ====&lt;br /&gt;
&lt;br /&gt;
Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.&lt;br /&gt;
&lt;br /&gt;
* ''' This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
==== Individual Aircraft ====&lt;br /&gt;
&lt;br /&gt;
Bugs associated with a particular aircraft should be listed&lt;br /&gt;
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.&lt;br /&gt;
&lt;br /&gt;
==== OpenSceneGraph ====&lt;br /&gt;
&lt;br /&gt;
There is a separate page for issues related to [[OpenSceneGraph]].&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3563</id>
		<title>Bugs</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3563"/>
		<updated>2007-06-17T07:34:21Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Airport lighting in poor weather. */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Known Bugs ==&lt;br /&gt;
&lt;br /&gt;
This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.&lt;br /&gt;
&lt;br /&gt;
==== Incorrect altimetry. ====&lt;br /&gt;
&lt;br /&gt;
There is evidently at least one serious misconception in the&lt;br /&gt;
code that calculates atmospheric pressure, altimeter settings, &lt;br /&gt;
et cetera.  This can be easily demonstrated:&lt;br /&gt;
&lt;br /&gt;
Park at or near the threshold of runway 33 at Aspen (KASE).&lt;br /&gt;
Under standard conditions, observe that the altimeter reads&lt;br /&gt;
7820 feet MSL, as it should.&lt;br /&gt;
&lt;br /&gt;
Use the Weather : Weather Conditions dialog popup to&lt;br /&gt;
look at the ground-level altimeter setting (QNH).&lt;br /&gt;
This is bottom row in the &amp;quot;Alt (inHg)&amp;quot; column of the popup.&lt;br /&gt;
Verify that it is 29.92.&lt;br /&gt;
&lt;br /&gt;
Now use the dialog box to change this property.  Change it&lt;br /&gt;
to 30.92, a one-inch difference.&lt;br /&gt;
&lt;br /&gt;
Go to your altimeter instrument and enter the new altimeter&lt;br /&gt;
setting in the Kollsman window.  Ideally, this '''should'''&lt;br /&gt;
cause the instrument to read the correct altitude once&lt;br /&gt;
again, namely 7820 feet MSL.&lt;br /&gt;
&lt;br /&gt;
However, due to bugs, it is likely that you will observe&lt;br /&gt;
something closer to 8120.  This means the airplane is 300 &lt;br /&gt;
feet lower than the altimeter says it is.&lt;br /&gt;
&lt;br /&gt;
In case it wasn't obvious, when flying around near Aspen,&lt;br /&gt;
being 300 feet lower than you think you are can be very&lt;br /&gt;
bad for your health.&lt;br /&gt;
&lt;br /&gt;
The absolutely correct formulas for computing the altimeter &lt;br /&gt;
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
A patch to fix the altimeter has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Altimetry misnomers and misconceptions. ====&lt;br /&gt;
&lt;br /&gt;
Both the Weather Conditions popup and the atis.cxx code&lt;br /&gt;
rely on the &amp;quot;pressure-sea-level-inhg&amp;quot; property and use&lt;br /&gt;
it in ways that the altimeter setting should be used.&lt;br /&gt;
&lt;br /&gt;
For some people this may be merely a misnomer, but for&lt;br /&gt;
others it is clearly a misconception, as recent events&lt;br /&gt;
have shown.&lt;br /&gt;
&lt;br /&gt;
The fact is, the altimeter setting is '''not''' the same &lt;br /&gt;
thing as the pressure at sea level (Psl), especially when &lt;br /&gt;
the airmass has a non-standard temperature profile.&lt;br /&gt;
The altimeter setting is something&lt;br /&gt;
else;  it is properly called the altimeter setting.  It&lt;br /&gt;
is also properly called the QNH, although private pilots&lt;br /&gt;
who fly only in the US may be unfamiliar with the QNH&lt;br /&gt;
terminology.&lt;br /&gt;
&lt;br /&gt;
In the Remarks section of a METAR, you can sometimes&lt;br /&gt;
find the ''Reduced'' Sea Level Pressure, which is&lt;br /&gt;
unfortunately denoted SLP.  This METAR SLP serves&lt;br /&gt;
the same function as the altimeter setting.  Despite&lt;br /&gt;
its name, the METAR SLP is not equal to the honest-to-goodness&lt;br /&gt;
pressure at honest-to-goodness sea level (Psl), as&lt;br /&gt;
discussed in more detail on&lt;br /&gt;
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
There needs to be a facility whereby routines that need&lt;br /&gt;
the altimeter setting can obtain the altimeter setting.&lt;br /&gt;
&lt;br /&gt;
Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
Existing code sometimes treads the &amp;quot;pressure-sea-level-inhg&amp;quot; &lt;br /&gt;
property as if it were Psl, and sometimes as if it were &lt;br /&gt;
METAR SLP.  All this needs to be vetted.&lt;br /&gt;
&lt;br /&gt;
==== Newton's laws violated by environment.cxx ====&lt;br /&gt;
&lt;br /&gt;
Consider the following results of an experiment using fgfs:&lt;br /&gt;
&lt;br /&gt;
  alt:  662  mM: 0.0288  P: 99000.8462  T: 286.8563  rho: 1.1975&lt;br /&gt;
  alt: 3462  mM: 0.0288  P: 89341.6721  T: 281.3920  rho: 1.1009&lt;br /&gt;
  &lt;br /&gt;
  alt:  662  mM: 0.0289  P: 99000.8422  T: 256.9910  rho: 1.3404&lt;br /&gt;
  alt: 3462  mM: 0.0289  P: 89341.6740  T: 252.0956  rho: 1.2333&lt;br /&gt;
&lt;br /&gt;
The first pair of lines represent before and after a simple&lt;br /&gt;
flight from one airport to another, with a net gain in altitude of&lt;br /&gt;
2800 feet, under standard conditions.  So far so good.&lt;br /&gt;
&lt;br /&gt;
The second pair of lines represent exactly the same flight, &lt;br /&gt;
except that the ambient temperature was 30 degrees colder&lt;br /&gt;
than before.  You can see that the density (rho) is greater,&lt;br /&gt;
in accordance with the ideal gas law.&lt;br /&gt;
&lt;br /&gt;
The problem is that the delta_P is exactly the same for the two&lt;br /&gt;
flights.  This is a problem because P is connected to the weight&lt;br /&gt;
of the air column.  If the air is 12% denser, the laws of physics &lt;br /&gt;
require it to have a 12% steeper pressure gradient dP/dh ... but &lt;br /&gt;
alas this is not observed.&lt;br /&gt;
&lt;br /&gt;
This incorrect pressure profile P(h) has many consequences affecting&lt;br /&gt;
engine performance, airfoil performance, altimetry, et cetera.&lt;br /&gt;
&lt;br /&gt;
==== Z-buffer burn-through. ====&lt;br /&gt;
&lt;br /&gt;
Sometimes distant objects can be seen through nearer objects that&lt;br /&gt;
are not supposed to be transparent.  For example:  Runway lights &lt;br /&gt;
sometimes burn through a solid cloud layer.  Also runway lights&lt;br /&gt;
sometimes burn through aircraft structure.  Some instruments&lt;br /&gt;
burn through the yoke.&lt;br /&gt;
&lt;br /&gt;
It seems that so-called &amp;quot;2D&amp;quot; objects in the&lt;br /&gt;
background are likely to burn through &amp;quot;3D&amp;quot; objects in the&lt;br /&gt;
foreground.  This is particularly noticeable in aircraft&lt;br /&gt;
that have a mixture of 2D and 3D instruments.&lt;br /&gt;
&lt;br /&gt;
The ''position'' in space of the offending objects is OK, as&lt;br /&gt;
you can verify by shifting your PoV to get a little bit of&lt;br /&gt;
a side view.  The obvious hypothesis is that the Z-order&lt;br /&gt;
is being mishandled in a Z-buffer somewhere.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak. ====&lt;br /&gt;
&lt;br /&gt;
The simulator will gobble up about 3 gigabytes&lt;br /&gt;
of virtual memory overnight, while paused.  &lt;br /&gt;
Without the&lt;br /&gt;
leak, the memory footprint would be less than 300 meg.  The&lt;br /&gt;
difference between 300 meg and 3 gig is quite &lt;br /&gt;
significant on machines that have only 1 or 2 gig&lt;br /&gt;
of main memory.&lt;br /&gt;
&lt;br /&gt;
A rather steady leak of 2 meg per minute is observed&lt;br /&gt;
during pause, no matter whether the aircraft is aloft&lt;br /&gt;
or parked on the ground.  '''Vastly less leakage''' (two&lt;br /&gt;
orders of magnitude less, possibly zero) is observed&lt;br /&gt;
when the simulator is not paused, and the aircraft&lt;br /&gt;
is simply sitting on the ground with the parking&lt;br /&gt;
brake set.&lt;br /&gt;
&lt;br /&gt;
This bug has been observed in multiple versions of fgfs,&lt;br /&gt;
including one compiled back in May, 2006 as well as&lt;br /&gt;
the most current CVS version.&lt;br /&gt;
&lt;br /&gt;
This is 100% reproducible with a &lt;br /&gt;
ATI RV350 [Mobility Radeon 9600 M10] chipset&lt;br /&gt;
and the ati-fglrx driver.&lt;br /&gt;
The leak is observed whether or not &lt;br /&gt;
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.&lt;br /&gt;
&lt;br /&gt;
==== Numerous bugs in ATIS feature. ====&lt;br /&gt;
&lt;br /&gt;
1) The ATIS is supposed to change whenever there is a&lt;br /&gt;
significant change in the weather.  The comments mention&lt;br /&gt;
this, but the code makes no attempt to implement this.&lt;br /&gt;
&lt;br /&gt;
2) The code assumes that ATIS is prepared on the hour.&lt;br /&gt;
In practice this is virtually never the case;  a new&lt;br /&gt;
ATIS is prepared hourly, but not on the hour.  Also&lt;br /&gt;
this assumption is inconsistent with ATIS changes&lt;br /&gt;
based on the weather.&lt;br /&gt;
&lt;br /&gt;
3) The code attempts to issue a station identifier, but&lt;br /&gt;
none is heard.&lt;br /&gt;
&lt;br /&gt;
4) Multiple departures from standard phraseology.&lt;br /&gt;
&lt;br /&gt;
5) The volume is too low;  ATIS is not readable over engine noise.&lt;br /&gt;
This defeats much of the purpose of ATIS.  The volume does&lt;br /&gt;
not respond to the /instrumentation/comm[N]/volume property.&lt;br /&gt;
&lt;br /&gt;
6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.&lt;br /&gt;
&lt;br /&gt;
x) Et cetera.&lt;br /&gt;
&lt;br /&gt;
A patch to fix a few dozen ATIS bugs is available, but has not been&lt;br /&gt;
incorporated into FG CVS.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --altitude option. ====&lt;br /&gt;
&lt;br /&gt;
When the aircraft is initialzed aloft using the &lt;br /&gt;
command-line --altitude=6000&lt;br /&gt;
option, 0.9.10 is observed to put up a blank screen &lt;br /&gt;
(no scenery, no panel) and to spew on the console &lt;br /&gt;
page after page like this:&lt;br /&gt;
&lt;br /&gt;
  Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..&lt;br /&gt;
  altitude         = -1.69132e-41&lt;br /&gt;
  sea level radius = -6.54575e-42&lt;br /&gt;
  latitude         = 6.9874e-316&lt;br /&gt;
  longitude        = 6.79737e-313&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_pitch&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_volume&lt;br /&gt;
&lt;br /&gt;
==== Multiple bugs in the location-in-air popup. ====&lt;br /&gt;
&lt;br /&gt;
The location-in-air popup turns off the magnetos and extends&lt;br /&gt;
the landing gear.  Some pilots and flight instructors &lt;br /&gt;
deem this to be undesirable behavior, especially if all&lt;br /&gt;
they are trying to do is relocate from one airborne position to&lt;br /&gt;
another.&lt;br /&gt;
&lt;br /&gt;
Similarly, it strongly perturbs the throttle setting, &lt;br /&gt;
aileron trim, elevator trim, rudder trim, &lt;br /&gt;
view angles, PoV position, and who-knows-what else.  &lt;br /&gt;
Again, people who know about airplanes consider this to&lt;br /&gt;
be undesirable behavior.&lt;br /&gt;
&lt;br /&gt;
There is also a tendency to place the aircraft into &lt;br /&gt;
dangerous unusual attitudes, and other bugs too numerous &lt;br /&gt;
to mention.&lt;br /&gt;
&lt;br /&gt;
Evidently, though, there is at least one person who likes&lt;br /&gt;
things the way they are.  Code that would have fixed these&lt;br /&gt;
bugs was rejected.  Neither specific nor constructive criticism&lt;br /&gt;
of the code was offered.  For details see the flightgear-devel&lt;br /&gt;
mailing list archives.&lt;br /&gt;
&lt;br /&gt;
==== Nearest fix. ====&lt;br /&gt;
&lt;br /&gt;
Did you know that there are 8 different BRAVO intersections&lt;br /&gt;
in the database?&lt;br /&gt;
&lt;br /&gt;
Until now there was no support in the code for this;  all but&lt;br /&gt;
one of the entries was thrown away at the lowest level. There&lt;br /&gt;
is a comment in the code saying that fixing this is on the&lt;br /&gt;
TODO list.&lt;br /&gt;
&lt;br /&gt;
As for navaids (as opposed to waypoints), the low-level code&lt;br /&gt;
already provides support for ambiguous IDs, but the information&lt;br /&gt;
is not being used very wisely by the higher layers.&lt;br /&gt;
&lt;br /&gt;
Code to fix these problems was offered to the community.&lt;br /&gt;
So far it has been completely ignored.&lt;br /&gt;
&lt;br /&gt;
==== HSI instrument failure. ====&lt;br /&gt;
&lt;br /&gt;
If you use the &amp;quot;heading indicator&amp;quot; checkbox on the&lt;br /&gt;
&amp;quot;instrument failure&amp;quot; popup to command a failure,&lt;br /&gt;
it has no effect on the HSI instrument used by&lt;br /&gt;
many aircraft in the simulator fleet.&lt;br /&gt;
&lt;br /&gt;
This is because of wrong code in hsi.xml.  &lt;br /&gt;
&lt;br /&gt;
Backend code to handle this correctly exists, but has&lt;br /&gt;
apparently never been used.  It needs one small fix,&lt;br /&gt;
followed by recompilation.  A patchset to take care&lt;br /&gt;
of all this was offered to the community, but has&lt;br /&gt;
not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Flux gate not really a flux gate. ====&lt;br /&gt;
&lt;br /&gt;
In the Instrumentation director, there are three heading-related&lt;br /&gt;
.cxx files.&lt;br /&gt;
* heading_indicator.cxx : vacuum driven, with drift&lt;br /&gt;
* heading_indicator_dg.cxx : electrically driven, with drift&lt;br /&gt;
* heading_indicator_fg.cxx : electrically driven, no drift&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;fg&amp;quot; in &amp;quot;heading_indicator_fg&amp;quot; is documented to stand for&lt;br /&gt;
&amp;quot;flux gate&amp;quot;, as if the heading were slaved to a flux-gate&lt;br /&gt;
compass ... but the code does not implement any such thing.&lt;br /&gt;
All it really does is initialize the indicated heading to &lt;br /&gt;
the correct magnetic heading value, and then implement a &lt;br /&gt;
no-drift policy.  This is incorrect behavior, as can be&lt;br /&gt;
seen by flying to an area where the magnetic variation is&lt;br /&gt;
different from what it was at the start of the flight.  A&lt;br /&gt;
true slaved heading indicator would gradually accommodate&lt;br /&gt;
the new magvar.&lt;br /&gt;
&lt;br /&gt;
The correct behavior ought to be easy to implement.&lt;br /&gt;
&lt;br /&gt;
==== Weird noises during initialization. ====&lt;br /&gt;
&lt;br /&gt;
It is observed that sometimes while the simulator is starting&lt;br /&gt;
up, before things are fully operational, weird noises are&lt;br /&gt;
produced.  For example, in the c182rg, gear-in-transit&lt;br /&gt;
noises are produced for several seconds before the first&lt;br /&gt;
display becomes visible.  (According to a dump of the&lt;br /&gt;
relevant variables, there is no evidence that the gear is&lt;br /&gt;
actually in transit, and no reason why it should be.)&lt;br /&gt;
&lt;br /&gt;
Code to fix this was submitted.  So far it has been&lt;br /&gt;
ignored.&lt;br /&gt;
&lt;br /&gt;
==== Weird displays during fullscreen initialization. ====&lt;br /&gt;
&lt;br /&gt;
If the --enable-fullscreen command-line option is used, &lt;br /&gt;
the window is enlarged to full-screen size at a time&lt;br /&gt;
when initialization is only half-complete.  From this&lt;br /&gt;
time until the end of initialization, the display &lt;br /&gt;
contains weird combinations of leftover graphic objects&lt;br /&gt;
and other junk.&lt;br /&gt;
&lt;br /&gt;
This is observed no matter whether the splash-screen feature&lt;br /&gt;
is enabled or disabled.&lt;br /&gt;
&lt;br /&gt;
==== Fullscreen window sometimes misplaced. ====&lt;br /&gt;
&lt;br /&gt;
About 20% of the time, when the --enable-fullscreen command-line&lt;br /&gt;
option is used, it opens a window of the correct size, but &lt;br /&gt;
badly misplaced relative to the screen, such that only one half&lt;br /&gt;
or one quarter of the window is on-screen.&lt;br /&gt;
&lt;br /&gt;
==== Navigation databases out-of-date ====&lt;br /&gt;
&lt;br /&gt;
The database of navigation waypoints and fixes has an internal&lt;br /&gt;
date of early 2005.  It is missing quite a few useful fixes.  &lt;br /&gt;
The FAA has defined quite a few new approaches in recent years,&lt;br /&gt;
and has revised others.&lt;br /&gt;
&lt;br /&gt;
An updated version, based on a pull of the much more&lt;br /&gt;
current x-plane database, was made available.  So far&lt;br /&gt;
it has been ignored.&lt;br /&gt;
&lt;br /&gt;
Similar remarks apply to the ''navaids'' database.&lt;br /&gt;
&lt;br /&gt;
==== Ident from phantom DME. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, some VOR stations and even some localizers&lt;br /&gt;
have a colocated DME station ... but there are plenty that&lt;br /&gt;
don't.&lt;br /&gt;
&lt;br /&gt;
The DME has its own Morse ident, with a distinctive higher pitch.&lt;br /&gt;
&lt;br /&gt;
In the simulator, due to a bug in the code, all stations&lt;br /&gt;
transmit the DME Morse ident ... even stations where no&lt;br /&gt;
DME is present.&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx finds the nearest VOR or LOC on the&lt;br /&gt;
frequency, and checks to see if it is in range.  It also asks&lt;br /&gt;
for the &amp;quot;nearest&amp;quot; DME on the frequency, but makes no attempt&lt;br /&gt;
to check that it is in range.  To say the same thing the&lt;br /&gt;
other way, there is no attempt to check that the aircraft is&lt;br /&gt;
within the service volume of the DME.  Since there is almost always&lt;br /&gt;
a DME /somewhere/ on the frequency, the has_dme variable will&lt;br /&gt;
always be set true.&lt;br /&gt;
&lt;br /&gt;
For a demonstration of this bug, park at KAOO airport and &lt;br /&gt;
tune up the AOO VOR (which has no DME).  Or park at almost&lt;br /&gt;
any airport and tune up the localizer (since relatively few&lt;br /&gt;
localizers have DME).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Airport lighting in poor weather. ====&lt;br /&gt;
&lt;br /&gt;
The code in tileentry.cxx turns on airport lights according to&lt;br /&gt;
the position of the sun relative to the horizon. &amp;lt;strike&amp;gt;One consequence&lt;br /&gt;
is that the lights are off during the day.&amp;lt;/strike&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In real life, there are many circumstances where airport lights,&lt;br /&gt;
including approach lights, are turned on during the day.  At tower airports, the lights are turned on during bad weather, including weather that &lt;br /&gt;
is only slightly bad, and also turned on if requested by the pilot.  For&lt;br /&gt;
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].&lt;br /&gt;
&lt;br /&gt;
At non-towered airports, the lights are usually pilot-controlled,&lt;br /&gt;
via radio.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strike&amp;gt;The absence of lighting during daytime in poor weather detracts &lt;br /&gt;
significantly from the realism, because it affects both the&lt;br /&gt;
legality and the practicality of performing instrument approaches&lt;br /&gt;
under such conditions.&amp;lt;/strike&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* In version 0.9.10 runway lights are turned on automatically in day time if visibility is low. Though I agree, that pilot controlled lights could be a nice feature, but it's not a bug, it's more like a wish list entry, I suppose. [[User:Alfozavr|Alfozavr]]&lt;br /&gt;
&lt;br /&gt;
==== Holes in the ground. ====&lt;br /&gt;
&lt;br /&gt;
Ever since the first win32-build of FG-OSG, there are at least two huge &lt;br /&gt;
ground scenery holes in the the Rhine/Main/Neckar-region in Germany. &lt;br /&gt;
The first one gapes at &lt;br /&gt;
the place which was formerly known as the city of Mannheim (near the &lt;br /&gt;
airport EDFM, which is still there), the second one has swallowed up a &lt;br /&gt;
big piece of Frankfurt am Main (near EDDF) and surrounding land. &lt;br /&gt;
&lt;br /&gt;
First posted to the flightgear-devel list in November, 2006.&lt;br /&gt;
&lt;br /&gt;
==== Mixture versus Altitude. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that at&lt;br /&gt;
high altitude airports (e.g. KGCN or KASE), to obtain max&lt;br /&gt;
static RPM, it suffices to move the mixture control only a&lt;br /&gt;
few mm aft of the full-forward (full-rich) position.&lt;br /&gt;
&lt;br /&gt;
This is unrealistic.  In a real aircraft under such conditions,&lt;br /&gt;
it would be necessary to pull the mixture control back about&lt;br /&gt;
an inch to obtain max RPM.&lt;br /&gt;
&lt;br /&gt;
It's hard to say whether the carburetor is underreacting to the&lt;br /&gt;
altitude, or overreacting to the mixture control.&lt;br /&gt;
&lt;br /&gt;
==== EGT reads high. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that the&lt;br /&gt;
EGT reads toward the high end of the scale under all conditions,&lt;br /&gt;
including idle.  This is unrealistic.&lt;br /&gt;
&lt;br /&gt;
Also, the EGT reads ''off-scale'' high under high-power conditions.&lt;br /&gt;
&lt;br /&gt;
==== Flags missing from instruments. ====&lt;br /&gt;
&lt;br /&gt;
Some of the standard instruments lack status flags.  For example,&lt;br /&gt;
the GS needle goes to  mid-scale if there is no valid signal.  That'll kill you for sure.  Reportedly the hi-res instruments implement flags, but the lo-res ones don't.  Many aircraft are using the lo-res instruments.&lt;br /&gt;
&lt;br /&gt;
Either the aircraft should be upgraded to use instruments that&lt;br /&gt;
display flags, or the instruments should be upgraded to be&lt;br /&gt;
display flags.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --model-hz option. ====&lt;br /&gt;
&lt;br /&gt;
Specifying the --model-hz=10 command-line option results in the&lt;br /&gt;
following mess:&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml&lt;br /&gt;
  Sorry, wdot doesn't appear to be trimmable&lt;br /&gt;
 Trim Failed&lt;br /&gt;
  Trim Results: &lt;br /&gt;
       Angle of Attack:   7.50  wdot:  3.21e+01 Tolerance: 1e-03  Failed&lt;br /&gt;
              Throttle:   0.50  udot:  0.00e+00 Tolerance: 1e-03  Passed&lt;br /&gt;
            Pitch Trim:   0.00  qdot: -5.44e-11 Tolerance: 1e-04  Passed&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 WWarning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
     [many repeats]&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 altitude         = 9&lt;br /&gt;
 sea level radius = 4.62829e-268&lt;br /&gt;
 latitude         = 1.52075e-314&lt;br /&gt;
 longitude        = -0.0967923&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = nan&lt;br /&gt;
 sea level radius = nan&lt;br /&gt;
 latitude         = nan&lt;br /&gt;
 longitude        = nan&lt;br /&gt;
&lt;br /&gt;
and so forth.&lt;br /&gt;
&lt;br /&gt;
* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.&lt;br /&gt;
&lt;br /&gt;
==== CPU hogging. ====&lt;br /&gt;
&lt;br /&gt;
The fsgs program will happily eat up &amp;gt;98% of the cpu cycles,&lt;br /&gt;
even when the simulator is paused.  That seems excessive,&lt;br /&gt;
particularly during pause.  This is on a 2GHz machine&lt;br /&gt;
with hardware acceleration.  As a point of reference, &lt;br /&gt;
glxgears uses only a fraction of one percent of the cpu.&lt;br /&gt;
&lt;br /&gt;
* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result  if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)&lt;br /&gt;
&lt;br /&gt;
==== Out-of-bounds array reference in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the interpolation table code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the &amp;quot;message&amp;quot; handling code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Glideslope service volume. ====&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx appears to assume the glideslope&lt;br /&gt;
service volume is the same as the localizer service&lt;br /&gt;
volume.  This is quite unrealistic.&lt;br /&gt;
&lt;br /&gt;
==== Extended service volume. ====&lt;br /&gt;
&lt;br /&gt;
In some parts of the world, a goodly fraction of the&lt;br /&gt;
localizers have an expanded service volume (ESV),&lt;br /&gt;
often quite a bit larger than the standard service&lt;br /&gt;
volume you see in the AIM.  The code in navradio.cxx&lt;br /&gt;
was ignoring the service volume information in the&lt;br /&gt;
database and wrongly assuming the default values&lt;br /&gt;
applied everywhere.  Code to fix the range-related&lt;br /&gt;
part of the problem has been offered&lt;br /&gt;
but not yet incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Other service volume issues. ====&lt;br /&gt;
&lt;br /&gt;
The code  in navradio.cxx has no understanding of how &lt;br /&gt;
'''azimuth''' affects the&lt;br /&gt;
localizer.  There is more to the story than reception range.&lt;br /&gt;
It is perfectly possible to be outside the LOC service volume &lt;br /&gt;
for reasons having to do with azimuth, not range.  &lt;br /&gt;
&lt;br /&gt;
Good ident will be heard, but false localizer courses will &lt;br /&gt;
cause serious trouble for the unwary pilot.&lt;br /&gt;
&lt;br /&gt;
A patch to fix this (along with the ESV issue) has been &lt;br /&gt;
offered, but ignored.&lt;br /&gt;
&lt;br /&gt;
There are also azimuthal issues with the /glideslope/&lt;br /&gt;
service volume.  This has not yet been patched.&lt;br /&gt;
&lt;br /&gt;
==== Menu buttons having a get-together. ====&lt;br /&gt;
&lt;br /&gt;
This concerns &amp;quot;radio buttons&amp;quot; on menus, such as on the &lt;br /&gt;
location-in-air popup and elsewhere.  By definition, it should be &lt;br /&gt;
impossible to have more than one radio button pushed down at a time.&lt;br /&gt;
However, illegal situations of this sort can be created&lt;br /&gt;
using a click-and-drag gesture.  Aim at&lt;br /&gt;
a radio button, hold the mouse-button down, and drag ...&lt;br /&gt;
as if you wanted to drag the radio button to a new location.&lt;br /&gt;
This allows you to set a radio button without the others&lt;br /&gt;
being unset.  If you persist, you can have every one of&lt;br /&gt;
the buttons in the pushed-down state at the same time.&lt;br /&gt;
&lt;br /&gt;
Before you say, &amp;quot;well, don't do that then&amp;quot; or &amp;quot;garbage in,&lt;br /&gt;
garbage out&amp;quot;, let me point out that it is possible for&lt;br /&gt;
a pilot to inadvertently make a tiny dragging gesture&lt;br /&gt;
when intending only a click.  Also, when the desired&lt;br /&gt;
button is in the pushed-down state, it is easy to not&lt;br /&gt;
notice that other buttons are in the undesired state.&lt;br /&gt;
&lt;br /&gt;
==== Altimeter setting unreadable. ====&lt;br /&gt;
&lt;br /&gt;
The standard altimeter (used by the default c172p aircraft&lt;br /&gt;
and many others) had been using an unhappy hodgepodge of&lt;br /&gt;
layers.  The analog Kollsman window was unusable, because&lt;br /&gt;
it was unlabeled, and the digital altimeter setting was&lt;br /&gt;
unusable, especially at altitudes near 2500 feet, partly &lt;br /&gt;
from being behind the needle.  On a real altimeter, things&lt;br /&gt;
are positioned so that cannot happen.&lt;br /&gt;
&lt;br /&gt;
Fixing this requires using a more suitable font, moving&lt;br /&gt;
the digits over, and getting rid of conflicting extraneous&lt;br /&gt;
markings.&lt;br /&gt;
&lt;br /&gt;
A patch to implement this fix has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Memory mismanagement in subsystem_mgr. ====&lt;br /&gt;
&lt;br /&gt;
It is bad luck to apply &amp;quot;delete&amp;quot; to an object that was not&lt;br /&gt;
created with &amp;quot;new&amp;quot; ... as in line 219 of subsystem_mgr.cxx&lt;br /&gt;
&lt;br /&gt;
A patch is available, but has not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Yet more memory mismanagement. ====&lt;br /&gt;
&lt;br /&gt;
When FG is trying to exit, it is very likely to abort&lt;br /&gt;
with a message such as&lt;br /&gt;
&lt;br /&gt;
  *** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***&lt;br /&gt;
&lt;br /&gt;
There are at least three different instances of this bug,&lt;br /&gt;
each producing a different traceback.  Here is one such&lt;br /&gt;
traceback:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
#0  0xb7573947 in raise () from /lib/tls/libc.so.6&lt;br /&gt;
#1  0xb75750c9 in abort () from /lib/tls/libc.so.6&lt;br /&gt;
#2  0xb75a908a in __libc_message () from /lib/tls/libc.so.6&lt;br /&gt;
#3  0xb75b094f in _int_free () from /lib/tls/libc.so.6&lt;br /&gt;
#4  0xb75b09f2 in free () from /lib/tls/libc.so.6&lt;br /&gt;
#5  0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6&lt;br /&gt;
#6  0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766&lt;br /&gt;
#7  0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#8  0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#9  0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105&lt;br /&gt;
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237&lt;br /&gt;
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6&lt;br /&gt;
#12 0x080919c7 in fgExit (status=0) at util.cxx:120&lt;br /&gt;
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Missing Features and Traps for the Unwary ==&lt;br /&gt;
&lt;br /&gt;
==== Version number, please. ====&lt;br /&gt;
&lt;br /&gt;
It would be helpful to have an easy, documented way to ascertain the&lt;br /&gt;
version number.  A --version option on the command line would be&lt;br /&gt;
nice.  Maybe also a help::about menu item, for use while fgfs is&lt;br /&gt;
already running.&lt;br /&gt;
&lt;br /&gt;
One could imagine that info about key libraries would also be&lt;br /&gt;
helpful.&lt;br /&gt;
&lt;br /&gt;
==== Rabbits extinct. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, many airports have '''sequenced flashers''' &lt;br /&gt;
(aka the rabbit) as part of the approach-light system.&lt;br /&gt;
&lt;br /&gt;
In the FlightGear world, the sequenced flashers are inoperative&lt;br /&gt;
everywhere.  Grepping through the code suggests that no attempt&lt;br /&gt;
has been made to implement this.&lt;br /&gt;
&lt;br /&gt;
==== No comm volume control. ====&lt;br /&gt;
&lt;br /&gt;
In many aircraft including the default c172p, the comm&lt;br /&gt;
radios have no volume control knob.  In other aircraft&lt;br /&gt;
including the pa24-250, there is such a knob, but it&lt;br /&gt;
apparently isn't clickable and apparently doesn't do &lt;br /&gt;
anything.  &lt;br /&gt;
&lt;br /&gt;
In contrast, the SenecaII exemplifies the ''desired'' behavior: &lt;br /&gt;
the knob rotates when clicked and &lt;br /&gt;
correctly controls the /instrumentation/comm[N]/volume&lt;br /&gt;
property.  (This alas has no effect on the volume of ATIS&lt;br /&gt;
audio, but that must be considered an ATIS bug not a&lt;br /&gt;
Seneca bug.)&lt;br /&gt;
&lt;br /&gt;
==== Incomplete Scenery. ====&lt;br /&gt;
&lt;br /&gt;
Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ]  without installing the shared models, will get you messages such as the following:&lt;br /&gt;
&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/localizer.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml&lt;br /&gt;
&lt;br /&gt;
You might get only a few such messages, or you might get &lt;br /&gt;
screenful after screenful.&lt;br /&gt;
&lt;br /&gt;
So, make sure you download all scenery files that are needed for fgfs.&lt;br /&gt;
&lt;br /&gt;
This obviously counts as a trap for the unwary.&lt;br /&gt;
&lt;br /&gt;
- This is patently not a bug and should be moved to a &amp;quot;tips&amp;quot; section or similar.  The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...&lt;br /&gt;
&lt;br /&gt;
==== ASOS and AWOS are AWOL. ====&lt;br /&gt;
&lt;br /&gt;
At many non-tower airports (and even some tower airports) there&lt;br /&gt;
is automatic weather reporting of some kind.&lt;br /&gt;
&lt;br /&gt;
It ought to be straightforward to implement this, as a slight&lt;br /&gt;
variation on the existing ATIS feature.&lt;br /&gt;
&lt;br /&gt;
==== Roundoff problems with textranslate step and scroll. ====&lt;br /&gt;
&lt;br /&gt;
The textranslate animation is delightful for 3D animation&lt;br /&gt;
of mechanical drum-type displays as on old-fashioned&lt;br /&gt;
odometers and Hobbs meters.&lt;br /&gt;
&lt;br /&gt;
It is not, however, a convenient way to implement digital&lt;br /&gt;
readouts.  It works OK for integers, but the code in &lt;br /&gt;
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the &amp;quot;.1&amp;quot; in 122.1 MHz, particularly when the scroll-value is zero.&lt;br /&gt;
* One workaround is to stick to integers, e.g. integer kHz &lt;br /&gt;
rather than fractional MHz.&lt;br /&gt;
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.&lt;br /&gt;
* A final option (with CVS) is to use the bias tag to let the code know how to&lt;br /&gt;
handle round-off.  Use a bias value of 1/2 your smallest step value, and &lt;br /&gt;
use the same bias value on all digits.&lt;br /&gt;
&lt;br /&gt;
What we really need is a whole new support routine for dealing&lt;br /&gt;
with 3D digital displays, something at least as nice as the&lt;br /&gt;
support for 2D instruments.&lt;br /&gt;
&lt;br /&gt;
==== Broken startup banner. ====&lt;br /&gt;
&lt;br /&gt;
On startup, the simulator prints Author: Unknown and prints a bogus Date.&lt;br /&gt;
&lt;br /&gt;
The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.&lt;br /&gt;
&lt;br /&gt;
== Fixed Bugs ==&lt;br /&gt;
&lt;br /&gt;
If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).&lt;br /&gt;
&lt;br /&gt;
==== Wild accelerations at low speeds. ====&lt;br /&gt;
&lt;br /&gt;
Improper inclinometer ball indications have been observed:&lt;br /&gt;
* When parked, the ball was pegged to one side.&lt;br /&gt;
* When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.&lt;br /&gt;
&lt;br /&gt;
This was observed in the c182 model and in the default c172 model.&lt;br /&gt;
&lt;br /&gt;
Tracing indicates that the problem is not within the slip_skid_ball.cxx&lt;br /&gt;
code, but rather upstream of there, in the flight dynamics.  Tracing&lt;br /&gt;
shows that the y-accel-fps_sec values are wildly fluctuating in&lt;br /&gt;
direction, and enormous in magnitude.&lt;br /&gt;
&lt;br /&gt;
Additional evidence pointing to the FDM comes from the fact that&lt;br /&gt;
the problem is observed with JSBSim and not with larcsim (although&lt;br /&gt;
larcsim has other problems, such as drifting slowly sideways while&lt;br /&gt;
parked).&lt;br /&gt;
&lt;br /&gt;
This is important from a procedures training point of view.  &lt;br /&gt;
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi.  In a real aircraft, a pilot who found the &lt;br /&gt;
inclinometer pegged would cancel the flight before even starting&lt;br /&gt;
the engine.&lt;br /&gt;
&lt;br /&gt;
Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:&lt;br /&gt;
&lt;br /&gt;
*velocities/vdot-fps&lt;br /&gt;
*velocities/a-pilot-y-ft sec2&lt;br /&gt;
*velocities/n-pilot-y-norm&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Misdirected diagnostic in JSBSim.cxx ====&lt;br /&gt;
&lt;br /&gt;
The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout.  This made both the log and the console record hard to interpret.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====&lt;br /&gt;
&lt;br /&gt;
The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.&lt;br /&gt;
&lt;br /&gt;
Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)&lt;br /&gt;
&lt;br /&gt;
* '''This bug has not been observed in 0.9.10.'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting &amp;quot;Could not gen source&amp;quot; ====&lt;br /&gt;
&lt;br /&gt;
Any further reports or stacktraces on this bug would be appreciated.&lt;br /&gt;
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.&lt;br /&gt;
Update your sound card drivers.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed in 0.9.8a'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.7 - ? Linux - Joystick crash with correct config files ====&lt;br /&gt;
&lt;br /&gt;
Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.&lt;br /&gt;
&lt;br /&gt;
* ''' This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
==== Individual Aircraft ====&lt;br /&gt;
&lt;br /&gt;
Bugs associated with a particular aircraft should be listed&lt;br /&gt;
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.&lt;br /&gt;
&lt;br /&gt;
==== OpenSceneGraph ====&lt;br /&gt;
&lt;br /&gt;
There is a separate page for issues related to [[OpenSceneGraph]].&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3562</id>
		<title>Bugs</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3562"/>
		<updated>2007-06-17T07:22:51Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Airport lighting in poor weather. */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Known Bugs ==&lt;br /&gt;
&lt;br /&gt;
This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.&lt;br /&gt;
&lt;br /&gt;
==== Incorrect altimetry. ====&lt;br /&gt;
&lt;br /&gt;
There is evidently at least one serious misconception in the&lt;br /&gt;
code that calculates atmospheric pressure, altimeter settings, &lt;br /&gt;
et cetera.  This can be easily demonstrated:&lt;br /&gt;
&lt;br /&gt;
Park at or near the threshold of runway 33 at Aspen (KASE).&lt;br /&gt;
Under standard conditions, observe that the altimeter reads&lt;br /&gt;
7820 feet MSL, as it should.&lt;br /&gt;
&lt;br /&gt;
Use the Weather : Weather Conditions dialog popup to&lt;br /&gt;
look at the ground-level altimeter setting (QNH).&lt;br /&gt;
This is bottom row in the &amp;quot;Alt (inHg)&amp;quot; column of the popup.&lt;br /&gt;
Verify that it is 29.92.&lt;br /&gt;
&lt;br /&gt;
Now use the dialog box to change this property.  Change it&lt;br /&gt;
to 30.92, a one-inch difference.&lt;br /&gt;
&lt;br /&gt;
Go to your altimeter instrument and enter the new altimeter&lt;br /&gt;
setting in the Kollsman window.  Ideally, this '''should'''&lt;br /&gt;
cause the instrument to read the correct altitude once&lt;br /&gt;
again, namely 7820 feet MSL.&lt;br /&gt;
&lt;br /&gt;
However, due to bugs, it is likely that you will observe&lt;br /&gt;
something closer to 8120.  This means the airplane is 300 &lt;br /&gt;
feet lower than the altimeter says it is.&lt;br /&gt;
&lt;br /&gt;
In case it wasn't obvious, when flying around near Aspen,&lt;br /&gt;
being 300 feet lower than you think you are can be very&lt;br /&gt;
bad for your health.&lt;br /&gt;
&lt;br /&gt;
The absolutely correct formulas for computing the altimeter &lt;br /&gt;
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
A patch to fix the altimeter has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Altimetry misnomers and misconceptions. ====&lt;br /&gt;
&lt;br /&gt;
Both the Weather Conditions popup and the atis.cxx code&lt;br /&gt;
rely on the &amp;quot;pressure-sea-level-inhg&amp;quot; property and use&lt;br /&gt;
it in ways that the altimeter setting should be used.&lt;br /&gt;
&lt;br /&gt;
For some people this may be merely a misnomer, but for&lt;br /&gt;
others it is clearly a misconception, as recent events&lt;br /&gt;
have shown.&lt;br /&gt;
&lt;br /&gt;
The fact is, the altimeter setting is '''not''' the same &lt;br /&gt;
thing as the pressure at sea level (Psl), especially when &lt;br /&gt;
the airmass has a non-standard temperature profile.&lt;br /&gt;
The altimeter setting is something&lt;br /&gt;
else;  it is properly called the altimeter setting.  It&lt;br /&gt;
is also properly called the QNH, although private pilots&lt;br /&gt;
who fly only in the US may be unfamiliar with the QNH&lt;br /&gt;
terminology.&lt;br /&gt;
&lt;br /&gt;
In the Remarks section of a METAR, you can sometimes&lt;br /&gt;
find the ''Reduced'' Sea Level Pressure, which is&lt;br /&gt;
unfortunately denoted SLP.  This METAR SLP serves&lt;br /&gt;
the same function as the altimeter setting.  Despite&lt;br /&gt;
its name, the METAR SLP is not equal to the honest-to-goodness&lt;br /&gt;
pressure at honest-to-goodness sea level (Psl), as&lt;br /&gt;
discussed in more detail on&lt;br /&gt;
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
There needs to be a facility whereby routines that need&lt;br /&gt;
the altimeter setting can obtain the altimeter setting.&lt;br /&gt;
&lt;br /&gt;
Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
Existing code sometimes treads the &amp;quot;pressure-sea-level-inhg&amp;quot; &lt;br /&gt;
property as if it were Psl, and sometimes as if it were &lt;br /&gt;
METAR SLP.  All this needs to be vetted.&lt;br /&gt;
&lt;br /&gt;
==== Newton's laws violated by environment.cxx ====&lt;br /&gt;
&lt;br /&gt;
Consider the following results of an experiment using fgfs:&lt;br /&gt;
&lt;br /&gt;
  alt:  662  mM: 0.0288  P: 99000.8462  T: 286.8563  rho: 1.1975&lt;br /&gt;
  alt: 3462  mM: 0.0288  P: 89341.6721  T: 281.3920  rho: 1.1009&lt;br /&gt;
  &lt;br /&gt;
  alt:  662  mM: 0.0289  P: 99000.8422  T: 256.9910  rho: 1.3404&lt;br /&gt;
  alt: 3462  mM: 0.0289  P: 89341.6740  T: 252.0956  rho: 1.2333&lt;br /&gt;
&lt;br /&gt;
The first pair of lines represent before and after a simple&lt;br /&gt;
flight from one airport to another, with a net gain in altitude of&lt;br /&gt;
2800 feet, under standard conditions.  So far so good.&lt;br /&gt;
&lt;br /&gt;
The second pair of lines represent exactly the same flight, &lt;br /&gt;
except that the ambient temperature was 30 degrees colder&lt;br /&gt;
than before.  You can see that the density (rho) is greater,&lt;br /&gt;
in accordance with the ideal gas law.&lt;br /&gt;
&lt;br /&gt;
The problem is that the delta_P is exactly the same for the two&lt;br /&gt;
flights.  This is a problem because P is connected to the weight&lt;br /&gt;
of the air column.  If the air is 12% denser, the laws of physics &lt;br /&gt;
require it to have a 12% steeper pressure gradient dP/dh ... but &lt;br /&gt;
alas this is not observed.&lt;br /&gt;
&lt;br /&gt;
This incorrect pressure profile P(h) has many consequences affecting&lt;br /&gt;
engine performance, airfoil performance, altimetry, et cetera.&lt;br /&gt;
&lt;br /&gt;
==== Z-buffer burn-through. ====&lt;br /&gt;
&lt;br /&gt;
Sometimes distant objects can be seen through nearer objects that&lt;br /&gt;
are not supposed to be transparent.  For example:  Runway lights &lt;br /&gt;
sometimes burn through a solid cloud layer.  Also runway lights&lt;br /&gt;
sometimes burn through aircraft structure.  Some instruments&lt;br /&gt;
burn through the yoke.&lt;br /&gt;
&lt;br /&gt;
It seems that so-called &amp;quot;2D&amp;quot; objects in the&lt;br /&gt;
background are likely to burn through &amp;quot;3D&amp;quot; objects in the&lt;br /&gt;
foreground.  This is particularly noticeable in aircraft&lt;br /&gt;
that have a mixture of 2D and 3D instruments.&lt;br /&gt;
&lt;br /&gt;
The ''position'' in space of the offending objects is OK, as&lt;br /&gt;
you can verify by shifting your PoV to get a little bit of&lt;br /&gt;
a side view.  The obvious hypothesis is that the Z-order&lt;br /&gt;
is being mishandled in a Z-buffer somewhere.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak. ====&lt;br /&gt;
&lt;br /&gt;
The simulator will gobble up about 3 gigabytes&lt;br /&gt;
of virtual memory overnight, while paused.  &lt;br /&gt;
Without the&lt;br /&gt;
leak, the memory footprint would be less than 300 meg.  The&lt;br /&gt;
difference between 300 meg and 3 gig is quite &lt;br /&gt;
significant on machines that have only 1 or 2 gig&lt;br /&gt;
of main memory.&lt;br /&gt;
&lt;br /&gt;
A rather steady leak of 2 meg per minute is observed&lt;br /&gt;
during pause, no matter whether the aircraft is aloft&lt;br /&gt;
or parked on the ground.  '''Vastly less leakage''' (two&lt;br /&gt;
orders of magnitude less, possibly zero) is observed&lt;br /&gt;
when the simulator is not paused, and the aircraft&lt;br /&gt;
is simply sitting on the ground with the parking&lt;br /&gt;
brake set.&lt;br /&gt;
&lt;br /&gt;
This bug has been observed in multiple versions of fgfs,&lt;br /&gt;
including one compiled back in May, 2006 as well as&lt;br /&gt;
the most current CVS version.&lt;br /&gt;
&lt;br /&gt;
This is 100% reproducible with a &lt;br /&gt;
ATI RV350 [Mobility Radeon 9600 M10] chipset&lt;br /&gt;
and the ati-fglrx driver.&lt;br /&gt;
The leak is observed whether or not &lt;br /&gt;
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.&lt;br /&gt;
&lt;br /&gt;
==== Numerous bugs in ATIS feature. ====&lt;br /&gt;
&lt;br /&gt;
1) The ATIS is supposed to change whenever there is a&lt;br /&gt;
significant change in the weather.  The comments mention&lt;br /&gt;
this, but the code makes no attempt to implement this.&lt;br /&gt;
&lt;br /&gt;
2) The code assumes that ATIS is prepared on the hour.&lt;br /&gt;
In practice this is virtually never the case;  a new&lt;br /&gt;
ATIS is prepared hourly, but not on the hour.  Also&lt;br /&gt;
this assumption is inconsistent with ATIS changes&lt;br /&gt;
based on the weather.&lt;br /&gt;
&lt;br /&gt;
3) The code attempts to issue a station identifier, but&lt;br /&gt;
none is heard.&lt;br /&gt;
&lt;br /&gt;
4) Multiple departures from standard phraseology.&lt;br /&gt;
&lt;br /&gt;
5) The volume is too low;  ATIS is not readable over engine noise.&lt;br /&gt;
This defeats much of the purpose of ATIS.  The volume does&lt;br /&gt;
not respond to the /instrumentation/comm[N]/volume property.&lt;br /&gt;
&lt;br /&gt;
6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.&lt;br /&gt;
&lt;br /&gt;
x) Et cetera.&lt;br /&gt;
&lt;br /&gt;
A patch to fix a few dozen ATIS bugs is available, but has not been&lt;br /&gt;
incorporated into FG CVS.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --altitude option. ====&lt;br /&gt;
&lt;br /&gt;
When the aircraft is initialzed aloft using the &lt;br /&gt;
command-line --altitude=6000&lt;br /&gt;
option, 0.9.10 is observed to put up a blank screen &lt;br /&gt;
(no scenery, no panel) and to spew on the console &lt;br /&gt;
page after page like this:&lt;br /&gt;
&lt;br /&gt;
  Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..&lt;br /&gt;
  altitude         = -1.69132e-41&lt;br /&gt;
  sea level radius = -6.54575e-42&lt;br /&gt;
  latitude         = 6.9874e-316&lt;br /&gt;
  longitude        = 6.79737e-313&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_pitch&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_volume&lt;br /&gt;
&lt;br /&gt;
==== Multiple bugs in the location-in-air popup. ====&lt;br /&gt;
&lt;br /&gt;
The location-in-air popup turns off the magnetos and extends&lt;br /&gt;
the landing gear.  Some pilots and flight instructors &lt;br /&gt;
deem this to be undesirable behavior, especially if all&lt;br /&gt;
they are trying to do is relocate from one airborne position to&lt;br /&gt;
another.&lt;br /&gt;
&lt;br /&gt;
Similarly, it strongly perturbs the throttle setting, &lt;br /&gt;
aileron trim, elevator trim, rudder trim, &lt;br /&gt;
view angles, PoV position, and who-knows-what else.  &lt;br /&gt;
Again, people who know about airplanes consider this to&lt;br /&gt;
be undesirable behavior.&lt;br /&gt;
&lt;br /&gt;
There is also a tendency to place the aircraft into &lt;br /&gt;
dangerous unusual attitudes, and other bugs too numerous &lt;br /&gt;
to mention.&lt;br /&gt;
&lt;br /&gt;
Evidently, though, there is at least one person who likes&lt;br /&gt;
things the way they are.  Code that would have fixed these&lt;br /&gt;
bugs was rejected.  Neither specific nor constructive criticism&lt;br /&gt;
of the code was offered.  For details see the flightgear-devel&lt;br /&gt;
mailing list archives.&lt;br /&gt;
&lt;br /&gt;
==== Nearest fix. ====&lt;br /&gt;
&lt;br /&gt;
Did you know that there are 8 different BRAVO intersections&lt;br /&gt;
in the database?&lt;br /&gt;
&lt;br /&gt;
Until now there was no support in the code for this;  all but&lt;br /&gt;
one of the entries was thrown away at the lowest level. There&lt;br /&gt;
is a comment in the code saying that fixing this is on the&lt;br /&gt;
TODO list.&lt;br /&gt;
&lt;br /&gt;
As for navaids (as opposed to waypoints), the low-level code&lt;br /&gt;
already provides support for ambiguous IDs, but the information&lt;br /&gt;
is not being used very wisely by the higher layers.&lt;br /&gt;
&lt;br /&gt;
Code to fix these problems was offered to the community.&lt;br /&gt;
So far it has been completely ignored.&lt;br /&gt;
&lt;br /&gt;
==== HSI instrument failure. ====&lt;br /&gt;
&lt;br /&gt;
If you use the &amp;quot;heading indicator&amp;quot; checkbox on the&lt;br /&gt;
&amp;quot;instrument failure&amp;quot; popup to command a failure,&lt;br /&gt;
it has no effect on the HSI instrument used by&lt;br /&gt;
many aircraft in the simulator fleet.&lt;br /&gt;
&lt;br /&gt;
This is because of wrong code in hsi.xml.  &lt;br /&gt;
&lt;br /&gt;
Backend code to handle this correctly exists, but has&lt;br /&gt;
apparently never been used.  It needs one small fix,&lt;br /&gt;
followed by recompilation.  A patchset to take care&lt;br /&gt;
of all this was offered to the community, but has&lt;br /&gt;
not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Flux gate not really a flux gate. ====&lt;br /&gt;
&lt;br /&gt;
In the Instrumentation director, there are three heading-related&lt;br /&gt;
.cxx files.&lt;br /&gt;
* heading_indicator.cxx : vacuum driven, with drift&lt;br /&gt;
* heading_indicator_dg.cxx : electrically driven, with drift&lt;br /&gt;
* heading_indicator_fg.cxx : electrically driven, no drift&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;fg&amp;quot; in &amp;quot;heading_indicator_fg&amp;quot; is documented to stand for&lt;br /&gt;
&amp;quot;flux gate&amp;quot;, as if the heading were slaved to a flux-gate&lt;br /&gt;
compass ... but the code does not implement any such thing.&lt;br /&gt;
All it really does is initialize the indicated heading to &lt;br /&gt;
the correct magnetic heading value, and then implement a &lt;br /&gt;
no-drift policy.  This is incorrect behavior, as can be&lt;br /&gt;
seen by flying to an area where the magnetic variation is&lt;br /&gt;
different from what it was at the start of the flight.  A&lt;br /&gt;
true slaved heading indicator would gradually accommodate&lt;br /&gt;
the new magvar.&lt;br /&gt;
&lt;br /&gt;
The correct behavior ought to be easy to implement.&lt;br /&gt;
&lt;br /&gt;
==== Weird noises during initialization. ====&lt;br /&gt;
&lt;br /&gt;
It is observed that sometimes while the simulator is starting&lt;br /&gt;
up, before things are fully operational, weird noises are&lt;br /&gt;
produced.  For example, in the c182rg, gear-in-transit&lt;br /&gt;
noises are produced for several seconds before the first&lt;br /&gt;
display becomes visible.  (According to a dump of the&lt;br /&gt;
relevant variables, there is no evidence that the gear is&lt;br /&gt;
actually in transit, and no reason why it should be.)&lt;br /&gt;
&lt;br /&gt;
Code to fix this was submitted.  So far it has been&lt;br /&gt;
ignored.&lt;br /&gt;
&lt;br /&gt;
==== Weird displays during fullscreen initialization. ====&lt;br /&gt;
&lt;br /&gt;
If the --enable-fullscreen command-line option is used, &lt;br /&gt;
the window is enlarged to full-screen size at a time&lt;br /&gt;
when initialization is only half-complete.  From this&lt;br /&gt;
time until the end of initialization, the display &lt;br /&gt;
contains weird combinations of leftover graphic objects&lt;br /&gt;
and other junk.&lt;br /&gt;
&lt;br /&gt;
This is observed no matter whether the splash-screen feature&lt;br /&gt;
is enabled or disabled.&lt;br /&gt;
&lt;br /&gt;
==== Fullscreen window sometimes misplaced. ====&lt;br /&gt;
&lt;br /&gt;
About 20% of the time, when the --enable-fullscreen command-line&lt;br /&gt;
option is used, it opens a window of the correct size, but &lt;br /&gt;
badly misplaced relative to the screen, such that only one half&lt;br /&gt;
or one quarter of the window is on-screen.&lt;br /&gt;
&lt;br /&gt;
==== Navigation databases out-of-date ====&lt;br /&gt;
&lt;br /&gt;
The database of navigation waypoints and fixes has an internal&lt;br /&gt;
date of early 2005.  It is missing quite a few useful fixes.  &lt;br /&gt;
The FAA has defined quite a few new approaches in recent years,&lt;br /&gt;
and has revised others.&lt;br /&gt;
&lt;br /&gt;
An updated version, based on a pull of the much more&lt;br /&gt;
current x-plane database, was made available.  So far&lt;br /&gt;
it has been ignored.&lt;br /&gt;
&lt;br /&gt;
Similar remarks apply to the ''navaids'' database.&lt;br /&gt;
&lt;br /&gt;
==== Ident from phantom DME. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, some VOR stations and even some localizers&lt;br /&gt;
have a colocated DME station ... but there are plenty that&lt;br /&gt;
don't.&lt;br /&gt;
&lt;br /&gt;
The DME has its own Morse ident, with a distinctive higher pitch.&lt;br /&gt;
&lt;br /&gt;
In the simulator, due to a bug in the code, all stations&lt;br /&gt;
transmit the DME Morse ident ... even stations where no&lt;br /&gt;
DME is present.&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx finds the nearest VOR or LOC on the&lt;br /&gt;
frequency, and checks to see if it is in range.  It also asks&lt;br /&gt;
for the &amp;quot;nearest&amp;quot; DME on the frequency, but makes no attempt&lt;br /&gt;
to check that it is in range.  To say the same thing the&lt;br /&gt;
other way, there is no attempt to check that the aircraft is&lt;br /&gt;
within the service volume of the DME.  Since there is almost always&lt;br /&gt;
a DME /somewhere/ on the frequency, the has_dme variable will&lt;br /&gt;
always be set true.&lt;br /&gt;
&lt;br /&gt;
For a demonstration of this bug, park at KAOO airport and &lt;br /&gt;
tune up the AOO VOR (which has no DME).  Or park at almost&lt;br /&gt;
any airport and tune up the localizer (since relatively few&lt;br /&gt;
localizers have DME).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Airport lighting in poor weather. ====&lt;br /&gt;
&lt;br /&gt;
The code in tileentry.cxx turns on airport lights according to&lt;br /&gt;
the position of the sun relative to the horizon.  One consequence&lt;br /&gt;
is that the lights are off during the day.&lt;br /&gt;
&lt;br /&gt;
In real life, there are many circumstances where airport lights,&lt;br /&gt;
including approach lights, are turned on during the day.  At tower airports, the lights are turned on during bad weather -- including weather that &lt;br /&gt;
is only slightly bad -- and also turned on if requested by the pilot.  For&lt;br /&gt;
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].&lt;br /&gt;
&lt;br /&gt;
At non-towered airports, the lights are usually pilot-controlled,&lt;br /&gt;
via radio.&lt;br /&gt;
&lt;br /&gt;
The absence of lighting during daytime in poor weather detracts &lt;br /&gt;
significantly from the realism, because it affects both the&lt;br /&gt;
legality and the practicality of performing instrument approaches&lt;br /&gt;
under such conditions.&lt;br /&gt;
&lt;br /&gt;
* In version 0.9.10 runway lights are turned on automatically in day time if visibility is low. Though I agree, that pilot controlled lights could be a nice feature, but it's not a bug, it's more like a wish list entry, I suppose.&lt;br /&gt;
&lt;br /&gt;
==== Holes in the ground. ====&lt;br /&gt;
&lt;br /&gt;
Ever since the first win32-build of FG-OSG, there are at least two huge &lt;br /&gt;
ground scenery holes in the the Rhine/Main/Neckar-region in Germany. &lt;br /&gt;
The first one gapes at &lt;br /&gt;
the place which was formerly known as the city of Mannheim (near the &lt;br /&gt;
airport EDFM, which is still there), the second one has swallowed up a &lt;br /&gt;
big piece of Frankfurt am Main (near EDDF) and surrounding land. &lt;br /&gt;
&lt;br /&gt;
First posted to the flightgear-devel list in November, 2006.&lt;br /&gt;
&lt;br /&gt;
==== Mixture versus Altitude. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that at&lt;br /&gt;
high altitude airports (e.g. KGCN or KASE), to obtain max&lt;br /&gt;
static RPM, it suffices to move the mixture control only a&lt;br /&gt;
few mm aft of the full-forward (full-rich) position.&lt;br /&gt;
&lt;br /&gt;
This is unrealistic.  In a real aircraft under such conditions,&lt;br /&gt;
it would be necessary to pull the mixture control back about&lt;br /&gt;
an inch to obtain max RPM.&lt;br /&gt;
&lt;br /&gt;
It's hard to say whether the carburetor is underreacting to the&lt;br /&gt;
altitude, or overreacting to the mixture control.&lt;br /&gt;
&lt;br /&gt;
==== EGT reads high. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that the&lt;br /&gt;
EGT reads toward the high end of the scale under all conditions,&lt;br /&gt;
including idle.  This is unrealistic.&lt;br /&gt;
&lt;br /&gt;
Also, the EGT reads ''off-scale'' high under high-power conditions.&lt;br /&gt;
&lt;br /&gt;
==== Flags missing from instruments. ====&lt;br /&gt;
&lt;br /&gt;
Some of the standard instruments lack status flags.  For example,&lt;br /&gt;
the GS needle goes to  mid-scale if there is no valid signal.  That'll kill you for sure.  Reportedly the hi-res instruments implement flags, but the lo-res ones don't.  Many aircraft are using the lo-res instruments.&lt;br /&gt;
&lt;br /&gt;
Either the aircraft should be upgraded to use instruments that&lt;br /&gt;
display flags, or the instruments should be upgraded to be&lt;br /&gt;
display flags.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --model-hz option. ====&lt;br /&gt;
&lt;br /&gt;
Specifying the --model-hz=10 command-line option results in the&lt;br /&gt;
following mess:&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml&lt;br /&gt;
  Sorry, wdot doesn't appear to be trimmable&lt;br /&gt;
 Trim Failed&lt;br /&gt;
  Trim Results: &lt;br /&gt;
       Angle of Attack:   7.50  wdot:  3.21e+01 Tolerance: 1e-03  Failed&lt;br /&gt;
              Throttle:   0.50  udot:  0.00e+00 Tolerance: 1e-03  Passed&lt;br /&gt;
            Pitch Trim:   0.00  qdot: -5.44e-11 Tolerance: 1e-04  Passed&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 WWarning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
     [many repeats]&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 altitude         = 9&lt;br /&gt;
 sea level radius = 4.62829e-268&lt;br /&gt;
 latitude         = 1.52075e-314&lt;br /&gt;
 longitude        = -0.0967923&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = nan&lt;br /&gt;
 sea level radius = nan&lt;br /&gt;
 latitude         = nan&lt;br /&gt;
 longitude        = nan&lt;br /&gt;
&lt;br /&gt;
and so forth.&lt;br /&gt;
&lt;br /&gt;
* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.&lt;br /&gt;
&lt;br /&gt;
==== CPU hogging. ====&lt;br /&gt;
&lt;br /&gt;
The fsgs program will happily eat up &amp;gt;98% of the cpu cycles,&lt;br /&gt;
even when the simulator is paused.  That seems excessive,&lt;br /&gt;
particularly during pause.  This is on a 2GHz machine&lt;br /&gt;
with hardware acceleration.  As a point of reference, &lt;br /&gt;
glxgears uses only a fraction of one percent of the cpu.&lt;br /&gt;
&lt;br /&gt;
* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result  if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)&lt;br /&gt;
&lt;br /&gt;
==== Out-of-bounds array reference in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the interpolation table code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the &amp;quot;message&amp;quot; handling code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Glideslope service volume. ====&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx appears to assume the glideslope&lt;br /&gt;
service volume is the same as the localizer service&lt;br /&gt;
volume.  This is quite unrealistic.&lt;br /&gt;
&lt;br /&gt;
==== Extended service volume. ====&lt;br /&gt;
&lt;br /&gt;
In some parts of the world, a goodly fraction of the&lt;br /&gt;
localizers have an expanded service volume (ESV),&lt;br /&gt;
often quite a bit larger than the standard service&lt;br /&gt;
volume you see in the AIM.  The code in navradio.cxx&lt;br /&gt;
was ignoring the service volume information in the&lt;br /&gt;
database and wrongly assuming the default values&lt;br /&gt;
applied everywhere.  Code to fix the range-related&lt;br /&gt;
part of the problem has been offered&lt;br /&gt;
but not yet incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Other service volume issues. ====&lt;br /&gt;
&lt;br /&gt;
The code  in navradio.cxx has no understanding of how &lt;br /&gt;
'''azimuth''' affects the&lt;br /&gt;
localizer.  There is more to the story than reception range.&lt;br /&gt;
It is perfectly possible to be outside the LOC service volume &lt;br /&gt;
for reasons having to do with azimuth, not range.  &lt;br /&gt;
&lt;br /&gt;
Good ident will be heard, but false localizer courses will &lt;br /&gt;
cause serious trouble for the unwary pilot.&lt;br /&gt;
&lt;br /&gt;
A patch to fix this (along with the ESV issue) has been &lt;br /&gt;
offered, but ignored.&lt;br /&gt;
&lt;br /&gt;
There are also azimuthal issues with the /glideslope/&lt;br /&gt;
service volume.  This has not yet been patched.&lt;br /&gt;
&lt;br /&gt;
==== Menu buttons having a get-together. ====&lt;br /&gt;
&lt;br /&gt;
This concerns &amp;quot;radio buttons&amp;quot; on menus, such as on the &lt;br /&gt;
location-in-air popup and elsewhere.  By definition, it should be &lt;br /&gt;
impossible to have more than one radio button pushed down at a time.&lt;br /&gt;
However, illegal situations of this sort can be created&lt;br /&gt;
using a click-and-drag gesture.  Aim at&lt;br /&gt;
a radio button, hold the mouse-button down, and drag ...&lt;br /&gt;
as if you wanted to drag the radio button to a new location.&lt;br /&gt;
This allows you to set a radio button without the others&lt;br /&gt;
being unset.  If you persist, you can have every one of&lt;br /&gt;
the buttons in the pushed-down state at the same time.&lt;br /&gt;
&lt;br /&gt;
Before you say, &amp;quot;well, don't do that then&amp;quot; or &amp;quot;garbage in,&lt;br /&gt;
garbage out&amp;quot;, let me point out that it is possible for&lt;br /&gt;
a pilot to inadvertently make a tiny dragging gesture&lt;br /&gt;
when intending only a click.  Also, when the desired&lt;br /&gt;
button is in the pushed-down state, it is easy to not&lt;br /&gt;
notice that other buttons are in the undesired state.&lt;br /&gt;
&lt;br /&gt;
==== Altimeter setting unreadable. ====&lt;br /&gt;
&lt;br /&gt;
The standard altimeter (used by the default c172p aircraft&lt;br /&gt;
and many others) had been using an unhappy hodgepodge of&lt;br /&gt;
layers.  The analog Kollsman window was unusable, because&lt;br /&gt;
it was unlabeled, and the digital altimeter setting was&lt;br /&gt;
unusable, especially at altitudes near 2500 feet, partly &lt;br /&gt;
from being behind the needle.  On a real altimeter, things&lt;br /&gt;
are positioned so that cannot happen.&lt;br /&gt;
&lt;br /&gt;
Fixing this requires using a more suitable font, moving&lt;br /&gt;
the digits over, and getting rid of conflicting extraneous&lt;br /&gt;
markings.&lt;br /&gt;
&lt;br /&gt;
A patch to implement this fix has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Memory mismanagement in subsystem_mgr. ====&lt;br /&gt;
&lt;br /&gt;
It is bad luck to apply &amp;quot;delete&amp;quot; to an object that was not&lt;br /&gt;
created with &amp;quot;new&amp;quot; ... as in line 219 of subsystem_mgr.cxx&lt;br /&gt;
&lt;br /&gt;
A patch is available, but has not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Yet more memory mismanagement. ====&lt;br /&gt;
&lt;br /&gt;
When FG is trying to exit, it is very likely to abort&lt;br /&gt;
with a message such as&lt;br /&gt;
&lt;br /&gt;
  *** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***&lt;br /&gt;
&lt;br /&gt;
There are at least three different instances of this bug,&lt;br /&gt;
each producing a different traceback.  Here is one such&lt;br /&gt;
traceback:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
#0  0xb7573947 in raise () from /lib/tls/libc.so.6&lt;br /&gt;
#1  0xb75750c9 in abort () from /lib/tls/libc.so.6&lt;br /&gt;
#2  0xb75a908a in __libc_message () from /lib/tls/libc.so.6&lt;br /&gt;
#3  0xb75b094f in _int_free () from /lib/tls/libc.so.6&lt;br /&gt;
#4  0xb75b09f2 in free () from /lib/tls/libc.so.6&lt;br /&gt;
#5  0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6&lt;br /&gt;
#6  0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766&lt;br /&gt;
#7  0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#8  0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#9  0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105&lt;br /&gt;
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237&lt;br /&gt;
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6&lt;br /&gt;
#12 0x080919c7 in fgExit (status=0) at util.cxx:120&lt;br /&gt;
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Missing Features and Traps for the Unwary ==&lt;br /&gt;
&lt;br /&gt;
==== Version number, please. ====&lt;br /&gt;
&lt;br /&gt;
It would be helpful to have an easy, documented way to ascertain the&lt;br /&gt;
version number.  A --version option on the command line would be&lt;br /&gt;
nice.  Maybe also a help::about menu item, for use while fgfs is&lt;br /&gt;
already running.&lt;br /&gt;
&lt;br /&gt;
One could imagine that info about key libraries would also be&lt;br /&gt;
helpful.&lt;br /&gt;
&lt;br /&gt;
==== Rabbits extinct. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, many airports have '''sequenced flashers''' &lt;br /&gt;
(aka the rabbit) as part of the approach-light system.&lt;br /&gt;
&lt;br /&gt;
In the FlightGear world, the sequenced flashers are inoperative&lt;br /&gt;
everywhere.  Grepping through the code suggests that no attempt&lt;br /&gt;
has been made to implement this.&lt;br /&gt;
&lt;br /&gt;
==== No comm volume control. ====&lt;br /&gt;
&lt;br /&gt;
In many aircraft including the default c172p, the comm&lt;br /&gt;
radios have no volume control knob.  In other aircraft&lt;br /&gt;
including the pa24-250, there is such a knob, but it&lt;br /&gt;
apparently isn't clickable and apparently doesn't do &lt;br /&gt;
anything.  &lt;br /&gt;
&lt;br /&gt;
In contrast, the SenecaII exemplifies the ''desired'' behavior: &lt;br /&gt;
the knob rotates when clicked and &lt;br /&gt;
correctly controls the /instrumentation/comm[N]/volume&lt;br /&gt;
property.  (This alas has no effect on the volume of ATIS&lt;br /&gt;
audio, but that must be considered an ATIS bug not a&lt;br /&gt;
Seneca bug.)&lt;br /&gt;
&lt;br /&gt;
==== Incomplete Scenery. ====&lt;br /&gt;
&lt;br /&gt;
Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ]  without installing the shared models, will get you messages such as the following:&lt;br /&gt;
&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/localizer.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml&lt;br /&gt;
&lt;br /&gt;
You might get only a few such messages, or you might get &lt;br /&gt;
screenful after screenful.&lt;br /&gt;
&lt;br /&gt;
So, make sure you download all scenery files that are needed for fgfs.&lt;br /&gt;
&lt;br /&gt;
This obviously counts as a trap for the unwary.&lt;br /&gt;
&lt;br /&gt;
- This is patently not a bug and should be moved to a &amp;quot;tips&amp;quot; section or similar.  The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...&lt;br /&gt;
&lt;br /&gt;
==== ASOS and AWOS are AWOL. ====&lt;br /&gt;
&lt;br /&gt;
At many non-tower airports (and even some tower airports) there&lt;br /&gt;
is automatic weather reporting of some kind.&lt;br /&gt;
&lt;br /&gt;
It ought to be straightforward to implement this, as a slight&lt;br /&gt;
variation on the existing ATIS feature.&lt;br /&gt;
&lt;br /&gt;
==== Roundoff problems with textranslate step and scroll. ====&lt;br /&gt;
&lt;br /&gt;
The textranslate animation is delightful for 3D animation&lt;br /&gt;
of mechanical drum-type displays as on old-fashioned&lt;br /&gt;
odometers and Hobbs meters.&lt;br /&gt;
&lt;br /&gt;
It is not, however, a convenient way to implement digital&lt;br /&gt;
readouts.  It works OK for integers, but the code in &lt;br /&gt;
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the &amp;quot;.1&amp;quot; in 122.1 MHz, particularly when the scroll-value is zero.&lt;br /&gt;
* One workaround is to stick to integers, e.g. integer kHz &lt;br /&gt;
rather than fractional MHz.&lt;br /&gt;
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.&lt;br /&gt;
* A final option (with CVS) is to use the bias tag to let the code know how to&lt;br /&gt;
handle round-off.  Use a bias value of 1/2 your smallest step value, and &lt;br /&gt;
use the same bias value on all digits.&lt;br /&gt;
&lt;br /&gt;
What we really need is a whole new support routine for dealing&lt;br /&gt;
with 3D digital displays, something at least as nice as the&lt;br /&gt;
support for 2D instruments.&lt;br /&gt;
&lt;br /&gt;
==== Broken startup banner. ====&lt;br /&gt;
&lt;br /&gt;
On startup, the simulator prints Author: Unknown and prints a bogus Date.&lt;br /&gt;
&lt;br /&gt;
The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.&lt;br /&gt;
&lt;br /&gt;
== Fixed Bugs ==&lt;br /&gt;
&lt;br /&gt;
If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).&lt;br /&gt;
&lt;br /&gt;
==== Wild accelerations at low speeds. ====&lt;br /&gt;
&lt;br /&gt;
Improper inclinometer ball indications have been observed:&lt;br /&gt;
* When parked, the ball was pegged to one side.&lt;br /&gt;
* When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.&lt;br /&gt;
&lt;br /&gt;
This was observed in the c182 model and in the default c172 model.&lt;br /&gt;
&lt;br /&gt;
Tracing indicates that the problem is not within the slip_skid_ball.cxx&lt;br /&gt;
code, but rather upstream of there, in the flight dynamics.  Tracing&lt;br /&gt;
shows that the y-accel-fps_sec values are wildly fluctuating in&lt;br /&gt;
direction, and enormous in magnitude.&lt;br /&gt;
&lt;br /&gt;
Additional evidence pointing to the FDM comes from the fact that&lt;br /&gt;
the problem is observed with JSBSim and not with larcsim (although&lt;br /&gt;
larcsim has other problems, such as drifting slowly sideways while&lt;br /&gt;
parked).&lt;br /&gt;
&lt;br /&gt;
This is important from a procedures training point of view.  &lt;br /&gt;
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi.  In a real aircraft, a pilot who found the &lt;br /&gt;
inclinometer pegged would cancel the flight before even starting&lt;br /&gt;
the engine.&lt;br /&gt;
&lt;br /&gt;
Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:&lt;br /&gt;
&lt;br /&gt;
*velocities/vdot-fps&lt;br /&gt;
*velocities/a-pilot-y-ft sec2&lt;br /&gt;
*velocities/n-pilot-y-norm&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Misdirected diagnostic in JSBSim.cxx ====&lt;br /&gt;
&lt;br /&gt;
The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout.  This made both the log and the console record hard to interpret.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====&lt;br /&gt;
&lt;br /&gt;
The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.&lt;br /&gt;
&lt;br /&gt;
Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)&lt;br /&gt;
&lt;br /&gt;
* '''This bug has not been observed in 0.9.10.'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting &amp;quot;Could not gen source&amp;quot; ====&lt;br /&gt;
&lt;br /&gt;
Any further reports or stacktraces on this bug would be appreciated.&lt;br /&gt;
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.&lt;br /&gt;
Update your sound card drivers.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed in 0.9.8a'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.7 - ? Linux - Joystick crash with correct config files ====&lt;br /&gt;
&lt;br /&gt;
Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.&lt;br /&gt;
&lt;br /&gt;
* ''' This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
==== Individual Aircraft ====&lt;br /&gt;
&lt;br /&gt;
Bugs associated with a particular aircraft should be listed&lt;br /&gt;
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.&lt;br /&gt;
&lt;br /&gt;
==== OpenSceneGraph ====&lt;br /&gt;
&lt;br /&gt;
There is a separate page for issues related to [[OpenSceneGraph]].&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3561</id>
		<title>Bugs</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3561"/>
		<updated>2007-06-17T07:22:31Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Airport lighting in poor weather. */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Known Bugs ==&lt;br /&gt;
&lt;br /&gt;
This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.&lt;br /&gt;
&lt;br /&gt;
==== Incorrect altimetry. ====&lt;br /&gt;
&lt;br /&gt;
There is evidently at least one serious misconception in the&lt;br /&gt;
code that calculates atmospheric pressure, altimeter settings, &lt;br /&gt;
et cetera.  This can be easily demonstrated:&lt;br /&gt;
&lt;br /&gt;
Park at or near the threshold of runway 33 at Aspen (KASE).&lt;br /&gt;
Under standard conditions, observe that the altimeter reads&lt;br /&gt;
7820 feet MSL, as it should.&lt;br /&gt;
&lt;br /&gt;
Use the Weather : Weather Conditions dialog popup to&lt;br /&gt;
look at the ground-level altimeter setting (QNH).&lt;br /&gt;
This is bottom row in the &amp;quot;Alt (inHg)&amp;quot; column of the popup.&lt;br /&gt;
Verify that it is 29.92.&lt;br /&gt;
&lt;br /&gt;
Now use the dialog box to change this property.  Change it&lt;br /&gt;
to 30.92, a one-inch difference.&lt;br /&gt;
&lt;br /&gt;
Go to your altimeter instrument and enter the new altimeter&lt;br /&gt;
setting in the Kollsman window.  Ideally, this '''should'''&lt;br /&gt;
cause the instrument to read the correct altitude once&lt;br /&gt;
again, namely 7820 feet MSL.&lt;br /&gt;
&lt;br /&gt;
However, due to bugs, it is likely that you will observe&lt;br /&gt;
something closer to 8120.  This means the airplane is 300 &lt;br /&gt;
feet lower than the altimeter says it is.&lt;br /&gt;
&lt;br /&gt;
In case it wasn't obvious, when flying around near Aspen,&lt;br /&gt;
being 300 feet lower than you think you are can be very&lt;br /&gt;
bad for your health.&lt;br /&gt;
&lt;br /&gt;
The absolutely correct formulas for computing the altimeter &lt;br /&gt;
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
A patch to fix the altimeter has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Altimetry misnomers and misconceptions. ====&lt;br /&gt;
&lt;br /&gt;
Both the Weather Conditions popup and the atis.cxx code&lt;br /&gt;
rely on the &amp;quot;pressure-sea-level-inhg&amp;quot; property and use&lt;br /&gt;
it in ways that the altimeter setting should be used.&lt;br /&gt;
&lt;br /&gt;
For some people this may be merely a misnomer, but for&lt;br /&gt;
others it is clearly a misconception, as recent events&lt;br /&gt;
have shown.&lt;br /&gt;
&lt;br /&gt;
The fact is, the altimeter setting is '''not''' the same &lt;br /&gt;
thing as the pressure at sea level (Psl), especially when &lt;br /&gt;
the airmass has a non-standard temperature profile.&lt;br /&gt;
The altimeter setting is something&lt;br /&gt;
else;  it is properly called the altimeter setting.  It&lt;br /&gt;
is also properly called the QNH, although private pilots&lt;br /&gt;
who fly only in the US may be unfamiliar with the QNH&lt;br /&gt;
terminology.&lt;br /&gt;
&lt;br /&gt;
In the Remarks section of a METAR, you can sometimes&lt;br /&gt;
find the ''Reduced'' Sea Level Pressure, which is&lt;br /&gt;
unfortunately denoted SLP.  This METAR SLP serves&lt;br /&gt;
the same function as the altimeter setting.  Despite&lt;br /&gt;
its name, the METAR SLP is not equal to the honest-to-goodness&lt;br /&gt;
pressure at honest-to-goodness sea level (Psl), as&lt;br /&gt;
discussed in more detail on&lt;br /&gt;
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
There needs to be a facility whereby routines that need&lt;br /&gt;
the altimeter setting can obtain the altimeter setting.&lt;br /&gt;
&lt;br /&gt;
Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
Existing code sometimes treads the &amp;quot;pressure-sea-level-inhg&amp;quot; &lt;br /&gt;
property as if it were Psl, and sometimes as if it were &lt;br /&gt;
METAR SLP.  All this needs to be vetted.&lt;br /&gt;
&lt;br /&gt;
==== Newton's laws violated by environment.cxx ====&lt;br /&gt;
&lt;br /&gt;
Consider the following results of an experiment using fgfs:&lt;br /&gt;
&lt;br /&gt;
  alt:  662  mM: 0.0288  P: 99000.8462  T: 286.8563  rho: 1.1975&lt;br /&gt;
  alt: 3462  mM: 0.0288  P: 89341.6721  T: 281.3920  rho: 1.1009&lt;br /&gt;
  &lt;br /&gt;
  alt:  662  mM: 0.0289  P: 99000.8422  T: 256.9910  rho: 1.3404&lt;br /&gt;
  alt: 3462  mM: 0.0289  P: 89341.6740  T: 252.0956  rho: 1.2333&lt;br /&gt;
&lt;br /&gt;
The first pair of lines represent before and after a simple&lt;br /&gt;
flight from one airport to another, with a net gain in altitude of&lt;br /&gt;
2800 feet, under standard conditions.  So far so good.&lt;br /&gt;
&lt;br /&gt;
The second pair of lines represent exactly the same flight, &lt;br /&gt;
except that the ambient temperature was 30 degrees colder&lt;br /&gt;
than before.  You can see that the density (rho) is greater,&lt;br /&gt;
in accordance with the ideal gas law.&lt;br /&gt;
&lt;br /&gt;
The problem is that the delta_P is exactly the same for the two&lt;br /&gt;
flights.  This is a problem because P is connected to the weight&lt;br /&gt;
of the air column.  If the air is 12% denser, the laws of physics &lt;br /&gt;
require it to have a 12% steeper pressure gradient dP/dh ... but &lt;br /&gt;
alas this is not observed.&lt;br /&gt;
&lt;br /&gt;
This incorrect pressure profile P(h) has many consequences affecting&lt;br /&gt;
engine performance, airfoil performance, altimetry, et cetera.&lt;br /&gt;
&lt;br /&gt;
==== Z-buffer burn-through. ====&lt;br /&gt;
&lt;br /&gt;
Sometimes distant objects can be seen through nearer objects that&lt;br /&gt;
are not supposed to be transparent.  For example:  Runway lights &lt;br /&gt;
sometimes burn through a solid cloud layer.  Also runway lights&lt;br /&gt;
sometimes burn through aircraft structure.  Some instruments&lt;br /&gt;
burn through the yoke.&lt;br /&gt;
&lt;br /&gt;
It seems that so-called &amp;quot;2D&amp;quot; objects in the&lt;br /&gt;
background are likely to burn through &amp;quot;3D&amp;quot; objects in the&lt;br /&gt;
foreground.  This is particularly noticeable in aircraft&lt;br /&gt;
that have a mixture of 2D and 3D instruments.&lt;br /&gt;
&lt;br /&gt;
The ''position'' in space of the offending objects is OK, as&lt;br /&gt;
you can verify by shifting your PoV to get a little bit of&lt;br /&gt;
a side view.  The obvious hypothesis is that the Z-order&lt;br /&gt;
is being mishandled in a Z-buffer somewhere.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak. ====&lt;br /&gt;
&lt;br /&gt;
The simulator will gobble up about 3 gigabytes&lt;br /&gt;
of virtual memory overnight, while paused.  &lt;br /&gt;
Without the&lt;br /&gt;
leak, the memory footprint would be less than 300 meg.  The&lt;br /&gt;
difference between 300 meg and 3 gig is quite &lt;br /&gt;
significant on machines that have only 1 or 2 gig&lt;br /&gt;
of main memory.&lt;br /&gt;
&lt;br /&gt;
A rather steady leak of 2 meg per minute is observed&lt;br /&gt;
during pause, no matter whether the aircraft is aloft&lt;br /&gt;
or parked on the ground.  '''Vastly less leakage''' (two&lt;br /&gt;
orders of magnitude less, possibly zero) is observed&lt;br /&gt;
when the simulator is not paused, and the aircraft&lt;br /&gt;
is simply sitting on the ground with the parking&lt;br /&gt;
brake set.&lt;br /&gt;
&lt;br /&gt;
This bug has been observed in multiple versions of fgfs,&lt;br /&gt;
including one compiled back in May, 2006 as well as&lt;br /&gt;
the most current CVS version.&lt;br /&gt;
&lt;br /&gt;
This is 100% reproducible with a &lt;br /&gt;
ATI RV350 [Mobility Radeon 9600 M10] chipset&lt;br /&gt;
and the ati-fglrx driver.&lt;br /&gt;
The leak is observed whether or not &lt;br /&gt;
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.&lt;br /&gt;
&lt;br /&gt;
==== Numerous bugs in ATIS feature. ====&lt;br /&gt;
&lt;br /&gt;
1) The ATIS is supposed to change whenever there is a&lt;br /&gt;
significant change in the weather.  The comments mention&lt;br /&gt;
this, but the code makes no attempt to implement this.&lt;br /&gt;
&lt;br /&gt;
2) The code assumes that ATIS is prepared on the hour.&lt;br /&gt;
In practice this is virtually never the case;  a new&lt;br /&gt;
ATIS is prepared hourly, but not on the hour.  Also&lt;br /&gt;
this assumption is inconsistent with ATIS changes&lt;br /&gt;
based on the weather.&lt;br /&gt;
&lt;br /&gt;
3) The code attempts to issue a station identifier, but&lt;br /&gt;
none is heard.&lt;br /&gt;
&lt;br /&gt;
4) Multiple departures from standard phraseology.&lt;br /&gt;
&lt;br /&gt;
5) The volume is too low;  ATIS is not readable over engine noise.&lt;br /&gt;
This defeats much of the purpose of ATIS.  The volume does&lt;br /&gt;
not respond to the /instrumentation/comm[N]/volume property.&lt;br /&gt;
&lt;br /&gt;
6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.&lt;br /&gt;
&lt;br /&gt;
x) Et cetera.&lt;br /&gt;
&lt;br /&gt;
A patch to fix a few dozen ATIS bugs is available, but has not been&lt;br /&gt;
incorporated into FG CVS.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --altitude option. ====&lt;br /&gt;
&lt;br /&gt;
When the aircraft is initialzed aloft using the &lt;br /&gt;
command-line --altitude=6000&lt;br /&gt;
option, 0.9.10 is observed to put up a blank screen &lt;br /&gt;
(no scenery, no panel) and to spew on the console &lt;br /&gt;
page after page like this:&lt;br /&gt;
&lt;br /&gt;
  Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..&lt;br /&gt;
  altitude         = -1.69132e-41&lt;br /&gt;
  sea level radius = -6.54575e-42&lt;br /&gt;
  latitude         = 6.9874e-316&lt;br /&gt;
  longitude        = 6.79737e-313&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_pitch&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_volume&lt;br /&gt;
&lt;br /&gt;
==== Multiple bugs in the location-in-air popup. ====&lt;br /&gt;
&lt;br /&gt;
The location-in-air popup turns off the magnetos and extends&lt;br /&gt;
the landing gear.  Some pilots and flight instructors &lt;br /&gt;
deem this to be undesirable behavior, especially if all&lt;br /&gt;
they are trying to do is relocate from one airborne position to&lt;br /&gt;
another.&lt;br /&gt;
&lt;br /&gt;
Similarly, it strongly perturbs the throttle setting, &lt;br /&gt;
aileron trim, elevator trim, rudder trim, &lt;br /&gt;
view angles, PoV position, and who-knows-what else.  &lt;br /&gt;
Again, people who know about airplanes consider this to&lt;br /&gt;
be undesirable behavior.&lt;br /&gt;
&lt;br /&gt;
There is also a tendency to place the aircraft into &lt;br /&gt;
dangerous unusual attitudes, and other bugs too numerous &lt;br /&gt;
to mention.&lt;br /&gt;
&lt;br /&gt;
Evidently, though, there is at least one person who likes&lt;br /&gt;
things the way they are.  Code that would have fixed these&lt;br /&gt;
bugs was rejected.  Neither specific nor constructive criticism&lt;br /&gt;
of the code was offered.  For details see the flightgear-devel&lt;br /&gt;
mailing list archives.&lt;br /&gt;
&lt;br /&gt;
==== Nearest fix. ====&lt;br /&gt;
&lt;br /&gt;
Did you know that there are 8 different BRAVO intersections&lt;br /&gt;
in the database?&lt;br /&gt;
&lt;br /&gt;
Until now there was no support in the code for this;  all but&lt;br /&gt;
one of the entries was thrown away at the lowest level. There&lt;br /&gt;
is a comment in the code saying that fixing this is on the&lt;br /&gt;
TODO list.&lt;br /&gt;
&lt;br /&gt;
As for navaids (as opposed to waypoints), the low-level code&lt;br /&gt;
already provides support for ambiguous IDs, but the information&lt;br /&gt;
is not being used very wisely by the higher layers.&lt;br /&gt;
&lt;br /&gt;
Code to fix these problems was offered to the community.&lt;br /&gt;
So far it has been completely ignored.&lt;br /&gt;
&lt;br /&gt;
==== HSI instrument failure. ====&lt;br /&gt;
&lt;br /&gt;
If you use the &amp;quot;heading indicator&amp;quot; checkbox on the&lt;br /&gt;
&amp;quot;instrument failure&amp;quot; popup to command a failure,&lt;br /&gt;
it has no effect on the HSI instrument used by&lt;br /&gt;
many aircraft in the simulator fleet.&lt;br /&gt;
&lt;br /&gt;
This is because of wrong code in hsi.xml.  &lt;br /&gt;
&lt;br /&gt;
Backend code to handle this correctly exists, but has&lt;br /&gt;
apparently never been used.  It needs one small fix,&lt;br /&gt;
followed by recompilation.  A patchset to take care&lt;br /&gt;
of all this was offered to the community, but has&lt;br /&gt;
not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Flux gate not really a flux gate. ====&lt;br /&gt;
&lt;br /&gt;
In the Instrumentation director, there are three heading-related&lt;br /&gt;
.cxx files.&lt;br /&gt;
* heading_indicator.cxx : vacuum driven, with drift&lt;br /&gt;
* heading_indicator_dg.cxx : electrically driven, with drift&lt;br /&gt;
* heading_indicator_fg.cxx : electrically driven, no drift&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;fg&amp;quot; in &amp;quot;heading_indicator_fg&amp;quot; is documented to stand for&lt;br /&gt;
&amp;quot;flux gate&amp;quot;, as if the heading were slaved to a flux-gate&lt;br /&gt;
compass ... but the code does not implement any such thing.&lt;br /&gt;
All it really does is initialize the indicated heading to &lt;br /&gt;
the correct magnetic heading value, and then implement a &lt;br /&gt;
no-drift policy.  This is incorrect behavior, as can be&lt;br /&gt;
seen by flying to an area where the magnetic variation is&lt;br /&gt;
different from what it was at the start of the flight.  A&lt;br /&gt;
true slaved heading indicator would gradually accommodate&lt;br /&gt;
the new magvar.&lt;br /&gt;
&lt;br /&gt;
The correct behavior ought to be easy to implement.&lt;br /&gt;
&lt;br /&gt;
==== Weird noises during initialization. ====&lt;br /&gt;
&lt;br /&gt;
It is observed that sometimes while the simulator is starting&lt;br /&gt;
up, before things are fully operational, weird noises are&lt;br /&gt;
produced.  For example, in the c182rg, gear-in-transit&lt;br /&gt;
noises are produced for several seconds before the first&lt;br /&gt;
display becomes visible.  (According to a dump of the&lt;br /&gt;
relevant variables, there is no evidence that the gear is&lt;br /&gt;
actually in transit, and no reason why it should be.)&lt;br /&gt;
&lt;br /&gt;
Code to fix this was submitted.  So far it has been&lt;br /&gt;
ignored.&lt;br /&gt;
&lt;br /&gt;
==== Weird displays during fullscreen initialization. ====&lt;br /&gt;
&lt;br /&gt;
If the --enable-fullscreen command-line option is used, &lt;br /&gt;
the window is enlarged to full-screen size at a time&lt;br /&gt;
when initialization is only half-complete.  From this&lt;br /&gt;
time until the end of initialization, the display &lt;br /&gt;
contains weird combinations of leftover graphic objects&lt;br /&gt;
and other junk.&lt;br /&gt;
&lt;br /&gt;
This is observed no matter whether the splash-screen feature&lt;br /&gt;
is enabled or disabled.&lt;br /&gt;
&lt;br /&gt;
==== Fullscreen window sometimes misplaced. ====&lt;br /&gt;
&lt;br /&gt;
About 20% of the time, when the --enable-fullscreen command-line&lt;br /&gt;
option is used, it opens a window of the correct size, but &lt;br /&gt;
badly misplaced relative to the screen, such that only one half&lt;br /&gt;
or one quarter of the window is on-screen.&lt;br /&gt;
&lt;br /&gt;
==== Navigation databases out-of-date ====&lt;br /&gt;
&lt;br /&gt;
The database of navigation waypoints and fixes has an internal&lt;br /&gt;
date of early 2005.  It is missing quite a few useful fixes.  &lt;br /&gt;
The FAA has defined quite a few new approaches in recent years,&lt;br /&gt;
and has revised others.&lt;br /&gt;
&lt;br /&gt;
An updated version, based on a pull of the much more&lt;br /&gt;
current x-plane database, was made available.  So far&lt;br /&gt;
it has been ignored.&lt;br /&gt;
&lt;br /&gt;
Similar remarks apply to the ''navaids'' database.&lt;br /&gt;
&lt;br /&gt;
==== Ident from phantom DME. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, some VOR stations and even some localizers&lt;br /&gt;
have a colocated DME station ... but there are plenty that&lt;br /&gt;
don't.&lt;br /&gt;
&lt;br /&gt;
The DME has its own Morse ident, with a distinctive higher pitch.&lt;br /&gt;
&lt;br /&gt;
In the simulator, due to a bug in the code, all stations&lt;br /&gt;
transmit the DME Morse ident ... even stations where no&lt;br /&gt;
DME is present.&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx finds the nearest VOR or LOC on the&lt;br /&gt;
frequency, and checks to see if it is in range.  It also asks&lt;br /&gt;
for the &amp;quot;nearest&amp;quot; DME on the frequency, but makes no attempt&lt;br /&gt;
to check that it is in range.  To say the same thing the&lt;br /&gt;
other way, there is no attempt to check that the aircraft is&lt;br /&gt;
within the service volume of the DME.  Since there is almost always&lt;br /&gt;
a DME /somewhere/ on the frequency, the has_dme variable will&lt;br /&gt;
always be set true.&lt;br /&gt;
&lt;br /&gt;
For a demonstration of this bug, park at KAOO airport and &lt;br /&gt;
tune up the AOO VOR (which has no DME).  Or park at almost&lt;br /&gt;
any airport and tune up the localizer (since relatively few&lt;br /&gt;
localizers have DME).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Airport lighting in poor weather. ====&lt;br /&gt;
&lt;br /&gt;
The code in tileentry.cxx turns on airport lights according to&lt;br /&gt;
the position of the sun relative to the horizon.  One consequence&lt;br /&gt;
is that the lights are off during the day.&lt;br /&gt;
&lt;br /&gt;
In real life, there are many circumstances where airport lights,&lt;br /&gt;
including approach lights, are turned on during the day.  At tower airports, the lights are turned on during bad weather -- including weather that &lt;br /&gt;
is only slightly bad -- and also turned on if requested by the pilot.  For&lt;br /&gt;
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].&lt;br /&gt;
&lt;br /&gt;
At non-towered airports, the lights are usually pilot-controlled,&lt;br /&gt;
via radio.&lt;br /&gt;
&lt;br /&gt;
The absence of lighting during daytime in poor weather detracts &lt;br /&gt;
significantly from the realism, because it affects both the&lt;br /&gt;
legality and the practicality of performing instrument approaches&lt;br /&gt;
under such conditions.&lt;br /&gt;
&lt;br /&gt;
** In version 0.9.10 runway lights are turned on automatically in day time if visibility is low. Though I agree, that pilot controlled lights could be a nice feature, but it's not a bug, it's more like a wish list entry, I suppose.&lt;br /&gt;
&lt;br /&gt;
==== Holes in the ground. ====&lt;br /&gt;
&lt;br /&gt;
Ever since the first win32-build of FG-OSG, there are at least two huge &lt;br /&gt;
ground scenery holes in the the Rhine/Main/Neckar-region in Germany. &lt;br /&gt;
The first one gapes at &lt;br /&gt;
the place which was formerly known as the city of Mannheim (near the &lt;br /&gt;
airport EDFM, which is still there), the second one has swallowed up a &lt;br /&gt;
big piece of Frankfurt am Main (near EDDF) and surrounding land. &lt;br /&gt;
&lt;br /&gt;
First posted to the flightgear-devel list in November, 2006.&lt;br /&gt;
&lt;br /&gt;
==== Mixture versus Altitude. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that at&lt;br /&gt;
high altitude airports (e.g. KGCN or KASE), to obtain max&lt;br /&gt;
static RPM, it suffices to move the mixture control only a&lt;br /&gt;
few mm aft of the full-forward (full-rich) position.&lt;br /&gt;
&lt;br /&gt;
This is unrealistic.  In a real aircraft under such conditions,&lt;br /&gt;
it would be necessary to pull the mixture control back about&lt;br /&gt;
an inch to obtain max RPM.&lt;br /&gt;
&lt;br /&gt;
It's hard to say whether the carburetor is underreacting to the&lt;br /&gt;
altitude, or overreacting to the mixture control.&lt;br /&gt;
&lt;br /&gt;
==== EGT reads high. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that the&lt;br /&gt;
EGT reads toward the high end of the scale under all conditions,&lt;br /&gt;
including idle.  This is unrealistic.&lt;br /&gt;
&lt;br /&gt;
Also, the EGT reads ''off-scale'' high under high-power conditions.&lt;br /&gt;
&lt;br /&gt;
==== Flags missing from instruments. ====&lt;br /&gt;
&lt;br /&gt;
Some of the standard instruments lack status flags.  For example,&lt;br /&gt;
the GS needle goes to  mid-scale if there is no valid signal.  That'll kill you for sure.  Reportedly the hi-res instruments implement flags, but the lo-res ones don't.  Many aircraft are using the lo-res instruments.&lt;br /&gt;
&lt;br /&gt;
Either the aircraft should be upgraded to use instruments that&lt;br /&gt;
display flags, or the instruments should be upgraded to be&lt;br /&gt;
display flags.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --model-hz option. ====&lt;br /&gt;
&lt;br /&gt;
Specifying the --model-hz=10 command-line option results in the&lt;br /&gt;
following mess:&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml&lt;br /&gt;
  Sorry, wdot doesn't appear to be trimmable&lt;br /&gt;
 Trim Failed&lt;br /&gt;
  Trim Results: &lt;br /&gt;
       Angle of Attack:   7.50  wdot:  3.21e+01 Tolerance: 1e-03  Failed&lt;br /&gt;
              Throttle:   0.50  udot:  0.00e+00 Tolerance: 1e-03  Passed&lt;br /&gt;
            Pitch Trim:   0.00  qdot: -5.44e-11 Tolerance: 1e-04  Passed&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 WWarning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
     [many repeats]&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 altitude         = 9&lt;br /&gt;
 sea level radius = 4.62829e-268&lt;br /&gt;
 latitude         = 1.52075e-314&lt;br /&gt;
 longitude        = -0.0967923&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = nan&lt;br /&gt;
 sea level radius = nan&lt;br /&gt;
 latitude         = nan&lt;br /&gt;
 longitude        = nan&lt;br /&gt;
&lt;br /&gt;
and so forth.&lt;br /&gt;
&lt;br /&gt;
* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.&lt;br /&gt;
&lt;br /&gt;
==== CPU hogging. ====&lt;br /&gt;
&lt;br /&gt;
The fsgs program will happily eat up &amp;gt;98% of the cpu cycles,&lt;br /&gt;
even when the simulator is paused.  That seems excessive,&lt;br /&gt;
particularly during pause.  This is on a 2GHz machine&lt;br /&gt;
with hardware acceleration.  As a point of reference, &lt;br /&gt;
glxgears uses only a fraction of one percent of the cpu.&lt;br /&gt;
&lt;br /&gt;
* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result  if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)&lt;br /&gt;
&lt;br /&gt;
==== Out-of-bounds array reference in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the interpolation table code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the &amp;quot;message&amp;quot; handling code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Glideslope service volume. ====&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx appears to assume the glideslope&lt;br /&gt;
service volume is the same as the localizer service&lt;br /&gt;
volume.  This is quite unrealistic.&lt;br /&gt;
&lt;br /&gt;
==== Extended service volume. ====&lt;br /&gt;
&lt;br /&gt;
In some parts of the world, a goodly fraction of the&lt;br /&gt;
localizers have an expanded service volume (ESV),&lt;br /&gt;
often quite a bit larger than the standard service&lt;br /&gt;
volume you see in the AIM.  The code in navradio.cxx&lt;br /&gt;
was ignoring the service volume information in the&lt;br /&gt;
database and wrongly assuming the default values&lt;br /&gt;
applied everywhere.  Code to fix the range-related&lt;br /&gt;
part of the problem has been offered&lt;br /&gt;
but not yet incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Other service volume issues. ====&lt;br /&gt;
&lt;br /&gt;
The code  in navradio.cxx has no understanding of how &lt;br /&gt;
'''azimuth''' affects the&lt;br /&gt;
localizer.  There is more to the story than reception range.&lt;br /&gt;
It is perfectly possible to be outside the LOC service volume &lt;br /&gt;
for reasons having to do with azimuth, not range.  &lt;br /&gt;
&lt;br /&gt;
Good ident will be heard, but false localizer courses will &lt;br /&gt;
cause serious trouble for the unwary pilot.&lt;br /&gt;
&lt;br /&gt;
A patch to fix this (along with the ESV issue) has been &lt;br /&gt;
offered, but ignored.&lt;br /&gt;
&lt;br /&gt;
There are also azimuthal issues with the /glideslope/&lt;br /&gt;
service volume.  This has not yet been patched.&lt;br /&gt;
&lt;br /&gt;
==== Menu buttons having a get-together. ====&lt;br /&gt;
&lt;br /&gt;
This concerns &amp;quot;radio buttons&amp;quot; on menus, such as on the &lt;br /&gt;
location-in-air popup and elsewhere.  By definition, it should be &lt;br /&gt;
impossible to have more than one radio button pushed down at a time.&lt;br /&gt;
However, illegal situations of this sort can be created&lt;br /&gt;
using a click-and-drag gesture.  Aim at&lt;br /&gt;
a radio button, hold the mouse-button down, and drag ...&lt;br /&gt;
as if you wanted to drag the radio button to a new location.&lt;br /&gt;
This allows you to set a radio button without the others&lt;br /&gt;
being unset.  If you persist, you can have every one of&lt;br /&gt;
the buttons in the pushed-down state at the same time.&lt;br /&gt;
&lt;br /&gt;
Before you say, &amp;quot;well, don't do that then&amp;quot; or &amp;quot;garbage in,&lt;br /&gt;
garbage out&amp;quot;, let me point out that it is possible for&lt;br /&gt;
a pilot to inadvertently make a tiny dragging gesture&lt;br /&gt;
when intending only a click.  Also, when the desired&lt;br /&gt;
button is in the pushed-down state, it is easy to not&lt;br /&gt;
notice that other buttons are in the undesired state.&lt;br /&gt;
&lt;br /&gt;
==== Altimeter setting unreadable. ====&lt;br /&gt;
&lt;br /&gt;
The standard altimeter (used by the default c172p aircraft&lt;br /&gt;
and many others) had been using an unhappy hodgepodge of&lt;br /&gt;
layers.  The analog Kollsman window was unusable, because&lt;br /&gt;
it was unlabeled, and the digital altimeter setting was&lt;br /&gt;
unusable, especially at altitudes near 2500 feet, partly &lt;br /&gt;
from being behind the needle.  On a real altimeter, things&lt;br /&gt;
are positioned so that cannot happen.&lt;br /&gt;
&lt;br /&gt;
Fixing this requires using a more suitable font, moving&lt;br /&gt;
the digits over, and getting rid of conflicting extraneous&lt;br /&gt;
markings.&lt;br /&gt;
&lt;br /&gt;
A patch to implement this fix has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Memory mismanagement in subsystem_mgr. ====&lt;br /&gt;
&lt;br /&gt;
It is bad luck to apply &amp;quot;delete&amp;quot; to an object that was not&lt;br /&gt;
created with &amp;quot;new&amp;quot; ... as in line 219 of subsystem_mgr.cxx&lt;br /&gt;
&lt;br /&gt;
A patch is available, but has not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Yet more memory mismanagement. ====&lt;br /&gt;
&lt;br /&gt;
When FG is trying to exit, it is very likely to abort&lt;br /&gt;
with a message such as&lt;br /&gt;
&lt;br /&gt;
  *** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***&lt;br /&gt;
&lt;br /&gt;
There are at least three different instances of this bug,&lt;br /&gt;
each producing a different traceback.  Here is one such&lt;br /&gt;
traceback:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
#0  0xb7573947 in raise () from /lib/tls/libc.so.6&lt;br /&gt;
#1  0xb75750c9 in abort () from /lib/tls/libc.so.6&lt;br /&gt;
#2  0xb75a908a in __libc_message () from /lib/tls/libc.so.6&lt;br /&gt;
#3  0xb75b094f in _int_free () from /lib/tls/libc.so.6&lt;br /&gt;
#4  0xb75b09f2 in free () from /lib/tls/libc.so.6&lt;br /&gt;
#5  0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6&lt;br /&gt;
#6  0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766&lt;br /&gt;
#7  0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#8  0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#9  0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105&lt;br /&gt;
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237&lt;br /&gt;
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6&lt;br /&gt;
#12 0x080919c7 in fgExit (status=0) at util.cxx:120&lt;br /&gt;
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Missing Features and Traps for the Unwary ==&lt;br /&gt;
&lt;br /&gt;
==== Version number, please. ====&lt;br /&gt;
&lt;br /&gt;
It would be helpful to have an easy, documented way to ascertain the&lt;br /&gt;
version number.  A --version option on the command line would be&lt;br /&gt;
nice.  Maybe also a help::about menu item, for use while fgfs is&lt;br /&gt;
already running.&lt;br /&gt;
&lt;br /&gt;
One could imagine that info about key libraries would also be&lt;br /&gt;
helpful.&lt;br /&gt;
&lt;br /&gt;
==== Rabbits extinct. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, many airports have '''sequenced flashers''' &lt;br /&gt;
(aka the rabbit) as part of the approach-light system.&lt;br /&gt;
&lt;br /&gt;
In the FlightGear world, the sequenced flashers are inoperative&lt;br /&gt;
everywhere.  Grepping through the code suggests that no attempt&lt;br /&gt;
has been made to implement this.&lt;br /&gt;
&lt;br /&gt;
==== No comm volume control. ====&lt;br /&gt;
&lt;br /&gt;
In many aircraft including the default c172p, the comm&lt;br /&gt;
radios have no volume control knob.  In other aircraft&lt;br /&gt;
including the pa24-250, there is such a knob, but it&lt;br /&gt;
apparently isn't clickable and apparently doesn't do &lt;br /&gt;
anything.  &lt;br /&gt;
&lt;br /&gt;
In contrast, the SenecaII exemplifies the ''desired'' behavior: &lt;br /&gt;
the knob rotates when clicked and &lt;br /&gt;
correctly controls the /instrumentation/comm[N]/volume&lt;br /&gt;
property.  (This alas has no effect on the volume of ATIS&lt;br /&gt;
audio, but that must be considered an ATIS bug not a&lt;br /&gt;
Seneca bug.)&lt;br /&gt;
&lt;br /&gt;
==== Incomplete Scenery. ====&lt;br /&gt;
&lt;br /&gt;
Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ]  without installing the shared models, will get you messages such as the following:&lt;br /&gt;
&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/localizer.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml&lt;br /&gt;
&lt;br /&gt;
You might get only a few such messages, or you might get &lt;br /&gt;
screenful after screenful.&lt;br /&gt;
&lt;br /&gt;
So, make sure you download all scenery files that are needed for fgfs.&lt;br /&gt;
&lt;br /&gt;
This obviously counts as a trap for the unwary.&lt;br /&gt;
&lt;br /&gt;
- This is patently not a bug and should be moved to a &amp;quot;tips&amp;quot; section or similar.  The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...&lt;br /&gt;
&lt;br /&gt;
==== ASOS and AWOS are AWOL. ====&lt;br /&gt;
&lt;br /&gt;
At many non-tower airports (and even some tower airports) there&lt;br /&gt;
is automatic weather reporting of some kind.&lt;br /&gt;
&lt;br /&gt;
It ought to be straightforward to implement this, as a slight&lt;br /&gt;
variation on the existing ATIS feature.&lt;br /&gt;
&lt;br /&gt;
==== Roundoff problems with textranslate step and scroll. ====&lt;br /&gt;
&lt;br /&gt;
The textranslate animation is delightful for 3D animation&lt;br /&gt;
of mechanical drum-type displays as on old-fashioned&lt;br /&gt;
odometers and Hobbs meters.&lt;br /&gt;
&lt;br /&gt;
It is not, however, a convenient way to implement digital&lt;br /&gt;
readouts.  It works OK for integers, but the code in &lt;br /&gt;
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the &amp;quot;.1&amp;quot; in 122.1 MHz, particularly when the scroll-value is zero.&lt;br /&gt;
* One workaround is to stick to integers, e.g. integer kHz &lt;br /&gt;
rather than fractional MHz.&lt;br /&gt;
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.&lt;br /&gt;
* A final option (with CVS) is to use the bias tag to let the code know how to&lt;br /&gt;
handle round-off.  Use a bias value of 1/2 your smallest step value, and &lt;br /&gt;
use the same bias value on all digits.&lt;br /&gt;
&lt;br /&gt;
What we really need is a whole new support routine for dealing&lt;br /&gt;
with 3D digital displays, something at least as nice as the&lt;br /&gt;
support for 2D instruments.&lt;br /&gt;
&lt;br /&gt;
==== Broken startup banner. ====&lt;br /&gt;
&lt;br /&gt;
On startup, the simulator prints Author: Unknown and prints a bogus Date.&lt;br /&gt;
&lt;br /&gt;
The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.&lt;br /&gt;
&lt;br /&gt;
== Fixed Bugs ==&lt;br /&gt;
&lt;br /&gt;
If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).&lt;br /&gt;
&lt;br /&gt;
==== Wild accelerations at low speeds. ====&lt;br /&gt;
&lt;br /&gt;
Improper inclinometer ball indications have been observed:&lt;br /&gt;
* When parked, the ball was pegged to one side.&lt;br /&gt;
* When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.&lt;br /&gt;
&lt;br /&gt;
This was observed in the c182 model and in the default c172 model.&lt;br /&gt;
&lt;br /&gt;
Tracing indicates that the problem is not within the slip_skid_ball.cxx&lt;br /&gt;
code, but rather upstream of there, in the flight dynamics.  Tracing&lt;br /&gt;
shows that the y-accel-fps_sec values are wildly fluctuating in&lt;br /&gt;
direction, and enormous in magnitude.&lt;br /&gt;
&lt;br /&gt;
Additional evidence pointing to the FDM comes from the fact that&lt;br /&gt;
the problem is observed with JSBSim and not with larcsim (although&lt;br /&gt;
larcsim has other problems, such as drifting slowly sideways while&lt;br /&gt;
parked).&lt;br /&gt;
&lt;br /&gt;
This is important from a procedures training point of view.  &lt;br /&gt;
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi.  In a real aircraft, a pilot who found the &lt;br /&gt;
inclinometer pegged would cancel the flight before even starting&lt;br /&gt;
the engine.&lt;br /&gt;
&lt;br /&gt;
Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:&lt;br /&gt;
&lt;br /&gt;
*velocities/vdot-fps&lt;br /&gt;
*velocities/a-pilot-y-ft sec2&lt;br /&gt;
*velocities/n-pilot-y-norm&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Misdirected diagnostic in JSBSim.cxx ====&lt;br /&gt;
&lt;br /&gt;
The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout.  This made both the log and the console record hard to interpret.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====&lt;br /&gt;
&lt;br /&gt;
The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.&lt;br /&gt;
&lt;br /&gt;
Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)&lt;br /&gt;
&lt;br /&gt;
* '''This bug has not been observed in 0.9.10.'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting &amp;quot;Could not gen source&amp;quot; ====&lt;br /&gt;
&lt;br /&gt;
Any further reports or stacktraces on this bug would be appreciated.&lt;br /&gt;
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.&lt;br /&gt;
Update your sound card drivers.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed in 0.9.8a'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.7 - ? Linux - Joystick crash with correct config files ====&lt;br /&gt;
&lt;br /&gt;
Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.&lt;br /&gt;
&lt;br /&gt;
* ''' This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
==== Individual Aircraft ====&lt;br /&gt;
&lt;br /&gt;
Bugs associated with a particular aircraft should be listed&lt;br /&gt;
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.&lt;br /&gt;
&lt;br /&gt;
==== OpenSceneGraph ====&lt;br /&gt;
&lt;br /&gt;
There is a separate page for issues related to [[OpenSceneGraph]].&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3560</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3560"/>
		<updated>2007-06-17T07:20:46Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
* no cockpit light at night visible&lt;br /&gt;
* no pilot and co pilot visible&lt;br /&gt;
* aircraft has no shadow&lt;br /&gt;
* strobe lights barley available (the ones of the b0105 helictopter look much better)&lt;br /&gt;
** Strobes not yet implemented. Anti-collision light blinks to the front but currently shows constant red aft.&lt;br /&gt;
* landing lights are missing&lt;br /&gt;
&lt;br /&gt;
3d Cockpit:&lt;br /&gt;
&lt;br /&gt;
* cockpit instruments do light at night, but the cockpit itself stays dark&lt;br /&gt;
* no rudder control pedals available&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** It's not a museum, the game is for people who want to fly the aircraft, not to sit inside the cockpit and look around.&lt;br /&gt;
* one of the levers has an error, it looks like a square and it is not round like the lever should be&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
* cockpit window has no windscreen wipers&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers.&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
* engine sound in cockpit does not differ from outside engine sound&lt;br /&gt;
* hud is not available&lt;br /&gt;
* aircraft is flipped when pressing the reset button&lt;br /&gt;
* aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3559</id>
		<title>Cessna 172P</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Cessna_172P&amp;diff=3559"/>
		<updated>2007-06-16T22:45:58Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* c172 Alias for c172p. &lt;br /&gt;
* c172-3d Alias for c172p-3d. &lt;br /&gt;
* c172-3d-yasim Alias for c172r-3d-yasim &lt;br /&gt;
* c172-610x Alias for jsbsim version. &lt;br /&gt;
* c172-610x-jsbsim Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-610x-null Cessna 172 with a full screen, hi-res panel &lt;br /&gt;
* c172-ifr Cessna 172 in IFR configuration &lt;br /&gt;
* c172-yasim Alias for c172r-yasim &lt;br /&gt;
* c172p Cessna 172P Skyhawk (1981 model) &lt;br /&gt;
* c172p-2dpanel Cessna 172P Skyhawk (1981 model), 2D panel &lt;br /&gt;
* c172r Alias for c172r-jsbsim. &lt;br /&gt;
* c172r-3d Alias for c172r-3d-jsbsim. &lt;br /&gt;
* c172r-3d-jsbsim Cessna 172R (JSBSim, 3D cockpit) &lt;br /&gt;
* c172r-3d-yasim Cessna 172R (YASim, 3D cockpit) &lt;br /&gt;
* c172r-jsbsim Cessna 172R (JSBSim, 2D panel). &lt;br /&gt;
* c172r-yasim Cessna 172R (YASim, 2D panel) &lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
c172x Cessna 172 flight dynamics testbed -&amp;gt; when using this alias, Flightgear aborts loading !&lt;br /&gt;
&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* when moving the rudder controls, there is a small error at the tail of the rudder&lt;br /&gt;
* no cockpit light at night visible&lt;br /&gt;
* no pilot and co pilot visible&lt;br /&gt;
* aircraft has no shadow&lt;br /&gt;
* strobe lights barley available (the ones of the b0105 helictopter look much better)&lt;br /&gt;
** Strobes not yet implemented. Anti-collision light blinks to the front but currently shows constant red aft.&lt;br /&gt;
* landing lights are missing&lt;br /&gt;
&lt;br /&gt;
3d Cockpit:&lt;br /&gt;
&lt;br /&gt;
* cockpit instruments do light at night, but the cockpit itself stays dark&lt;br /&gt;
* no rudder control pedals available&lt;br /&gt;
* can't hear sound when pressing the switches and levers in the cockpit&lt;br /&gt;
** It is questionable whether switchgear and levers can be heard over the engine in the real aircraft.&lt;br /&gt;
* cockpit instruments look flat, they don't have a 3d look&lt;br /&gt;
** According to Aircraft Readme, 3d instruments are WIP.&lt;br /&gt;
* cockpit is textured but textures need more polish, for example there are no door opener visible at the side doors&lt;br /&gt;
** who needs to see those door openers (it's not a museum, it's all about flying)&lt;br /&gt;
* one of the levers has an error, it looks like a square and it is not round like the lever should be&lt;br /&gt;
** The Carb Heat control on the real 172P *is* square in shape.&lt;br /&gt;
* no pilot or co pilot present&lt;br /&gt;
* cockpit window has no windscreen wipers&lt;br /&gt;
** The Cessna 172 is not fitted with windscreen wipers.&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* It is routine to observe 135 Kias at 2850 RPM in level flight at 1000 MSL, using only 13 gph.  This is not the sort of performance seen in real-life Skyhawks.&lt;br /&gt;
* engine sound in cockpit does not differ from outside engine sound&lt;br /&gt;
* hud is not available&lt;br /&gt;
* aircraft is flipped when pressing the reset button&lt;br /&gt;
* aircraft has the wrong elevation (approximately 20 meter above the runway) after pressing the reset key&lt;br /&gt;
* when I nosedive the sound of the engine gets higher and higher like it should, but then after some seconds of nosediving this high engine sound abruptly ends and the tone pitch is suddenly so low like it is when doing a normal horizontal flight -&amp;gt; this sounds like a bug in flightgear&lt;br /&gt;
** This occurs at approx 325 Knots (as show on HUD) which is over 2x Vne. The airframe could be assumed to have failed before this speed is reached.&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
== Related content ==&lt;br /&gt;
&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Boeing_737-300&amp;diff=3558</id>
		<title>Boeing 737-300</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Boeing_737-300&amp;diff=3558"/>
		<updated>2007-06-16T22:00:36Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/Issues/Todo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox Aircraft&lt;br /&gt;
|image =[[Image:737-300.jpg|737-300]]&lt;br /&gt;
|caption =United Airline Boeing 737-300&lt;br /&gt;
|name =Boeing 737&lt;br /&gt;
|type =Airliner&lt;br /&gt;
|authors =David Culp, Innis Cunningham&lt;br /&gt;
|fdm =&lt;br /&gt;
|status =Early-production&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
{|&lt;br /&gt;
|__TOC__&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Development status/Issues/Todo ==&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* cockpit and passenger windows are not transparent&lt;br /&gt;
* aircraft textures do not abut very well (see on top of airplane)&lt;br /&gt;
* wings have no textures - aircraft has no shadow&lt;br /&gt;
* no aircraft lights available (landing light, strobe light etc.)&lt;br /&gt;
* aircraft has no wheel well area for the landing gears&lt;br /&gt;
* no jetstream visible&lt;br /&gt;
* nozzle do not change shape when changing thrust&lt;br /&gt;
* there are no flaps when using reverse thrust&lt;br /&gt;
&lt;br /&gt;
3d Cockpit:&lt;br /&gt;
&lt;br /&gt;
* no 3d cockpit available&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
General:&lt;br /&gt;
&lt;br /&gt;
* engine sound in cockpit does not differ from outside engine sound&lt;br /&gt;
* engines can't be turned off&lt;br /&gt;
* no hud available&lt;br /&gt;
&lt;br /&gt;
(!) landing gear hangs in the air, when the aircraft is on the ground&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
*[http://en.wikipedia.org/wiki/Boeing_737 Wikipedia Boeing 737 Article]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Airliners]]&lt;br /&gt;
[[Category:Civilian aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=North_American_OV-10A_Bronco&amp;diff=3557</id>
		<title>North American OV-10A Bronco</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=North_American_OV-10A_Bronco&amp;diff=3557"/>
		<updated>2007-06-16T21:58:47Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/ToDo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;The North American Rockwell OV-10 Bronco is a turboprop-driven light attack and cargo aircraft. Although it is a fixed-wing aircraft, its mission capabilities resemble a fast, long-range, inexpensive and reliable ultra-heavy attack helicopter. It flies at 244 knots (452 kilometers/hour), carries 3 tons of external munitions, and easily loiters for 3 or more hours. It is prized for its versatility, redundancy, load, wide field of view, short-field ability, low operational costs and ease of maintenance.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;The OV-10 has been used by the United States' Air Force, Marines and Navy, the military forces of several other nations, and the U.S. Customs Service, Bureau of Land Management, NASA and California Department of Forestry.  There is at least one airplane in private hands as well.  The OV-10 package for FlightGear contains three versions of the airplane:  A U.S. Air Forces Europe version, which models an OV-10A assigned to the 601st Tactical Control Wing at Sembach Airbase, Germany;  A California Department of Forestry version, used for fire fighting command and control; and a NASA version, used for atmospheric and aerodynamic research.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
{{infobox Aircraft&lt;br /&gt;
|image =[[Image:OV-10A2.jpg|320px]]&lt;br /&gt;
|caption =OV-10A USAFE&lt;br /&gt;
|name =North American OV-10A Bronco&lt;br /&gt;
|type =Military Aircraft&lt;br /&gt;
|authors =Capt. Slug, David Culp, Jens Thoms Toerring, Julien Pierru, Vivian Meazza&lt;br /&gt;
|fdm =JSBSim&lt;br /&gt;
|status =Production&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
{|&lt;br /&gt;
|__TOC__&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== User's Manual ==&lt;br /&gt;
&lt;br /&gt;
The FlightGear OV-10 features a user-selectable &amp;quot;easy mode&amp;quot;.  By default the airplane starts in &amp;quot;easy mode&amp;quot;. &lt;br /&gt;
&lt;br /&gt;
=== Starting procedure ===&lt;br /&gt;
[[Image:engine-panel.jpg|thumb|Engine Panel]]&lt;br /&gt;
To start the engines (not necessary in the easy mode) switch the current view to the engine panel view and:&lt;br /&gt;
&lt;br /&gt;
*switch on the Engine 1 start switch&lt;br /&gt;
*switch on the Engine 2 start switch&lt;br /&gt;
&lt;br /&gt;
Once they are started the switches fall back to the RUN position and you can hear the engines RPM go up. When the RPM stabilizes the engines are at idle and ready for take off.&lt;br /&gt;
&lt;br /&gt;
=== Armament procedure ===&lt;br /&gt;
To charge the guns (not required when in &amp;quot;easy mode&amp;quot;):&lt;br /&gt;
*Guns LH and RH switches .......... READY&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Trigger .......................... Squeeze&lt;br /&gt;
*Master Arm switch ................ OFF&lt;br /&gt;
&lt;br /&gt;
To fire the guns:&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Trigger .......................... Squeeze&lt;br /&gt;
&lt;br /&gt;
WARNING:  The Master Arm switch should be set to the OFF position bewteen firing passes.&lt;br /&gt;
&lt;br /&gt;
To Fire a rocket:&lt;br /&gt;
*Appropriate station switch ....... FIRE&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Weapons release button ........... Push&lt;br /&gt;
&lt;br /&gt;
CAUTION:  The rocket pod may be set for SINGLE or RIPPLE fire, and is not selectable from within the cockpit.&lt;br /&gt;
CAUTION:  If the station switch is mistakenly set to DROP, the entire rocket pod will be dropped.&lt;br /&gt;
&lt;br /&gt;
To drop a bomb:&lt;br /&gt;
*Appropriate station switch ....... DROP&lt;br /&gt;
*Fuse switch ...................... Select NOSE or TAIL&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Weapons release button ........... Push&lt;br /&gt;
&lt;br /&gt;
== Dimensions ==&lt;br /&gt;
[[Image:ov10a_3view.gif|thumb|OV-10A 3view|right]]&lt;br /&gt;
* Span: 40 feet (12.2 meters)&lt;br /&gt;
* Length: 41 feet, 7 inches (12.7 meters)&lt;br /&gt;
* Height: 15 feet, 1 inch (4.6 meters)&lt;br /&gt;
* Weight: Empty: 7,190 pounds (3,261 kilograms)&lt;br /&gt;
* Maximum take-off gross weight: 14,444 pounds (6,552 kilograms)&lt;br /&gt;
&lt;br /&gt;
Note that the sponsons (the small winglets attached to the fuselage) can be removed, as the CDF did with their OV-10's.  The fuselage rear cargo door could also be removed, as was necessary when dropping paratroopers.  The Air Force models did not carry the mid-wing weapons racks, and although the AIM-9 control box remained in the cockpit, the AIM-9 system was deactivated.&lt;br /&gt;
&lt;br /&gt;
== Performance ==&lt;br /&gt;
* MAXIMUM SPEED AT SEA LEVEL: 244 knots (452 kilometers/hour).  This published number may be for a very light airplane with sponsons removed.  In a more standard configuration, with a 230 gal. external fuel tank, the OV-10A would do about 180 knots indicated on a very hot day, and 220 knots on a very cold day.&lt;br /&gt;
* SERVICE CEILING: 28,800 feet (8,778 meters), but regulations limited the ceiling to 25,000 feet due to lack of cockpit pressurization.&lt;br /&gt;
* CREW: One pilot and optionally one observer (removable rear seat for greater fuselage cargo capacity).&lt;br /&gt;
* FUEL: Five self-sealing fuel tanks in wing: 252-gallon capacity (954 liters) 150-, 230-, or 300-gallon (568-, 871-, or 1,136-liter) external tank.&lt;br /&gt;
* RANGE: 700 nautical miles (1,297 kilometers) with internal fuel 1200 nautical miles (2224 kilometers) with 150-gallon (568-liter) drop tank.&lt;br /&gt;
* MISSION PERFORMANCE: 5.5 hours loiter time with 150-gallon (568-liter) drop tank50 nautical miles (93 kilometers) and 2 hours loiter time with full ordnance load.&lt;br /&gt;
* MAXIMUM DIVING SPEED:  350 knots.&lt;br /&gt;
&lt;br /&gt;
== Special Features ==&lt;br /&gt;
[[Image:OV10A-loaded.jpg|thumb|OV-10A USAFE]]&lt;br /&gt;
=== Fuel System ===&lt;br /&gt;
==== Internal Fuel System ====&lt;br /&gt;
* 5 wing stored tanks gravity fed to the engines (fuel cutoff after 15 consecutive seconds of negative G flight).&lt;br /&gt;
* default tanks if external is empty or not used.&lt;br /&gt;
&lt;br /&gt;
==== External Fuel System ====&lt;br /&gt;
* 1 230 gallons external tank fixed to external station 3, pump fed. If the pump is still activated and the tank is empty or has been dropped the pump will fail after 15 minutes, an orange light turns on on the upper right corner of the panel when pump output pressure is low .&lt;br /&gt;
[[Image:OV10A-CDF.jpg|thumb|OV-10A CDF]]&lt;br /&gt;
&lt;br /&gt;
=== Armament ===&lt;br /&gt;
(Read the armament procedure in the User's Manual section)&lt;br /&gt;
* 4 M60C 7.62mm machine guns, two in each sponson (shoot tracers, 500 rounds).&lt;br /&gt;
* 2 Mk82 500lbs bomb, with either nose or tail (delayed) fuse.&lt;br /&gt;
* 2 LAU68 2.75in rocket pods, with single or multiple fire sequence (7 rockets in each pod).&lt;br /&gt;
&lt;br /&gt;
Station Load:&lt;br /&gt;
* Station 1: LAU68 (single fire mode).&lt;br /&gt;
* Station 2: Mk82.&lt;br /&gt;
* Station 3: External Fuel tank.&lt;br /&gt;
* Station 4: Mk82.&lt;br /&gt;
* Station 5: LAU68 (ripple fire mode).&lt;br /&gt;
&lt;br /&gt;
The weight of each weapon is figured into the Flight Dynamics Model, however drag effects are not yet modeled.  The gunsight is fixed at present.  We hope to add adjustable sight depression in the future.  Note that the weapons, when released, are AI models, and as such do not know the terrain elevation.  This means it is not yet possible to mark the point of impact.  This ability may be added to FlightGear in the future.&lt;br /&gt;
&lt;br /&gt;
The trigger on your joystick is not set up to be a trigger if you are using the default FlightGear joystick bindings.  The OV-10 model will automatically re-bind your keyboard &amp;quot;space&amp;quot; key for use as a weapons release button.&lt;br /&gt;
&lt;br /&gt;
=== Radar Detector ===&lt;br /&gt;
* 1 AN/ALR 46 Radar detection system&lt;br /&gt;
&lt;br /&gt;
=== Misc. ===&lt;br /&gt;
* right engine smoke created by mixing oil into fuel thus making a white smoke (s to trigger, S to stop).&lt;br /&gt;
[[Image:OV10A-NASA-in-action.jpg|thumb|OV-10A NASA]]&lt;br /&gt;
* Parachutists:  in the Air Force version press the 'j' key to drop five parachutists from the rear of the airplane.&lt;br /&gt;
&lt;br /&gt;
* Ejection Seat:  in the Air Force version press the 'e' key to eject.&lt;br /&gt;
&lt;br /&gt;
=== Available Versions ===&lt;br /&gt;
* US Air Force Europe (USAFE), from the 601st Tactical Control Wing, based at Sembach Airbase, Germany from about 1976 to 1984, used as forward air control, light attack, observation and utility roles.&lt;br /&gt;
* California Department of Forestry (CDF), used for fire detection and combat.&lt;br /&gt;
* NASA, used for atmospheric research.&lt;br /&gt;
&lt;br /&gt;
== Development status/ToDo ==&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* full 3D model complete&lt;br /&gt;
* fully animated&lt;br /&gt;
* fully textured&lt;br /&gt;
* external models: 230gal fuel tank, Mk82 bomb, rockets, parachuters, ejection seat/parachute&lt;br /&gt;
&lt;br /&gt;
[[Image:OV10A-cockpit.jpg|thumb|OV-10A cockpit|right]]&lt;br /&gt;
&lt;br /&gt;
Cockpit:&lt;br /&gt;
&lt;br /&gt;
* All versions now have a 3D cockpit&lt;br /&gt;
* most instruments present&lt;br /&gt;
* realistic fuel system implemented&lt;br /&gt;
* working weapons and external stations release&lt;br /&gt;
&lt;br /&gt;
TODO:&lt;br /&gt;
&lt;br /&gt;
* finish 3D cockpit&lt;br /&gt;
* add ignition sequence&lt;br /&gt;
* add radar detection system (AN/ALR-46)&lt;br /&gt;
&lt;br /&gt;
(!) all the 3 versions in the new release have the same name in the aircraft selection list (US airforce 0V-10 etc.)&lt;br /&gt;
&lt;br /&gt;
(!) landing gear hangs in the air, when aircraft is on the ground&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
[http://flamebunny.homelinux.net/OV10A.php OV10A Bronco development project]&lt;br /&gt;
&lt;br /&gt;
[http://www.ov-10bronco.net/techspecs-ov10a.cfm OV10A Bronco technical specifications]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/OV-10 Wikipedia's article on OV-10 Bronco]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Military aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=North_American_OV-10A_Bronco&amp;diff=3556</id>
		<title>North American OV-10A Bronco</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=North_American_OV-10A_Bronco&amp;diff=3556"/>
		<updated>2007-06-16T21:57:58Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Development status/ToDo */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;The North American Rockwell OV-10 Bronco is a turboprop-driven light attack and cargo aircraft. Although it is a fixed-wing aircraft, its mission capabilities resemble a fast, long-range, inexpensive and reliable ultra-heavy attack helicopter. It flies at 244 knots (452 kilometers/hour), carries 3 tons of external munitions, and easily loiters for 3 or more hours. It is prized for its versatility, redundancy, load, wide field of view, short-field ability, low operational costs and ease of maintenance.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;The OV-10 has been used by the United States' Air Force, Marines and Navy, the military forces of several other nations, and the U.S. Customs Service, Bureau of Land Management, NASA and California Department of Forestry.  There is at least one airplane in private hands as well.  The OV-10 package for FlightGear contains three versions of the airplane:  A U.S. Air Forces Europe version, which models an OV-10A assigned to the 601st Tactical Control Wing at Sembach Airbase, Germany;  A California Department of Forestry version, used for fire fighting command and control; and a NASA version, used for atmospheric and aerodynamic research.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
{{infobox Aircraft&lt;br /&gt;
|image =[[Image:OV-10A2.jpg|320px]]&lt;br /&gt;
|caption =OV-10A USAFE&lt;br /&gt;
|name =North American OV-10A Bronco&lt;br /&gt;
|type =Military Aircraft&lt;br /&gt;
|authors =Capt. Slug, David Culp, Jens Thoms Toerring, Julien Pierru, Vivian Meazza&lt;br /&gt;
|fdm =JSBSim&lt;br /&gt;
|status =Production&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
{|&lt;br /&gt;
|__TOC__&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== User's Manual ==&lt;br /&gt;
&lt;br /&gt;
The FlightGear OV-10 features a user-selectable &amp;quot;easy mode&amp;quot;.  By default the airplane starts in &amp;quot;easy mode&amp;quot;. &lt;br /&gt;
&lt;br /&gt;
=== Starting procedure ===&lt;br /&gt;
[[Image:engine-panel.jpg|thumb|Engine Panel]]&lt;br /&gt;
To start the engines (not necessary in the easy mode) switch the current view to the engine panel view and:&lt;br /&gt;
&lt;br /&gt;
*switch on the Engine 1 start switch&lt;br /&gt;
*switch on the Engine 2 start switch&lt;br /&gt;
&lt;br /&gt;
Once they are started the switches fall back to the RUN position and you can hear the engines RPM go up. When the RPM stabilizes the engines are at idle and ready for take off.&lt;br /&gt;
&lt;br /&gt;
=== Armament procedure ===&lt;br /&gt;
To charge the guns (not required when in &amp;quot;easy mode&amp;quot;):&lt;br /&gt;
*Guns LH and RH switches .......... READY&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Trigger .......................... Squeeze&lt;br /&gt;
*Master Arm switch ................ OFF&lt;br /&gt;
&lt;br /&gt;
To fire the guns:&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Trigger .......................... Squeeze&lt;br /&gt;
&lt;br /&gt;
WARNING:  The Master Arm switch should be set to the OFF position bewteen firing passes.&lt;br /&gt;
&lt;br /&gt;
To Fire a rocket:&lt;br /&gt;
*Appropriate station switch ....... FIRE&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Weapons release button ........... Push&lt;br /&gt;
&lt;br /&gt;
CAUTION:  The rocket pod may be set for SINGLE or RIPPLE fire, and is not selectable from within the cockpit.&lt;br /&gt;
CAUTION:  If the station switch is mistakenly set to DROP, the entire rocket pod will be dropped.&lt;br /&gt;
&lt;br /&gt;
To drop a bomb:&lt;br /&gt;
*Appropriate station switch ....... DROP&lt;br /&gt;
*Fuse switch ...................... Select NOSE or TAIL&lt;br /&gt;
*Master Arm switch ................ ON&lt;br /&gt;
*Weapons release button ........... Push&lt;br /&gt;
&lt;br /&gt;
== Dimensions ==&lt;br /&gt;
[[Image:ov10a_3view.gif|thumb|OV-10A 3view|right]]&lt;br /&gt;
* Span: 40 feet (12.2 meters)&lt;br /&gt;
* Length: 41 feet, 7 inches (12.7 meters)&lt;br /&gt;
* Height: 15 feet, 1 inch (4.6 meters)&lt;br /&gt;
* Weight: Empty: 7,190 pounds (3,261 kilograms)&lt;br /&gt;
* Maximum take-off gross weight: 14,444 pounds (6,552 kilograms)&lt;br /&gt;
&lt;br /&gt;
Note that the sponsons (the small winglets attached to the fuselage) can be removed, as the CDF did with their OV-10's.  The fuselage rear cargo door could also be removed, as was necessary when dropping paratroopers.  The Air Force models did not carry the mid-wing weapons racks, and although the AIM-9 control box remained in the cockpit, the AIM-9 system was deactivated.&lt;br /&gt;
&lt;br /&gt;
== Performance ==&lt;br /&gt;
* MAXIMUM SPEED AT SEA LEVEL: 244 knots (452 kilometers/hour).  This published number may be for a very light airplane with sponsons removed.  In a more standard configuration, with a 230 gal. external fuel tank, the OV-10A would do about 180 knots indicated on a very hot day, and 220 knots on a very cold day.&lt;br /&gt;
* SERVICE CEILING: 28,800 feet (8,778 meters), but regulations limited the ceiling to 25,000 feet due to lack of cockpit pressurization.&lt;br /&gt;
* CREW: One pilot and optionally one observer (removable rear seat for greater fuselage cargo capacity).&lt;br /&gt;
* FUEL: Five self-sealing fuel tanks in wing: 252-gallon capacity (954 liters) 150-, 230-, or 300-gallon (568-, 871-, or 1,136-liter) external tank.&lt;br /&gt;
* RANGE: 700 nautical miles (1,297 kilometers) with internal fuel 1200 nautical miles (2224 kilometers) with 150-gallon (568-liter) drop tank.&lt;br /&gt;
* MISSION PERFORMANCE: 5.5 hours loiter time with 150-gallon (568-liter) drop tank50 nautical miles (93 kilometers) and 2 hours loiter time with full ordnance load.&lt;br /&gt;
* MAXIMUM DIVING SPEED:  350 knots.&lt;br /&gt;
&lt;br /&gt;
== Special Features ==&lt;br /&gt;
[[Image:OV10A-loaded.jpg|thumb|OV-10A USAFE]]&lt;br /&gt;
=== Fuel System ===&lt;br /&gt;
==== Internal Fuel System ====&lt;br /&gt;
* 5 wing stored tanks gravity fed to the engines (fuel cutoff after 15 consecutive seconds of negative G flight).&lt;br /&gt;
* default tanks if external is empty or not used.&lt;br /&gt;
&lt;br /&gt;
==== External Fuel System ====&lt;br /&gt;
* 1 230 gallons external tank fixed to external station 3, pump fed. If the pump is still activated and the tank is empty or has been dropped the pump will fail after 15 minutes, an orange light turns on on the upper right corner of the panel when pump output pressure is low .&lt;br /&gt;
[[Image:OV10A-CDF.jpg|thumb|OV-10A CDF]]&lt;br /&gt;
&lt;br /&gt;
=== Armament ===&lt;br /&gt;
(Read the armament procedure in the User's Manual section)&lt;br /&gt;
* 4 M60C 7.62mm machine guns, two in each sponson (shoot tracers, 500 rounds).&lt;br /&gt;
* 2 Mk82 500lbs bomb, with either nose or tail (delayed) fuse.&lt;br /&gt;
* 2 LAU68 2.75in rocket pods, with single or multiple fire sequence (7 rockets in each pod).&lt;br /&gt;
&lt;br /&gt;
Station Load:&lt;br /&gt;
* Station 1: LAU68 (single fire mode).&lt;br /&gt;
* Station 2: Mk82.&lt;br /&gt;
* Station 3: External Fuel tank.&lt;br /&gt;
* Station 4: Mk82.&lt;br /&gt;
* Station 5: LAU68 (ripple fire mode).&lt;br /&gt;
&lt;br /&gt;
The weight of each weapon is figured into the Flight Dynamics Model, however drag effects are not yet modeled.  The gunsight is fixed at present.  We hope to add adjustable sight depression in the future.  Note that the weapons, when released, are AI models, and as such do not know the terrain elevation.  This means it is not yet possible to mark the point of impact.  This ability may be added to FlightGear in the future.&lt;br /&gt;
&lt;br /&gt;
The trigger on your joystick is not set up to be a trigger if you are using the default FlightGear joystick bindings.  The OV-10 model will automatically re-bind your keyboard &amp;quot;space&amp;quot; key for use as a weapons release button.&lt;br /&gt;
&lt;br /&gt;
=== Radar Detector ===&lt;br /&gt;
* 1 AN/ALR 46 Radar detection system&lt;br /&gt;
&lt;br /&gt;
=== Misc. ===&lt;br /&gt;
* right engine smoke created by mixing oil into fuel thus making a white smoke (s to trigger, S to stop).&lt;br /&gt;
[[Image:OV10A-NASA-in-action.jpg|thumb|OV-10A NASA]]&lt;br /&gt;
* Parachutists:  in the Air Force version press the 'j' key to drop five parachutists from the rear of the airplane.&lt;br /&gt;
&lt;br /&gt;
* Ejection Seat:  in the Air Force version press the 'e' key to eject.&lt;br /&gt;
&lt;br /&gt;
=== Available Versions ===&lt;br /&gt;
* US Air Force Europe (USAFE), from the 601st Tactical Control Wing, based at Sembach Airbase, Germany from about 1976 to 1984, used as forward air control, light attack, observation and utility roles.&lt;br /&gt;
* California Department of Forestry (CDF), used for fire detection and combat.&lt;br /&gt;
* NASA, used for atmospheric research.&lt;br /&gt;
&lt;br /&gt;
== Development status/ToDo ==&lt;br /&gt;
Outside:&lt;br /&gt;
&lt;br /&gt;
* full 3D model complete&lt;br /&gt;
* fully animated&lt;br /&gt;
* fully textured&lt;br /&gt;
* external models: 230gal fuel tank, Mk82 bomb, rockets, parachuters, ejection seat/parachute&lt;br /&gt;
&lt;br /&gt;
[[Image:OV10A-cockpit.jpg|thumb|OV-10A cockpit|right]]&lt;br /&gt;
&lt;br /&gt;
Cockpit:&lt;br /&gt;
&lt;br /&gt;
* All versions now have a 3D cockpit&lt;br /&gt;
* most instruments present&lt;br /&gt;
* realistic fuel system implemented&lt;br /&gt;
* working weapons and external stations release&lt;br /&gt;
&lt;br /&gt;
TODO:&lt;br /&gt;
&lt;br /&gt;
* finish 3D cockpit&lt;br /&gt;
* add ignition sequence&lt;br /&gt;
* add radar detection system (AN/ALR-46)&lt;br /&gt;
&lt;br /&gt;
(!) all the 3 versions in the new release have the same name in the aircraft selection list (US airforce 0V-10 etc.)&lt;br /&gt;
(!) landing gear hangs in the air, when aircraft is on the ground&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
[http://flamebunny.homelinux.net/OV10A.php OV10A Bronco development project]&lt;br /&gt;
&lt;br /&gt;
[http://www.ov-10bronco.net/techspecs-ov10a.cfm OV10A Bronco technical specifications]&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/OV-10 Wikipedia's article on OV-10 Bronco]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
=== Related lists ===&lt;br /&gt;
* [[Aircraft]]&lt;br /&gt;
* [[Aircraft Todo]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Aircraft]]&lt;br /&gt;
[[Category:Military aircraft]]&lt;br /&gt;
[[Category:Aircraft TODO]]&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3555</id>
		<title>Talk:Antonov An-2</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3555"/>
		<updated>2007-06-16T21:50:02Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;I tryed the 0.2 version and would like to comment on some points:&lt;br /&gt;
&lt;br /&gt;
- I think the name of the airplane in the list should be not &amp;quot;Legendary Russian An-2&amp;quot;, but simply &amp;quot;Antonov An-2&amp;quot;, even though it is a legend actually (but Cessna c172 or P51D are also legendary)&lt;br /&gt;
&lt;br /&gt;
- 44mb unpacked seems too much, I think; maybe texture resolutions and sound quality could be degraded by half (other FG models don't exceed 10mb even with several versions and look and sound fine, check the OV-10A Bronco, for example)&lt;br /&gt;
&lt;br /&gt;
- may be this link [http://www.flightgear.ru/files/models/an2-0.2.tar.gz] should be placed here, in the wiki (for now it is available only at the Russian version of the FG site)&lt;br /&gt;
&lt;br /&gt;
- the pilot's eyes are situated too high and too close to the instrument panel, 3D-cockpit instruments are barely readable from this point of view&lt;br /&gt;
&lt;br /&gt;
- low rpm engine sound is good, but when the speed rises the sound becomes strange&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Corrected introductory text from the bundled manual:&lt;br /&gt;
&lt;br /&gt;
'''Introduction'''&lt;br /&gt;
&lt;br /&gt;
This is the model of the legendary Russian An-2. Its first flight took place in 1947 and some aircraft are in service even today.&lt;br /&gt;
&lt;br /&gt;
The model was originally prepared for Microsoft Flight Simulator by Anton Nikolaev in 2005. It became a real hit ''(only commerical products can be bestsellers)'' in the Russian flightsim community.&lt;br /&gt;
&lt;br /&gt;
The FlightGear An-2 model was converted from the MSFS version through a specific procedure. FlightGear An-2 model is published under GPL with the author's permission ''(Anton Nikolaev?)''.&lt;br /&gt;
&lt;br /&gt;
Textures and sounds were taken without any conversion. 2D panel, 3D cockpit, original instruments, FDM, systems and some other things were converted to FlightGear by Yurik V. Nikiforoff in may 2006 - april 2007.&lt;br /&gt;
&lt;br /&gt;
8 liveries (paintjobs) included.&lt;br /&gt;
&lt;br /&gt;
This is version 0.2 of the model. It has a 3D cockpit and incorporates many improvements to systems, animation etc.&lt;br /&gt;
&lt;br /&gt;
You can see a photo of a real AN-2 here.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3554</id>
		<title>Talk:North American OV-10A Bronco</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3554"/>
		<updated>2007-06-16T21:43:55Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Category_talk:Aircraft&amp;diff=3552</id>
		<title>Category talk:Aircraft</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Category_talk:Aircraft&amp;diff=3552"/>
		<updated>2007-06-15T12:27:06Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Please, can someone add DHC-2 Beaver description to this section.&lt;br /&gt;
DHC-2 model in FlightGear is very qualitative in all aspects and it is fun to fly. The only thing it misses is an operating manual here.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3551</id>
		<title>Talk:North American OV-10A Bronco</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3551"/>
		<updated>2007-06-15T07:29:54Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Dear authors of the OV-10A Bronco model, please, take the following things into account:&lt;br /&gt;
&lt;br /&gt;
- USAFE and NASA '''share the same paintjob''' and loadout (as I understand, there will be a new NASA version, when FlightGear 0.9.11 is released)&lt;br /&gt;
&lt;br /&gt;
- USAFE version is available as a '''separate download''', while it is included in the 3-version package at the same time, the separate download could be deleted, so that only the 3-version package is left&lt;br /&gt;
&lt;br /&gt;
- '''Landing gear''' is a bit higher, than the ground surface, it visually hangs in the air, when the airplane is standing on the ground (it is noticable when shadow is on), though the gap between the landing gear and the ground surface is very small&lt;br /&gt;
&lt;br /&gt;
- '''CDF version''' has no instruments and controls in its 3D-cockpit, the cockpit is a flat foto-texture (as I understand, CDF version will receive a 3D-cockpit, when FlightGear 0.9.11 is released)&lt;br /&gt;
&lt;br /&gt;
- '''Engines start-up/turn-off''' is not possible (only fuel flow can be cut), as I understand it will also change, when FlightGear 0.9.11 is released&lt;br /&gt;
&lt;br /&gt;
- '''Outside lights''' are present, but they can't be switched on/off and they actually don't light&lt;br /&gt;
&lt;br /&gt;
- '''OBS / HDG knobs''' are not functional in the 3D-cockpit (can be set only through the radio dialog)&lt;br /&gt;
&lt;br /&gt;
- '''pressure''' value is not shown in the altimeter in the 3D-cockpit (can be set only through the instrument settings dialog)&lt;br /&gt;
&lt;br /&gt;
The above mentioned things correspond to '''v20060619''' of your model, that is available for download from the FlightGear official site.&lt;br /&gt;
&lt;br /&gt;
Apart from the small issues mentioned above, the model is great! It feels and looks complete in almost all aspects: good flight model, animated body (flaps, gear, ailerons, elevators, rudders), neat 3D-cockpit, nice sounds, working systems, lights etc. Many thanks for it. I liked the opportunity to really use the removable fuel tank. I fly OV-10A very often.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3549</id>
		<title>Bugs</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3549"/>
		<updated>2007-06-13T22:19:35Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Airport lighting in poor weather. */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Known Bugs ==&lt;br /&gt;
&lt;br /&gt;
This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.&lt;br /&gt;
&lt;br /&gt;
==== Incorrect altimetry. ====&lt;br /&gt;
&lt;br /&gt;
There is evidently at least one serious misconception in the&lt;br /&gt;
code that calculates atmospheric pressure, altimeter settings, &lt;br /&gt;
et cetera.  This can be easily demonstrated:&lt;br /&gt;
&lt;br /&gt;
Park at or near the threshold of runway 33 at Aspen (KASE).&lt;br /&gt;
Under standard conditions, observe that the altimeter reads&lt;br /&gt;
7820 feet MSL, as it should.&lt;br /&gt;
&lt;br /&gt;
Use the Weather : Weather Conditions dialog popup to&lt;br /&gt;
look at the ground-level altimeter setting (QNH).&lt;br /&gt;
This is bottom row in the &amp;quot;Alt (inHg)&amp;quot; column of the popup.&lt;br /&gt;
Verify that it is 29.92.&lt;br /&gt;
&lt;br /&gt;
Now use the dialog box to change this property.  Change it&lt;br /&gt;
to 30.92, a one-inch difference.&lt;br /&gt;
&lt;br /&gt;
Go to your altimeter instrument and enter the new altimeter&lt;br /&gt;
setting in the Kollsman window.  Ideally, this '''should'''&lt;br /&gt;
cause the instrument to read the correct altitude once&lt;br /&gt;
again, namely 7820 feet MSL.&lt;br /&gt;
&lt;br /&gt;
However, due to bugs, it is likely that you will observe&lt;br /&gt;
something closer to 8120.  This means the airplane is 300 &lt;br /&gt;
feet lower than the altimeter says it is.&lt;br /&gt;
&lt;br /&gt;
In case it wasn't obvious, when flying around near Aspen,&lt;br /&gt;
being 300 feet lower than you think you are can be very&lt;br /&gt;
bad for your health.&lt;br /&gt;
&lt;br /&gt;
The absolutely correct formulas for computing the altimeter &lt;br /&gt;
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
A patch to fix the altimeter has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Altimetry misnomers and misconceptions. ====&lt;br /&gt;
&lt;br /&gt;
Both the Weather Conditions popup and the atis.cxx code&lt;br /&gt;
rely on the &amp;quot;pressure-sea-level-inhg&amp;quot; property and use&lt;br /&gt;
it in ways that the altimeter setting should be used.&lt;br /&gt;
&lt;br /&gt;
For some people this may be merely a misnomer, but for&lt;br /&gt;
others it is clearly a misconception, as recent events&lt;br /&gt;
have shown.&lt;br /&gt;
&lt;br /&gt;
The fact is, the altimeter setting is '''not''' the same &lt;br /&gt;
thing as the pressure at sea level (Psl), especially when &lt;br /&gt;
the airmass has a non-standard temperature profile.&lt;br /&gt;
The altimeter setting is something&lt;br /&gt;
else;  it is properly called the altimeter setting.  It&lt;br /&gt;
is also properly called the QNH, although private pilots&lt;br /&gt;
who fly only in the US may be unfamiliar with the QNH&lt;br /&gt;
terminology.&lt;br /&gt;
&lt;br /&gt;
In the Remarks section of a METAR, you can sometimes&lt;br /&gt;
find the ''Reduced'' Sea Level Pressure, which is&lt;br /&gt;
unfortunately denoted SLP.  This METAR SLP serves&lt;br /&gt;
the same function as the altimeter setting.  Despite&lt;br /&gt;
its name, the METAR SLP is not equal to the honest-to-goodness&lt;br /&gt;
pressure at honest-to-goodness sea level (Psl), as&lt;br /&gt;
discussed in more detail on&lt;br /&gt;
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
There needs to be a facility whereby routines that need&lt;br /&gt;
the altimeter setting can obtain the altimeter setting.&lt;br /&gt;
&lt;br /&gt;
Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
Existing code sometimes treads the &amp;quot;pressure-sea-level-inhg&amp;quot; &lt;br /&gt;
property as if it were Psl, and sometimes as if it were &lt;br /&gt;
METAR SLP.  All this needs to be vetted.&lt;br /&gt;
&lt;br /&gt;
==== Newton's laws violated by environment.cxx ====&lt;br /&gt;
&lt;br /&gt;
Consider the following results of an experiment using fgfs:&lt;br /&gt;
&lt;br /&gt;
  alt:  662  mM: 0.0288  P: 99000.8462  T: 286.8563  rho: 1.1975&lt;br /&gt;
  alt: 3462  mM: 0.0288  P: 89341.6721  T: 281.3920  rho: 1.1009&lt;br /&gt;
  &lt;br /&gt;
  alt:  662  mM: 0.0289  P: 99000.8422  T: 256.9910  rho: 1.3404&lt;br /&gt;
  alt: 3462  mM: 0.0289  P: 89341.6740  T: 252.0956  rho: 1.2333&lt;br /&gt;
&lt;br /&gt;
The first pair of lines represent before and after a simple&lt;br /&gt;
flight from one airport to another, with a net gain in altitude of&lt;br /&gt;
2800 feet, under standard conditions.  So far so good.&lt;br /&gt;
&lt;br /&gt;
The second pair of lines represent exactly the same flight, &lt;br /&gt;
except that the ambient temperature was 30 degrees colder&lt;br /&gt;
than before.  You can see that the density (rho) is greater,&lt;br /&gt;
in accordance with the ideal gas law.&lt;br /&gt;
&lt;br /&gt;
The problem is that the delta_P is exactly the same for the two&lt;br /&gt;
flights.  This is a problem because P is connected to the weight&lt;br /&gt;
of the air column.  If the air is 12% denser, the laws of physics &lt;br /&gt;
require it to have a 12% steeper pressure gradient dP/dh ... but &lt;br /&gt;
alas this is not observed.&lt;br /&gt;
&lt;br /&gt;
This incorrect pressure profile P(h) has many consequences affecting&lt;br /&gt;
engine performance, airfoil performance, altimetry, et cetera.&lt;br /&gt;
&lt;br /&gt;
==== Z-buffer burn-through. ====&lt;br /&gt;
&lt;br /&gt;
Sometimes distant objects can be seen through nearer objects that&lt;br /&gt;
are not supposed to be transparent.  For example:  Runway lights &lt;br /&gt;
sometimes burn through a solid cloud layer.  Also runway lights&lt;br /&gt;
sometimes burn through aircraft structure.  Some instruments&lt;br /&gt;
burn through the yoke.&lt;br /&gt;
&lt;br /&gt;
It seems that so-called &amp;quot;2D&amp;quot; objects in the&lt;br /&gt;
background are likely to burn through &amp;quot;3D&amp;quot; objects in the&lt;br /&gt;
foreground.  This is particularly noticeable in aircraft&lt;br /&gt;
that have a mixture of 2D and 3D instruments.&lt;br /&gt;
&lt;br /&gt;
The ''position'' in space of the offending objects is OK, as&lt;br /&gt;
you can verify by shifting your PoV to get a little bit of&lt;br /&gt;
a side view.  The obvious hypothesis is that the Z-order&lt;br /&gt;
is being mishandled in a Z-buffer somewhere.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak. ====&lt;br /&gt;
&lt;br /&gt;
The simulator will gobble up about 3 gigabytes&lt;br /&gt;
of virtual memory overnight, while paused.  &lt;br /&gt;
Without the&lt;br /&gt;
leak, the memory footprint would be less than 300 meg.  The&lt;br /&gt;
difference between 300 meg and 3 gig is quite &lt;br /&gt;
significant on machines that have only 1 or 2 gig&lt;br /&gt;
of main memory.&lt;br /&gt;
&lt;br /&gt;
A rather steady leak of 2 meg per minute is observed&lt;br /&gt;
during pause, no matter whether the aircraft is aloft&lt;br /&gt;
or parked on the ground.  '''Vastly less leakage''' (two&lt;br /&gt;
orders of magnitude less, possibly zero) is observed&lt;br /&gt;
when the simulator is not paused, and the aircraft&lt;br /&gt;
is simply sitting on the ground with the parking&lt;br /&gt;
brake set.&lt;br /&gt;
&lt;br /&gt;
This bug has been observed in multiple versions of fgfs,&lt;br /&gt;
including one compiled back in May, 2006 as well as&lt;br /&gt;
the most current CVS version.&lt;br /&gt;
&lt;br /&gt;
This is 100% reproducible with a &lt;br /&gt;
ATI RV350 [Mobility Radeon 9600 M10] chipset&lt;br /&gt;
and the ati-fglrx driver.&lt;br /&gt;
The leak is observed whether or not &lt;br /&gt;
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.&lt;br /&gt;
&lt;br /&gt;
==== Numerous bugs in ATIS feature. ====&lt;br /&gt;
&lt;br /&gt;
1) The ATIS is supposed to change whenever there is a&lt;br /&gt;
significant change in the weather.  The comments mention&lt;br /&gt;
this, but the code makes no attempt to implement this.&lt;br /&gt;
&lt;br /&gt;
2) The code assumes that ATIS is prepared on the hour.&lt;br /&gt;
In practice this is virtually never the case;  a new&lt;br /&gt;
ATIS is prepared hourly, but not on the hour.  Also&lt;br /&gt;
this assumption is inconsistent with ATIS changes&lt;br /&gt;
based on the weather.&lt;br /&gt;
&lt;br /&gt;
3) The code attempts to issue a station identifier, but&lt;br /&gt;
none is heard.&lt;br /&gt;
&lt;br /&gt;
4) Multiple departures from standard phraseology.&lt;br /&gt;
&lt;br /&gt;
5) The volume is too low;  ATIS is not readable over engine noise.&lt;br /&gt;
This defeats much of the purpose of ATIS.  The volume does&lt;br /&gt;
not respond to the /instrumentation/comm[N]/volume property.&lt;br /&gt;
&lt;br /&gt;
6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.&lt;br /&gt;
&lt;br /&gt;
x) Et cetera.&lt;br /&gt;
&lt;br /&gt;
A patch to fix a few dozen ATIS bugs is available, but has not been&lt;br /&gt;
incorporated into FG CVS.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --altitude option. ====&lt;br /&gt;
&lt;br /&gt;
When the aircraft is initialzed aloft using the &lt;br /&gt;
command-line --altitude=6000&lt;br /&gt;
option, 0.9.10 is observed to put up a blank screen &lt;br /&gt;
(no scenery, no panel) and to spew on the console &lt;br /&gt;
page after page like this:&lt;br /&gt;
&lt;br /&gt;
  Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..&lt;br /&gt;
  altitude         = -1.69132e-41&lt;br /&gt;
  sea level radius = -6.54575e-42&lt;br /&gt;
  latitude         = 6.9874e-316&lt;br /&gt;
  longitude        = 6.79737e-313&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_pitch&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_volume&lt;br /&gt;
&lt;br /&gt;
==== Multiple bugs in the location-in-air popup. ====&lt;br /&gt;
&lt;br /&gt;
The location-in-air popup turns off the magnetos and extends&lt;br /&gt;
the landing gear.  Some pilots and flight instructors &lt;br /&gt;
deem this to be undesirable behavior, especially if all&lt;br /&gt;
they are trying to do is relocate from one airborne position to&lt;br /&gt;
another.&lt;br /&gt;
&lt;br /&gt;
Similarly, it strongly perturbs the throttle setting, &lt;br /&gt;
aileron trim, elevator trim, rudder trim, &lt;br /&gt;
view angles, PoV position, and who-knows-what else.  &lt;br /&gt;
Again, people who know about airplanes consider this to&lt;br /&gt;
be undesirable behavior.&lt;br /&gt;
&lt;br /&gt;
There is also a tendency to place the aircraft into &lt;br /&gt;
dangerous unusual attitudes, and other bugs too numerous &lt;br /&gt;
to mention.&lt;br /&gt;
&lt;br /&gt;
Evidently, though, there is at least one person who likes&lt;br /&gt;
things the way they are.  Code that would have fixed these&lt;br /&gt;
bugs was rejected.  Neither specific nor constructive criticism&lt;br /&gt;
of the code was offered.  For details see the flightgear-devel&lt;br /&gt;
mailing list archives.&lt;br /&gt;
&lt;br /&gt;
==== Nearest fix. ====&lt;br /&gt;
&lt;br /&gt;
Did you know that there are 8 different BRAVO intersections&lt;br /&gt;
in the database?&lt;br /&gt;
&lt;br /&gt;
Until now there was no support in the code for this;  all but&lt;br /&gt;
one of the entries was thrown away at the lowest level. There&lt;br /&gt;
is a comment in the code saying that fixing this is on the&lt;br /&gt;
TODO list.&lt;br /&gt;
&lt;br /&gt;
As for navaids (as opposed to waypoints), the low-level code&lt;br /&gt;
already provides support for ambiguous IDs, but the information&lt;br /&gt;
is not being used very wisely by the higher layers.&lt;br /&gt;
&lt;br /&gt;
Code to fix these problems was offered to the community.&lt;br /&gt;
So far it has been completely ignored.&lt;br /&gt;
&lt;br /&gt;
==== HSI instrument failure. ====&lt;br /&gt;
&lt;br /&gt;
If you use the &amp;quot;heading indicator&amp;quot; checkbox on the&lt;br /&gt;
&amp;quot;instrument failure&amp;quot; popup to command a failure,&lt;br /&gt;
it has no effect on the HSI instrument used by&lt;br /&gt;
many aircraft in the simulator fleet.&lt;br /&gt;
&lt;br /&gt;
This is because of wrong code in hsi.xml.  &lt;br /&gt;
&lt;br /&gt;
Backend code to handle this correctly exists, but has&lt;br /&gt;
apparently never been used.  It needs one small fix,&lt;br /&gt;
followed by recompilation.  A patchset to take care&lt;br /&gt;
of all this was offered to the community, but has&lt;br /&gt;
not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Flux gate not really a flux gate. ====&lt;br /&gt;
&lt;br /&gt;
In the Instrumentation director, there are three heading-related&lt;br /&gt;
.cxx files.&lt;br /&gt;
* heading_indicator.cxx : vacuum driven, with drift&lt;br /&gt;
* heading_indicator_dg.cxx : electrically driven, with drift&lt;br /&gt;
* heading_indicator_fg.cxx : electrically driven, no drift&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;fg&amp;quot; in &amp;quot;heading_indicator_fg&amp;quot; is documented to stand for&lt;br /&gt;
&amp;quot;flux gate&amp;quot;, as if the heading were slaved to a flux-gate&lt;br /&gt;
compass ... but the code does not implement any such thing.&lt;br /&gt;
All it really does is initialize the indicated heading to &lt;br /&gt;
the correct magnetic heading value, and then implement a &lt;br /&gt;
no-drift policy.  This is incorrect behavior, as can be&lt;br /&gt;
seen by flying to an area where the magnetic variation is&lt;br /&gt;
different from what it was at the start of the flight.  A&lt;br /&gt;
true slaved heading indicator would gradually accommodate&lt;br /&gt;
the new magvar.&lt;br /&gt;
&lt;br /&gt;
The correct behavior ought to be easy to implement.&lt;br /&gt;
&lt;br /&gt;
==== Weird noises during initialization. ====&lt;br /&gt;
&lt;br /&gt;
It is observed that sometimes while the simulator is starting&lt;br /&gt;
up, before things are fully operational, weird noises are&lt;br /&gt;
produced.  For example, in the c182rg, gear-in-transit&lt;br /&gt;
noises are produced for several seconds before the first&lt;br /&gt;
display becomes visible.  (According to a dump of the&lt;br /&gt;
relevant variables, there is no evidence that the gear is&lt;br /&gt;
actually in transit, and no reason why it should be.)&lt;br /&gt;
&lt;br /&gt;
Code to fix this was submitted.  So far it has been&lt;br /&gt;
ignored.&lt;br /&gt;
&lt;br /&gt;
==== Weird displays during fullscreen initialization. ====&lt;br /&gt;
&lt;br /&gt;
If the --enable-fullscreen command-line option is used, &lt;br /&gt;
the window is enlarged to full-screen size at a time&lt;br /&gt;
when initialization is only half-complete.  From this&lt;br /&gt;
time until the end of initialization, the display &lt;br /&gt;
contains weird combinations of leftover graphic objects&lt;br /&gt;
and other junk.&lt;br /&gt;
&lt;br /&gt;
This is observed no matter whether the splash-screen feature&lt;br /&gt;
is enabled or disabled.&lt;br /&gt;
&lt;br /&gt;
==== Fullscreen window sometimes misplaced. ====&lt;br /&gt;
&lt;br /&gt;
About 20% of the time, when the --enable-fullscreen command-line&lt;br /&gt;
option is used, it opens a window of the correct size, but &lt;br /&gt;
badly misplaced relative to the screen, such that only one half&lt;br /&gt;
or one quarter of the window is on-screen.&lt;br /&gt;
&lt;br /&gt;
==== Navigation databases out-of-date ====&lt;br /&gt;
&lt;br /&gt;
The database of navigation waypoints and fixes has an internal&lt;br /&gt;
date of early 2005.  It is missing quite a few useful fixes.  &lt;br /&gt;
The FAA has defined quite a few new approaches in recent years,&lt;br /&gt;
and has revised others.&lt;br /&gt;
&lt;br /&gt;
An updated version, based on a pull of the much more&lt;br /&gt;
current x-plane database, was made available.  So far&lt;br /&gt;
it has been ignored.&lt;br /&gt;
&lt;br /&gt;
Similar remarks apply to the ''navaids'' database.&lt;br /&gt;
&lt;br /&gt;
==== Ident from phantom DME. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, some VOR stations and even some localizers&lt;br /&gt;
have a colocated DME station ... but there are plenty that&lt;br /&gt;
don't.&lt;br /&gt;
&lt;br /&gt;
The DME has its own Morse ident, with a distinctive higher pitch.&lt;br /&gt;
&lt;br /&gt;
In the simulator, due to a bug in the code, all stations&lt;br /&gt;
transmit the DME Morse ident ... even stations where no&lt;br /&gt;
DME is present.&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx finds the nearest VOR or LOC on the&lt;br /&gt;
frequency, and checks to see if it is in range.  It also asks&lt;br /&gt;
for the &amp;quot;nearest&amp;quot; DME on the frequency, but makes no attempt&lt;br /&gt;
to check that it is in range.  To say the same thing the&lt;br /&gt;
other way, there is no attempt to check that the aircraft is&lt;br /&gt;
within the service volume of the DME.  Since there is almost always&lt;br /&gt;
a DME /somewhere/ on the frequency, the has_dme variable will&lt;br /&gt;
always be set true.&lt;br /&gt;
&lt;br /&gt;
For a demonstration of this bug, park at KAOO airport and &lt;br /&gt;
tune up the AOO VOR (which has no DME).  Or park at almost&lt;br /&gt;
any airport and tune up the localizer (since relatively few&lt;br /&gt;
localizers have DME).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Airport lighting in poor weather. ====&lt;br /&gt;
&lt;br /&gt;
The code in tileentry.cxx turns on airport lights according to&lt;br /&gt;
the position of the sun relative to the horizon.  One consequence&lt;br /&gt;
is that the lights are off during the day.&lt;br /&gt;
&lt;br /&gt;
In real life, there are many circumstances where airport lights,&lt;br /&gt;
including approach lights, are turned on during the day.  At tower airports, the lights are turned on during bad weather -- including weather that &lt;br /&gt;
is only slightly bad -- and also turned on if requested by the pilot.  For&lt;br /&gt;
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].&lt;br /&gt;
&lt;br /&gt;
At non-towered airports, the lights are usually pilot-controlled,&lt;br /&gt;
via radio.&lt;br /&gt;
&lt;br /&gt;
The absence of lighting during daytime in poor weather detracts &lt;br /&gt;
significantly from the realism, because it affects both the&lt;br /&gt;
legality and the practicality of performing instrument approaches&lt;br /&gt;
under such conditions.&lt;br /&gt;
&lt;br /&gt;
_ In version 0.9.10 runway lights are turned on automatically in day time if visibility is low. Though I agree, that pilot controlled lights could be a nice feature, but it's not a bug, it's more like a wish list entry, I suppose.&lt;br /&gt;
&lt;br /&gt;
==== Holes in the ground. ====&lt;br /&gt;
&lt;br /&gt;
Ever since the first win32-build of FG-OSG, there are at least two huge &lt;br /&gt;
ground scenery holes in the the Rhine/Main/Neckar-region in Germany. &lt;br /&gt;
The first one gapes at &lt;br /&gt;
the place which was formerly known as the city of Mannheim (near the &lt;br /&gt;
airport EDFM, which is still there), the second one has swallowed up a &lt;br /&gt;
big piece of Frankfurt am Main (near EDDF) and surrounding land. &lt;br /&gt;
&lt;br /&gt;
First posted to the flightgear-devel list in November, 2006.&lt;br /&gt;
&lt;br /&gt;
==== Mixture versus Altitude. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that at&lt;br /&gt;
high altitude airports (e.g. KGCN or KASE), to obtain max&lt;br /&gt;
static RPM, it suffices to move the mixture control only a&lt;br /&gt;
few mm aft of the full-forward (full-rich) position.&lt;br /&gt;
&lt;br /&gt;
This is unrealistic.  In a real aircraft under such conditions,&lt;br /&gt;
it would be necessary to pull the mixture control back about&lt;br /&gt;
an inch to obtain max RPM.&lt;br /&gt;
&lt;br /&gt;
It's hard to say whether the carburetor is underreacting to the&lt;br /&gt;
altitude, or overreacting to the mixture control.&lt;br /&gt;
&lt;br /&gt;
==== EGT reads high. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that the&lt;br /&gt;
EGT reads toward the high end of the scale under all conditions,&lt;br /&gt;
including idle.  This is unrealistic.&lt;br /&gt;
&lt;br /&gt;
Also, the EGT reads ''off-scale'' high under high-power conditions.&lt;br /&gt;
&lt;br /&gt;
==== Flags missing from instruments. ====&lt;br /&gt;
&lt;br /&gt;
Some of the standard instruments lack status flags.  For example,&lt;br /&gt;
the GS needle goes to  mid-scale if there is no valid signal.  That'll kill you for sure.  Reportedly the hi-res instruments implement flags, but the lo-res ones don't.  Many aircraft are using the lo-res instruments.&lt;br /&gt;
&lt;br /&gt;
Either the aircraft should be upgraded to use instruments that&lt;br /&gt;
display flags, or the instruments should be upgraded to be&lt;br /&gt;
display flags.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --model-hz option. ====&lt;br /&gt;
&lt;br /&gt;
Specifying the --model-hz=10 command-line option results in the&lt;br /&gt;
following mess:&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml&lt;br /&gt;
  Sorry, wdot doesn't appear to be trimmable&lt;br /&gt;
 Trim Failed&lt;br /&gt;
  Trim Results: &lt;br /&gt;
       Angle of Attack:   7.50  wdot:  3.21e+01 Tolerance: 1e-03  Failed&lt;br /&gt;
              Throttle:   0.50  udot:  0.00e+00 Tolerance: 1e-03  Passed&lt;br /&gt;
            Pitch Trim:   0.00  qdot: -5.44e-11 Tolerance: 1e-04  Passed&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 WWarning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
     [many repeats]&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 altitude         = 9&lt;br /&gt;
 sea level radius = 4.62829e-268&lt;br /&gt;
 latitude         = 1.52075e-314&lt;br /&gt;
 longitude        = -0.0967923&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = nan&lt;br /&gt;
 sea level radius = nan&lt;br /&gt;
 latitude         = nan&lt;br /&gt;
 longitude        = nan&lt;br /&gt;
&lt;br /&gt;
and so forth.&lt;br /&gt;
&lt;br /&gt;
* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.&lt;br /&gt;
&lt;br /&gt;
==== CPU hogging. ====&lt;br /&gt;
&lt;br /&gt;
The fsgs program will happily eat up &amp;gt;98% of the cpu cycles,&lt;br /&gt;
even when the simulator is paused.  That seems excessive,&lt;br /&gt;
particularly during pause.  This is on a 2GHz machine&lt;br /&gt;
with hardware acceleration.  As a point of reference, &lt;br /&gt;
glxgears uses only a fraction of one percent of the cpu.&lt;br /&gt;
&lt;br /&gt;
* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result  if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)&lt;br /&gt;
&lt;br /&gt;
==== Out-of-bounds array reference in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the interpolation table code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the &amp;quot;message&amp;quot; handling code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Glideslope service volume. ====&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx appears to assume the glideslope&lt;br /&gt;
service volume is the same as the localizer service&lt;br /&gt;
volume.  This is quite unrealistic.&lt;br /&gt;
&lt;br /&gt;
==== Extended service volume. ====&lt;br /&gt;
&lt;br /&gt;
In some parts of the world, a goodly fraction of the&lt;br /&gt;
localizers have an expanded service volume (ESV),&lt;br /&gt;
often quite a bit larger than the standard service&lt;br /&gt;
volume you see in the AIM.  The code in navradio.cxx&lt;br /&gt;
was ignoring the service volume information in the&lt;br /&gt;
database and wrongly assuming the default values&lt;br /&gt;
applied everywhere.  Code to fix the range-related&lt;br /&gt;
part of the problem has been offered&lt;br /&gt;
but not yet incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Other service volume issues. ====&lt;br /&gt;
&lt;br /&gt;
The code  in navradio.cxx has no understanding of how &lt;br /&gt;
'''azimuth''' affects the&lt;br /&gt;
localizer.  There is more to the story than reception range.&lt;br /&gt;
It is perfectly possible to be outside the LOC service volume &lt;br /&gt;
for reasons having to do with azimuth, not range.  &lt;br /&gt;
&lt;br /&gt;
Good ident will be heard, but false localizer courses will &lt;br /&gt;
cause serious trouble for the unwary pilot.&lt;br /&gt;
&lt;br /&gt;
A patch to fix this (along with the ESV issue) has been &lt;br /&gt;
offered, but ignored.&lt;br /&gt;
&lt;br /&gt;
There are also azimuthal issues with the /glideslope/&lt;br /&gt;
service volume.  This has not yet been patched.&lt;br /&gt;
&lt;br /&gt;
==== Menu buttons having a get-together. ====&lt;br /&gt;
&lt;br /&gt;
This concerns &amp;quot;radio buttons&amp;quot; on menus, such as on the &lt;br /&gt;
location-in-air popup and elsewhere.  By definition, it should be &lt;br /&gt;
impossible to have more than one radio button pushed down at a time.&lt;br /&gt;
However, illegal situations of this sort can be created&lt;br /&gt;
using a click-and-drag gesture.  Aim at&lt;br /&gt;
a radio button, hold the mouse-button down, and drag ...&lt;br /&gt;
as if you wanted to drag the radio button to a new location.&lt;br /&gt;
This allows you to set a radio button without the others&lt;br /&gt;
being unset.  If you persist, you can have every one of&lt;br /&gt;
the buttons in the pushed-down state at the same time.&lt;br /&gt;
&lt;br /&gt;
Before you say, &amp;quot;well, don't do that then&amp;quot; or &amp;quot;garbage in,&lt;br /&gt;
garbage out&amp;quot;, let me point out that it is possible for&lt;br /&gt;
a pilot to inadvertently make a tiny dragging gesture&lt;br /&gt;
when intending only a click.  Also, when the desired&lt;br /&gt;
button is in the pushed-down state, it is easy to not&lt;br /&gt;
notice that other buttons are in the undesired state.&lt;br /&gt;
&lt;br /&gt;
==== Altimeter setting unreadable. ====&lt;br /&gt;
&lt;br /&gt;
The standard altimeter (used by the default c172p aircraft&lt;br /&gt;
and many others) had been using an unhappy hodgepodge of&lt;br /&gt;
layers.  The analog Kollsman window was unusable, because&lt;br /&gt;
it was unlabeled, and the digital altimeter setting was&lt;br /&gt;
unusable, especially at altitudes near 2500 feet, partly &lt;br /&gt;
from being behind the needle.  On a real altimeter, things&lt;br /&gt;
are positioned so that cannot happen.&lt;br /&gt;
&lt;br /&gt;
Fixing this requires using a more suitable font, moving&lt;br /&gt;
the digits over, and getting rid of conflicting extraneous&lt;br /&gt;
markings.&lt;br /&gt;
&lt;br /&gt;
A patch to implement this fix has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Memory mismanagement in subsystem_mgr. ====&lt;br /&gt;
&lt;br /&gt;
It is bad luck to apply &amp;quot;delete&amp;quot; to an object that was not&lt;br /&gt;
created with &amp;quot;new&amp;quot; ... as in line 219 of subsystem_mgr.cxx&lt;br /&gt;
&lt;br /&gt;
A patch is available, but has not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Yet more memory mismanagement. ====&lt;br /&gt;
&lt;br /&gt;
When FG is trying to exit, it is very likely to abort&lt;br /&gt;
with a message such as&lt;br /&gt;
&lt;br /&gt;
  *** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***&lt;br /&gt;
&lt;br /&gt;
There are at least three different instances of this bug,&lt;br /&gt;
each producing a different traceback.  Here is one such&lt;br /&gt;
traceback:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
#0  0xb7573947 in raise () from /lib/tls/libc.so.6&lt;br /&gt;
#1  0xb75750c9 in abort () from /lib/tls/libc.so.6&lt;br /&gt;
#2  0xb75a908a in __libc_message () from /lib/tls/libc.so.6&lt;br /&gt;
#3  0xb75b094f in _int_free () from /lib/tls/libc.so.6&lt;br /&gt;
#4  0xb75b09f2 in free () from /lib/tls/libc.so.6&lt;br /&gt;
#5  0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6&lt;br /&gt;
#6  0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766&lt;br /&gt;
#7  0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#8  0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#9  0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105&lt;br /&gt;
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237&lt;br /&gt;
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6&lt;br /&gt;
#12 0x080919c7 in fgExit (status=0) at util.cxx:120&lt;br /&gt;
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Missing Features and Traps for the Unwary ==&lt;br /&gt;
&lt;br /&gt;
==== Version number, please. ====&lt;br /&gt;
&lt;br /&gt;
It would be helpful to have an easy, documented way to ascertain the&lt;br /&gt;
version number.  A --version option on the command line would be&lt;br /&gt;
nice.  Maybe also a help::about menu item, for use while fgfs is&lt;br /&gt;
already running.&lt;br /&gt;
&lt;br /&gt;
One could imagine that info about key libraries would also be&lt;br /&gt;
helpful.&lt;br /&gt;
&lt;br /&gt;
==== Rabbits extinct. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, many airports have '''sequenced flashers''' &lt;br /&gt;
(aka the rabbit) as part of the approach-light system.&lt;br /&gt;
&lt;br /&gt;
In the FlightGear world, the sequenced flashers are inoperative&lt;br /&gt;
everywhere.  Grepping through the code suggests that no attempt&lt;br /&gt;
has been made to implement this.&lt;br /&gt;
&lt;br /&gt;
==== No comm volume control. ====&lt;br /&gt;
&lt;br /&gt;
In many aircraft including the default c172p, the comm&lt;br /&gt;
radios have no volume control knob.  In other aircraft&lt;br /&gt;
including the pa24-250, there is such a knob, but it&lt;br /&gt;
apparently isn't clickable and apparently doesn't do &lt;br /&gt;
anything.  &lt;br /&gt;
&lt;br /&gt;
In contrast, the SenecaII exemplifies the ''desired'' behavior: &lt;br /&gt;
the knob rotates when clicked and &lt;br /&gt;
correctly controls the /instrumentation/comm[N]/volume&lt;br /&gt;
property.  (This alas has no effect on the volume of ATIS&lt;br /&gt;
audio, but that must be considered an ATIS bug not a&lt;br /&gt;
Seneca bug.)&lt;br /&gt;
&lt;br /&gt;
==== Incomplete Scenery. ====&lt;br /&gt;
&lt;br /&gt;
Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ]  without installing the shared models, will get you messages such as the following:&lt;br /&gt;
&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/localizer.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml&lt;br /&gt;
&lt;br /&gt;
You might get only a few such messages, or you might get &lt;br /&gt;
screenful after screenful.&lt;br /&gt;
&lt;br /&gt;
So, make sure you download all scenery files that are needed for fgfs.&lt;br /&gt;
&lt;br /&gt;
This obviously counts as a trap for the unwary.&lt;br /&gt;
&lt;br /&gt;
- This is patently not a bug and should be moved to a &amp;quot;tips&amp;quot; section or similar.  The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...&lt;br /&gt;
&lt;br /&gt;
==== ASOS and AWOS are AWOL. ====&lt;br /&gt;
&lt;br /&gt;
At many non-tower airports (and even some tower airports) there&lt;br /&gt;
is automatic weather reporting of some kind.&lt;br /&gt;
&lt;br /&gt;
It ought to be straightforward to implement this, as a slight&lt;br /&gt;
variation on the existing ATIS feature.&lt;br /&gt;
&lt;br /&gt;
==== Roundoff problems with textranslate step and scroll. ====&lt;br /&gt;
&lt;br /&gt;
The textranslate animation is delightful for 3D animation&lt;br /&gt;
of mechanical drum-type displays as on old-fashioned&lt;br /&gt;
odometers and Hobbs meters.&lt;br /&gt;
&lt;br /&gt;
It is not, however, a convenient way to implement digital&lt;br /&gt;
readouts.  It works OK for integers, but the code in &lt;br /&gt;
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the &amp;quot;.1&amp;quot; in 122.1 MHz, particularly when the scroll-value is zero.&lt;br /&gt;
* One workaround is to stick to integers, e.g. integer kHz &lt;br /&gt;
rather than fractional MHz.&lt;br /&gt;
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.&lt;br /&gt;
* A final option (with CVS) is to use the bias tag to let the code know how to&lt;br /&gt;
handle round-off.  Use a bias value of 1/2 your smallest step value, and &lt;br /&gt;
use the same bias value on all digits.&lt;br /&gt;
&lt;br /&gt;
What we really need is a whole new support routine for dealing&lt;br /&gt;
with 3D digital displays, something at least as nice as the&lt;br /&gt;
support for 2D instruments.&lt;br /&gt;
&lt;br /&gt;
==== Broken startup banner. ====&lt;br /&gt;
&lt;br /&gt;
On startup, the simulator prints Author: Unknown and prints a bogus Date.&lt;br /&gt;
&lt;br /&gt;
The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.&lt;br /&gt;
&lt;br /&gt;
== Fixed Bugs ==&lt;br /&gt;
&lt;br /&gt;
If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).&lt;br /&gt;
&lt;br /&gt;
==== Wild accelerations at low speeds. ====&lt;br /&gt;
&lt;br /&gt;
Improper inclinometer ball indications have been observed:&lt;br /&gt;
* When parked, the ball was pegged to one side.&lt;br /&gt;
* When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.&lt;br /&gt;
&lt;br /&gt;
This was observed in the c182 model and in the default c172 model.&lt;br /&gt;
&lt;br /&gt;
Tracing indicates that the problem is not within the slip_skid_ball.cxx&lt;br /&gt;
code, but rather upstream of there, in the flight dynamics.  Tracing&lt;br /&gt;
shows that the y-accel-fps_sec values are wildly fluctuating in&lt;br /&gt;
direction, and enormous in magnitude.&lt;br /&gt;
&lt;br /&gt;
Additional evidence pointing to the FDM comes from the fact that&lt;br /&gt;
the problem is observed with JSBSim and not with larcsim (although&lt;br /&gt;
larcsim has other problems, such as drifting slowly sideways while&lt;br /&gt;
parked).&lt;br /&gt;
&lt;br /&gt;
This is important from a procedures training point of view.  &lt;br /&gt;
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi.  In a real aircraft, a pilot who found the &lt;br /&gt;
inclinometer pegged would cancel the flight before even starting&lt;br /&gt;
the engine.&lt;br /&gt;
&lt;br /&gt;
Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:&lt;br /&gt;
&lt;br /&gt;
*velocities/vdot-fps&lt;br /&gt;
*velocities/a-pilot-y-ft sec2&lt;br /&gt;
*velocities/n-pilot-y-norm&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Misdirected diagnostic in JSBSim.cxx ====&lt;br /&gt;
&lt;br /&gt;
The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout.  This made both the log and the console record hard to interpret.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====&lt;br /&gt;
&lt;br /&gt;
The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.&lt;br /&gt;
&lt;br /&gt;
Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)&lt;br /&gt;
&lt;br /&gt;
* '''This bug has not been observed in 0.9.10.'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting &amp;quot;Could not gen source&amp;quot; ====&lt;br /&gt;
&lt;br /&gt;
Any further reports or stacktraces on this bug would be appreciated.&lt;br /&gt;
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.&lt;br /&gt;
Update your sound card drivers.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed in 0.9.8a'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.7 - ? Linux - Joystick crash with correct config files ====&lt;br /&gt;
&lt;br /&gt;
Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.&lt;br /&gt;
&lt;br /&gt;
* ''' This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
==== Individual Aircraft ====&lt;br /&gt;
&lt;br /&gt;
Bugs associated with a particular aircraft should be listed&lt;br /&gt;
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.&lt;br /&gt;
&lt;br /&gt;
==== OpenSceneGraph ====&lt;br /&gt;
&lt;br /&gt;
There is a separate page for issues related to [[OpenSceneGraph]].&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3548</id>
		<title>Bugs</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3548"/>
		<updated>2007-06-13T22:19:03Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Airport lighting in poor weather. */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Known Bugs ==&lt;br /&gt;
&lt;br /&gt;
This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.&lt;br /&gt;
&lt;br /&gt;
==== Incorrect altimetry. ====&lt;br /&gt;
&lt;br /&gt;
There is evidently at least one serious misconception in the&lt;br /&gt;
code that calculates atmospheric pressure, altimeter settings, &lt;br /&gt;
et cetera.  This can be easily demonstrated:&lt;br /&gt;
&lt;br /&gt;
Park at or near the threshold of runway 33 at Aspen (KASE).&lt;br /&gt;
Under standard conditions, observe that the altimeter reads&lt;br /&gt;
7820 feet MSL, as it should.&lt;br /&gt;
&lt;br /&gt;
Use the Weather : Weather Conditions dialog popup to&lt;br /&gt;
look at the ground-level altimeter setting (QNH).&lt;br /&gt;
This is bottom row in the &amp;quot;Alt (inHg)&amp;quot; column of the popup.&lt;br /&gt;
Verify that it is 29.92.&lt;br /&gt;
&lt;br /&gt;
Now use the dialog box to change this property.  Change it&lt;br /&gt;
to 30.92, a one-inch difference.&lt;br /&gt;
&lt;br /&gt;
Go to your altimeter instrument and enter the new altimeter&lt;br /&gt;
setting in the Kollsman window.  Ideally, this '''should'''&lt;br /&gt;
cause the instrument to read the correct altitude once&lt;br /&gt;
again, namely 7820 feet MSL.&lt;br /&gt;
&lt;br /&gt;
However, due to bugs, it is likely that you will observe&lt;br /&gt;
something closer to 8120.  This means the airplane is 300 &lt;br /&gt;
feet lower than the altimeter says it is.&lt;br /&gt;
&lt;br /&gt;
In case it wasn't obvious, when flying around near Aspen,&lt;br /&gt;
being 300 feet lower than you think you are can be very&lt;br /&gt;
bad for your health.&lt;br /&gt;
&lt;br /&gt;
The absolutely correct formulas for computing the altimeter &lt;br /&gt;
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
A patch to fix the altimeter has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Altimetry misnomers and misconceptions. ====&lt;br /&gt;
&lt;br /&gt;
Both the Weather Conditions popup and the atis.cxx code&lt;br /&gt;
rely on the &amp;quot;pressure-sea-level-inhg&amp;quot; property and use&lt;br /&gt;
it in ways that the altimeter setting should be used.&lt;br /&gt;
&lt;br /&gt;
For some people this may be merely a misnomer, but for&lt;br /&gt;
others it is clearly a misconception, as recent events&lt;br /&gt;
have shown.&lt;br /&gt;
&lt;br /&gt;
The fact is, the altimeter setting is '''not''' the same &lt;br /&gt;
thing as the pressure at sea level (Psl), especially when &lt;br /&gt;
the airmass has a non-standard temperature profile.&lt;br /&gt;
The altimeter setting is something&lt;br /&gt;
else;  it is properly called the altimeter setting.  It&lt;br /&gt;
is also properly called the QNH, although private pilots&lt;br /&gt;
who fly only in the US may be unfamiliar with the QNH&lt;br /&gt;
terminology.&lt;br /&gt;
&lt;br /&gt;
In the Remarks section of a METAR, you can sometimes&lt;br /&gt;
find the ''Reduced'' Sea Level Pressure, which is&lt;br /&gt;
unfortunately denoted SLP.  This METAR SLP serves&lt;br /&gt;
the same function as the altimeter setting.  Despite&lt;br /&gt;
its name, the METAR SLP is not equal to the honest-to-goodness&lt;br /&gt;
pressure at honest-to-goodness sea level (Psl), as&lt;br /&gt;
discussed in more detail on&lt;br /&gt;
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
There needs to be a facility whereby routines that need&lt;br /&gt;
the altimeter setting can obtain the altimeter setting.&lt;br /&gt;
&lt;br /&gt;
Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
Existing code sometimes treads the &amp;quot;pressure-sea-level-inhg&amp;quot; &lt;br /&gt;
property as if it were Psl, and sometimes as if it were &lt;br /&gt;
METAR SLP.  All this needs to be vetted.&lt;br /&gt;
&lt;br /&gt;
==== Newton's laws violated by environment.cxx ====&lt;br /&gt;
&lt;br /&gt;
Consider the following results of an experiment using fgfs:&lt;br /&gt;
&lt;br /&gt;
  alt:  662  mM: 0.0288  P: 99000.8462  T: 286.8563  rho: 1.1975&lt;br /&gt;
  alt: 3462  mM: 0.0288  P: 89341.6721  T: 281.3920  rho: 1.1009&lt;br /&gt;
  &lt;br /&gt;
  alt:  662  mM: 0.0289  P: 99000.8422  T: 256.9910  rho: 1.3404&lt;br /&gt;
  alt: 3462  mM: 0.0289  P: 89341.6740  T: 252.0956  rho: 1.2333&lt;br /&gt;
&lt;br /&gt;
The first pair of lines represent before and after a simple&lt;br /&gt;
flight from one airport to another, with a net gain in altitude of&lt;br /&gt;
2800 feet, under standard conditions.  So far so good.&lt;br /&gt;
&lt;br /&gt;
The second pair of lines represent exactly the same flight, &lt;br /&gt;
except that the ambient temperature was 30 degrees colder&lt;br /&gt;
than before.  You can see that the density (rho) is greater,&lt;br /&gt;
in accordance with the ideal gas law.&lt;br /&gt;
&lt;br /&gt;
The problem is that the delta_P is exactly the same for the two&lt;br /&gt;
flights.  This is a problem because P is connected to the weight&lt;br /&gt;
of the air column.  If the air is 12% denser, the laws of physics &lt;br /&gt;
require it to have a 12% steeper pressure gradient dP/dh ... but &lt;br /&gt;
alas this is not observed.&lt;br /&gt;
&lt;br /&gt;
This incorrect pressure profile P(h) has many consequences affecting&lt;br /&gt;
engine performance, airfoil performance, altimetry, et cetera.&lt;br /&gt;
&lt;br /&gt;
==== Z-buffer burn-through. ====&lt;br /&gt;
&lt;br /&gt;
Sometimes distant objects can be seen through nearer objects that&lt;br /&gt;
are not supposed to be transparent.  For example:  Runway lights &lt;br /&gt;
sometimes burn through a solid cloud layer.  Also runway lights&lt;br /&gt;
sometimes burn through aircraft structure.  Some instruments&lt;br /&gt;
burn through the yoke.&lt;br /&gt;
&lt;br /&gt;
It seems that so-called &amp;quot;2D&amp;quot; objects in the&lt;br /&gt;
background are likely to burn through &amp;quot;3D&amp;quot; objects in the&lt;br /&gt;
foreground.  This is particularly noticeable in aircraft&lt;br /&gt;
that have a mixture of 2D and 3D instruments.&lt;br /&gt;
&lt;br /&gt;
The ''position'' in space of the offending objects is OK, as&lt;br /&gt;
you can verify by shifting your PoV to get a little bit of&lt;br /&gt;
a side view.  The obvious hypothesis is that the Z-order&lt;br /&gt;
is being mishandled in a Z-buffer somewhere.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak. ====&lt;br /&gt;
&lt;br /&gt;
The simulator will gobble up about 3 gigabytes&lt;br /&gt;
of virtual memory overnight, while paused.  &lt;br /&gt;
Without the&lt;br /&gt;
leak, the memory footprint would be less than 300 meg.  The&lt;br /&gt;
difference between 300 meg and 3 gig is quite &lt;br /&gt;
significant on machines that have only 1 or 2 gig&lt;br /&gt;
of main memory.&lt;br /&gt;
&lt;br /&gt;
A rather steady leak of 2 meg per minute is observed&lt;br /&gt;
during pause, no matter whether the aircraft is aloft&lt;br /&gt;
or parked on the ground.  '''Vastly less leakage''' (two&lt;br /&gt;
orders of magnitude less, possibly zero) is observed&lt;br /&gt;
when the simulator is not paused, and the aircraft&lt;br /&gt;
is simply sitting on the ground with the parking&lt;br /&gt;
brake set.&lt;br /&gt;
&lt;br /&gt;
This bug has been observed in multiple versions of fgfs,&lt;br /&gt;
including one compiled back in May, 2006 as well as&lt;br /&gt;
the most current CVS version.&lt;br /&gt;
&lt;br /&gt;
This is 100% reproducible with a &lt;br /&gt;
ATI RV350 [Mobility Radeon 9600 M10] chipset&lt;br /&gt;
and the ati-fglrx driver.&lt;br /&gt;
The leak is observed whether or not &lt;br /&gt;
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.&lt;br /&gt;
&lt;br /&gt;
==== Numerous bugs in ATIS feature. ====&lt;br /&gt;
&lt;br /&gt;
1) The ATIS is supposed to change whenever there is a&lt;br /&gt;
significant change in the weather.  The comments mention&lt;br /&gt;
this, but the code makes no attempt to implement this.&lt;br /&gt;
&lt;br /&gt;
2) The code assumes that ATIS is prepared on the hour.&lt;br /&gt;
In practice this is virtually never the case;  a new&lt;br /&gt;
ATIS is prepared hourly, but not on the hour.  Also&lt;br /&gt;
this assumption is inconsistent with ATIS changes&lt;br /&gt;
based on the weather.&lt;br /&gt;
&lt;br /&gt;
3) The code attempts to issue a station identifier, but&lt;br /&gt;
none is heard.&lt;br /&gt;
&lt;br /&gt;
4) Multiple departures from standard phraseology.&lt;br /&gt;
&lt;br /&gt;
5) The volume is too low;  ATIS is not readable over engine noise.&lt;br /&gt;
This defeats much of the purpose of ATIS.  The volume does&lt;br /&gt;
not respond to the /instrumentation/comm[N]/volume property.&lt;br /&gt;
&lt;br /&gt;
6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.&lt;br /&gt;
&lt;br /&gt;
x) Et cetera.&lt;br /&gt;
&lt;br /&gt;
A patch to fix a few dozen ATIS bugs is available, but has not been&lt;br /&gt;
incorporated into FG CVS.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --altitude option. ====&lt;br /&gt;
&lt;br /&gt;
When the aircraft is initialzed aloft using the &lt;br /&gt;
command-line --altitude=6000&lt;br /&gt;
option, 0.9.10 is observed to put up a blank screen &lt;br /&gt;
(no scenery, no panel) and to spew on the console &lt;br /&gt;
page after page like this:&lt;br /&gt;
&lt;br /&gt;
  Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..&lt;br /&gt;
  altitude         = -1.69132e-41&lt;br /&gt;
  sea level radius = -6.54575e-42&lt;br /&gt;
  latitude         = 6.9874e-316&lt;br /&gt;
  longitude        = 6.79737e-313&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_pitch&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_volume&lt;br /&gt;
&lt;br /&gt;
==== Multiple bugs in the location-in-air popup. ====&lt;br /&gt;
&lt;br /&gt;
The location-in-air popup turns off the magnetos and extends&lt;br /&gt;
the landing gear.  Some pilots and flight instructors &lt;br /&gt;
deem this to be undesirable behavior, especially if all&lt;br /&gt;
they are trying to do is relocate from one airborne position to&lt;br /&gt;
another.&lt;br /&gt;
&lt;br /&gt;
Similarly, it strongly perturbs the throttle setting, &lt;br /&gt;
aileron trim, elevator trim, rudder trim, &lt;br /&gt;
view angles, PoV position, and who-knows-what else.  &lt;br /&gt;
Again, people who know about airplanes consider this to&lt;br /&gt;
be undesirable behavior.&lt;br /&gt;
&lt;br /&gt;
There is also a tendency to place the aircraft into &lt;br /&gt;
dangerous unusual attitudes, and other bugs too numerous &lt;br /&gt;
to mention.&lt;br /&gt;
&lt;br /&gt;
Evidently, though, there is at least one person who likes&lt;br /&gt;
things the way they are.  Code that would have fixed these&lt;br /&gt;
bugs was rejected.  Neither specific nor constructive criticism&lt;br /&gt;
of the code was offered.  For details see the flightgear-devel&lt;br /&gt;
mailing list archives.&lt;br /&gt;
&lt;br /&gt;
==== Nearest fix. ====&lt;br /&gt;
&lt;br /&gt;
Did you know that there are 8 different BRAVO intersections&lt;br /&gt;
in the database?&lt;br /&gt;
&lt;br /&gt;
Until now there was no support in the code for this;  all but&lt;br /&gt;
one of the entries was thrown away at the lowest level. There&lt;br /&gt;
is a comment in the code saying that fixing this is on the&lt;br /&gt;
TODO list.&lt;br /&gt;
&lt;br /&gt;
As for navaids (as opposed to waypoints), the low-level code&lt;br /&gt;
already provides support for ambiguous IDs, but the information&lt;br /&gt;
is not being used very wisely by the higher layers.&lt;br /&gt;
&lt;br /&gt;
Code to fix these problems was offered to the community.&lt;br /&gt;
So far it has been completely ignored.&lt;br /&gt;
&lt;br /&gt;
==== HSI instrument failure. ====&lt;br /&gt;
&lt;br /&gt;
If you use the &amp;quot;heading indicator&amp;quot; checkbox on the&lt;br /&gt;
&amp;quot;instrument failure&amp;quot; popup to command a failure,&lt;br /&gt;
it has no effect on the HSI instrument used by&lt;br /&gt;
many aircraft in the simulator fleet.&lt;br /&gt;
&lt;br /&gt;
This is because of wrong code in hsi.xml.  &lt;br /&gt;
&lt;br /&gt;
Backend code to handle this correctly exists, but has&lt;br /&gt;
apparently never been used.  It needs one small fix,&lt;br /&gt;
followed by recompilation.  A patchset to take care&lt;br /&gt;
of all this was offered to the community, but has&lt;br /&gt;
not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Flux gate not really a flux gate. ====&lt;br /&gt;
&lt;br /&gt;
In the Instrumentation director, there are three heading-related&lt;br /&gt;
.cxx files.&lt;br /&gt;
* heading_indicator.cxx : vacuum driven, with drift&lt;br /&gt;
* heading_indicator_dg.cxx : electrically driven, with drift&lt;br /&gt;
* heading_indicator_fg.cxx : electrically driven, no drift&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;fg&amp;quot; in &amp;quot;heading_indicator_fg&amp;quot; is documented to stand for&lt;br /&gt;
&amp;quot;flux gate&amp;quot;, as if the heading were slaved to a flux-gate&lt;br /&gt;
compass ... but the code does not implement any such thing.&lt;br /&gt;
All it really does is initialize the indicated heading to &lt;br /&gt;
the correct magnetic heading value, and then implement a &lt;br /&gt;
no-drift policy.  This is incorrect behavior, as can be&lt;br /&gt;
seen by flying to an area where the magnetic variation is&lt;br /&gt;
different from what it was at the start of the flight.  A&lt;br /&gt;
true slaved heading indicator would gradually accommodate&lt;br /&gt;
the new magvar.&lt;br /&gt;
&lt;br /&gt;
The correct behavior ought to be easy to implement.&lt;br /&gt;
&lt;br /&gt;
==== Weird noises during initialization. ====&lt;br /&gt;
&lt;br /&gt;
It is observed that sometimes while the simulator is starting&lt;br /&gt;
up, before things are fully operational, weird noises are&lt;br /&gt;
produced.  For example, in the c182rg, gear-in-transit&lt;br /&gt;
noises are produced for several seconds before the first&lt;br /&gt;
display becomes visible.  (According to a dump of the&lt;br /&gt;
relevant variables, there is no evidence that the gear is&lt;br /&gt;
actually in transit, and no reason why it should be.)&lt;br /&gt;
&lt;br /&gt;
Code to fix this was submitted.  So far it has been&lt;br /&gt;
ignored.&lt;br /&gt;
&lt;br /&gt;
==== Weird displays during fullscreen initialization. ====&lt;br /&gt;
&lt;br /&gt;
If the --enable-fullscreen command-line option is used, &lt;br /&gt;
the window is enlarged to full-screen size at a time&lt;br /&gt;
when initialization is only half-complete.  From this&lt;br /&gt;
time until the end of initialization, the display &lt;br /&gt;
contains weird combinations of leftover graphic objects&lt;br /&gt;
and other junk.&lt;br /&gt;
&lt;br /&gt;
This is observed no matter whether the splash-screen feature&lt;br /&gt;
is enabled or disabled.&lt;br /&gt;
&lt;br /&gt;
==== Fullscreen window sometimes misplaced. ====&lt;br /&gt;
&lt;br /&gt;
About 20% of the time, when the --enable-fullscreen command-line&lt;br /&gt;
option is used, it opens a window of the correct size, but &lt;br /&gt;
badly misplaced relative to the screen, such that only one half&lt;br /&gt;
or one quarter of the window is on-screen.&lt;br /&gt;
&lt;br /&gt;
==== Navigation databases out-of-date ====&lt;br /&gt;
&lt;br /&gt;
The database of navigation waypoints and fixes has an internal&lt;br /&gt;
date of early 2005.  It is missing quite a few useful fixes.  &lt;br /&gt;
The FAA has defined quite a few new approaches in recent years,&lt;br /&gt;
and has revised others.&lt;br /&gt;
&lt;br /&gt;
An updated version, based on a pull of the much more&lt;br /&gt;
current x-plane database, was made available.  So far&lt;br /&gt;
it has been ignored.&lt;br /&gt;
&lt;br /&gt;
Similar remarks apply to the ''navaids'' database.&lt;br /&gt;
&lt;br /&gt;
==== Ident from phantom DME. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, some VOR stations and even some localizers&lt;br /&gt;
have a colocated DME station ... but there are plenty that&lt;br /&gt;
don't.&lt;br /&gt;
&lt;br /&gt;
The DME has its own Morse ident, with a distinctive higher pitch.&lt;br /&gt;
&lt;br /&gt;
In the simulator, due to a bug in the code, all stations&lt;br /&gt;
transmit the DME Morse ident ... even stations where no&lt;br /&gt;
DME is present.&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx finds the nearest VOR or LOC on the&lt;br /&gt;
frequency, and checks to see if it is in range.  It also asks&lt;br /&gt;
for the &amp;quot;nearest&amp;quot; DME on the frequency, but makes no attempt&lt;br /&gt;
to check that it is in range.  To say the same thing the&lt;br /&gt;
other way, there is no attempt to check that the aircraft is&lt;br /&gt;
within the service volume of the DME.  Since there is almost always&lt;br /&gt;
a DME /somewhere/ on the frequency, the has_dme variable will&lt;br /&gt;
always be set true.&lt;br /&gt;
&lt;br /&gt;
For a demonstration of this bug, park at KAOO airport and &lt;br /&gt;
tune up the AOO VOR (which has no DME).  Or park at almost&lt;br /&gt;
any airport and tune up the localizer (since relatively few&lt;br /&gt;
localizers have DME).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Airport lighting in poor weather. ====&lt;br /&gt;
&lt;br /&gt;
The code in tileentry.cxx turns on airport lights according to&lt;br /&gt;
the position of the sun relative to the horizon.  One consequence&lt;br /&gt;
is that the lights are off during the day.&lt;br /&gt;
&lt;br /&gt;
In real life, there are many circumstances where airport lights,&lt;br /&gt;
including approach lights, are turned on during the day.  At tower airports, the lights are turned on during bad weather -- including weather that &lt;br /&gt;
is only slightly bad -- and also turned on if requested by the pilot.  For&lt;br /&gt;
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].&lt;br /&gt;
&lt;br /&gt;
At non-towered airports, the lights are usually pilot-controlled,&lt;br /&gt;
via radio.&lt;br /&gt;
&lt;br /&gt;
The absence of lighting during daytime in poor weather detracts &lt;br /&gt;
significantly from the realism, because it affects both the&lt;br /&gt;
legality and the practicality of performing instrument approaches&lt;br /&gt;
under such conditions.&lt;br /&gt;
&lt;br /&gt;
___ In version 0.9.10 runway lights are turned on automatically in day time if visibility is low. Though I agree, that pilot controlled lights could be a nice feature, but it's not a bug, it's more like a wish list entry, I suppose.&lt;br /&gt;
&lt;br /&gt;
==== Holes in the ground. ====&lt;br /&gt;
&lt;br /&gt;
Ever since the first win32-build of FG-OSG, there are at least two huge &lt;br /&gt;
ground scenery holes in the the Rhine/Main/Neckar-region in Germany. &lt;br /&gt;
The first one gapes at &lt;br /&gt;
the place which was formerly known as the city of Mannheim (near the &lt;br /&gt;
airport EDFM, which is still there), the second one has swallowed up a &lt;br /&gt;
big piece of Frankfurt am Main (near EDDF) and surrounding land. &lt;br /&gt;
&lt;br /&gt;
First posted to the flightgear-devel list in November, 2006.&lt;br /&gt;
&lt;br /&gt;
==== Mixture versus Altitude. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that at&lt;br /&gt;
high altitude airports (e.g. KGCN or KASE), to obtain max&lt;br /&gt;
static RPM, it suffices to move the mixture control only a&lt;br /&gt;
few mm aft of the full-forward (full-rich) position.&lt;br /&gt;
&lt;br /&gt;
This is unrealistic.  In a real aircraft under such conditions,&lt;br /&gt;
it would be necessary to pull the mixture control back about&lt;br /&gt;
an inch to obtain max RPM.&lt;br /&gt;
&lt;br /&gt;
It's hard to say whether the carburetor is underreacting to the&lt;br /&gt;
altitude, or overreacting to the mixture control.&lt;br /&gt;
&lt;br /&gt;
==== EGT reads high. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that the&lt;br /&gt;
EGT reads toward the high end of the scale under all conditions,&lt;br /&gt;
including idle.  This is unrealistic.&lt;br /&gt;
&lt;br /&gt;
Also, the EGT reads ''off-scale'' high under high-power conditions.&lt;br /&gt;
&lt;br /&gt;
==== Flags missing from instruments. ====&lt;br /&gt;
&lt;br /&gt;
Some of the standard instruments lack status flags.  For example,&lt;br /&gt;
the GS needle goes to  mid-scale if there is no valid signal.  That'll kill you for sure.  Reportedly the hi-res instruments implement flags, but the lo-res ones don't.  Many aircraft are using the lo-res instruments.&lt;br /&gt;
&lt;br /&gt;
Either the aircraft should be upgraded to use instruments that&lt;br /&gt;
display flags, or the instruments should be upgraded to be&lt;br /&gt;
display flags.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --model-hz option. ====&lt;br /&gt;
&lt;br /&gt;
Specifying the --model-hz=10 command-line option results in the&lt;br /&gt;
following mess:&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml&lt;br /&gt;
  Sorry, wdot doesn't appear to be trimmable&lt;br /&gt;
 Trim Failed&lt;br /&gt;
  Trim Results: &lt;br /&gt;
       Angle of Attack:   7.50  wdot:  3.21e+01 Tolerance: 1e-03  Failed&lt;br /&gt;
              Throttle:   0.50  udot:  0.00e+00 Tolerance: 1e-03  Passed&lt;br /&gt;
            Pitch Trim:   0.00  qdot: -5.44e-11 Tolerance: 1e-04  Passed&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 WWarning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
     [many repeats]&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 altitude         = 9&lt;br /&gt;
 sea level radius = 4.62829e-268&lt;br /&gt;
 latitude         = 1.52075e-314&lt;br /&gt;
 longitude        = -0.0967923&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = nan&lt;br /&gt;
 sea level radius = nan&lt;br /&gt;
 latitude         = nan&lt;br /&gt;
 longitude        = nan&lt;br /&gt;
&lt;br /&gt;
and so forth.&lt;br /&gt;
&lt;br /&gt;
* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.&lt;br /&gt;
&lt;br /&gt;
==== CPU hogging. ====&lt;br /&gt;
&lt;br /&gt;
The fsgs program will happily eat up &amp;gt;98% of the cpu cycles,&lt;br /&gt;
even when the simulator is paused.  That seems excessive,&lt;br /&gt;
particularly during pause.  This is on a 2GHz machine&lt;br /&gt;
with hardware acceleration.  As a point of reference, &lt;br /&gt;
glxgears uses only a fraction of one percent of the cpu.&lt;br /&gt;
&lt;br /&gt;
* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result  if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)&lt;br /&gt;
&lt;br /&gt;
==== Out-of-bounds array reference in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the interpolation table code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the &amp;quot;message&amp;quot; handling code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Glideslope service volume. ====&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx appears to assume the glideslope&lt;br /&gt;
service volume is the same as the localizer service&lt;br /&gt;
volume.  This is quite unrealistic.&lt;br /&gt;
&lt;br /&gt;
==== Extended service volume. ====&lt;br /&gt;
&lt;br /&gt;
In some parts of the world, a goodly fraction of the&lt;br /&gt;
localizers have an expanded service volume (ESV),&lt;br /&gt;
often quite a bit larger than the standard service&lt;br /&gt;
volume you see in the AIM.  The code in navradio.cxx&lt;br /&gt;
was ignoring the service volume information in the&lt;br /&gt;
database and wrongly assuming the default values&lt;br /&gt;
applied everywhere.  Code to fix the range-related&lt;br /&gt;
part of the problem has been offered&lt;br /&gt;
but not yet incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Other service volume issues. ====&lt;br /&gt;
&lt;br /&gt;
The code  in navradio.cxx has no understanding of how &lt;br /&gt;
'''azimuth''' affects the&lt;br /&gt;
localizer.  There is more to the story than reception range.&lt;br /&gt;
It is perfectly possible to be outside the LOC service volume &lt;br /&gt;
for reasons having to do with azimuth, not range.  &lt;br /&gt;
&lt;br /&gt;
Good ident will be heard, but false localizer courses will &lt;br /&gt;
cause serious trouble for the unwary pilot.&lt;br /&gt;
&lt;br /&gt;
A patch to fix this (along with the ESV issue) has been &lt;br /&gt;
offered, but ignored.&lt;br /&gt;
&lt;br /&gt;
There are also azimuthal issues with the /glideslope/&lt;br /&gt;
service volume.  This has not yet been patched.&lt;br /&gt;
&lt;br /&gt;
==== Menu buttons having a get-together. ====&lt;br /&gt;
&lt;br /&gt;
This concerns &amp;quot;radio buttons&amp;quot; on menus, such as on the &lt;br /&gt;
location-in-air popup and elsewhere.  By definition, it should be &lt;br /&gt;
impossible to have more than one radio button pushed down at a time.&lt;br /&gt;
However, illegal situations of this sort can be created&lt;br /&gt;
using a click-and-drag gesture.  Aim at&lt;br /&gt;
a radio button, hold the mouse-button down, and drag ...&lt;br /&gt;
as if you wanted to drag the radio button to a new location.&lt;br /&gt;
This allows you to set a radio button without the others&lt;br /&gt;
being unset.  If you persist, you can have every one of&lt;br /&gt;
the buttons in the pushed-down state at the same time.&lt;br /&gt;
&lt;br /&gt;
Before you say, &amp;quot;well, don't do that then&amp;quot; or &amp;quot;garbage in,&lt;br /&gt;
garbage out&amp;quot;, let me point out that it is possible for&lt;br /&gt;
a pilot to inadvertently make a tiny dragging gesture&lt;br /&gt;
when intending only a click.  Also, when the desired&lt;br /&gt;
button is in the pushed-down state, it is easy to not&lt;br /&gt;
notice that other buttons are in the undesired state.&lt;br /&gt;
&lt;br /&gt;
==== Altimeter setting unreadable. ====&lt;br /&gt;
&lt;br /&gt;
The standard altimeter (used by the default c172p aircraft&lt;br /&gt;
and many others) had been using an unhappy hodgepodge of&lt;br /&gt;
layers.  The analog Kollsman window was unusable, because&lt;br /&gt;
it was unlabeled, and the digital altimeter setting was&lt;br /&gt;
unusable, especially at altitudes near 2500 feet, partly &lt;br /&gt;
from being behind the needle.  On a real altimeter, things&lt;br /&gt;
are positioned so that cannot happen.&lt;br /&gt;
&lt;br /&gt;
Fixing this requires using a more suitable font, moving&lt;br /&gt;
the digits over, and getting rid of conflicting extraneous&lt;br /&gt;
markings.&lt;br /&gt;
&lt;br /&gt;
A patch to implement this fix has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Memory mismanagement in subsystem_mgr. ====&lt;br /&gt;
&lt;br /&gt;
It is bad luck to apply &amp;quot;delete&amp;quot; to an object that was not&lt;br /&gt;
created with &amp;quot;new&amp;quot; ... as in line 219 of subsystem_mgr.cxx&lt;br /&gt;
&lt;br /&gt;
A patch is available, but has not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Yet more memory mismanagement. ====&lt;br /&gt;
&lt;br /&gt;
When FG is trying to exit, it is very likely to abort&lt;br /&gt;
with a message such as&lt;br /&gt;
&lt;br /&gt;
  *** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***&lt;br /&gt;
&lt;br /&gt;
There are at least three different instances of this bug,&lt;br /&gt;
each producing a different traceback.  Here is one such&lt;br /&gt;
traceback:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
#0  0xb7573947 in raise () from /lib/tls/libc.so.6&lt;br /&gt;
#1  0xb75750c9 in abort () from /lib/tls/libc.so.6&lt;br /&gt;
#2  0xb75a908a in __libc_message () from /lib/tls/libc.so.6&lt;br /&gt;
#3  0xb75b094f in _int_free () from /lib/tls/libc.so.6&lt;br /&gt;
#4  0xb75b09f2 in free () from /lib/tls/libc.so.6&lt;br /&gt;
#5  0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6&lt;br /&gt;
#6  0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766&lt;br /&gt;
#7  0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#8  0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#9  0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105&lt;br /&gt;
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237&lt;br /&gt;
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6&lt;br /&gt;
#12 0x080919c7 in fgExit (status=0) at util.cxx:120&lt;br /&gt;
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Missing Features and Traps for the Unwary ==&lt;br /&gt;
&lt;br /&gt;
==== Version number, please. ====&lt;br /&gt;
&lt;br /&gt;
It would be helpful to have an easy, documented way to ascertain the&lt;br /&gt;
version number.  A --version option on the command line would be&lt;br /&gt;
nice.  Maybe also a help::about menu item, for use while fgfs is&lt;br /&gt;
already running.&lt;br /&gt;
&lt;br /&gt;
One could imagine that info about key libraries would also be&lt;br /&gt;
helpful.&lt;br /&gt;
&lt;br /&gt;
==== Rabbits extinct. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, many airports have '''sequenced flashers''' &lt;br /&gt;
(aka the rabbit) as part of the approach-light system.&lt;br /&gt;
&lt;br /&gt;
In the FlightGear world, the sequenced flashers are inoperative&lt;br /&gt;
everywhere.  Grepping through the code suggests that no attempt&lt;br /&gt;
has been made to implement this.&lt;br /&gt;
&lt;br /&gt;
==== No comm volume control. ====&lt;br /&gt;
&lt;br /&gt;
In many aircraft including the default c172p, the comm&lt;br /&gt;
radios have no volume control knob.  In other aircraft&lt;br /&gt;
including the pa24-250, there is such a knob, but it&lt;br /&gt;
apparently isn't clickable and apparently doesn't do &lt;br /&gt;
anything.  &lt;br /&gt;
&lt;br /&gt;
In contrast, the SenecaII exemplifies the ''desired'' behavior: &lt;br /&gt;
the knob rotates when clicked and &lt;br /&gt;
correctly controls the /instrumentation/comm[N]/volume&lt;br /&gt;
property.  (This alas has no effect on the volume of ATIS&lt;br /&gt;
audio, but that must be considered an ATIS bug not a&lt;br /&gt;
Seneca bug.)&lt;br /&gt;
&lt;br /&gt;
==== Incomplete Scenery. ====&lt;br /&gt;
&lt;br /&gt;
Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ]  without installing the shared models, will get you messages such as the following:&lt;br /&gt;
&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/localizer.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml&lt;br /&gt;
&lt;br /&gt;
You might get only a few such messages, or you might get &lt;br /&gt;
screenful after screenful.&lt;br /&gt;
&lt;br /&gt;
So, make sure you download all scenery files that are needed for fgfs.&lt;br /&gt;
&lt;br /&gt;
This obviously counts as a trap for the unwary.&lt;br /&gt;
&lt;br /&gt;
- This is patently not a bug and should be moved to a &amp;quot;tips&amp;quot; section or similar.  The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...&lt;br /&gt;
&lt;br /&gt;
==== ASOS and AWOS are AWOL. ====&lt;br /&gt;
&lt;br /&gt;
At many non-tower airports (and even some tower airports) there&lt;br /&gt;
is automatic weather reporting of some kind.&lt;br /&gt;
&lt;br /&gt;
It ought to be straightforward to implement this, as a slight&lt;br /&gt;
variation on the existing ATIS feature.&lt;br /&gt;
&lt;br /&gt;
==== Roundoff problems with textranslate step and scroll. ====&lt;br /&gt;
&lt;br /&gt;
The textranslate animation is delightful for 3D animation&lt;br /&gt;
of mechanical drum-type displays as on old-fashioned&lt;br /&gt;
odometers and Hobbs meters.&lt;br /&gt;
&lt;br /&gt;
It is not, however, a convenient way to implement digital&lt;br /&gt;
readouts.  It works OK for integers, but the code in &lt;br /&gt;
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the &amp;quot;.1&amp;quot; in 122.1 MHz, particularly when the scroll-value is zero.&lt;br /&gt;
* One workaround is to stick to integers, e.g. integer kHz &lt;br /&gt;
rather than fractional MHz.&lt;br /&gt;
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.&lt;br /&gt;
* A final option (with CVS) is to use the bias tag to let the code know how to&lt;br /&gt;
handle round-off.  Use a bias value of 1/2 your smallest step value, and &lt;br /&gt;
use the same bias value on all digits.&lt;br /&gt;
&lt;br /&gt;
What we really need is a whole new support routine for dealing&lt;br /&gt;
with 3D digital displays, something at least as nice as the&lt;br /&gt;
support for 2D instruments.&lt;br /&gt;
&lt;br /&gt;
==== Broken startup banner. ====&lt;br /&gt;
&lt;br /&gt;
On startup, the simulator prints Author: Unknown and prints a bogus Date.&lt;br /&gt;
&lt;br /&gt;
The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.&lt;br /&gt;
&lt;br /&gt;
== Fixed Bugs ==&lt;br /&gt;
&lt;br /&gt;
If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).&lt;br /&gt;
&lt;br /&gt;
==== Wild accelerations at low speeds. ====&lt;br /&gt;
&lt;br /&gt;
Improper inclinometer ball indications have been observed:&lt;br /&gt;
* When parked, the ball was pegged to one side.&lt;br /&gt;
* When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.&lt;br /&gt;
&lt;br /&gt;
This was observed in the c182 model and in the default c172 model.&lt;br /&gt;
&lt;br /&gt;
Tracing indicates that the problem is not within the slip_skid_ball.cxx&lt;br /&gt;
code, but rather upstream of there, in the flight dynamics.  Tracing&lt;br /&gt;
shows that the y-accel-fps_sec values are wildly fluctuating in&lt;br /&gt;
direction, and enormous in magnitude.&lt;br /&gt;
&lt;br /&gt;
Additional evidence pointing to the FDM comes from the fact that&lt;br /&gt;
the problem is observed with JSBSim and not with larcsim (although&lt;br /&gt;
larcsim has other problems, such as drifting slowly sideways while&lt;br /&gt;
parked).&lt;br /&gt;
&lt;br /&gt;
This is important from a procedures training point of view.  &lt;br /&gt;
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi.  In a real aircraft, a pilot who found the &lt;br /&gt;
inclinometer pegged would cancel the flight before even starting&lt;br /&gt;
the engine.&lt;br /&gt;
&lt;br /&gt;
Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:&lt;br /&gt;
&lt;br /&gt;
*velocities/vdot-fps&lt;br /&gt;
*velocities/a-pilot-y-ft sec2&lt;br /&gt;
*velocities/n-pilot-y-norm&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Misdirected diagnostic in JSBSim.cxx ====&lt;br /&gt;
&lt;br /&gt;
The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout.  This made both the log and the console record hard to interpret.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====&lt;br /&gt;
&lt;br /&gt;
The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.&lt;br /&gt;
&lt;br /&gt;
Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)&lt;br /&gt;
&lt;br /&gt;
* '''This bug has not been observed in 0.9.10.'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting &amp;quot;Could not gen source&amp;quot; ====&lt;br /&gt;
&lt;br /&gt;
Any further reports or stacktraces on this bug would be appreciated.&lt;br /&gt;
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.&lt;br /&gt;
Update your sound card drivers.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed in 0.9.8a'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.7 - ? Linux - Joystick crash with correct config files ====&lt;br /&gt;
&lt;br /&gt;
Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.&lt;br /&gt;
&lt;br /&gt;
* ''' This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
==== Individual Aircraft ====&lt;br /&gt;
&lt;br /&gt;
Bugs associated with a particular aircraft should be listed&lt;br /&gt;
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.&lt;br /&gt;
&lt;br /&gt;
==== OpenSceneGraph ====&lt;br /&gt;
&lt;br /&gt;
There is a separate page for issues related to [[OpenSceneGraph]].&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3547</id>
		<title>Bugs</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Bugs&amp;diff=3547"/>
		<updated>2007-06-13T22:14:32Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: /* Airport lighting in poor weather. */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Known Bugs ==&lt;br /&gt;
&lt;br /&gt;
This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.&lt;br /&gt;
&lt;br /&gt;
==== Incorrect altimetry. ====&lt;br /&gt;
&lt;br /&gt;
There is evidently at least one serious misconception in the&lt;br /&gt;
code that calculates atmospheric pressure, altimeter settings, &lt;br /&gt;
et cetera.  This can be easily demonstrated:&lt;br /&gt;
&lt;br /&gt;
Park at or near the threshold of runway 33 at Aspen (KASE).&lt;br /&gt;
Under standard conditions, observe that the altimeter reads&lt;br /&gt;
7820 feet MSL, as it should.&lt;br /&gt;
&lt;br /&gt;
Use the Weather : Weather Conditions dialog popup to&lt;br /&gt;
look at the ground-level altimeter setting (QNH).&lt;br /&gt;
This is bottom row in the &amp;quot;Alt (inHg)&amp;quot; column of the popup.&lt;br /&gt;
Verify that it is 29.92.&lt;br /&gt;
&lt;br /&gt;
Now use the dialog box to change this property.  Change it&lt;br /&gt;
to 30.92, a one-inch difference.&lt;br /&gt;
&lt;br /&gt;
Go to your altimeter instrument and enter the new altimeter&lt;br /&gt;
setting in the Kollsman window.  Ideally, this '''should'''&lt;br /&gt;
cause the instrument to read the correct altitude once&lt;br /&gt;
again, namely 7820 feet MSL.&lt;br /&gt;
&lt;br /&gt;
However, due to bugs, it is likely that you will observe&lt;br /&gt;
something closer to 8120.  This means the airplane is 300 &lt;br /&gt;
feet lower than the altimeter says it is.&lt;br /&gt;
&lt;br /&gt;
In case it wasn't obvious, when flying around near Aspen,&lt;br /&gt;
being 300 feet lower than you think you are can be very&lt;br /&gt;
bad for your health.&lt;br /&gt;
&lt;br /&gt;
The absolutely correct formulas for computing the altimeter &lt;br /&gt;
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
A patch to fix the altimeter has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Altimetry misnomers and misconceptions. ====&lt;br /&gt;
&lt;br /&gt;
Both the Weather Conditions popup and the atis.cxx code&lt;br /&gt;
rely on the &amp;quot;pressure-sea-level-inhg&amp;quot; property and use&lt;br /&gt;
it in ways that the altimeter setting should be used.&lt;br /&gt;
&lt;br /&gt;
For some people this may be merely a misnomer, but for&lt;br /&gt;
others it is clearly a misconception, as recent events&lt;br /&gt;
have shown.&lt;br /&gt;
&lt;br /&gt;
The fact is, the altimeter setting is '''not''' the same &lt;br /&gt;
thing as the pressure at sea level (Psl), especially when &lt;br /&gt;
the airmass has a non-standard temperature profile.&lt;br /&gt;
The altimeter setting is something&lt;br /&gt;
else;  it is properly called the altimeter setting.  It&lt;br /&gt;
is also properly called the QNH, although private pilots&lt;br /&gt;
who fly only in the US may be unfamiliar with the QNH&lt;br /&gt;
terminology.&lt;br /&gt;
&lt;br /&gt;
In the Remarks section of a METAR, you can sometimes&lt;br /&gt;
find the ''Reduced'' Sea Level Pressure, which is&lt;br /&gt;
unfortunately denoted SLP.  This METAR SLP serves&lt;br /&gt;
the same function as the altimeter setting.  Despite&lt;br /&gt;
its name, the METAR SLP is not equal to the honest-to-goodness&lt;br /&gt;
pressure at honest-to-goodness sea level (Psl), as&lt;br /&gt;
discussed in more detail on&lt;br /&gt;
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
There needs to be a facility whereby routines that need&lt;br /&gt;
the altimeter setting can obtain the altimeter setting.&lt;br /&gt;
&lt;br /&gt;
Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].&lt;br /&gt;
&lt;br /&gt;
Existing code sometimes treads the &amp;quot;pressure-sea-level-inhg&amp;quot; &lt;br /&gt;
property as if it were Psl, and sometimes as if it were &lt;br /&gt;
METAR SLP.  All this needs to be vetted.&lt;br /&gt;
&lt;br /&gt;
==== Newton's laws violated by environment.cxx ====&lt;br /&gt;
&lt;br /&gt;
Consider the following results of an experiment using fgfs:&lt;br /&gt;
&lt;br /&gt;
  alt:  662  mM: 0.0288  P: 99000.8462  T: 286.8563  rho: 1.1975&lt;br /&gt;
  alt: 3462  mM: 0.0288  P: 89341.6721  T: 281.3920  rho: 1.1009&lt;br /&gt;
  &lt;br /&gt;
  alt:  662  mM: 0.0289  P: 99000.8422  T: 256.9910  rho: 1.3404&lt;br /&gt;
  alt: 3462  mM: 0.0289  P: 89341.6740  T: 252.0956  rho: 1.2333&lt;br /&gt;
&lt;br /&gt;
The first pair of lines represent before and after a simple&lt;br /&gt;
flight from one airport to another, with a net gain in altitude of&lt;br /&gt;
2800 feet, under standard conditions.  So far so good.&lt;br /&gt;
&lt;br /&gt;
The second pair of lines represent exactly the same flight, &lt;br /&gt;
except that the ambient temperature was 30 degrees colder&lt;br /&gt;
than before.  You can see that the density (rho) is greater,&lt;br /&gt;
in accordance with the ideal gas law.&lt;br /&gt;
&lt;br /&gt;
The problem is that the delta_P is exactly the same for the two&lt;br /&gt;
flights.  This is a problem because P is connected to the weight&lt;br /&gt;
of the air column.  If the air is 12% denser, the laws of physics &lt;br /&gt;
require it to have a 12% steeper pressure gradient dP/dh ... but &lt;br /&gt;
alas this is not observed.&lt;br /&gt;
&lt;br /&gt;
This incorrect pressure profile P(h) has many consequences affecting&lt;br /&gt;
engine performance, airfoil performance, altimetry, et cetera.&lt;br /&gt;
&lt;br /&gt;
==== Z-buffer burn-through. ====&lt;br /&gt;
&lt;br /&gt;
Sometimes distant objects can be seen through nearer objects that&lt;br /&gt;
are not supposed to be transparent.  For example:  Runway lights &lt;br /&gt;
sometimes burn through a solid cloud layer.  Also runway lights&lt;br /&gt;
sometimes burn through aircraft structure.  Some instruments&lt;br /&gt;
burn through the yoke.&lt;br /&gt;
&lt;br /&gt;
It seems that so-called &amp;quot;2D&amp;quot; objects in the&lt;br /&gt;
background are likely to burn through &amp;quot;3D&amp;quot; objects in the&lt;br /&gt;
foreground.  This is particularly noticeable in aircraft&lt;br /&gt;
that have a mixture of 2D and 3D instruments.&lt;br /&gt;
&lt;br /&gt;
The ''position'' in space of the offending objects is OK, as&lt;br /&gt;
you can verify by shifting your PoV to get a little bit of&lt;br /&gt;
a side view.  The obvious hypothesis is that the Z-order&lt;br /&gt;
is being mishandled in a Z-buffer somewhere.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak. ====&lt;br /&gt;
&lt;br /&gt;
The simulator will gobble up about 3 gigabytes&lt;br /&gt;
of virtual memory overnight, while paused.  &lt;br /&gt;
Without the&lt;br /&gt;
leak, the memory footprint would be less than 300 meg.  The&lt;br /&gt;
difference between 300 meg and 3 gig is quite &lt;br /&gt;
significant on machines that have only 1 or 2 gig&lt;br /&gt;
of main memory.&lt;br /&gt;
&lt;br /&gt;
A rather steady leak of 2 meg per minute is observed&lt;br /&gt;
during pause, no matter whether the aircraft is aloft&lt;br /&gt;
or parked on the ground.  '''Vastly less leakage''' (two&lt;br /&gt;
orders of magnitude less, possibly zero) is observed&lt;br /&gt;
when the simulator is not paused, and the aircraft&lt;br /&gt;
is simply sitting on the ground with the parking&lt;br /&gt;
brake set.&lt;br /&gt;
&lt;br /&gt;
This bug has been observed in multiple versions of fgfs,&lt;br /&gt;
including one compiled back in May, 2006 as well as&lt;br /&gt;
the most current CVS version.&lt;br /&gt;
&lt;br /&gt;
This is 100% reproducible with a &lt;br /&gt;
ATI RV350 [Mobility Radeon 9600 M10] chipset&lt;br /&gt;
and the ati-fglrx driver.&lt;br /&gt;
The leak is observed whether or not &lt;br /&gt;
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.&lt;br /&gt;
&lt;br /&gt;
==== Numerous bugs in ATIS feature. ====&lt;br /&gt;
&lt;br /&gt;
1) The ATIS is supposed to change whenever there is a&lt;br /&gt;
significant change in the weather.  The comments mention&lt;br /&gt;
this, but the code makes no attempt to implement this.&lt;br /&gt;
&lt;br /&gt;
2) The code assumes that ATIS is prepared on the hour.&lt;br /&gt;
In practice this is virtually never the case;  a new&lt;br /&gt;
ATIS is prepared hourly, but not on the hour.  Also&lt;br /&gt;
this assumption is inconsistent with ATIS changes&lt;br /&gt;
based on the weather.&lt;br /&gt;
&lt;br /&gt;
3) The code attempts to issue a station identifier, but&lt;br /&gt;
none is heard.&lt;br /&gt;
&lt;br /&gt;
4) Multiple departures from standard phraseology.&lt;br /&gt;
&lt;br /&gt;
5) The volume is too low;  ATIS is not readable over engine noise.&lt;br /&gt;
This defeats much of the purpose of ATIS.  The volume does&lt;br /&gt;
not respond to the /instrumentation/comm[N]/volume property.&lt;br /&gt;
&lt;br /&gt;
6) When using the --enable-real-weather-fetch option, the weather conditions used for the ATIS message are the conditions at aircraft current position and not the conditions at the airfield. The METAR used at the aircraft's current position could come from a different airport.&lt;br /&gt;
&lt;br /&gt;
x) Et cetera.&lt;br /&gt;
&lt;br /&gt;
A patch to fix a few dozen ATIS bugs is available, but has not been&lt;br /&gt;
incorporated into FG CVS.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --altitude option. ====&lt;br /&gt;
&lt;br /&gt;
When the aircraft is initialzed aloft using the &lt;br /&gt;
command-line --altitude=6000&lt;br /&gt;
option, 0.9.10 is observed to put up a blank screen &lt;br /&gt;
(no scenery, no panel) and to spew on the console &lt;br /&gt;
page after page like this:&lt;br /&gt;
&lt;br /&gt;
  Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..&lt;br /&gt;
  altitude         = -1.69132e-41&lt;br /&gt;
  sea level radius = -6.54575e-42&lt;br /&gt;
  latitude         = 6.9874e-316&lt;br /&gt;
  longitude        = 6.79737e-313&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_pitch&lt;br /&gt;
  OpenAL error (AL_INVALID_VALUE): set_volume&lt;br /&gt;
&lt;br /&gt;
==== Multiple bugs in the location-in-air popup. ====&lt;br /&gt;
&lt;br /&gt;
The location-in-air popup turns off the magnetos and extends&lt;br /&gt;
the landing gear.  Some pilots and flight instructors &lt;br /&gt;
deem this to be undesirable behavior, especially if all&lt;br /&gt;
they are trying to do is relocate from one airborne position to&lt;br /&gt;
another.&lt;br /&gt;
&lt;br /&gt;
Similarly, it strongly perturbs the throttle setting, &lt;br /&gt;
aileron trim, elevator trim, rudder trim, &lt;br /&gt;
view angles, PoV position, and who-knows-what else.  &lt;br /&gt;
Again, people who know about airplanes consider this to&lt;br /&gt;
be undesirable behavior.&lt;br /&gt;
&lt;br /&gt;
There is also a tendency to place the aircraft into &lt;br /&gt;
dangerous unusual attitudes, and other bugs too numerous &lt;br /&gt;
to mention.&lt;br /&gt;
&lt;br /&gt;
Evidently, though, there is at least one person who likes&lt;br /&gt;
things the way they are.  Code that would have fixed these&lt;br /&gt;
bugs was rejected.  Neither specific nor constructive criticism&lt;br /&gt;
of the code was offered.  For details see the flightgear-devel&lt;br /&gt;
mailing list archives.&lt;br /&gt;
&lt;br /&gt;
==== Nearest fix. ====&lt;br /&gt;
&lt;br /&gt;
Did you know that there are 8 different BRAVO intersections&lt;br /&gt;
in the database?&lt;br /&gt;
&lt;br /&gt;
Until now there was no support in the code for this;  all but&lt;br /&gt;
one of the entries was thrown away at the lowest level. There&lt;br /&gt;
is a comment in the code saying that fixing this is on the&lt;br /&gt;
TODO list.&lt;br /&gt;
&lt;br /&gt;
As for navaids (as opposed to waypoints), the low-level code&lt;br /&gt;
already provides support for ambiguous IDs, but the information&lt;br /&gt;
is not being used very wisely by the higher layers.&lt;br /&gt;
&lt;br /&gt;
Code to fix these problems was offered to the community.&lt;br /&gt;
So far it has been completely ignored.&lt;br /&gt;
&lt;br /&gt;
==== HSI instrument failure. ====&lt;br /&gt;
&lt;br /&gt;
If you use the &amp;quot;heading indicator&amp;quot; checkbox on the&lt;br /&gt;
&amp;quot;instrument failure&amp;quot; popup to command a failure,&lt;br /&gt;
it has no effect on the HSI instrument used by&lt;br /&gt;
many aircraft in the simulator fleet.&lt;br /&gt;
&lt;br /&gt;
This is because of wrong code in hsi.xml.  &lt;br /&gt;
&lt;br /&gt;
Backend code to handle this correctly exists, but has&lt;br /&gt;
apparently never been used.  It needs one small fix,&lt;br /&gt;
followed by recompilation.  A patchset to take care&lt;br /&gt;
of all this was offered to the community, but has&lt;br /&gt;
not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Flux gate not really a flux gate. ====&lt;br /&gt;
&lt;br /&gt;
In the Instrumentation director, there are three heading-related&lt;br /&gt;
.cxx files.&lt;br /&gt;
* heading_indicator.cxx : vacuum driven, with drift&lt;br /&gt;
* heading_indicator_dg.cxx : electrically driven, with drift&lt;br /&gt;
* heading_indicator_fg.cxx : electrically driven, no drift&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;fg&amp;quot; in &amp;quot;heading_indicator_fg&amp;quot; is documented to stand for&lt;br /&gt;
&amp;quot;flux gate&amp;quot;, as if the heading were slaved to a flux-gate&lt;br /&gt;
compass ... but the code does not implement any such thing.&lt;br /&gt;
All it really does is initialize the indicated heading to &lt;br /&gt;
the correct magnetic heading value, and then implement a &lt;br /&gt;
no-drift policy.  This is incorrect behavior, as can be&lt;br /&gt;
seen by flying to an area where the magnetic variation is&lt;br /&gt;
different from what it was at the start of the flight.  A&lt;br /&gt;
true slaved heading indicator would gradually accommodate&lt;br /&gt;
the new magvar.&lt;br /&gt;
&lt;br /&gt;
The correct behavior ought to be easy to implement.&lt;br /&gt;
&lt;br /&gt;
==== Weird noises during initialization. ====&lt;br /&gt;
&lt;br /&gt;
It is observed that sometimes while the simulator is starting&lt;br /&gt;
up, before things are fully operational, weird noises are&lt;br /&gt;
produced.  For example, in the c182rg, gear-in-transit&lt;br /&gt;
noises are produced for several seconds before the first&lt;br /&gt;
display becomes visible.  (According to a dump of the&lt;br /&gt;
relevant variables, there is no evidence that the gear is&lt;br /&gt;
actually in transit, and no reason why it should be.)&lt;br /&gt;
&lt;br /&gt;
Code to fix this was submitted.  So far it has been&lt;br /&gt;
ignored.&lt;br /&gt;
&lt;br /&gt;
==== Weird displays during fullscreen initialization. ====&lt;br /&gt;
&lt;br /&gt;
If the --enable-fullscreen command-line option is used, &lt;br /&gt;
the window is enlarged to full-screen size at a time&lt;br /&gt;
when initialization is only half-complete.  From this&lt;br /&gt;
time until the end of initialization, the display &lt;br /&gt;
contains weird combinations of leftover graphic objects&lt;br /&gt;
and other junk.&lt;br /&gt;
&lt;br /&gt;
This is observed no matter whether the splash-screen feature&lt;br /&gt;
is enabled or disabled.&lt;br /&gt;
&lt;br /&gt;
==== Fullscreen window sometimes misplaced. ====&lt;br /&gt;
&lt;br /&gt;
About 20% of the time, when the --enable-fullscreen command-line&lt;br /&gt;
option is used, it opens a window of the correct size, but &lt;br /&gt;
badly misplaced relative to the screen, such that only one half&lt;br /&gt;
or one quarter of the window is on-screen.&lt;br /&gt;
&lt;br /&gt;
==== Navigation databases out-of-date ====&lt;br /&gt;
&lt;br /&gt;
The database of navigation waypoints and fixes has an internal&lt;br /&gt;
date of early 2005.  It is missing quite a few useful fixes.  &lt;br /&gt;
The FAA has defined quite a few new approaches in recent years,&lt;br /&gt;
and has revised others.&lt;br /&gt;
&lt;br /&gt;
An updated version, based on a pull of the much more&lt;br /&gt;
current x-plane database, was made available.  So far&lt;br /&gt;
it has been ignored.&lt;br /&gt;
&lt;br /&gt;
Similar remarks apply to the ''navaids'' database.&lt;br /&gt;
&lt;br /&gt;
==== Ident from phantom DME. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, some VOR stations and even some localizers&lt;br /&gt;
have a colocated DME station ... but there are plenty that&lt;br /&gt;
don't.&lt;br /&gt;
&lt;br /&gt;
The DME has its own Morse ident, with a distinctive higher pitch.&lt;br /&gt;
&lt;br /&gt;
In the simulator, due to a bug in the code, all stations&lt;br /&gt;
transmit the DME Morse ident ... even stations where no&lt;br /&gt;
DME is present.&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx finds the nearest VOR or LOC on the&lt;br /&gt;
frequency, and checks to see if it is in range.  It also asks&lt;br /&gt;
for the &amp;quot;nearest&amp;quot; DME on the frequency, but makes no attempt&lt;br /&gt;
to check that it is in range.  To say the same thing the&lt;br /&gt;
other way, there is no attempt to check that the aircraft is&lt;br /&gt;
within the service volume of the DME.  Since there is almost always&lt;br /&gt;
a DME /somewhere/ on the frequency, the has_dme variable will&lt;br /&gt;
always be set true.&lt;br /&gt;
&lt;br /&gt;
For a demonstration of this bug, park at KAOO airport and &lt;br /&gt;
tune up the AOO VOR (which has no DME).  Or park at almost&lt;br /&gt;
any airport and tune up the localizer (since relatively few&lt;br /&gt;
localizers have DME).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Airport lighting in poor weather. ====&lt;br /&gt;
&lt;br /&gt;
The code in tileentry.cxx turns on airport lights according to&lt;br /&gt;
the position of the sun relative to the horizon.  One consequence&lt;br /&gt;
is that the lights are off during the day.&lt;br /&gt;
&lt;br /&gt;
In real life, there are many circumstances where airport lights,&lt;br /&gt;
including approach lights, are turned on during the day.  At tower airports, the lights are turned on during bad weather -- including weather that &lt;br /&gt;
is only slightly bad -- and also turned on if requested by the pilot.  For&lt;br /&gt;
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].&lt;br /&gt;
&lt;br /&gt;
At non-towered airports, the lights are usually pilot-controlled,&lt;br /&gt;
via radio.&lt;br /&gt;
&lt;br /&gt;
The absence of lighting during daytime in poor weather detracts &lt;br /&gt;
significantly from the realism, because it affects both the&lt;br /&gt;
legality and the practicality of performing instrument approaches&lt;br /&gt;
under such conditions.&lt;br /&gt;
&lt;br /&gt;
In version 0.9.10 runway lights are turned on automatically in day time if visibility is low.&lt;br /&gt;
Though I agree, that pilot controlled lights could be a nice feature, but it's not a bug, it's wish list entry, I suppose.&lt;br /&gt;
&lt;br /&gt;
==== Holes in the ground. ====&lt;br /&gt;
&lt;br /&gt;
Ever since the first win32-build of FG-OSG, there are at least two huge &lt;br /&gt;
ground scenery holes in the the Rhine/Main/Neckar-region in Germany. &lt;br /&gt;
The first one gapes at &lt;br /&gt;
the place which was formerly known as the city of Mannheim (near the &lt;br /&gt;
airport EDFM, which is still there), the second one has swallowed up a &lt;br /&gt;
big piece of Frankfurt am Main (near EDDF) and surrounding land. &lt;br /&gt;
&lt;br /&gt;
First posted to the flightgear-devel list in November, 2006.&lt;br /&gt;
&lt;br /&gt;
==== Mixture versus Altitude. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that at&lt;br /&gt;
high altitude airports (e.g. KGCN or KASE), to obtain max&lt;br /&gt;
static RPM, it suffices to move the mixture control only a&lt;br /&gt;
few mm aft of the full-forward (full-rich) position.&lt;br /&gt;
&lt;br /&gt;
This is unrealistic.  In a real aircraft under such conditions,&lt;br /&gt;
it would be necessary to pull the mixture control back about&lt;br /&gt;
an inch to obtain max RPM.&lt;br /&gt;
&lt;br /&gt;
It's hard to say whether the carburetor is underreacting to the&lt;br /&gt;
altitude, or overreacting to the mixture control.&lt;br /&gt;
&lt;br /&gt;
==== EGT reads high. ====&lt;br /&gt;
&lt;br /&gt;
It is observed in the default c172p and in the c182 that the&lt;br /&gt;
EGT reads toward the high end of the scale under all conditions,&lt;br /&gt;
including idle.  This is unrealistic.&lt;br /&gt;
&lt;br /&gt;
Also, the EGT reads ''off-scale'' high under high-power conditions.&lt;br /&gt;
&lt;br /&gt;
==== Flags missing from instruments. ====&lt;br /&gt;
&lt;br /&gt;
Some of the standard instruments lack status flags.  For example,&lt;br /&gt;
the GS needle goes to  mid-scale if there is no valid signal.  That'll kill you for sure.  Reportedly the hi-res instruments implement flags, but the lo-res ones don't.  Many aircraft are using the lo-res instruments.&lt;br /&gt;
&lt;br /&gt;
Either the aircraft should be upgraded to use instruments that&lt;br /&gt;
display flags, or the instruments should be upgraded to be&lt;br /&gt;
display flags.&lt;br /&gt;
&lt;br /&gt;
==== Problems with --model-hz option. ====&lt;br /&gt;
&lt;br /&gt;
Specifying the --model-hz=10 command-line option results in the&lt;br /&gt;
following mess:&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml&lt;br /&gt;
  Sorry, wdot doesn't appear to be trimmable&lt;br /&gt;
 Trim Failed&lt;br /&gt;
  Trim Results: &lt;br /&gt;
       Angle of Attack:   7.50  wdot:  3.21e+01 Tolerance: 1e-03  Failed&lt;br /&gt;
              Throttle:   0.50  udot:  0.00e+00 Tolerance: 1e-03  Passed&lt;br /&gt;
            Pitch Trim:   0.00  qdot: -5.44e-11 Tolerance: 1e-04  Passed&lt;br /&gt;
  Model Author:  Unknown&lt;br /&gt;
  Creation Date: 2002-01-01&lt;br /&gt;
  Description:   Cessna C-182RG&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 WWarning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
     [many repeats]&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 altitude         = 9&lt;br /&gt;
 sea level radius = 4.62829e-268&lt;br /&gt;
 latitude         = 1.52075e-314&lt;br /&gt;
 longitude        = -0.0967923&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: catching up on tile delete queue&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = -1.18461e-41&lt;br /&gt;
 sea level radius = -4.87596e-42&lt;br /&gt;
 latitude         = 6.98923e-316&lt;br /&gt;
 longitude        = 6.79738e-313&lt;br /&gt;
 Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)&lt;br /&gt;
         nan nan nan -inf inf -inf segment ignored..&lt;br /&gt;
 altitude         = nan&lt;br /&gt;
 sea level radius = nan&lt;br /&gt;
 latitude         = nan&lt;br /&gt;
 longitude        = nan&lt;br /&gt;
&lt;br /&gt;
and so forth.&lt;br /&gt;
&lt;br /&gt;
* Is this really that unexpected? 10 Hz is a extremely low update frequency for the FDM. The normal rate is 120 Hz.&lt;br /&gt;
&lt;br /&gt;
==== CPU hogging. ====&lt;br /&gt;
&lt;br /&gt;
The fsgs program will happily eat up &amp;gt;98% of the cpu cycles,&lt;br /&gt;
even when the simulator is paused.  That seems excessive,&lt;br /&gt;
particularly during pause.  This is on a 2GHz machine&lt;br /&gt;
with hardware acceleration.  As a point of reference, &lt;br /&gt;
glxgears uses only a fraction of one percent of the cpu.&lt;br /&gt;
&lt;br /&gt;
* This is an effect of the render-as-fast-as-you-can approach taken by FlightGear. Presumably the user still wants to be able to interact with the graphics when the simulator is paused. Activating sync to VBLANK might give the desired result  if the cpu is fast enough to have time over between the frames. (Since most of the work in glxgear is done by the GPU it can much easier saturate the GPU with little CPU effort than FlightGear can.)&lt;br /&gt;
&lt;br /&gt;
==== Out-of-bounds array reference in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the interpolation table code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Memory leak in JSBSim ====&lt;br /&gt;
&lt;br /&gt;
This is in the &amp;quot;message&amp;quot; handling code.&lt;br /&gt;
&lt;br /&gt;
This bug has been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim.&lt;br /&gt;
&lt;br /&gt;
==== Glideslope service volume. ====&lt;br /&gt;
&lt;br /&gt;
The code in navradio.cxx appears to assume the glideslope&lt;br /&gt;
service volume is the same as the localizer service&lt;br /&gt;
volume.  This is quite unrealistic.&lt;br /&gt;
&lt;br /&gt;
==== Extended service volume. ====&lt;br /&gt;
&lt;br /&gt;
In some parts of the world, a goodly fraction of the&lt;br /&gt;
localizers have an expanded service volume (ESV),&lt;br /&gt;
often quite a bit larger than the standard service&lt;br /&gt;
volume you see in the AIM.  The code in navradio.cxx&lt;br /&gt;
was ignoring the service volume information in the&lt;br /&gt;
database and wrongly assuming the default values&lt;br /&gt;
applied everywhere.  Code to fix the range-related&lt;br /&gt;
part of the problem has been offered&lt;br /&gt;
but not yet incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Other service volume issues. ====&lt;br /&gt;
&lt;br /&gt;
The code  in navradio.cxx has no understanding of how &lt;br /&gt;
'''azimuth''' affects the&lt;br /&gt;
localizer.  There is more to the story than reception range.&lt;br /&gt;
It is perfectly possible to be outside the LOC service volume &lt;br /&gt;
for reasons having to do with azimuth, not range.  &lt;br /&gt;
&lt;br /&gt;
Good ident will be heard, but false localizer courses will &lt;br /&gt;
cause serious trouble for the unwary pilot.&lt;br /&gt;
&lt;br /&gt;
A patch to fix this (along with the ESV issue) has been &lt;br /&gt;
offered, but ignored.&lt;br /&gt;
&lt;br /&gt;
There are also azimuthal issues with the /glideslope/&lt;br /&gt;
service volume.  This has not yet been patched.&lt;br /&gt;
&lt;br /&gt;
==== Menu buttons having a get-together. ====&lt;br /&gt;
&lt;br /&gt;
This concerns &amp;quot;radio buttons&amp;quot; on menus, such as on the &lt;br /&gt;
location-in-air popup and elsewhere.  By definition, it should be &lt;br /&gt;
impossible to have more than one radio button pushed down at a time.&lt;br /&gt;
However, illegal situations of this sort can be created&lt;br /&gt;
using a click-and-drag gesture.  Aim at&lt;br /&gt;
a radio button, hold the mouse-button down, and drag ...&lt;br /&gt;
as if you wanted to drag the radio button to a new location.&lt;br /&gt;
This allows you to set a radio button without the others&lt;br /&gt;
being unset.  If you persist, you can have every one of&lt;br /&gt;
the buttons in the pushed-down state at the same time.&lt;br /&gt;
&lt;br /&gt;
Before you say, &amp;quot;well, don't do that then&amp;quot; or &amp;quot;garbage in,&lt;br /&gt;
garbage out&amp;quot;, let me point out that it is possible for&lt;br /&gt;
a pilot to inadvertently make a tiny dragging gesture&lt;br /&gt;
when intending only a click.  Also, when the desired&lt;br /&gt;
button is in the pushed-down state, it is easy to not&lt;br /&gt;
notice that other buttons are in the undesired state.&lt;br /&gt;
&lt;br /&gt;
==== Altimeter setting unreadable. ====&lt;br /&gt;
&lt;br /&gt;
The standard altimeter (used by the default c172p aircraft&lt;br /&gt;
and many others) had been using an unhappy hodgepodge of&lt;br /&gt;
layers.  The analog Kollsman window was unusable, because&lt;br /&gt;
it was unlabeled, and the digital altimeter setting was&lt;br /&gt;
unusable, especially at altitudes near 2500 feet, partly &lt;br /&gt;
from being behind the needle.  On a real altimeter, things&lt;br /&gt;
are positioned so that cannot happen.&lt;br /&gt;
&lt;br /&gt;
Fixing this requires using a more suitable font, moving&lt;br /&gt;
the digits over, and getting rid of conflicting extraneous&lt;br /&gt;
markings.&lt;br /&gt;
&lt;br /&gt;
A patch to implement this fix has been offered.&lt;br /&gt;
&lt;br /&gt;
==== Memory mismanagement in subsystem_mgr. ====&lt;br /&gt;
&lt;br /&gt;
It is bad luck to apply &amp;quot;delete&amp;quot; to an object that was not&lt;br /&gt;
created with &amp;quot;new&amp;quot; ... as in line 219 of subsystem_mgr.cxx&lt;br /&gt;
&lt;br /&gt;
A patch is available, but has not been incorporated.&lt;br /&gt;
&lt;br /&gt;
==== Yet more memory mismanagement. ====&lt;br /&gt;
&lt;br /&gt;
When FG is trying to exit, it is very likely to abort&lt;br /&gt;
with a message such as&lt;br /&gt;
&lt;br /&gt;
  *** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***&lt;br /&gt;
&lt;br /&gt;
There are at least three different instances of this bug,&lt;br /&gt;
each producing a different traceback.  Here is one such&lt;br /&gt;
traceback:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
#0  0xb7573947 in raise () from /lib/tls/libc.so.6&lt;br /&gt;
#1  0xb75750c9 in abort () from /lib/tls/libc.so.6&lt;br /&gt;
#2  0xb75a908a in __libc_message () from /lib/tls/libc.so.6&lt;br /&gt;
#3  0xb75b094f in _int_free () from /lib/tls/libc.so.6&lt;br /&gt;
#4  0xb75b09f2 in free () from /lib/tls/libc.so.6&lt;br /&gt;
#5  0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6&lt;br /&gt;
#6  0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766&lt;br /&gt;
#7  0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#8  0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93&lt;br /&gt;
#9  0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105&lt;br /&gt;
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237&lt;br /&gt;
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6&lt;br /&gt;
#12 0x080919c7 in fgExit (status=0) at util.cxx:120&lt;br /&gt;
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Missing Features and Traps for the Unwary ==&lt;br /&gt;
&lt;br /&gt;
==== Version number, please. ====&lt;br /&gt;
&lt;br /&gt;
It would be helpful to have an easy, documented way to ascertain the&lt;br /&gt;
version number.  A --version option on the command line would be&lt;br /&gt;
nice.  Maybe also a help::about menu item, for use while fgfs is&lt;br /&gt;
already running.&lt;br /&gt;
&lt;br /&gt;
One could imagine that info about key libraries would also be&lt;br /&gt;
helpful.&lt;br /&gt;
&lt;br /&gt;
==== Rabbits extinct. ====&lt;br /&gt;
&lt;br /&gt;
In the real world, many airports have '''sequenced flashers''' &lt;br /&gt;
(aka the rabbit) as part of the approach-light system.&lt;br /&gt;
&lt;br /&gt;
In the FlightGear world, the sequenced flashers are inoperative&lt;br /&gt;
everywhere.  Grepping through the code suggests that no attempt&lt;br /&gt;
has been made to implement this.&lt;br /&gt;
&lt;br /&gt;
==== No comm volume control. ====&lt;br /&gt;
&lt;br /&gt;
In many aircraft including the default c172p, the comm&lt;br /&gt;
radios have no volume control knob.  In other aircraft&lt;br /&gt;
including the pa24-250, there is such a knob, but it&lt;br /&gt;
apparently isn't clickable and apparently doesn't do &lt;br /&gt;
anything.  &lt;br /&gt;
&lt;br /&gt;
In contrast, the SenecaII exemplifies the ''desired'' behavior: &lt;br /&gt;
the knob rotates when clicked and &lt;br /&gt;
correctly controls the /instrumentation/comm[N]/volume&lt;br /&gt;
property.  (This alas has no effect on the volume of ATIS&lt;br /&gt;
audio, but that must be considered an ATIS bug not a&lt;br /&gt;
Seneca bug.)&lt;br /&gt;
&lt;br /&gt;
==== Incomplete Scenery. ====&lt;br /&gt;
&lt;br /&gt;
Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ]  without installing the shared models, will get you messages such as the following:&lt;br /&gt;
&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/localizer.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml&lt;br /&gt;
  Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml&lt;br /&gt;
&lt;br /&gt;
You might get only a few such messages, or you might get &lt;br /&gt;
screenful after screenful.&lt;br /&gt;
&lt;br /&gt;
So, make sure you download all scenery files that are needed for fgfs.&lt;br /&gt;
&lt;br /&gt;
This obviously counts as a trap for the unwary.&lt;br /&gt;
&lt;br /&gt;
- This is patently not a bug and should be moved to a &amp;quot;tips&amp;quot; section or similar.  The need to download the shared models is clearly stated (in big, bold, capitals no less) on the fgfsdb download page in a central position...&lt;br /&gt;
&lt;br /&gt;
==== ASOS and AWOS are AWOL. ====&lt;br /&gt;
&lt;br /&gt;
At many non-tower airports (and even some tower airports) there&lt;br /&gt;
is automatic weather reporting of some kind.&lt;br /&gt;
&lt;br /&gt;
It ought to be straightforward to implement this, as a slight&lt;br /&gt;
variation on the existing ATIS feature.&lt;br /&gt;
&lt;br /&gt;
==== Roundoff problems with textranslate step and scroll. ====&lt;br /&gt;
&lt;br /&gt;
The textranslate animation is delightful for 3D animation&lt;br /&gt;
of mechanical drum-type displays as on old-fashioned&lt;br /&gt;
odometers and Hobbs meters.&lt;br /&gt;
&lt;br /&gt;
It is not, however, a convenient way to implement digital&lt;br /&gt;
readouts.  It works OK for integers, but the code in &lt;br /&gt;
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the &amp;quot;.1&amp;quot; in 122.1 MHz, particularly when the scroll-value is zero.&lt;br /&gt;
* One workaround is to stick to integers, e.g. integer kHz &lt;br /&gt;
rather than fractional MHz.&lt;br /&gt;
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.&lt;br /&gt;
* A final option (with CVS) is to use the bias tag to let the code know how to&lt;br /&gt;
handle round-off.  Use a bias value of 1/2 your smallest step value, and &lt;br /&gt;
use the same bias value on all digits.&lt;br /&gt;
&lt;br /&gt;
What we really need is a whole new support routine for dealing&lt;br /&gt;
with 3D digital displays, something at least as nice as the&lt;br /&gt;
support for 2D instruments.&lt;br /&gt;
&lt;br /&gt;
==== Broken startup banner. ====&lt;br /&gt;
&lt;br /&gt;
On startup, the simulator prints Author: Unknown and prints a bogus Date.&lt;br /&gt;
&lt;br /&gt;
The printout comes from JSBSim and refers to the (lack of) author, date and version fields in the JSBSim flight model XML file for the aircraft. According to the schema for JSBSim-ML (the markup language specification for JSBSim aircraft) the author, creation date, version, and description are not required fields, so the message that is printed out should account for missing elements.&lt;br /&gt;
&lt;br /&gt;
== Fixed Bugs ==&lt;br /&gt;
&lt;br /&gt;
If the fix refers to a version number that hasn't been released yet, it means that the fix is in CVS (this makes life easier maintaining the page - status doesn't have to be changed each release).&lt;br /&gt;
&lt;br /&gt;
==== Wild accelerations at low speeds. ====&lt;br /&gt;
&lt;br /&gt;
Improper inclinometer ball indications have been observed:&lt;br /&gt;
* When parked, the ball was pegged to one side.&lt;br /&gt;
* When taxiing at low speeds (a few knots or less) the ball oscillated wildly back and forth.&lt;br /&gt;
&lt;br /&gt;
This was observed in the c182 model and in the default c172 model.&lt;br /&gt;
&lt;br /&gt;
Tracing indicates that the problem is not within the slip_skid_ball.cxx&lt;br /&gt;
code, but rather upstream of there, in the flight dynamics.  Tracing&lt;br /&gt;
shows that the y-accel-fps_sec values are wildly fluctuating in&lt;br /&gt;
direction, and enormous in magnitude.&lt;br /&gt;
&lt;br /&gt;
Additional evidence pointing to the FDM comes from the fact that&lt;br /&gt;
the problem is observed with JSBSim and not with larcsim (although&lt;br /&gt;
larcsim has other problems, such as drifting slowly sideways while&lt;br /&gt;
parked).&lt;br /&gt;
&lt;br /&gt;
This is important from a procedures training point of view.  &lt;br /&gt;
If you want to have a realistic flight, one of the checklist items is to verify, insofar as possible, that the instruments give correct indications during preflight and taxi.  In a real aircraft, a pilot who found the &lt;br /&gt;
inclinometer pegged would cancel the flight before even starting&lt;br /&gt;
the engine.&lt;br /&gt;
&lt;br /&gt;
Note: This has probably been resolved in the latest release of JSBSim that is now incorporated into FlightGear. It may have stemmed from bad ground reactions modeling. Standalone tests with JSBSim and the C-172 sitting on the runway show the following properties steadily holding at zero:&lt;br /&gt;
&lt;br /&gt;
*velocities/vdot-fps&lt;br /&gt;
*velocities/a-pilot-y-ft sec2&lt;br /&gt;
*velocities/n-pilot-y-norm&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Misdirected diagnostic in JSBSim.cxx ====&lt;br /&gt;
&lt;br /&gt;
The file JSBSim.cxx directed the last four lines of a five-line diagnostic message to cout.  This made both the log and the console record hard to interpret.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====&lt;br /&gt;
&lt;br /&gt;
The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.&lt;br /&gt;
&lt;br /&gt;
Workround: Specify the latitude as a slight offset to what you require. Eg instad of --lon=16 make it --lon=16.0001 The difference visually is next to nothing. :-)&lt;br /&gt;
&lt;br /&gt;
* '''This bug has not been observed in 0.9.10.'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting &amp;quot;Could not gen source&amp;quot; ====&lt;br /&gt;
&lt;br /&gt;
Any further reports or stacktraces on this bug would be appreciated.&lt;br /&gt;
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.&lt;br /&gt;
Update your sound card drivers.&lt;br /&gt;
&lt;br /&gt;
* '''This bug has been fixed in 0.9.8a'''&lt;br /&gt;
&lt;br /&gt;
==== 0.9.7 - ? Linux - Joystick crash with correct config files ====&lt;br /&gt;
&lt;br /&gt;
Workround: Comment out any unused axes (and, possibly buttons) in the config file - if your joystick has 3 axes, comment out axes 4 through end.&lt;br /&gt;
&lt;br /&gt;
* ''' This bug has been fixed.'''&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
==== Individual Aircraft ====&lt;br /&gt;
&lt;br /&gt;
Bugs associated with a particular aircraft should be listed&lt;br /&gt;
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.&lt;br /&gt;
&lt;br /&gt;
==== OpenSceneGraph ====&lt;br /&gt;
&lt;br /&gt;
There is a separate page for issues related to [[OpenSceneGraph]].&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3546</id>
		<title>Talk:North American OV-10A Bronco</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3546"/>
		<updated>2007-06-13T20:20:23Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Dear authors of the OV-10A Bronco model, please, take the following things into account:&lt;br /&gt;
&lt;br /&gt;
- USAFE and NASA '''share the same paintjob''' and loadout (as I understand, there will be a new NASA version, when FlightGear 0.9.11 is released)&lt;br /&gt;
&lt;br /&gt;
- USAFE version is available as a '''separate download''', while it is included in the 3-version package at the same time, the separate download could be deleted, so that only the 3-version package is left&lt;br /&gt;
&lt;br /&gt;
- '''Landing gear''' is a bit higher, than the ground surface, it visually hangs in the air, when the airplane is standing on the ground (it is noticable when shadow is on), though the gap between the landing gear and the ground surface is very small&lt;br /&gt;
&lt;br /&gt;
- '''CDF version''' has no instruments and controls in its 3D-cockpit, the cockpit is a flat foto-texture (as I understand, CDF version will receive a 3D-cockpit, when FlightGear 0.9.11 is released)&lt;br /&gt;
&lt;br /&gt;
- '''Engines start-up/turn-off''' is not possible (only fuel flow can be cut), as I understand it will also change, when FlightGear 0.9.11 is released&lt;br /&gt;
&lt;br /&gt;
- '''Outside lights''' are present, but they can't be switched on/off and they actually don't light&lt;br /&gt;
&lt;br /&gt;
The above mentioned things correspond to '''v20060619''' of your model, that is available for download from the FlightGear official site.&lt;br /&gt;
&lt;br /&gt;
Apart from the small issues mentioned above, the model is great! It feels and looks complete in almost all aspects: good flight model, animated body (flaps, gear, ailerons, elevators, rudders), neat 3D-cockpit, nice sounds, working systems, lights etc. Many thanks for it. I fly it very often.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3545</id>
		<title>Talk:Antonov An-2</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3545"/>
		<updated>2007-06-13T15:41:40Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;I tryed the 0.2 version and would like to comment on some points:&lt;br /&gt;
&lt;br /&gt;
- I think the name of the airplane in the list should be not &amp;quot;Legendary Russian An-2&amp;quot;, but simply &amp;quot;Antonov An-2&amp;quot;, even though it is a legend actually (but Cessna c172 or P51D are also legendary)&lt;br /&gt;
&lt;br /&gt;
- 44mb unpacked seems too much, I think; maybe texture resolutions and sound quality could be degraded by half (other FG models don't exceed 10mb even with several versions and look and sound fine, check the OV-10A Bronco, for example)&lt;br /&gt;
&lt;br /&gt;
- may be this link [http://www.flightgear.ru/files/models/an2-0.2.tar.gz] should be placed here, in the wiki (for now it is available only at the Russian version of the FG site)&lt;br /&gt;
&lt;br /&gt;
- the pilot's eyes are situated too high and too close to the instrument panel, 3D-cockpit instruments are barely readable from this point of view&lt;br /&gt;
&lt;br /&gt;
- the engine alone sounds good, but when the speed rises, something is mixed up and the sound becomes strange&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Corrected introductory text from the bundled manual:&lt;br /&gt;
&lt;br /&gt;
'''Introduction'''&lt;br /&gt;
&lt;br /&gt;
This is the model of the legendary Russian An-2. Its first flight took place in 1947 and some aircraft are in service even today.&lt;br /&gt;
&lt;br /&gt;
The model was originally prepared for Microsoft Flight Simulator by Anton Nikolaev in 2005. It became a real hit ''(only commerical products can be bestsellers)'' in the Russian flightsim community.&lt;br /&gt;
&lt;br /&gt;
The FlightGear An-2 model was converted from the MSFS version through a specific procedure. FlightGear An-2 model is published under GPL with the author's permission ''(Anton Nikolaev?)''.&lt;br /&gt;
&lt;br /&gt;
Textures and sounds were taken without any conversion. 2D panel, 3D cockpit, original instruments, FDM, systems and some other things were converted to FlightGear by Yurik V. Nikiforoff in may 2006 - april 2007.&lt;br /&gt;
&lt;br /&gt;
8 liveries (paintjobs) included.&lt;br /&gt;
&lt;br /&gt;
This is version 0.2 of the model. It has a 3D cockpit and incorporates many improvements to systems, animation etc.&lt;br /&gt;
&lt;br /&gt;
You can see a photo of a real AN-2 here.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3544</id>
		<title>Talk:Antonov An-2</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3544"/>
		<updated>2007-06-13T14:56:44Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;I tryed the 0.2 version and would like to comment on some points:&lt;br /&gt;
&lt;br /&gt;
- I think the name of the airplane in the list should be not &amp;quot;Legendary Russian An-2&amp;quot;, but simply &amp;quot;Antonov An-2&amp;quot;, even though it is a legend actually&lt;br /&gt;
&lt;br /&gt;
- 44mb unpacked is too much, I think; maybe texture resolutions and sound quality should be degraded by half (other FG models don't exceed 10mb even with several versions and look and sound fine, check the OV-10A Bronco, for example)&lt;br /&gt;
&lt;br /&gt;
- may be this link [http://www.flightgear.ru/files/models/an2-0.2.tar.gz] should be placed here, in the wiki (for now it is available only at the Russian version of the FG site)&lt;br /&gt;
&lt;br /&gt;
- I will try flying it and check systems later and will try to provide more feedback&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Corrected introductory text from the bundled manual:&lt;br /&gt;
&lt;br /&gt;
'''Introduction'''&lt;br /&gt;
&lt;br /&gt;
This is the model of the legendary Russian An-2. Its first flight took place in 1947 and some aircraft are in service even today.&lt;br /&gt;
&lt;br /&gt;
The model was originally prepared for Microsoft Flight Simulator by Anton Nikolaev in 2005. It became a real hit ''(only commerical products can be bestsellers)'' in the Russian flightsim community.&lt;br /&gt;
&lt;br /&gt;
The FlightGear An-2 model was converted from the MSFS version through a specific procedure. FlightGear An-2 model is published under GPL with the author's permission ''(Anton Nikolaev?)''.&lt;br /&gt;
&lt;br /&gt;
Textures and sounds were taken without any conversion. 2D panel, 3D cockpit, original instruments, FDM, systems and some other things were converted to FlightGear by Yurik V. Nikiforoff in may 2006 - april 2007.&lt;br /&gt;
&lt;br /&gt;
8 liveries (paintjobs) included.&lt;br /&gt;
&lt;br /&gt;
This is version 0.2 of the model. It has a 3D cockpit and incorporates many improvements to systems, animation etc.&lt;br /&gt;
&lt;br /&gt;
You can see a photo of a real AN-2 here.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3543</id>
		<title>Talk:Antonov An-2</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3543"/>
		<updated>2007-06-13T10:17:23Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;I tryed the 0.2 version and would like to comment on some points:&lt;br /&gt;
&lt;br /&gt;
- I think the name of the airplane in the list should be not &amp;quot;Legendary Antonov An-2&amp;quot;, but simply &amp;quot;Antonov An-2&amp;quot;, even though it is a legend actually&lt;br /&gt;
&lt;br /&gt;
- 44mb unpacked is too much, I think; maybe texture resolutions and sound quality should be degraded by half (other FG models don't exceed 10mb even with several versions and look and sound fine, check the OV-10A Bronco, for example)&lt;br /&gt;
&lt;br /&gt;
- may be this link [http://www.flightgear.ru/files/models/an2-0.2.tar.gz] should be placed here, in the wiki (for now it is available only at the Russian version of the FG site)&lt;br /&gt;
&lt;br /&gt;
- I will try flying it and check systems later and will try to provide more feedback&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Corrected introductory text from the bundled manual:&lt;br /&gt;
&lt;br /&gt;
'''Introduction'''&lt;br /&gt;
&lt;br /&gt;
This is the model of the legendary Russian An-2. Its first flight took place in 1947 and some aircraft are in service even today.&lt;br /&gt;
&lt;br /&gt;
The model was originally prepared for Microsoft Flight Simulator by Anton Nikolaev in 2005. It became a real hit ''(only commerical products can be bestsellers)'' in the Russian flightsim community.&lt;br /&gt;
&lt;br /&gt;
The FlightGear An-2 model was converted from the MSFS version through a specific procedure. FlightGear An-2 model is published under GPL with the author's permission ''(Anton Nikolaev?)''.&lt;br /&gt;
&lt;br /&gt;
Textures and sounds were taken without any conversion. 2D panel, 3D cockpit, original instruments, FDM, systems and some other things were converted to FlightGear by Yurik V. Nikiforoff in may 2006 - april 2007.&lt;br /&gt;
&lt;br /&gt;
8 liveries (paintjobs) included.&lt;br /&gt;
&lt;br /&gt;
This is version 0.2 of the model. It has a 3D cockpit and incorporates many improvements to systems, animation etc.&lt;br /&gt;
&lt;br /&gt;
You can see a photo of a real AN-2 here.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3542</id>
		<title>Talk:Antonov An-2</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:Antonov_An-2&amp;diff=3542"/>
		<updated>2007-06-13T10:16:37Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;I tryed the 0.2 version and would like to comment on some points:&lt;br /&gt;
&lt;br /&gt;
- I think the name of the airplane in the list should be not &amp;quot;Legendary Antonov An-2&amp;quot;, but simply &amp;quot;Antonov An-2&amp;quot;, even though it is a legend actually&lt;br /&gt;
&lt;br /&gt;
- 44mb unpacked is too much, I think; maybe texture resolutions and sound quality should be degraded by half (other FG models don't exceed 10mb even with several versions and look and sound fine, check the OV-10A Bronco, for example)&lt;br /&gt;
&lt;br /&gt;
- may be this link [http://www.flightgear.ru/files/models/an2-0.2.tar.gz] should be placed here, in the wiki (for now it is available only at the Russian version of the FG site)&lt;br /&gt;
&lt;br /&gt;
- I will try flying it and check systems later and will try to provide more feedback&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Corrected introductory text from the bundled manual:&lt;br /&gt;
&lt;br /&gt;
'''Introduction'''&lt;br /&gt;
&lt;br /&gt;
This is the model of the legendary Russian An-2. Its first flight took place in 1947 and some aircraft are in service even today.&lt;br /&gt;
&lt;br /&gt;
The model was originally prepared for Microsoft Flight Simulator by Anton Nikolaev in 2005. It became a real hit ''(only commerical products can be bestsellers)'' in the Russian flightsim community.&lt;br /&gt;
&lt;br /&gt;
The FlightGear An-2 model was converted from the MSFS version through a specific procedure. FlightGear An-2 model is published under GPL with the author's permission ''(Anton Nikolaev?)''.&lt;br /&gt;
&lt;br /&gt;
Textures and sounds were taken without any conversion. 2D panel, 3D cockpit, original instruments, FDM, systems and some other things were converted to FlightGear by Yurik V. Nikiforoff in may 2006 - april 2007.&lt;br /&gt;
&lt;br /&gt;
8 liveries (paintjobs) included.&lt;br /&gt;
&lt;br /&gt;
This is version 0.2 of the model. It has a 3D cockpit and incorporates many improvements to systems, animation etc.&lt;br /&gt;
&lt;br /&gt;
You can see a photo of a real AN-2 you here.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3540</id>
		<title>Talk:North American OV-10A Bronco</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3540"/>
		<updated>2007-06-13T09:06:31Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Dear authors of the OV-10A model, please, take the following things into account:&lt;br /&gt;
&lt;br /&gt;
- OV-10A Bronco USAFE and NASA '''share the same paintjob''' and loadout, as I understand it will chnage together with the release of the 0.9.11 FlightGear&lt;br /&gt;
&lt;br /&gt;
- OV-10A Bronco USAFE is available for '''separate download''', while it is included in the 3-version package, I think, the separate download could be deleted, so that only the 3-version package is left&lt;br /&gt;
&lt;br /&gt;
- '''Landing gear''' is a bit higher, than the ground surface, it visually hangs in the air when the airplane is standing on the ground (it is noticable only when shadow is on), though the gap between the landing gear and the ground surface is small&lt;br /&gt;
&lt;br /&gt;
- '''CDF version''' has no instruments and controls in its 3D-cockpit, the cockpit is a flat foto-texture, I hope this will change in the next release, as it's quite difficult to control it without the instruments&lt;br /&gt;
&lt;br /&gt;
- '''Engines start-up/turn-off''' is not possible (only fuel flow can be cut), as I understand it will change together with the release of the 0.9.11 FlightGear&lt;br /&gt;
&lt;br /&gt;
- '''Outside lights''' are present, but they can't be switched on/off and they actually don't light&lt;br /&gt;
&lt;br /&gt;
The above mentioned things correspond to '''v20060619''' of your model, that is available for download from the FlightGear official site.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3539</id>
		<title>Talk:North American OV-10A Bronco</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Talk:North_American_OV-10A_Bronco&amp;diff=3539"/>
		<updated>2007-06-13T09:05:19Z</updated>

		<summary type="html">&lt;p&gt;Alfozavr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Dear authors of the OV-10A model, please, take the following things into account:&lt;br /&gt;
&lt;br /&gt;
- OV-10A Bronco USAFE and NASA share the same paintjob and loadout, as I understand it will chnage together with the release of the 0.9.11 FlightGear&lt;br /&gt;
&lt;br /&gt;
- OV-10A Bronco USAFE is available for separate download, while it is included in the 3-version package, I think, the separate download could be deleted, so that only the 3-version package is left&lt;br /&gt;
&lt;br /&gt;
- Landing gear is a bit higher, than the ground surface, it visually hangs in the air when the airplane is standing on the ground (it is noticable only when shadow is on), though the gap between the landing gear and the ground surface is small&lt;br /&gt;
&lt;br /&gt;
- CDF version has no instruments and controls in its 3D-cockpit, the cockpit is a flat foto-texture, I hope this will change in the next release, as it's quite difficult to control it without the instruments&lt;br /&gt;
&lt;br /&gt;
- Engines start-up/turn-off is not possible (only fuel flow can be cut), as I understand it will change together with the release of the 0.9.11 FlightGear&lt;br /&gt;
&lt;br /&gt;
- Outside lights are present, but they can't be switched on/off and they actually don't light&lt;br /&gt;
&lt;br /&gt;
The above mentioned things correspond to v20060619 of your model, that is available for download from the FlightGear official site.&lt;/div&gt;</summary>
		<author><name>Alfozavr</name></author>
	</entry>
</feed>