FlightGear wiki - User contributions [en]

Tactical Air Navigation

2009-10-31T16:47:37Z

Ajmacleod:

'''TACtical Air Navigation''', or '''TACAN''', is a navigation system used by [[:Category:Military aircraft|military aircraft]]. It provides the user with a distance and bearing from a ground station. It is a more accurate version of the [[VHF]] omnidirectional range / Distance Measuring Equipment (VOR/DME) system that provides range and bearing information for civil aviation. At VORTAC facilities, the DME portion of the TACAN system is available for civil use.

==Operation==
TACAN in general can be described as the military version of the VOR/DME system. It operates in the frequency band 960-1215 MHz. The bearing unit of TACAN is more accurate than a standard VOR since it makes use of a two frequency principle, with 15 Hz and 135 Hz components.

The distance measurement component of TACAN operates with the same specifications as do civil DMEs. Therefore to reduce the number of required stations, TACAN stations are frequently co-located with VOR facilities. These co-located stations are known as VORTACs. This is a station composed of a VOR for civil bearing information and a TACAN for military bearing information and military/civil distance measuring information. The TACAN transponder performs the function of a DME without the need for a separate, collocated DME. Because the rotation of the antenna creates a large portion of the azimuth signal, if the antenna fails, the azimuth component is no longer available and the TACAN downgrades to a DME only mode.

===FlightGear===
A few planes in FlightGear are equipped with TACAN. Here's a list of known aircraft with TACAN:

* [[Grumman A-6E|A-6E]]
* [[Fairchild A-10|A-10]]
* [[Douglas A4 Skyhawk|A4F]]
* [[Blackburn Buccaneer]]
* [[Grumman F-14 Tomcat]]
* [[English Electric Lightning|Lightning]]
* [[Northrop T-38|T38]]

To set TACAN, go to the <tt>Equipment > Radio Settings</tt> dialog. When using in-air refuel, first read [[Howto: Air-Air Refueling]].

[[Category:Aviation]]

Sopwith Camel

2008-11-11T19:05:23Z

Ajmacleod:

{{infobox Aircraft
|image =SopwithCamel.jpg
|name =Sopwith Camel
|type =Historical aircraft
|fdm = UIUC, YASim
|status =production
|authors =AJ MacLeod, Vivian Meazza, Michael Selig(UIUC FDM)
|fgname = <tt>sopwithCamel</tt> (alias for <tt>sopwithCamel-v1-nl-uiuc</tt>), <tt>sopwithCamel-YASim</tt>, <tt>sopwithCamel-v1-nl-uiuc</tt>
}}

{|
|__TOC__
|}

== Development status/Issues/Todo ==

== External links ==
== Related content ==
=== Related lists ===
* [[Aircraft]]
* [[Aircraft Todo]]
* [[FlightGear 1.0 default aircraft]]

[[Category:Aircraft]]
[[Category:Historical aircraft]]
[[Category:Aircraft TODO]]

Howto:Creating 3D instruments

2008-10-28T19:15:24Z

Ajmacleod: fix spelling that was originally correct...

This tutorial describes the basic process of '''creating''' a 3D '''instrument''' for use in [[FlightGear]]. For now, we're assuming that you have created the actual 3d model to use and wish to include it in a cockpit and animate it. As an example, we will be animating the ITT gauge for the [[Fokker 50]].

===What you need===
You will need:
* a text editor (even notepad will do, but one that does syntax highlighting might help you spot typos more easily; if you're on Windows, [http://notepad-plus.sourceforge.net/uk/site.htm Notepad++] looks suitable.)
* your 3d modelling package
* and of course a copy of FlightGear

===Creating the XML file===
The first step is to create an XML file which will load the 3D model and animate it. There are no hard and fast rules about where these files should live or what they must be called, but we'll follow the fairly standard procedure of calling it itt.xml and placing it in the Models directory.

So, using your favourite text editor, create a file called itt.xml in the Aircraft/fokker50/Models directory (folder).

It should start like this (and please remember that case is ALWAYS important);

<?xml version="1.0"?>
<PropertyList>
</PropertyList>

Everything you will add to this file '''must''' go between the <PropertyList> tags.

Now, our file does nothing useful at this point. First of all, we want to tell FG to load the 3d model of our instrument. Add a section under <PropertyList> like this;

<path>itt.ac</path>

This is obviously the name of the 3d model file we wish to load. The model in question looks like this:

[[Image:Fokker51_ITT_screenshot1.jpg]]

===Adding an animation===

As you can see, the main item to animate is the temperature needle, and its name is "needle" (you can animate either [[AC3D]] "objects" or complete "groups"). We will want to use a "rotate" animation (for more details on available animation types, see "model-howto.html" which is provided with FG in the Docs directory.)

So, we add an <animation> section to our XML file.

<pre>
<animation>
<type>rotate</type>
<object-name>needle</object-name>
</pre>

Now, we need to specify a property which will determine the amount of rotation required; in other words, the property that provides the ITT value at any one time. To find the name of this property, we need to start FlightGear in the usual manner with the correct aircraft (fokker50 in this case). Once FG has started, open the property browser (file/browse internal properties). You will see the top level of the property tree. Click on "engines" and you will see a list of engines; click on the first one (engine) and you will see a long list of properties and their current values.

[[Image:Fokker50_prop_browser_screenshot1.jpg]]

Now, we have a slight problem at this stage; the fokker50 was created before JSBSim could model turboprops, and so the ITT property is not available right now. For the purposes of this tutorial though, we'll just use the exhaust temperature instead; the process is what's important.

So, the next line in our XML file will specify the property to use;

<property>engines/engine/egt_degf</property>

Next we need to specify exactly how much that property moves the needle. There are several ways to do this, but we'll use a simple interpolation table since these are especially useful in more complicated situations. The ITT gauge is marked from 0 degC to 1200 degC; since we're having to use a value that's reported in degF for now, we'll just convert those two values. 0 degC is about 32 degF and 1200 degC is about 2192 degF. Two handy tips here; for Linux/unix users, the "units" program is truly invaluable; for everyone, google has a useful units converter; for example search for "
1200 degrees celsius in fahrenheit"

On to our table then.

<pre>
<interpolation>
<entry><ind>32</ind><dep>0</dep></entry>
<entry><ind>2192</ind><dep>230</dep></entry>
</interpolation>
</pre>

The <ind> entries are the ''ind''ependent variables, or values read from the property tree; the <dep> entries are the ''dep''endent variables, or corresponding degrees the object will be rotated by. In this case I found that number by rotating the needle in AC3D from one end of the scale to the other and reading off the rotation value reported (see screenshot)

[[Image:Fokker50_rotation_value.jpg]]

Having configured the type of animation, the controlling property, and specified the effect of that property, we need to describe an axis and centre for the animation.

In this case, the centre is easy, because the needle centre is at the origin of the 3d model. If you wanted the rotation centre to be somewhere else, you could use your modelling app to obtain these values.

<pre>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
</pre>

The axis is also very simple in this case;

<pre>
<axis>
<x>-1</x>
<y>0</y>
<z>0</z>
</axis>
</pre>

The negative sign on the x axis means that the rotation will be clockwise when viewed from the -x direction (i.e. looking "forwards")

That concludes the rotation animation and so (as always) we need to add a suitable closing tag;

<pre>
</animation>
</pre>

===Digital display===
Our itt.xml file, as it stands, should now "work" in flightgear; that is, it will animate the needle object to display exhaust temperature on the first engine, in degC (despite the input property being in degF!)

However, the bottom half of the gauge contains a digital readout of the same information, and we haven't mentioned that yet. In order to only introduce one new aspect at a time, for the moment I am going to ignore the fact that our input property is in degF and simply display it using the digits; there are several ways we could display degC (or indeed any kind of value) instead, but those are probably best left to another tutorial.

Now, in order to give the illusion of a digital display, we are going to use a slightly less obvious technique than the simple rotation used for the needle. Our digits are going to come from this texture, freshly borrowed from another model in FlightGear (remember, this is open source software - don't reinvent the wheel unless it's absolutely necessary!).

[[Image:digits.jpg]]

Now, each "digit" in the 3d model is a separate rectangle, and each is mapped to the number zero on that texture. What we are going to do is use a "textranslate" animation to slide the texture along to the relevant number in each case. Here's the code for the first digit;

<pre>

<animation>
<type>textranslate</type>
<object-name>digit1</object-name>
<property>engines/engine/egt_degf</property>
<factor>0.0001</factor>
<step>1000</step>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>
</pre>

As always, if you need more detailed explanations of any of these animations, remember to RTFM which in this case is the model-howto.html referred to previously.

Each subsequent digit is handled in the same way, though with the object-name, factor and step values modified accordingly.

For example, the next digit along, the "hundreds" digit;

<pre>
<animation>
<type>textranslate</type>
<object-name>digit2</object-name>
<property>engines/engine/egt_degf</property>
<factor>0.001</factor>
<step>100</step>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>
</pre>

And so on, for the remaining two. Now, your itt instrument should display the EGT in degC using the needle, and give a "digital" readout of the same in degF.

===Level Of Detail===
To prevent objects like this instrument being drawn when the aircraft is actually too far away for them to be seen anyway we use a Level Of Detail section (a "range" "animation".) Notice the <pre></pre> section; this is a comment, feel free to add them where you need a reminder of what's going on.

<pre>

<animation>
<type>range</type>
<min-m>0</min-m>
<max-m>30</max-m>
</animation>
</pre>

Now, if you've managed to stay with us the whole way through, the file should look something like this one, which you can download and compare with. [[Media:itt.xml]] Notice that under each new opening xml tag (such as <animation>) the text is indented one more level. Sensible people(!) use one tab to indent each level, others try to use various numbers of spaces to indent; whatever you use, the single most important thing is to be consistent. Consistent indentation makes the file much easier to read.

===Including the instrument in an aircraft===

Now to the exciting bit, actually seeing the fruits of our labour in FlightGear!
Including our itt.xml file in the fokker50 is actually an easy step. The "model" XML file controls the 3d model; this is often called aircraftname-model.xml and nearly always lives in the aircraftname/Models directory. However, FG is very flexible and in this case, the model XML file is fokker50/Models/fokker50.xml . To avoid confusion, it would be preferable for this to be called fokker50-model.xml, and if you're creating one from scratch, please use that convention.

If we open that file in a text editor, it should look quite familiar; you will recognise the way it specifies an ac3d file, and animates the various parts of it. However, we wish to include an instrument, and that is done very simply. Below the <offsets> section, add a section like this;

<pre>

<model>
<path>Aircraft/fokker50/Models/itt.xml</path>
<offsets>
<x-m>-8.9088</x-m>
<y-m>-0.0811</y-m>
<z-m>-1.0722</z-m>
<pitch-deg>-10</pitch-deg>
</offsets>
</model>
</pre>

Those numbers can be easily obtained from your 3d modelling app; just open the aircraft model and place an object in the correct position, then use the distances here. The usual FG model coordinate system is used; x=back, y=right, z=up, from the pilot's perspective; the origin is the one in the 3d model (.ac file). The "pitch" entry is fairly obvious; pitch of zero is a completely vertical instrument, pitch of -90 is one tilted "top edge forwards" to lie flat.

Now, when you start FlightGear, you should see your fully-working instrument in all its glory, situated where it ought to be! If you need to move it later, it's trivial to tweak the numbers above to suit.

[[Category:Aircraft enhancement]]
[[Category:Modeling]]

Blackburn Buccaneer

2008-10-07T17:03:03Z

Ajmacleod: /* External links */

{{stub}}

{{infobox Aircraft
|image =
|name =Blackburn Buccaneer
|type = Low level tactical strike aircraft
|authors =Vivian Meazza, AJ MacLeod
|fdm = YASim
|status =alpha v.01
|download =
}}

Blackburn Buccaneer, a low level tactical tactical strike aircraft

buccaneer-obs: Blackburn Buccaneer S2(Observer)
buccaneer: Blackburn Buccaneer S2(YASim)
buccaneer-wingman: Blackburn Buccaneer S2(Wingman)

=== See also ===
*[[Table of models]]

== External links ==
*http://www.flightgear.org/Downloads/aircraft/
*http://en.wikipedia.org/wiki/Blackburn_Buccaneer

[[Category:Aircraft]]
[[Category:Aircraft TODO]]

Blackburn Buccaneer

2008-10-07T17:01:12Z

Ajmacleod:

Howto:Reload sound configuration without restarting

2008-08-27T21:40:57Z

Ajmacleod:

As a massive timesaver for those working on sound configuration files, the following piece of nasal code can be entered in the nasal console (found on the Debug menu.)

<code>fgcommand("reinit", props.Node.new({ subsystem: "fx" }))</code>

Every time that line is executed, the sound subsystem ("fx") is restarted and the config file reloaded, enabling you to test your changes instantly. Just remember to actually save your sound config file each time you want to test so that FG sees the most recent changes.

[[Category:Howto|Reload_sound_config_without_restarting_FG]]

Howto:Reload sound configuration without restarting

2008-08-27T21:40:36Z

Ajmacleod: Howto: reload sound config without restarting FG moved to Howto: Reload sound config without restarting FG: capitalisation

Howto:Reload sound configuration without restarting

2008-08-27T21:39:57Z

Ajmacleod:

Howto:Reload sound configuration without restarting

2008-08-27T21:27:42Z

Ajmacleod: New page: As a massive timesaver for those working on sound configuration files, the following piece of nasal code can be entered in the nasal console (found on the Debug menu.) <code>fgcommand("re...

Howto:Aerial refueling

2008-08-18T14:28:16Z

Ajmacleod: /* What's possible */

== What's possible ==
At present, there are two tanker [[aircraft]] ([[Boeing KC-135E|KC135-E]] and KA6-D) and several receiving aircraft ([[Douglas A4 Skyhawk|A4F]], [[Grumman A-6E|A-6E]], [[Fairchild A-10|A-10]], [[Grumman F-14 Tomcat|F-14 Tomcat]], [[English Electric Lightning|Lightning]] and [[Northrop T-38|T38]]) capable of in-air refuelling. When flying one of these aircraft in the default scenery area, one can locate the tanker aircraft using air-air [http://en.wikipedia.org/wiki/TACAN TACAN (Wikipedia link)] and/or radar and then receive a full or partial load of fuel by flying in close formation behind the tanker. Refuelling is also possible between aircraft in a [[Howto: Multiplayer|Multiplayer]] session. The KC135 is a boom refueller, while the KA6 has a hose. The A4F and Lightning are both fitted with a probe for hose refuelling while the T38 is fitted with a boom receiver. At the moment, either type can refuel from any tanker, but in the future it is likely that the correct type will have to be used (this has been implemented in CVS).

== Necessary preparations ==
Like the aircraft carriers, AAR is implemented as an "AI scenario". Selecting these normally requires editing the "preferences.xml" file in the flightgear data directory.

There is a shortcut in this case though; simply selecting the Lightning, A4F or T38 should automatically load a scenario containing a tanker, assuming you haven't changed anything in your preferences.xml file.

Assuming this is the case, choose one of the aforementioned aircraft, make sure that "AI models" are enabled and start at [[KSFO]] (the default airport.)

Depending on the scenario, you might see the tanker crossing overhead when the sim starts; if not, don't worry.

== In the cockpit ==
Perhaps the first thing to do after starting the engines if necessary is to select the appropriate TACAN channel if your aircraft is so equipped (the A4F and Lightning both are). For the KC135 (by default used by the Lightning and T38) this is currently "040X", and for the KA6D (used by the A4F) it is "050X". Enter this channel using the relevant dropdown boxes in the "radios" dialogue (from the menus, "equipment/radios" or press control-r).

You should now see the current bearing to the tanker indicated in the nav display of the A4 or the TACAN indicator (green needle) in the Lightning. If the tanker is within range, it will also appear on the radar display of the T38 or Lightning. Take off...

== In the Air ==
Turn to an appropriate heading, guided by the TACAN bearing (you should try a "leading" approach to close in on the tanker) and look for the tanker on the radar or nav. screen. Around 5nm away, you should reduce your speed to around 20kts faster than the tanker (these fly at 280 kts TAS) - a "slow overtake". The KC135 will be visible from about 10nm, the KA6-D, being smaller, just over 1 nm. You should use airbrakes as necessary to keep control of your speed should you find yourself overshooting.

[[Image:KC-135E.jpg|thumb|270px|The KC-135E aircraft with the boom.]]
Close to within 50ft of the tanker (don't get too close, or visual artifacts might hide the boom from view). You should see indication in the cockpit that you are receiving fuel - there is a green light in the A4 fuel gauge, and you should see the indicated tank load increase.

Getting to this stage is not necessarily easy - it can take a lot of practice. As with carrier landings, this is not an easy manoeuver in real life either and there are additional complications in the sim; the tanker, being an AI model, is unaffected by the wind and flies TAS (True Air Speed), while you are flying IAS (Indicated Air Speed) and are affected by the environment. As in real life, your aircraft will also steadily increase in weight as the tanks fill which will affect the trim of the aircraft. (You might find it helpful to use the autothrottle to help control your speed - ctrl-s then Page Up/Down to increase and decrease the set speed.)

Once your tanks are full, or you have taken as much fuel as you wish, close the throttle a little, back away from the tanker and continue your intended flight.

== More advanced topics ==

=== Multiplayer Refuelling ===

Refuelling is possible within a MultiPlayer session given certain conditions. A basic flyable KC135 model is available - the pilot of this aircraft should use the callsign "MOBIL1", "MOBIL2" or "MOBIL3". Other numbers are acceptable, but only these three have A-A TACAN channels assigned. These are 060X, 061X and 062X respectively.

If the receiving aircraft uses a YASim FDM, there are no further complications. Should the receiving aircraft be JSBSim based, the user must make sure that there are no AI tankers in their configuration. This means disabling (commenting out) all refuelling "scenarios" in the relevant aircraft-set.xml and in preferences.xml.

MP refuelling works in exactly the same way as AI refuelling and is a fun challenge. It is best to ensure that your network connection is as free from interruptions as possible; the MP code does a degree of prediction if there is a "blip" in the stream of packets and this can make close formation flight very difficult or even impossible.

=== Selecting Different Scenarios ===

There are several AAR scenarios available in the AI directory. refueling_demo.xml has a KC135 circling near KSFO at 3000ft; refueling_demo_1.xml the KC135 on a North/South towline at 8000ft and refueling_demo_2.xml the KA6D on a similar N/S path but at 8500ft.

These can be selected by several methods; using the --ai-scenario command line option, or by editing preferences.xml.

==== Command line method ====

Add the --ai-scenario option to your usual flightgear command line; e.g. <code>fgfs --aircraft=lightning --ai-scenario=refueling_demo_2</code>

==== Preferences.xml method ====
Use your operating system's search facility to locate this if you don't know where it is). Open preferences.xml in a text editor (e.g. notepad if on windows) and search for the <ai> </ai> tags. Place a line like <code><scenario>refueling_demo</scenario></code> somewhere within the <ai> tags; you should see other scenarios already there too, perhaps commented out : i.e. with <! -- -->

[[Category:Howto|Air-Air Refueling]]

Soaring

2008-07-21T22:14:02Z

Ajmacleod:

FlightGear now has several glider models and winch, AI aerotow or MP aerotow launching methods (in addition to the normal "in-air start" method.)

== Winch Launches ==

Winch launches are currently available with the Bocian and ASK21. With the Bocian, it's possible to click in the scenery on a point where you would like to place a winch; with both, you can use control-w to place a winch directly in front of the glider. Press w to start the launch (in the ASK you need to hold it down) and, once at the top of the tow, release the cable with W.

== Aerotows ==

For aerotows, two types are possible - AI or human pilot (via multiplayer). To get an AI aerotow, select either the ASK or Bocian, choose KRHV as your airport and select the KRHV_towing_demo in the "Scenario" list box in FGRUN (the "Flightgear Wizard".) You should see a J3 Cub wobble its way towards you from a nearby taxiway, and pause close to your aircraft. Press control-o to hook on to it, and hold tight... the O key releases the cable.

For a multiplayer aerotow, you obviously need to arrange a tow with a human pilot - full instructions are available here: [[Doing_aerotow_over_the_net]]

Other gliders available for FG which use the JSBSim (notably the sgs233) or UIUC FDMs are not yet capable of winch or aerotow launches. Code to facilitate this has been added to JSBSim since the 1.0 release and it is hoped that JSBSim gliders should be compatible with ground launches in the next release. In the meantime, for such gliders it is necessary to start in the air - the sgs233 does so automatically.

== Thermals and Sinks ==

Thermals and sinks are modeled, but they must be defined individually in a thermal scenario file. To see how this is done it would be best to examine the file called data/AI/thermal_demo.xml, which sets up 11 thermals and 6 sinks around San Francisco Bay. To learn more about AI scenarios in general, see the related article called [[AI Systems]]. Note that the thermals and sinks exist independently of FlightGear's weather system, so it's possible to have cloud layers that don't match your thermal heights. To prevent this you may want to manually set the cloud layers to match your thermals. Thermal cap clouds are available since about one month ''after'' 0.9.10 was released. If you are using 0.9.10 or earlier you can make cap clouds work by a) fetching the cap cloud model from CVS, and b) adding a <z-m> offset to the cap cloud wrapper file to put the cloud at the right altitude.

== Extra Soaring Locations ==

A very nice piece of add-on scenery for gliding in the Menden (EDLA) area is available [http://home.arcor.de/vollnhals-bremen/Arnsberg/Arnsberg.html], including the required AI scenario file containing thermals for that area.

If you want to discover the Austrian alpine region, you might want to read [[Pinzgauer Spaziergang]].

== Logging your flights ==

If you log on to a multiplayer server while soaring, then your flight will be recorded at the FGTracker site, like this: [http://fgfs.i-net.hu/modules/fgtracker/?FUNCT=FLIGHT&FLIGHTID=1305&PHPSESSID=b3f9752f0f47468b0df49303e806c288], which makes flight review a snap.

== Learn the theory ==

For those wishing to gain a more in-depth knowledge of correct glider operation, the [http://www.faa.gov/library/manuals/aircraft/glider_handbook/ FAA glider handbook] makes good reading.

Howto:Do aerotow over the net

2008-01-07T21:37:43Z

Ajmacleod:

With FlightGear 1.0 and later, you can practice aerotowing over the net using the multiplayer system. At this time, only two towplanes and two gliders are capable of participating in MP aerotows. These are the J3 (j3cub), the Beaver (dhc2W) towplanes and the ASK21 and Bocian gliders. The following example uses the J3 and the Bocian, though if you are new to aerotowing use the Beaver; it's much easier due to tow with.

[[Image:aerotow2.jpg]]

Taxi the J3 within 60m to the Bocian. The Bocian pilot has to press Ctrl-o. Both pilots should see a radio message that they are connected to each other, then the J3 pilot can taxi. Until we have the instrumentation designed that is capable of displaying the distance between the two aircraft, the J3 pilot should watch /sim/hitches/aerotow/tow/dist and /sim/hitches/aerotow/tow/dist-time-lag-corrected in the property browser. Be very slow if the dist gets near 60m, the length of the tow. Increase the speed slowly. Both pilots should try to lift off gently - the glider pilot should be particularly careful not to lift the tail of the towplane. Either pilot can release the tow by pressing "O" (Shift-o).

[[Image:aerotow.jpg]]

If you are not using a local network connection, both pilots should log in on the same server to minimize the time lag. The time lag will still rather large. Therefore /sim/hitches/aerotow/tow/dist and /sim/hitches/aerotow/tow/dist-time-lag-corrected differ significantly (the second value is the estimated dist, the other pilot is seeing right now).

Howto:Do aerotow over the net

2008-01-07T21:37:07Z

Ajmacleod: Update version details, other minor edits

With FlightGear 1.0 and later, you can now practice aerotowing over the net (using the multiplayer system). At this time, only two motor-aircraft and two gliders are capable of participating in MP aerotows. These are the J3 (j3cub), the Beaver (dhc2W) towplanes and the ASK21 and Bocian gliders. The following example uses the J3 and the Bocian, though if you are new to aerotowing use the Beaver; it's much easier due to tow with.

[[Image:aerotow2.jpg]]

Taxi the J3 within 60m to the Bocian. The Bocian pilot has to press Ctrl-o. Both pilots should see a radio message that they are connected to each other, then the J3 pilot can taxi. Until we have the instrumentation designed that is capable of displaying the distance between the two aircraft, the J3 pilot should watch /sim/hitches/aerotow/tow/dist and /sim/hitches/aerotow/tow/dist-time-lag-corrected in the property browser. Be very slow if the dist gets near 60m, the length of the tow. Increase the speed slowly. Both pilots should try to lift off gently - the glider pilot should be particularly careful not to lift the tail of the towplane. Either pilot can release the tow by pressing "O" (Shift-o).

[[Image:aerotow.jpg]]

If you are not using a local network connection, both pilots should log in on the same server to minimize the time lag. The time lag will still rather large. Therefore /sim/hitches/aerotow/tow/dist and /sim/hitches/aerotow/tow/dist-time-lag-corrected differ significantly (the second value is the estimated dist, the other pilot is seeing right now).

2007-08-22T13:47:34Z

Ajmacleod:

File:Nasal console.jpg

2007-08-22T13:38:46Z

Ajmacleod: Nasal Console

Nasal Console

Howto:Write simple scripts in Nasal

2007-08-22T10:32:43Z

Ajmacleod:

Howto:Write simple scripts in Nasal

2007-08-22T10:27:19Z

Ajmacleod:

Howto:Write simple scripts in Nasal

2007-08-22T10:14:08Z

Ajmacleod: begin the tutorial

Main Page

2007-08-22T09:58:35Z

Ajmacleod:

__NOTOC__
__NOEDITSECTION__
'''FlightGear''' Flight Simulator project is an open-source, multi-platform, cooperative flight simulator development project. Source code for the entire project is available ([http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=FlightGear-0.9#dirlist CVS repository]) and licensed under the [http://www.gnu.org/copyleft/gpl.html GNU General Public License].

The goal of the '''FlightGear''' project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in [[Volunteer|contributing]].

There are many exciting possibilities for an open, free flight sim. We hope that this project will be interesting and useful to many people in many areas.

'''FlightGear''' comes with a set of illustrated documentation, notably
"The Manual", which is available as
[ftp://ftp.de.flightgear.org/pub/fgfs/Docs/getstart.pdf PDF] and
[http://www.flightgear.org/Docs/getstart/getstart.html HTML]. If you
prefer to follow the 'bleeding edge' set of FlightGear instructions,
then the following articles are likely to make you happy. You will
notice that parts of this Wiki duplicate information that's already
present in "The Manual".

{|cellspacing="10"
| width="50%"|
== User Documentation ==

=== Getting Started ===
* [[ New to FlightGear ]]
* [[ Why FlightGear ]]
* [[ Features ]]
* [[ FAQ ]]
* [[ Hardware Recommendations ]]
* [[ Recommended Software ]]
* [[ Troubleshooting Problems ]]
* [[ Volunteer ]]
* [[ Real Life Experience ]]

=== Configuring Flightgear ===
* [[ Command Line Parameters ]]
* [[ Installing Scenery ]]
* [[ Improving Framerates ]]
* [[ Multiplayer Howto ]]
* [[ Linux software audio mixing with FlightGear ]]

=== Using Flightgear ===
* [[Aircraft]]
* [[ Suggested Flights ]]
* [[ Starting in the Air ]]
* [[ Instant Replay ]]
* [[ Preset Properties ]]
* [[ Realism ]]
* [[ Flying the Helicopter ]]
* [[ Doing aerotow over the net ]]

=== Interactive Scenarios ===
* [[ Carrier Howto ]]
* [[ Air-Air Refueling Howto ]]
* [[ AI Systems ]]
* [[ Interactive Traffic ]]
* [[ Soaring ]]

=== Flying Resources ===
* [[ Definitions Acronyms ]]
* [[ Getting IFR Charts ]]
* [[ Understanding Altitude ]]
* [[ Understanding Navigation ]]
* [[ Understanding Propeller Torque and P-Factor ]]
* [[ Understanding Aerodynamics ]]
* [[ Communications ]]
* [[ Weather ]]
* [[ Avionics and Instruments ]]
* [http://www.wingfiles.com/ Everything you need ]
* [http://www.faa.gov/library/manuals/ FAA Handbooks & Manuals]

| width="50%" valign="top" |
== Developer Documentation ==

=== Compiling ===
* [[ Building Flightgear ]]
* [[ Building Terragear ]]
* [[ OpenSceneGraph ]]
* [[ Building FlightGear Launch Control ]]

=== Contributing ===
* [[ Submitting Patches ]]
* [[ Code Cleanup ]]
* [[ Development Resources ]]
* [[ Extension Support ]]
* [[ Technical Reports ]]
* [[ Changes since 0.9.10 ]]

=== Code Internals ===
* [[ Property Tree ]]
* [[ Subsystems ]]
* [[ Commands ]]
* [[ FDM API ]]
* [[ Nasal scripting language ]]
* [[ File Formats ]]

=== Modeling ===
* [[ Modeling - Getting Started ]]
* [[ Model Import and Export ]]
* [[ Modeling Resources ]]
* [[ Autopilot Tuning Resources ]]
* [[ Aircraft Information Resources ]]
* [[ Blender Ground Signs Tutorial]]
* [[ Normals and Transparency Tutorial ]]
* [[ Creating instruments for FG ]]
* [[ Writing simple scripts in "nasal" ]]

=== Todo ===
* [[ Long Term Goals ]]
* [[ Bugs ]]
* [[ FGFS Todo ]]
* [[:Category:Aircraft TODO]]
* [[ Feature Requests / Proposals / Ideas ]]
* [[ FlightGear Expo Checklist ]]

=== Miscellaneous ===
* [[ Glass Cockpit Projects ]]
* [[ Tutorial Resources ]]
* [[ Copyright Inquiry ]]
* [http://www.cafepress.com/fgfs_gear FlightGear - Gear]
* [[Resources]]
* [[ Sign Specification Proposal ]]
|}

Howto:Creating 3D instruments

2007-07-18T21:50:15Z

Ajmacleod:

'''Introduction:'''
This tutorial describes the basic process of creating a 3d instrument for use in FlightGear. For now, we're assuming that you have created the actual 3d model to use and wish to include it in a cockpit and animate it. As an example, we will be animating the ITT gauge for the Fokker 50.

'''What you need:'''
You will need; a text editor (even notepad will do, but one that does syntax highlighting might help you spot typos more easily; if you're on Windows, [http://notepad-plus.sourceforge.net/uk/site.htm Notepad++] looks suitable.)

You will also need your 3d modelling package, and of course a copy of FlightGear.

'''Creating the XML file:'''
The first step is to create an XML file which will load the 3d model and animate it. There are no hard and fast rules about where these files should live or what they must be called, but we'll follow the fairly standard procedure of calling it itt.xml and placing it in the Models directory.

So, using your favourite text editor, create a file called itt.xml in the Aircraft/fokker50/Models directory (folder).

It should start like this (and please remember that case is ALWAYS important);

<?xml version="1.0"?>
<PropertyList>
</PropertyList>

Everything you will add to this file '''must''' go between the <PropertyList> tags.

Now, our file does nothing useful at this point. First of all, we want to tell FG to load the 3d model of our instrument. Add a section under <PropertyList> like this;

<path>itt.ac</path>

This is obviously the name of the 3d model file we wish to load. The model in question looks like this:

[[Image:Fokker51_ITT_screenshot1.jpg]]

'''Adding an animation:'''

As you can see, the main item to animate is the temperature needle, and its name is "needle" (you can animate either ac3d "objects" or complete "groups"). We will want to use a "rotate" animation (for more details on available animation types, see "model-howto.html" which is provided with FG in the Docs directory.)

So, we add an <animation> section to our XML file.

<pre>
<animation>
<type>rotate</type>
<object-name>needle</object-name>
</pre>

Now, we need to specify a property which will determine the amount of rotation required; in other words, the property that provides the ITT value at any one time. To find the name of this property, we need to start FlightGear in the usual manner with the correct aircraft (fokker50 in this case). Once FG has started, open the property browser (file/browse internal properties). You will see the top level of the property tree. Click on "engines" and you will see a list of engines; click on the first one (engine) and you will see a long list of properties and their current values.

[[Image:Fokker50_prop_browser_screenshot1.jpg]]

Now, we have a slight problem at this stage; the fokker50 was created before JSBSim could model turboprops, and so the ITT property is not available right now. For the purposes of this tutorial though, we'll just use the exhaust temperature instead; the process is what's important.

So, the next line in our XML file will specify the property to use;

<property>engines/engine/egt_degf</property>

Next we need to specify exactly how much that property moves the needle. There are several ways to do this, but we'll use a simple interpolation table since these are especially useful in more complicated situations. The ITT gauge is marked from 0 degC to 1200 degC; since we're having to use a value that's reported in degF for now, we'll just convert those two values. 0 degC is about 32 degF and 1200 degC is about 2192 degF. Two handy tips here; for Linux/unix users, the "units" program is truly invaluable; for everyone, google has a useful units converter; for example search for "
1200 degrees celsius in fahrenheit"

On to our table then.

<pre>
<interpolation>
<entry><ind>32</ind><dep>0</dep></entry>
<entry><ind>2192</ind><dep>230</dep></entry>
</interpolation>
</pre>

The <ind> entries are what's indicated on the gauge; the <dep> entries determine how many degrees the object will be rotated by. In this case I found that number by rotating the needle in AC3D from one end of the scale to the other and reading off the rotation value reported (see screenshot)

[[Image:Fokker50_rotation_value.jpg]]

Having configured the type of animation, the controlling property, and specified the effect of that property, we need to describe an axis and centre for the animation.

In this case, the centre is easy, because the needle centre is at the origin of the 3d model. If you wanted the rotation centre to be somewhere else, you could use your modelling app to obtain these values.

<pre>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
</pre>

The axis is also very simple in this case;

<pre>
<axis>
<x>-1</x>
<y>0</y>
<z>0</z>
</axis>
</pre>

The negative sign on the x axis means that the rotation will be clockwise when viewed from the -x direction (i.e. looking "forwards")

That concludes the rotation animation and so (as always) we need to add a suitable closing tag;

<pre>
</animation>
</pre>

'''Digital display:'''
Our itt.xml file, as it stands, should now "work" in flightgear; that is, it will animate the needle object to display exhaust temperature on the first engine, in degC (despite the input property being in degF!)

However, the bottom half of the gauge contains a digital readout of the same information, and we haven't mentioned that yet. In order to only introduce one new aspect at a time, for the moment I am going to ignore the fact that our input property is in degF and simply display it using the digits; there are several ways we could display degC (or indeed any kind of value) instead, but those are probably best left to another tutorial.

Now, in order to give the illusion of a digital display, we are going to use a slightly less obvious technique than the simple rotation used for the needle. Our digits are going to come from this texture, freshly borrowed from another model in FlightGear (remember, this is open source software - don't reinvent the wheel unless it's absolutely necessary!).

[[Image:digits.jpg]]

Now, each "digit" in the 3d model is a separate rectangle, and each is mapped to the number zero on that texture. What we are going to do is use a "textranslate" animation to slide the texture along to the relevant number in each case. Here's the code for the first digit;

<pre>

<animation>
<type>textranslate</type>
<object-name>digit1</object-name>
<property>engines/engine/egt_degf</property>
<factor>0.0001</factor>
<step>1000</step>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>
</pre>

As always, if you need more detailed explanations of any of these animations, remember to RTFM which in this case is the model-howto.html referred to previously.

Each subsequent digit is handled in the same way, though with the object-name, factor and step values modified accordingly.

For example, the next digit along, the "hundreds" digit;

<pre>
<animation>
<type>textranslate</type>
<object-name>digit2</object-name>
<property>engines/engine/egt_degf</property>
<factor>0.001</factor>
<step>100</step>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>
</pre>

And so on, for the remaining two. Now, your itt instrument should display the EGT in degC using the needle, and give a "digital" readout of the same in degF.

'''Level Of Detail:'''
To prevent objects like this instrument being drawn when the aircraft is actually too far away for them to be seen anyway we use a Level Of Detail section (a "range" "animation".) Notice the <pre></pre> section; this is a comment, feel free to add them where you need a reminder of what's going on.

<pre>

<animation>
<type>range</type>
<min-m>0</min-m>
<max-m>30</max-m>
</animation>
</pre>

Now, if you've managed to stay with us the whole way through, the file should look something like this one, which you can download and compare with. [[Media:itt.xml]] Notice that under each new opening xml tag (such as <animation>) the text is indented one more level. Sensible people(!) use one tab to indent each level, others try to use various numbers of spaces to indent; whatever you use, the single most important thing is to be consistent. Consistent indentation makes the file much easier to read.

'''Including the instrument in an aircraft:'''

Now to the exciting bit, actually seeing the fruits of our labour in FlightGear!
Including our itt.xml file in the fokker50 is actually an easy step. The "model" XML file controls the 3d model; this is often called aircraftname-model.xml and nearly always lives in the aircraftname/Models directory. However, FG is very flexible and in this case, the model XML file is fokker50/Models/fokker50.xml . To avoid confusion, it would be preferable for this to be called fokker50-model.xml, and if you're creating one from scratch, please use that convention.

If we open that file in a text editor, it should look quite familiar; you will recognise the way it specifies an ac3d file, and animates the various parts of it. However, we wish to include an instrument, and that is done very simply. Below the <offsets> section, add a section like this;

<pre>

<model>
<path>Aircraft/fokker50/Models/itt.xml</path>
<offsets>
<x-m>-8.9088</x-m>
<y-m>-0.0811</y-m>
<z-m>-1.0722</z-m>
<pitch-deg>-10</pitch-deg>
</offsets>
</model>
</pre>

Those numbers can be easily obtained from your 3d modelling app; just open the aircraft model and place an object in the correct position, then use the distances here. The usual FG model coordinate system is used; x=back, y=right, z=up, from the pilot's perspective; the origin is the one in the 3d model (.ac file). The "pitch" entry is fairly obvious; pitch of zero is a completely vertical instrument, pitch of -90 is one tilted "top edge forwards" to lie flat.

Now, when you start flightgear, you should see your fully-working instrument in all its glory, situated where it ought to be! If you need to move it later, it's trivial to tweak the numbers above to suit.

Howto:Creating 3D instruments

2007-07-18T21:49:08Z

Ajmacleod: add how to include instrument into aircraft

'''Introduction:'''
This tutorial describes the basic process of creating a 3d instrument for use in FlightGear. For now, we're assuming that you have created the actual 3d model to use and wish to include it in a cockpit and animate it. As an example, we will be animating the ITT gauge for the Fokker 50.

'''What you need:'''
You will need; a text editor (even notepad will do, but one that does syntax highlighting might help you spot typos more easily; if you're on Windows, [http://notepad-plus.sourceforge.net/uk/site.htm Notepad++] looks suitable.)

You will also need your 3d modelling package, and of course a copy of FlightGear.

'''Creating the XML file:'''
The first step is to create an XML file which will load the 3d model and animate it. There are no hard and fast rules about where these files should live or what they must be called, but we'll follow the fairly standard procedure of calling it itt.xml and placing it in the Models directory.

So, using your favourite text editor, create a file called itt.xml in the Aircraft/fokker50/Models directory (folder).

It should start like this (and please remember that case is ALWAYS important);

<?xml version="1.0"?>
<PropertyList>
</PropertyList>

Everything you will add to this file '''must''' go between the <PropertyList> tags.

Now, our file does nothing useful at this point. First of all, we want to tell FG to load the 3d model of our instrument. Add a section under <PropertyList> like this;

<path>itt.ac</path>

This is obviously the name of the 3d model file we wish to load. The model in question looks like this:

[[Image:Fokker51_ITT_screenshot1.jpg]]

'''Adding an animation:'''

As you can see, the main item to animate is the temperature needle, and its name is "needle" (you can animate either ac3d "objects" or complete "groups"). We will want to use a "rotate" animation (for more details on available animation types, see "model-howto.html" which is provided with FG in the Docs directory.)

So, we add an <animation> section to our XML file.

<pre>
<animation>
<type>rotate</type>
<object-name>needle</object-name>
</pre>

Now, we need to specify a property which will determine the amount of rotation required; in other words, the property that provides the ITT value at any one time. To find the name of this property, we need to start FlightGear in the usual manner with the correct aircraft (fokker50 in this case). Once FG has started, open the property browser (file/browse internal properties). You will see the top level of the property tree. Click on "engines" and you will see a list of engines; click on the first one (engine) and you will see a long list of properties and their current values.

[[Image:Fokker50_prop_browser_screenshot1.jpg]]

Now, we have a slight problem at this stage; the fokker50 was created before JSBSim could model turboprops, and so the ITT property is not available right now. For the purposes of this tutorial though, we'll just use the exhaust temperature instead; the process is what's important.

So, the next line in our XML file will specify the property to use;

<property>engines/engine/egt_degf</property>

Next we need to specify exactly how much that property moves the needle. There are several ways to do this, but we'll use a simple interpolation table since these are especially useful in more complicated situations. The ITT gauge is marked from 0 degC to 1200 degC; since we're having to use a value that's reported in degF for now, we'll just convert those two values. 0 degC is about 32 degF and 1200 degC is about 2192 degF. Two handy tips here; for Linux/unix users, the "units" program is truly invaluable; for everyone, google has a useful units converter; for example search for "
1200 degrees celsius in fahrenheit"

On to our table then.

<pre>
<interpolation>
<entry><ind>32</ind><dep>0</dep></entry>
<entry><ind>2192</ind><dep>230</dep></entry>
</interpolation>
</pre>

The <ind> entries are what's indicated on the gauge; the <dep> entries determine how many degrees the object will be rotated by. In this case I found that number by rotating the needle in AC3D from one end of the scale to the other and reading off the rotation value reported (see screenshot)

[[Image:Fokker50_rotation_value.jpg]]

Having configured the type of animation, the controlling property, and specified the effect of that property, we need to describe an axis and centre for the animation.

In this case, the centre is easy, because the needle centre is at the origin of the 3d model. If you wanted the rotation centre to be somewhere else, you could use your modelling app to obtain these values.

<pre>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
</pre>

The axis is also very simple in this case;

<pre>
<axis>
<x>-1</x>
<y>0</y>
<z>0</z>
</axis>
</pre>

The negative sign on the x axis means that the rotation will be clockwise when viewed from the -x direction (i.e. looking "forwards")

That concludes the rotation animation and so (as always) we need to add a suitable closing tag;

<pre>
</animation>
</pre>

'''Digital display:'''
Our itt.xml file, as it stands, should now "work" in flightgear; that is, it will animate the needle object to display exhaust temperature on the first engine, in degC (despite the input property being in degF!)

However, the bottom half of the gauge contains a digital readout of the same information, and we haven't mentioned that yet. In order to only introduce one new aspect at a time, for the moment I am going to ignore the fact that our input property is in degF and simply display it using the digits; there are several ways we could display degC (or indeed any kind of value) instead, but those are probably best left to another tutorial.

Now, in order to give the illusion of a digital display, we are going to use a slightly less obvious technique than the simple rotation used for the needle. Our digits are going to come from this texture, freshly borrowed from another model in FlightGear (remember, this is open source software - don't reinvent the wheel unless it's absolutely necessary!).

[[Image:digits.jpg]]

Now, each "digit" in the 3d model is a separate rectangle, and each is mapped to the number zero on that texture. What we are going to do is use a "textranslate" animation to slide the texture along to the relevant number in each case. Here's the code for the first digit;

<pre>

<animation>
<type>textranslate</type>
<object-name>digit1</object-name>
<property>engines/engine/egt_degf</property>
<factor>0.0001</factor>
<step>1000</step>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>
</pre>

As always, if you need more detailed explanations of any of these animations, remember to RTFM which in this case is the model-howto.html referred to previously.

Each subsequent digit is handled in the same way, though with the object-name, factor and step values modified accordingly.

For example, the next digit along, the "hundreds" digit;

<pre>
<animation>
<type>textranslate</type>
<object-name>digit2</object-name>
<property>engines/engine/egt_degf</property>
<factor>0.001</factor>
<step>100</step>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>
</pre>

And so on, for the remaining two. Now, your itt instrument should display the EGT in degC using the needle, and give a "digital" readout of the same in degF.

'''Level Of Detail:'''
To prevent objects like this instrument being drawn when the aircraft is actually too far away for them to be seen anyway we use a Level Of Detail section (a "range" "animation".) Notice the <pre></pre> section; this is a comment, feel free to add them where you need a reminder of what's going on.

<pre>

<animation>
<type>range</type>
<min-m>0</min-m>
<max-m>30</max-m>
</animation>
</pre>

Now, if you've managed to stay with us the whole way through, the file should look something like this one, which you can download and compare with. [[Media:itt.xml]] Notice that under each new opening xml tag (such as <animation>) the text is indented one more level. Sensible people(!) use one tab to indent each level, others try to use various numbers of spaces to indent; whatever you use, the single most important thing is to be consistent. Consistent indentation makes the file much easier to read.

'''Including the instrument in an aircraft:'''

Now to the exciting bit, actually seeing the fruits of our labour in FlightGear!
Including our itt.xml file in the fokker50 is actually an easy step. The "model" XML file controls the 3d model; this is often called aircraftname-model.xml and nearly always lives in the aircraftname/Models directory. However, FG is very flexible and in this case, the model XML file is fokker50/Models/fokker50.xml . To avoid confusion, it would be preferable for this to be called fokker50-model.xml, and if you're creating one from scratch, please use that convention.

If we open that file in a text editor, it should look quite familiar; you will recognise the way it specifies an ac3d file, and animates the various parts of it. However, we wish to include an instrument, and that is done very simply. Below the <offsets> section, add a section like this;

<pre>

<model>
<offsets>
<x-m>-8.9088</x-m>
<y-m>-0.0811</y-m>
<z-m>-1.0722</z-m>
<pitch-deg>-10</pitch-deg>
</offsets>
</model>
</pre>

Those numbers can be easily obtained from your 3d modelling app; just open the aircraft model and place an object in the correct position, then use the distances here. The usual FG model coordinate system is used; x=back, y=right, z=up, from the pilot's perspective; the origin is the one in the 3d model (.ac file). The "pitch" entry is fairly obvious; pitch of zero is a completely vertical instrument, pitch of -90 is one tilted "top edge forwards" to lie flat.

Now, when you start flightgear, you should see your fully-working instrument in all its glory, situated where it ought to be! If you need to move it later, it's trivial to tweak the numbers above to suit.

Sopwith Camel

2007-07-10T18:31:15Z

Ajmacleod: /* Development status/Issues/Todo */

Alias for sopwithCamel-v1-nl-uiuc sopwithCamel-v1-nl-uiuc

== Development status/Issues/Todo ==

== External links ==
== Related content ==
=== Related lists ===
* [[Aircraft]]
* [[Aircraft Todo]]

[[Category:Aircraft]]
[[Category:Civilian aircraft]]
[[Category:Aircraft TODO]]

2007-07-04T11:57:52Z

Ajmacleod: Property Browser open at engines/engine

Property Browser open at engines/engine

File:Fokker51 ITT screenshot1.jpg

2007-07-04T11:38:58Z

Ajmacleod: ITT Screenshot 1 showing overview of model in AC3D

ITT Screenshot 1 showing overview of model in AC3D

Main Page

2007-07-04T11:10:11Z

Ajmacleod:

__NOTOC__
__NOEDITSECTION__
'''FlightGear''' Flight Simulator project is an open-source, multi-platform, cooperative flight simulator development project. Source code for the entire project is available ([http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=FlightGear-0.9#dirlist CVS repository]) and licensed under the [http://www.gnu.org/copyleft/gpl.html GNU General Public License].

The goal of the '''FlightGear''' project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in [[Volunteer|contributing]].

There are many exciting possibilities for an open, free flight sim. We hope that this project will be interesting and useful to many people in many areas.

'''FlightGear''' comes with a set of illustrated documentation, notably
"The Manual", which is available as
[ftp://ftp.de.flightgear.org/pub/fgfs/Docs/getstart.pdf PDF] and
[http://www.flightgear.org/Docs/getstart/getstart.html HTML]. If you
prefer to follow the 'bleeding edge' set of FlightGear instructions,
then the following articles are likely to make you happy. You will
notice that parts of this Wiki duplicate information that's already
present in "The Manual".

{|cellspacing="10"
| width="50%"|
== User Documentation ==

=== Getting Started ===
* [[ New to FlightGear ]]
* [[ Why FlightGear ]]
* [[ Features ]]
* [[ FAQ ]]
* [[ Hardware Recommendations ]]
* [[ Recommended Software ]]
* [[ Troubleshooting Problems ]]
* [[ Volunteer ]]
* [[ Real Life Experience ]]

=== Configuring Flightgear ===
* [[ Command Line Parameters ]]
* [[ Installing Scenery ]]
* [[ Improving Framerates ]]
* [[ Multiplayer Howto ]]
* [[ Linux software audio mixing with FlightGear ]]

=== Using Flightgear ===
* [[Aircraft]]
* [[ Suggested Flights ]]
* [[ Starting in the Air ]]
* [[ Instant Replay ]]
* [[ Preset Properties ]]
* [[ Realism ]]
* [[ Flying the Helicopter ]]
* [[ Doing aerotow over the net ]]

=== Interactive Scenarios ===
* [[ Carrier Howto ]]
* [[ Air-Air Refueling Howto ]]
* [[ AI Systems ]]
* [[ Interactive Traffic ]]
* [[ Soaring ]]

=== Flying Resources ===
* [[ Definitions Acronyms ]]
* [[ Getting IFR Charts ]]
* [[ Understanding Altitude ]]
* [[ Understanding Navigation ]]
* [[ Understanding Propeller Torque and P-Factor ]]
* [[ Understanding Aerodynamics ]]
* [[ Communications ]]
* [[ Weather ]]
* [[ Avionics and Instruments ]]
* [http://www.wingfiles.com/ Everything you need ]
* [http://www.faa.gov/library/manuals/ FAA Handbooks & Manuals]

| width="50%" valign="top" |
== Developer Documentation ==

=== Compiling ===
* [[ Building Flightgear ]]
* [[ Building Terragear ]]
* [[ OpenSceneGraph ]]
* [[ Building FlightGear Launch Control ]]

=== Contributing ===
* [[ Submitting Patches ]]
* [[ Code Cleanup ]]
* [[ Development Resources ]]
* [[ Extension Support ]]
* [[ Technical Reports ]]
* [[ Changes since 0.9.10 ]]

=== Code Internals ===
* [[ Property Tree ]]
* [[ Subsystems ]]
* [[ Commands ]]
* [[ FDM API ]]
* [[ Nasal scripting language ]]
* [[ File Formats ]]

=== Modeling ===
* [[ Modeling - Getting Started ]]
* [[ Model Import and Export ]]
* [[ Modeling Resources ]]
* [[ Autopilot Tuning Resources ]]
* [[ Aircraft Information Resources ]]
* [[ Blender Ground Signs Tutorial]]
* [[ Normals and Transparency Tutorial ]]
* [[ Creating instruments for FG ]]

=== Todo ===
* [[ Long Term Goals ]]
* [[ Bugs ]]
* [[ FGFS Todo ]]
* [[:Category:Aircraft TODO]]
* [[ Feature Requests / Proposals / Ideas ]]
* [[ FlightGear Expo Checklist ]]

=== Miscellaneous ===
* [[ Glass Cockpit Projects ]]
* [[ Tutorial Resources ]]
* [[ Copyright Inquiry ]]
* [http://www.cafepress.com/fgfs_gear FlightGear - Gear]
* [[Resources]]
* [[ Sign Specification Proposal ]]
|}

Bugs

2007-03-01T19:33:40Z

Ajmacleod: /* Incomplete Scenery. */

== Known Bugs ==

This section contains known and recorded bugs. It makes no claim to be a complete list, or even to be particularly accurate.

==== Incorrect altimetry. ====

There is evidently at least one serious misconception in the
code that calculates atmospheric pressure, altimeter settings,
et cetera. This can be easily demonstrated:

Park at or near the threshold of runway 33 at Aspen (KASE).
Under standard conditions, observe that the altimeter reads
7820 feet MSL, as it should.

Use the Weather : Weather Conditions dialog popup to
look at the ground-level altimeter setting (QNH).
This is bottom row in the "Alt (inHg)" column of the popup.
Verify that it is 29.92.

Now use the dialog box to change this property. Change it
to 30.92, a one-inch difference.

Go to your altimeter instrument and enter the new altimeter
setting in the Kollsman window. Ideally, this '''should'''
cause the instrument to read the correct altitude once
again, namely 7820 feet MSL.

However, due to bugs, it is likely that you will observe
something closer to 8120. This means the airplane is 300
feet lower than the altimeter says it is.

In case it wasn't obvious, when flying around near Aspen,
being 300 feet lower than you think you are can be very
bad for your health.

The absolutely correct formulas for computing the altimeter
setting are derived and explained on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

A patch to fix the altimeter has been offered.

==== Altimetry misnomers and misconceptions. ====

Both the Weather Conditions popup and the atis.cxx code
rely on the "pressure-sea-level-inhg" property and use
it in ways that the altimeter setting should be used.

For some people this may be merely a misnomer, but for
others it is clearly a misconception, as recent events
have shown.

The fact is, the altimeter setting is '''not''' the same
thing as the pressure at sea level (Psl), especially when
the airmass has a non-standard temperature profile.
The altimeter setting is something
else; it is properly called the altimeter setting. It
is also properly called the QNH, although private pilots
who fly only in the US may be unfamiliar with the QNH
terminology.

In the Remarks section of a METAR, you can sometimes
find the ''Reduced'' Sea Level Pressure, which is
unfortunately denoted SLP. This METAR SLP serves
the same function as the altimeter setting. Despite
its name, the METAR SLP is not equal to the honest-to-goodness
pressure at honest-to-goodness sea level (Psl), as
discussed in more detail on
[http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

There needs to be a facility whereby routines that need
the altimeter setting can obtain the altimeter setting.

Correct altimetry formulas may be found on the [http://www.av8n.com/physics/altimetry.htm jsd altimetry page].

Existing code sometimes treads the "pressure-sea-level-inhg"
property as if it were Psl, and sometimes as if it were
METAR SLP. All this needs to be vetted.

==== Newton's laws violated by environment.cxx ====

Consider the following results of an experiment using fgfs:

alt: 662 mM: 0.0288 P: 99000.8462 T: 286.8563 rho: 1.1975
alt: 3462 mM: 0.0288 P: 89341.6721 T: 281.3920 rho: 1.1009

alt: 662 mM: 0.0289 P: 99000.8422 T: 256.9910 rho: 1.3404
alt: 3462 mM: 0.0289 P: 89341.6740 T: 252.0956 rho: 1.2333

The first pair of lines represent before and after a simple
flight from one airport to another, with a net gain in altitude of
2800 feet, under standard conditions. So far so good.

The second pair of lines represent exactly the same flight,
except that the ambient temperature was 30 degrees colder
than before. You can see that the density (rho) is greater,
in accordance with the ideal gas law.

The problem is that the delta_P is exactly the same for the two
flights. This is a problem because P is connected to the weight
of the air column. If the air is 12% denser, the laws of physics
require it to have a 12% steeper pressure gradient dP/dh ... but
alas this is not observed.

This incorrect pressure profile P(h) has many consequences affecting
engine performance, airfoil performance, altimetry, et cetera.

==== Z-buffer burn-through. ====

Sometimes distant objects can be seen through nearer objects that
are not supposed to be transparent. For example: Runway lights
sometimes burn through a solid cloud layer. Also runway lights
sometimes burn through aircraft structure. Some instruments
burn through the yoke.

It seems that so-called "2D" objects in the
background are likely to burn through "3D" objects in the
foreground. This is particularly noticeable in aircraft
that have a mixture of 2D and 3D instruments.

The ''position'' in space of the offending objects is OK, as
you can verify by shifting your PoV to get a little bit of
a side view. The obvious hypothesis is that the Z-order
is being mishandled in a Z-buffer somewhere.

==== Memory leak. ====

The simulator will gobble up about 3 gigabytes
of virtual memory overnight, while paused.
Without the
leak, the memory footprint would be less than 300 meg. The
difference between 300 meg and 3 gig is quite
significant on machines that have only 1 or 2 gig
of main memory.

A rather steady leak of 2 meg per minute is observed
during pause, no matter whether the aircraft is aloft
or parked on the ground. '''Vastly less leakage''' (two
orders of magnitude less, possibly zero) is observed
when the simulator is not paused, and the aircraft
is simply sitting on the ground with the parking
brake set.

This bug has been observed in multiple versions of fgfs,
including one compiled back in May, 2006 as well as
the most current CVS version.

This is 100% reproducible with a
ATI RV350 [Mobility Radeon 9600 M10] chipset
and the ati-fglrx driver.
The leak is observed whether or not
OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set.

==== Numerous bugs in ATIS feature. ====

1) The ATIS is supposed to change whenever there is a
significant change in the weather. The comments mention
this, but the code makes no attempt to implement this.

2) The code assumes that ATIS is prepared on the hour.
In practice this is virtually never the case; a new
ATIS is prepared hourly, but not on the hour. Also
this assumption is inconsistent with ATIS changes
based on the weather.

3) The code attempts to issue a station identifier, but
none is heard.

4) Multiple departures from standard phraseology.

5) The volume is too low; ATIS is not readable over engine noise.
This defeats much of the purpose of ATIS. The volume does
not respond to the /instrumentation/comm[N]/volume property.

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.

x) Et cetera.

A patch to fix a few dozen ATIS bugs is available, but has not been
incorporated into FG CVS.

==== Problems with --altitude option. ====

When the aircraft is initialzed aloft using the
command-line --altitude=6000
option, 0.9.10 is observed to put up a blank screen
(no scenery, no panel) and to spew on the console
page after page like this:

Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan 2.7093e+06 4.27332e+06 -3.87316e+06 segment ignored..
altitude = -1.69132e-41
sea level radius = -6.54575e-42
latitude = 6.9874e-316
longitude = 6.79737e-313
OpenAL error (AL_INVALID_VALUE): set_pitch
OpenAL error (AL_INVALID_VALUE): set_volume

==== Multiple bugs in the location-in-air popup. ====

The location-in-air popup turns off the magnetos and extends
the landing gear. Some pilots and flight instructors
deem this to be undesirable behavior, especially if all
they are trying to do is relocate from one airborne position to
another.

Similarly, it strongly perturbs the throttle setting,
aileron trim, elevator trim, rudder trim,
view angles, PoV position, and who-knows-what else.
Again, people who know about airplanes consider this to
be undesirable behavior.

There is also a tendency to place the aircraft into
dangerous unusual attitudes, and other bugs too numerous
to mention.

Evidently, though, there is at least one person who likes
things the way they are. Code that would have fixed these
bugs was rejected. Neither specific nor constructive criticism
of the code was offered. For details see the flightgear-devel
mailing list archives.

==== Nearest fix. ====

Did you know that there are 8 different BRAVO intersections
in the database?

Until now there was no support in the code for this; all but
one of the entries was thrown away at the lowest level. There
is a comment in the code saying that fixing this is on the
TODO list.

As for navaids (as opposed to waypoints), the low-level code
already provides support for ambiguous IDs, but the information
is not being used very wisely by the higher layers.

Code to fix these problems was offered to the community.
So far it has been completely ignored.

==== HSI instrument failure. ====

If you use the "heading indicator" checkbox on the
"instrument failure" popup to command a failure,
it has no effect on the HSI instrument used by
many aircraft in the simulator fleet.

This is because of wrong code in hsi.xml.

Backend code to handle this correctly exists, but has
apparently never been used. It needs one small fix,
followed by recompilation. A patchset to take care
of all this was offered to the community, but has
not been incorporated.

==== Flux gate not really a flux gate. ====

In the Instrumentation director, there are three heading-related
.cxx files.
* heading_indicator.cxx : vacuum driven, with drift
* heading_indicator_dg.cxx : electrically driven, with drift
* heading_indicator_fg.cxx : electrically driven, no drift

The "fg" in "heading_indicator_fg" is documented to stand for
"flux gate", as if the heading were slaved to a flux-gate
compass ... but the code does not implement any such thing.
All it really does is initialize the indicated heading to
the correct magnetic heading value, and then implement a
no-drift policy. This is incorrect behavior, as can be
seen by flying to an area where the magnetic variation is
different from what it was at the start of the flight. A
true slaved heading indicator would gradually accommodate
the new magvar.

The correct behavior ought to be easy to implement.

==== Weird noises during initialization. ====

It is observed that sometimes while the simulator is starting
up, before things are fully operational, weird noises are
produced. For example, in the c182rg, gear-in-transit
noises are produced for several seconds before the first
display becomes visible. (According to a dump of the
relevant variables, there is no evidence that the gear is
actually in transit, and no reason why it should be.)

Code to fix this was submitted. So far it has been
ignored.

==== Weird displays during fullscreen initialization. ====

If the --enable-fullscreen command-line option is used,
the window is enlarged to full-screen size at a time
when initialization is only half-complete. From this
time until the end of initialization, the display
contains weird combinations of leftover graphic objects
and other junk.

This is observed no matter whether the splash-screen feature
is enabled or disabled.

==== Fullscreen window sometimes misplaced. ====

About 20% of the time, when the --enable-fullscreen command-line
option is used, it opens a window of the correct size, but
badly misplaced relative to the screen, such that only one half
or one quarter of the window is on-screen.

==== Navigation databases out-of-date ====

The database of navigation waypoints and fixes has an internal
date of early 2005. It is missing quite a few useful fixes.
The FAA has defined quite a few new approaches in recent years,
and has revised others.

An updated version, based on a pull of the much more
current x-plane database, was made available. So far
it has been ignored.

Similar remarks apply to the ''navaids'' database.

==== Ident from phantom DME. ====

In the real world, some VOR stations and even some localizers
have a colocated DME station ... but there are plenty that
don't.

The DME has its own Morse ident, with a distinctive higher pitch.

In the simulator, due to a bug in the code, all stations
transmit the DME Morse ident ... even stations where no
DME is present.

The code in navradio.cxx finds the nearest VOR or LOC on the
frequency, and checks to see if it is in range. It also asks
for the "nearest" DME on the frequency, but makes no attempt
to check that it is in range. To say the same thing the
other way, there is no attempt to check that the aircraft is
within the service volume of the DME. Since there is almost always
a DME /somewhere/ on the frequency, the has_dme variable will
always be set true.

For a demonstration of this bug, park at KAOO airport and
tune up the AOO VOR (which has no DME). Or park at almost
any airport and tune up the localizer (since relatively few
localizers have DME).

==== Wild accelerations at low speeds. ====

Improper inclinometer ball indications have been observed:
-- When parked, the ball was pegged to one side.
-- When taxiing at low speeds (a few knots or less) the ball
oscillated wildly back and forth.

This was observed in the c182 model and in the default c172 model.

Tracing indicates that the problem is not within the slip_skid_ball.cxx
code, but rather upstream of there, in the flight dynamics. Tracing
shows that the y-accel-fps_sec values are wildly fluctuating in
direction, and enormous in magnitude.

Additional evidence pointing to the FDM comes from the fact that
the problem is observed with JSBSim and not with larcsim (although
larcsim has other problems, such as drifting slowly sideways while
parked).

This is important from a procedures training point of view.
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
inclinometer pegged would cancel the flight before even starting
the engine.

==== Airport lighting in poor weather. ====

The code in tileentry.cxx turns on airport lights according to
the position of the sun relative to the horizon. One consequence
is that the lights are off during the day.

In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower airports, the lights are turned on during bad weather -- including weather that
is only slightly bad -- and also turned on if requested by the pilot. For
details, see [[http://www.faa.gov/ATPUBS/ATC/ATC.pdf FAA Order 7110.65p]].

At non-towered airports, the lights are usually pilot-controlled,
via radio.

The absence of lighting during daytime in poor weather detracts
significantly from the realism, because it affects both the
legality and the practicality of performing instrument approaches
under such conditions.

==== Holes in the ground. ====

Ever since the first win32-build of FG-OSG, there are at least two huge
ground scenery holes in the the Rhine/Main/Neckar-region in Germany.
The first one gapes at
the place which was formerly known as the city of Mannheim (near the
airport EDFM, which is still there), the second one has swallowed up a
big piece of Frankfurt am Main (near EDDF) and surrounding land.

First posted to the flightgear-devel list in November, 2006.

==== Mixture versus Altitude. ====

It is observed in the default c172p and in the c182 that at
high altitude airports (e.g. KGCN or KASE), to obtain max
static RPM, it suffices to move the mixture control only a
few mm aft of the full-forward (full-rich) position.

This is unrealistic. In a real aircraft under such conditions,
it would be necessary to pull the mixture control back about
an inch to obtain max RPM.

It's hard to say whether the carburetor is underreacting to the
altitude, or overreacting to the mixture control.

==== EGT reads high. ====

It is observed in the default c172p and in the c182 that the
EGT reads toward the high end of the scale under all conditions,
including idle. This is unrealistic.

Also, the EGT reads ''off-scale'' high under high-power conditions.

==== Flags missing from instruments. ====

Some of the standard instruments lack status flags. For example,
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.

Either the aircraft should be upgraded to use instruments that
display flags, or the instruments should be upgraded to be
display flags.

==== Problems with --model-hz option. ====

Specifying the --model-hz=10 command-line option results in the
following mess:
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
Reading xml electrical system model from /games/cvs/data/Aircraft/c182/c182-electrical.xml
Sorry, wdot doesn't appear to be trimmable
Trim Failed
Trim Results:
Angle of Attack: 7.50 wdot: 3.21e+01 Tolerance: 1e-03 Failed
Throttle: 0.50 udot: 0.00e+00 Tolerance: 1e-03 Passed
Pitch Trim: 0.00 qdot: -5.44e-11 Tolerance: 1e-04 Passed
Model Author: Unknown
Creation Date: 2002-01-01
Description: Cessna C-182RG
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
WWarning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
[many repeats]
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
altitude = 9
sea level radius = 4.62829e-268
latitude = 1.52075e-314
longitude = -0.0967923
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: catching up on tile delete queue
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = -1.18461e-41
sea level radius = -4.87596e-42
latitude = 6.98923e-316
longitude = 6.79738e-313
Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan -inf inf -inf segment ignored..
altitude = nan
sea level radius = nan
latitude = nan
longitude = nan

and so forth.

==== CPU hogging. ====

The fsgs program will happily eat up >98% of the cpu cycles,
even when the simulator is paused. That seems excessive,
particularly during pause. This is on a 2GHz machine
with hardware acceleration. As a point of reference,
glxgears uses only a fraction of one percent of the cpu.

* 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.)

==== Misdirected diagnostic in JSBSim.cxx ====

The file JSBSim.cxx contains the following code:

if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
"FGInterface is being called without scenery below the aircraft!");
cout << "altitude = " << alt << endl;
cout << "sea level radius = " << slr << endl;
cout << "latitude = " << lat << endl;
cout << "longitude = " << lon << endl;
//return;
}

Apparently this "ought" to be a five-line diagnostic message.

In fact, the first line is directed to the SG_LOG at priority SG_WARN,
while the other four lines are directed to cout regardless of
priority. This makes both the log and the console record hard
to interpret.

This is one of many bugs that have been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim
but not pulled into the FG version.

==== Out-of-bounds array reference in JSBSim ====

This is in the interpolation table code.

This is one of many bugs that have been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim

==== Memory leak in JSBSim ====

This is in the "message" handling code.

This is one of many bugs that have been fixed in the [[http://jsbsim.sourceforge.net/ SF CVS]] version of JSBSim

==== Glideslope service volume. ====

The code in navradio.cxx appears to assume the glideslope
service volume is the same as the localizer service
volume. This is quite unrealistic.

==== Extended service volume. ====

In some parts of the world, a goodly fraction of the
localizers have an expanded service volume (ESV),
often quite a bit larger than the standard service
volume you see in the AIM. The code in navradio.cxx
was ignoring the service volume information in the
database and wrongly assuming the default values
applied everywhere. Code to fix the range-related
part of the problem has been offered
but not yet incorporated.

==== Other service volume issues. ====

The code in navradio.cxx has no understanding of how
'''azimuth''' affects the
localizer. There is more to the story than reception range.
It is perfectly possible to be outside the LOC service volume
for reasons having to do with azimuth, not range.

Good ident will be heard, but false localizer courses will
cause serious trouble for the unwary pilot.

A patch to fix this (along with the ESV issue) has been
offered, but ignored.

There are also azimuthal issues with the /glideslope/
service volume. This has not yet been patched.

==== Menu buttons having a get-together. ====

This concerns "radio buttons" on menus, such as on the
location-in-air popup and elsewhere. By definition, it should be
impossible to have more than one radio button pushed down at a time.
However, illegal situations of this sort can be created
using a click-and-drag gesture. Aim at
a radio button, hold the mouse-button down, and drag ...
as if you wanted to drag the radio button to a new location.
This allows you to set a radio button without the others
being unset. If you persist, you can have every one of
the buttons in the pushed-down state at the same time.

Before you say, "well, don't do that then" or "garbage in,
garbage out", let me point out that it is possible for
a pilot to inadvertently make a tiny dragging gesture
when intending only a click. Also, when the desired
button is in the pushed-down state, it is easy to not
notice that other buttons are in the undesired state.

==== Altimeter setting unreadable. ====

The standard altimeter (used by the default c172p aircraft
and many others) had been using an unhappy hodgepodge of
layers. The analog Kollsman window was unusable, because
it was unlabeled, and the digital altimeter setting was
unusable, especially at altitudes near 2500 feet, partly
from being behind the needle. On a real altimeter, things
are positioned so that cannot happen.

Fixing this requires using a more suitable font, moving
the digits over, and getting rid of conflicting extraneous
markings.

A patch to implement this fix has been offered.

==== Broken startup banner. ====

On startup, the simulator prints Author: Unknown and
prints a bogus Date, even when an author and a date
have been specified in the *-set.xml file. Apparently
the code is having trouble reading elements from
the file. This has been observed on a wide variety
of aircraft.

==== Memory mismanagement in subsystem_mgr. ====

It is bad luck to apply "delete" to an object that was not
created with "new" ... as in line 219 of subsystem_mgr.cxx

A patch is available, but has not been incorporated.

==== Yet more memory mismanagement. ====

When FG is trying to exit, it is very likely to abort
with a message such as

*** glibc detected *** double free or corruption (!prev): 0x0ad08b88 ***

There are at least three different instances of this bug,
each producing a different traceback. Here is one such
traceback:

<code>
#0 0xb7573947 in raise () from /lib/tls/libc.so.6
#1 0xb75750c9 in abort () from /lib/tls/libc.so.6
#2 0xb75a908a in __libc_message () from /lib/tls/libc.so.6
#3 0xb75b094f in _int_free () from /lib/tls/libc.so.6
#4 0xb75b09f2 in free () from /lib/tls/libc.so.6
#5 0xb77373b1 in operator delete () from /usr/lib/libstdc++.so.6
#6 0x085455db in ~SGPropertyNode (this=0xad08b88) at props.cxx:766
#7 0x08545597 in ~SGPropertyNode (this=0xace47e8) at ../../simgear/structure/SGSharedPtr.hxx:93
#8 0x08545597 in ~SGPropertyNode (this=0x86d7728) at ../../simgear/structure/SGSharedPtr.hxx:93
#9 0x080821d3 in ~FGGlobals (this=0x86d7598) at globals.cxx:105
#10 0x0805a969 in fgExitCleanup () at bootstrap.cxx:237
#11 0xb75764f0 in exit () from /lib/tls/libc.so.6
#12 0x080919c7 in fgExit (status=0) at util.cxx:120
#13 0x0806e452 in do_exit (arg=0xf186950) at fg_commands.cxx:224
</code>

== Missing Features and Traps for the Unwary ==

==== Version number, please. ====

It would be helpful to have an easy, documented way to ascertain the
version number. A --version option on the command line would be
nice. Maybe also a help::about menu item, for use while fgfs is
already running.

One could imagine that info about key libraries would also be
helpful.

==== Rabbits extinct. ====

In the real world, many airports have '''sequenced flashers'''
(aka the rabbit) as part of the approach-light system.

In the FlightGear world, the sequenced flashers are inoperative
everywhere. Grepping through the code suggests that no attempt
has been made to implement this.

==== No comm volume control. ====

In many aircraft including the default c172p, the comm
radios have no volume control knob. In other aircraft
including the pa24-250, there is such a knob, but it
apparently isn't clickable and apparently doesn't do
anything.

In contrast, the SenecaII exemplifies the ''desired'' behavior:
the knob rotates when clicked and
correctly controls the /instrumentation/comm[N]/volume
property. (This alas has no effect on the volume of ATIS
audio, but that must be considered an ATIS bug not a
Seneca bug.)

==== Incomplete Scenery. ====

Installing scenery from the [http://fgfsdb.stockill.org/ Stockill Database ] without installing the shared models, will get you messages such as the following:

Failed to open file .../data/Models/fgfsdb/localizer.xml
Failed to open file .../data/Models/fgfsdb/WaterWorks30m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank5m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank10m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank20m.xml
Failed to open file .../data/Models/fgfsdb/GenericStorageTank30m.xml

You might get only a few such messages, or you might get
screenful after screenful.

So, make sure you download all scenery files that are needed for fgfs.

This obviously counts as a trap for the unwary.

- This is patently not a bug and should be moved to a "tips" 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...

==== ASOS and AWOS are AWOL. ====

At many non-tower airports (and even some tower airports) there
is automatic weather reporting of some kind.

It ought to be straightforward to implement this, as a slight
variation on the existing ATIS feature.

==== Roundoff problems with textranslate step and scroll. ====

The textranslate animation is delightful for 3D animation
of mechanical drum-type displays as on old-fashioned
odometers and Hobbs meters.

It is not, however, a convenient way to implement digital
readouts. It works OK for integers, but the code in
apply_mod() suffers from roundoff errors when dealing with decimal fractions, such as the ".1" in 122.1 MHz, particularly when the scroll-value is zero.
* One workaround is to stick to integers, e.g. integer kHz
rather than fractional MHz.
* Another workaround is to employ a small positive scroll value, step*1e-6 should suffice.
* A final option (with CVS) is to use the bias tag to let the code know how to
handle round-off. Use a bias value of 1/2 your smallest step value, and
use the same bias value on all digits.

What we really need is a whole new support routine for dealing
with 3D digital displays, something at least as nice as the
support for 2D instruments.

== Fixed Bugs ==

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).

==== Linux and perhaps Windows crashes when specifiying --lon or --lat ====

The 0.9.8 version of flightgear has an issue with starting coordinates that are lie on the boundary before tiles or coordinates.

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. :-)

* '''This bug has not been observed in 0.9.10.'''

==== 0.9.5 - 0.9.8 - Windows - Crash on start reporting "Could not gen source" ====

Any further reports or stacktraces on this bug would be appreciated.
Workround: Launch two copies of FGFS in quick succession: one should work. You may need three.
Update your sound card drivers.

* '''This bug has been fixed in 0.9.8a'''

==== 0.9.7 - ? Linux - Joystick crash with correct config files ====

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.

* ''' This bug has been fixed.'''

== See Also ==

==== Individual Aircraft ====

Bugs associated with a particular aircraft should be listed
on the aircraft's [[Aircraft_Todo|ToDo]] page, not here.

==== OpenSceneGraph ====

There is a separate page for issues related to [[OpenSceneGraph]].

Soaring

2007-01-20T19:46:30Z

Ajmacleod:

At this time no released version of FlightGear has any glider launching methods. Working winch launches and even multiplayer aerotows have however been successfully tested, the code is in CVS now (see [[Doing_aerotow_over_the_net]]) and will be included in the next release. If you cannot use CVS though, to go gliding you must start up in the air. For an example of how to do this see the related article called [[Starting in the Air]], or see the start file for the Schweizer 2-33 (called sgs233-set.xml).

Thermals and sinks are modeled, but they must be defined individually in a thermal scenario file. To see how this is done it would be best to examine the file called data/AI/thermal_demo.xml, which sets up 11 thermals and 6 sinks around San Francisco Bay. To learn more about AI scenarios in general, see the related article called [[AI Systems]]. Note that the thermals and sinks exist independently of FlightGear's weather system, so it's possible to have cloud layers that don't match your thermal heights. To prevent this you may want to manually set the cloud layers to match your thermals.

A very nice piece of add-on scenery for gliding in the Menden (EDLA) area is available [http://home.arcor.de/vollnhals-bremen/Arnsberg/Arnsberg.html], including the required AI scenario file containing thermals for that area.

If you log on to a multiplayer server (server port 5002 only) while soaring, then your flight will be recorded at the FGTracker site, like this: [http://fgfs.i-net.hu/modules/fgtracker/?FUNCT=FLIGHT&FLIGHTID=1305&PHPSESSID=b3f9752f0f47468b0df49303e806c288], which makes flight review a snap.