FlightGear wiki - User contributions [en]

Template:Model Gallery

2024-04-26T13:22:44Z

AndersM: Correct version Draken

{{ #switch: {{{section|}}}
| carrier_borne_aircraft =
{{Gallery
| Buccaneer.jpg | [[Blackburn Buccaneer]]
| Douglas_A4.jpg | [[Douglas A-4 Skyhawk]]
| A-6E.jpg | [[Grumman A-6E|Grumman A-6E Intruder]]
| F-8E.jpg | [[F-8 Crusader]]
| F-14.jpg | [[Grumman F-14 Tomcat]]
| Hawker_Seahawk.jpg | [[Hawker Seahawk|Hawker Seahawk FGA6]]
}}
| experimental =
{{Gallery
| BAC_TSR-2_Prototype.jpg | [[BAC TSR-2 Prototype]]
| V22Osprey.jpg |[[Bell Boeing V22 Osprey | Bell V-22 Osprey]]
| X15.jpg | [[North American X-15]]
| YF-23.jpg | [[Northrop/McDonnell Douglas YF-23]]
}}
| helicopters =
{{Gallery
| Ah-1_vietnam_firebase.png | [[AH-1 Cobra]]
| H21c.jpg | [[Boeing-Vertol H21C]]
| CH-47 Chinook.jpg | [[CH-47 Chinook Helicopter]]
| Bo105.jpg | [[Eurocopter Bo105]]
| Ec135.jpg | [[Eurocopter EC135]]
| EC130.jpg | [[Eurocopter EC130 B4]]
| OH-6.png | [[Hughes OH-6 Cayuse]]
| WG13.jpg | [[Lynx WG13]]
| S51.jpg | [[Sikorsky S51]]
| S58.jpg | [[Sikorsky S58]]
| s76c_landed.jpg | [[Sikorsky S76C]]
| Uh60.jpg| [[Sikorsky UH60]]
| Aluette2.jpg | [[Aérospatiale Alouette II|Alouette II]]
| Hup-3.jpg | [[Piasecki HUP-3]]
| R22.jpg | [[Robinson R22]]
}}
| historical_aircraft =
{{Gallery
| Couzinet70.jpg |[[Couzinet 70]]
| dh91.jpg | [[De Havilland D.H. 91 Albatross]]
| Douglas_DC3.jpg | [[Douglas DC-3]]
| ComperSwift.jpg | [[ComperSwift Comper]]
| Lockheed_1049.jpg | [[Lockheed 1049|Lockheed Constellation]]
| 314.jpg | [[Boeing 314]]
| DHC-3.jpg | [[de Havilland Canada DHC-3 Otter]]
| 1903_Wright_Flyer.jpg | [[Wright Flyer (UIUC)]]
| Short_Empire.jpg | [[Short Empire]]
| Dc-3-splash.png | [[Douglas DC-3-C47]]
}}
| light_civilian_aircraft =
{{Gallery
| A24-liverie-default.png | [[Aeroprakt A24 Viking]]
| Aerostar_700.jpg | [[Aerostar 700]]
| FK9MK2.jpg | [[B&F FK9 Mark 2]]
| Beech99.jpg | [[Beechcraft Model 99]]
| Cessna_172P.jpg | [[Cessna C172|Cessna 172P]] (1982)
| Edgley_Optica_01.jpg | [[Edgley Optica]]
| PA28-Warrior.jpg | [[Piper_PA28_Warrior_II|Piper PA28 Warrior II]]
| Pa-24.jpg | [[Piper PA-24 Comanche|Piper Comanche (PA24-250)]]
| Piper j3cub.jpg | [[Piper J3 Cub]] (1946)
| Piper SenecaII.jpg | [[Piper PA34-200T Seneca II|Piper Seneca II (PA34-200T)]]
| dr400.jpg | [[Robin DR400]]
| DR400-dauphin.jpg | [[Robin DR400 Dauphin]]
| Rallye-MS893.jpg | [[Rallye-MS893E]]
| Piper_Dakota.png | [[Piper Dakota]]
| Velocity-XL-RG.jpg | [[Velocity XL RG]]
}}
| lighter_than_air =
{{Gallery
| Zeppelin_NT.jpg | [[Zeppelin NT]]
| ZF_Navy_free_balloon.jpg | [[ZF Navy free balloon]]
| Submarine_Scout.jpg | [[Submarine Scout]]
| Zeppelin_LZ_121_Nordstern.jpg | [[Zeppelin LZ 121 Nordstern]]
}}
| business_jets =
{{Gallery
| CessnaCitationX.jpg | [[Cessna Citation X]]
}}
| modern_airliners_narrowbody_midsize =
{{Gallery
| A320-family.jpg | [[Airbus A320 family]]
| Beechcraft B1900D.png | [[Beechcraft B1900D]]
| 707.jpg | [[Boeing 707]]
| 717-200.jpg | [[Boeing 717]]
| B727-200-1.png | [[Boeing 727|Boeing 727]]
| 737-100.png | [[Boeing 737-100]]
| 737-300.jpg | [[Boeing 737-300]]
| Boeing 737-400 British Airways.jpg | [[Boeing 737-400]]
| 757-2002.jpg | [[Boeing 757-200|Boeing 757 series]]
| Picture 11.png | [[Bombardier CRJ-200LR]]
| CRJ700.jpg | [[Bombardier CRJ700 series]]
| Concorde.png | [[Concorde]]
| Fokker50.jpg | [[Fokker 50]]
| MD-80.png | [[McDonnell Douglas MD-80]]
| Tu154.jpg | [[Tupolev 154]]
}}
| modern_airliners_widebody_jumbo =
{{Gallery
| Fgfs-20230726152543.png | [[Airbus_A330|Airbus A330 family]]
| A340-313X-001.png | [[Airbus A340-313X|Airbus A340-300]]
| A340-600HGW-3.png | [[Airbus A340-600HGW|Airbus A340-600]]
| A350picture.png | [[Airbus A350]]
| A380.jpg | [[Airbus A380]]
| 747-400.jpg | [[Boeing 747-400]]
| 747-8i.png | [[Boeing_747-8i|Boeing 747-8]]
| Boeing 767-300.png | [[Boeing 767-300]]
| Boeing777-200LR.jpg | [[Boeing 777-200|Boeing 777 series]]
| 787.png | [[Boeing 787]]
| DC10_NWA_landing.jpg | [[McDonnell_Douglas_DC-10-30|McDonnell Douglas DC-10]]
| MD-11-Octal450.png | [[McDonnell Douglas MD-11]]
}}
| modern_military_aircraft =
{{Gallery
| A-10.jpg | [[Fairchild A-10]]
| B-52F.jpg | [[Boeing B-52]]
| E-3B.jpg | [[Boeing E-3 Sentry]]
| F-15C.jpg | [[F-15C Eagle]]
| F-80C.jpg | [[F-80C Shooting Star]]
| Harrier.jpg | [[British Aerospace Harrier]]
| General_Dynamics_F16.jpg | [[General Dynamics F-16]]
| Cessna T-37.jpg | [[Cessna T-37]]
| Dassault Mirage F.1 at altitude.png | [[Dassault Mirage F.1]]
| M20005prespic.png | [[Dassault Mirage 2000-5]]
| Northrop_T-38.jpg | [[Northrop T-38]]
| OV-10A2.jpg | [[North American OV-10A Bronco]]
| Saab_J35.jpg | [[Saab J 35Ã– Draken|Saab J35F Draken]]
| LCA.jpeg | [[HAL Tejas]]
| F-22.png | [[Lockheed Martin F-22 Raptor]]
| MiG-29_splash.png | [[Mikoyan-Gurevich_MiG-29]]
| PC-9M.jpg | [[Pilatus PC-9M]]
| PC-21.jpg | [[Pilatus PC-21]]
}}
| science_fiction =
{{Gallery
| bluebird_hovercraft.jpg | [[Bluebird]]
| UFO.jpg | [[UFO from the 'White Project' of the UNESCO]]
}}
| spacecraft =
{{Gallery
| Shuttle.jpg | [[Space Shuttle]]
| Vostok-1-Exterior.png | [[Vostok-1]]
}}
| ultra_light = 
{{Gallery
| AirwaveXtreme150.jpg | [[Airwave Xtreme 150]]
| Hornet.jpg | [[GDT Hornet (autogyro)]]
| DG-101G_001.jpg | [[Glaser-Dirks DG-101G]]
| DG-300.jpg | [[Glaser-Dirks DG-300]]
| Dragonfly-towing.jpg | [[Dragonfly|Moyes Dragonfly]]
| Paraglider.jpg | [[Paraglider]]
| Asw20.jpg | [[ASW-20 sailplane|Schleicher ASW-20]]
| Sgs233.jpg | [[Schweizer 2-33]]
}}
| vehicles = 
{{Gallery
| AerocarI_1.png | {{int|Taylor Aerocar}}
| Follow_me.jpg | {{int|Follow me}}
| Jeep.jpg | {{int|Jeep}}
| Lamborghini Murcielago LP640 March10.jpg | {{int|Lamborghini Murcielago}}
| M113AS3.jpg | {{int|M113AS3}}
| Mobile_Stairs.jpg | {{int|Mobile Stairs}}
| Pushback.jpg | {{int|Pushback}}
| Snowplow.jpg | {{int|Snowplow}}
}}
| warbirds =
{{Gallery
| Beaufighter.png | [[Bristol Beaufighter]]
| Fokker_DrI.jpg | [[Fokker Dr.I]]
| P51d-mustang.png | [[P-51D Mustang]]
| A6M2_fgfs-screen-166.jpg | [[A6M2 Zero]]
| ki-84.jpg | [[Nakajima Ki-84]]
| Fw190.jpg | [[Focke-Wulf Fw 190]]
| Sopwith_Camel.png | [[Sopwith Camel]]
| Spitfire.jpg | [[Supermarine Spitfire]]
| MiG-15bis-Exterior.jpg | [[MiG-15]]
| F4u-park.jpg | [[F4U Corsair]]
| 109-1.png | [[Messerschmitt Bf 109]]
}}
}}<noinclude>

{{Informative template | 1=
__NOTOC__
== Goal ==
This template is used in aircraft/helicopter/vehicle gallery pages and their translations. By using and maintaining this template the translations of the gallery pages can be up to date and synchronised with the least required work possible.

This is the right place to add aircrafts to the lists in [[Aircraft]], [[:de:Flugzeuge]], [[:es:Aeronaves]], etc.

== Usage ==
<nowiki>{{</nowiki>'''Model Gallery''' <nowiki>|</nowiki>section=<nowiki>}}</nowiki>
; section: Section of aircraft to show. Must be one of the following or no gallery will be shown:
:* '''carrier_borne_aircraft'''
:* '''experimental'''
:* '''helicopters'''
:* '''historical_aircraft'''
:* '''light_civilian_aircraft'''
:* '''lighter_than_air'''
:* '''modern_airliners_narrowbody_midsize'''
:* '''modern_airliners_widebody_jumbo'''
:* '''modern_military_aircraft'''
:* '''science_fiction'''
:* '''spacecraft'''
:* '''ultra_light'''
:* '''vehicles'''
:* '''warbirds'''

== Example ==
<nowiki>{{Model Gallery |section=lighter_than_air}}</nowiki>
{{Model Gallery |section=lighter_than_air}}

}}

[[Category:Templates]]</noinclude>

Saab 35 Draken/info

2024-02-12T13:52:39Z

AndersM:

<includeonly>{{infobox aircraft
| name = Saab 35 Draken
| hangar = fgaddon
| aircraft = SaabJ35F
| image = Saab_J35.jpg
| image2 = Saab_J35_cockpit.jpg
| type = Fighter aircraft
| config = Delta-wing aircraft
| propulsion = Single-engine jet
| authors = Anders M (3D model, FDM, Cockpit)
| fdm = JSBSim
| fgname = SaabJ35F
| manufacturer = Saab
| status-fdm = 3
| status-systems = 3
| status-cockpit = 4
| status-model = 4
| status = 0.9.6
| forumtid = 18798
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Saab 35 Draken]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Saab 35 Draken

2024-02-11T12:08:50Z

AndersM:

{{:{{PAGENAME}}/info}}
The '''Saab J35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit images.

=== Special aircraft keys ===
{| class="keytable"
! Key
! Function
|-
| {{key press|Shift|S}}
| Automatic start sequence including all systems. (The aircraft needs to be stationary.)
|-
| {{key press|Shift|L}}
| Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
|-
| {{key press|Ctrl|J}}
| Jettison drop tanks in air.
|-
| {{key press|Ctrl|D}}
| Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks
|-
| {{key press|Shift|Q}}
| Fuel cut off, not normally needed.
|-
| {{key press|Shift|P}}
| Use drag chute handle
|-
| {{key press|e}}
| Fire ADEN 30mm cannon (100 rounds available, 1700 rounds per minute)
|-
| {{key press|z}}
|Sight ring: Decreased distance
|-
| {{key press|Shift|Z}}
| Sight ring: Increased distance
|}

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below. Acknowledge by pressing the light to silence the alarm. No warning signal while taxing.

*HÖJDV: Flashes when autopilot HÖJD (altitude hold) is set and aircraft not at target altitude or vertical speed above 200 m/min. Lit when stable at target altitude. It is recommended to be at target altitude before setting autopilot to HÖJD.
*Landing gear down and locked: (LANDSTÄLL LÅST UTE) Green lights front lower left

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of drop-tanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7). Click for PLANÉ mode.

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''Clock'''

Clock ring: Knob furthest right from clock turns the ring. Set pointing to the minute hand before lift off to keep track of flying time.

Clock mode button: Lowest knob. Switches between clock and stopwatch. In reality also setting of the clock but not implemented.

Stopwatch button: Starts, stops and resets the stopwatch.

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*!STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Only a limited simulation of the radar is implemented:

* Showing a sweep and antenna azimut. (mode TYST and SÄND)

* In multiplayer the radar shows aircrafts in radar range: dist < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground. (mode SÄND)

Radar Modes. Set by radar panel on the right side of cockpit(16):

FRÅN: Power off

BER: Readies radar for transmission. Takes 20 sec (In reality 3 min)

TILL: Like BER but sights and weapon connections also ready. (Same as BER in the simulation.)

TYST: Everything running but no emissions from antenna.

SÄND: Everything running and antenna emitting.

Yellow lines are navigation indicators used by the navigation system. See below.

Knobs on radar panel set intensity of scope (LJUSSTYRKA FSKOP) and navigation lines (KORSVISARE).

'''Radio'''
The radio equipment consists of two transceiver and one control unit of model Fr-21. They are on the left horizontal panel. In the simulation both transceivers are used for communication. In the real aircraft one was the receiver for combat control data feeding the AHK and other avionics. The letters A-K stores pre set frequencies for transceiver A (closest to the control unit) and the numbers 1-5 stores pre set frequencies for transceiver B. A stores the COM1 frequency at FG start up. Number 1 stores the COM2 frequency at FG start up. The frequency for the other letters and numbers are in the text file $FG_HOME/Export/SaabJ35F-Fr21.txt and can be changed by the user.
Pressing the buttons marked with dash (-) makes it possible to manually set the frequency using the knobs on the two manual units. Changing mode from Normal to Reserv changes sending unit from A to B.
The radio is off at simulation start. Transceiver B uses battery power and transceiver A uses main AC.

'''Autopilot'''

The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold. If plané on altitude selector the autopilot will folow a glide slope of approx 3 degrees.
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''Navigation radio and mode selector'''

Right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, AHK 0, cn manual, Radar lines parked.
*FÖRV: (Preselected) No nav radio, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*STRIL: (Combat control) Activates Route Manager, AHK NYTT MÅL, cn direction to next waypoint, Radar lines parked.
*STRID: (Combat) No nav info, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction line, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR. In plané mode a glideslope will also be shown on radar.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon. In plané mode a glideslope will also be shown on radar.
*LANDN 40: (Landing 40 km) Uses ILS set by the three letters. Radar shows direction line and glide path, AHK LANDA, cn direction to ILS beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters. Radar shows direction line, AHK BARBRO, cn direction to ILS beacon.

'''Important controls and switches'''

* Drag chute handle: (BROMSFALLSKÄRM) Lower left.(15) First use deploys drag chute. Second drops it. It takes approx. 3 seconds to deploy and should be done under 320 km/h and above 200 km/h. The handle can not be used if throttle above 85%.
* Throttle: (GASKRAN) lower left.
* Landing gear: (LAND-STÄLL) lower left.
* Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Landing light switches: (LAND TAXI) Left front canopy rim.(12) Left and right landing light. If switches are in on position the lights will be automatically turned on/off as landing gear are lowered/rised.
*Navigation lights: (LANTERNOR) Right aft panel.(13) Four settings off, bright, blinking and dim.
*Indicator lights: (IND. LAMPOR) Sets full or half intensity of indicator lights and caution panel,
*Instrument lighting: (INST-LYSE) Left side above throttle. (1) Sets the brightness of the red instrument lighting.
*Consol light: (KONS_LYSE) Left side above throttle.(1) Sets the brightness of the consol lights illuminating the left and right consols.
*Cabin light: (KABIN LYSE) Left side above throttle.(1) Turns cabin light on or off.
*Clock ring: Knob right of clock turns the ring. Set pointing to the minutehand before lift off to keep track of flying time.
*Start panel: Lower left instrument panel.(2) Se below.

====== Weapons and sight ======
ADEN 30 mm cannon implemented. Choose AKAN with weapon chooser knob. Right side radar panel(16). If AKAN is selected a gyroscopic gun sight is projected. Use knob on the sights right side(17) to set target wing span and keyboard controls (z/Z) to adjust ring diameter. Nose wheel needs to be up for weapons to function.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* It is neutral in roll at low alpha. Keep an eye on the horizon.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 270 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

Lift off: Rotate at 270 km/h to 10-12 degrees pitch. Lift off at approx 300 km/h. Turn of afterburner at 500 km/h if not needed for climbing. Normal climb speed Mach 0.9.

Landing: Lower speed to 500 km/h. Lower gears and turn on landing lights. Turn to final lowering the speed to 325 km/h. Keep a speed of 300 km/h and a plané of 3 degrees (100 m at 2 km distance), RPM 80-85%. After touchdown raise the nose up to increase drag until speed is 240 km/h. Apply brakes. Lower nose at 160 km/h.

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

{{Saab}}

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engine jets]]

Saab 35 Draken

2024-02-11T12:08:09Z

AndersM: Updating info

{{:{{PAGENAME}}/info}}
The '''Saab J35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit images.

=== Special aircraft keys ===
{| class="keytable"
! Key
! Function
|-
| {{key press|Shift|S}}
| Automatic start sequence including all systems. (The aircraft needs to be stationary.)
|-
| {{key press|Shift|L}}
| Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
|-
| {{key press|Ctrl|J}}
| Jettison drop tanks in air.
|-
| {{key press|Ctrl|D}}
| Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks
|-
| {{key press|Shift|Q}}
| Fuel cut off, not normally needed.
|-
| {{key press|Shift|P}}
| Use drag chute handle
|-
| {{key press|e}}
| Fire ADEN 30mm cannon (100 rounds available, 1700 rounds per minute)
|-
| {{key press|z}}
|Sight ring: Decreased distance
|-
| {{key press|Shift|Z}}
| Sight ring: Increased distance
|}

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below. Acknowledge by pressing the light to silence the alarm. No warning signal while taxing.

*HÖJDV: Flashes when autopilot HÖJD (altitude hold) is set and aircraft not at target altitude or vertical speed above 200 m/min. Lit when stable at target altitude. It is recommended to be at target altitude before setting autopilot to HÖJD.
*Landing gear down and locked: (LANDSTÄLL LÅST UTE) Green lights front lower left

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of drop-tanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7). Click for PLANÉ mode.

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''Clock'''
Clock ring: Knob furthest right from clock turns the ring. Set pointing to the minute hand before lift off to keep track of flying time.

Clock mode button: Lowest knob. Switches between clock and stopwatch. In reality also setting of the clock but not implemented.

Stopwatch button: Starts, stops and resets the stopwatch.

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*!STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Only a limited simulation of the radar is implemented:

* Showing a sweep and antenna azimut. (mode TYST and SÄND)

* In multiplayer the radar shows aircrafts in radar range: dist < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground. (mode SÄND)

Radar Modes. Set by radar panel on the right side of cockpit(16):

FRÅN: Power off

BER: Readies radar for transmission. Takes 20 sec (In reality 3 min)

TILL: Like BER but sights and weapon connections also ready. (Same as BER in the simulation.)

TYST: Everything running but no emissions from antenna.

SÄND: Everything running and antenna emitting.

Yellow lines are navigation indicators used by the navigation system. See below.

Knobs on radar panel set intensity of scope (LJUSSTYRKA FSKOP) and navigation lines (KORSVISARE).

'''Radio'''
The radio equipment consists of two transceiver and one control unit of model Fr-21. They are on the left horizontal panel. In the simulation both transceivers are used for communication. In the real aircraft one was the receiver for combat control data feeding the AHK and other avionics. The letters A-K stores pre set frequencies for transceiver A (closest to the control unit) and the numbers 1-5 stores pre set frequencies for transceiver B. A stores the COM1 frequency at FG start up. Number 1 stores the COM2 frequency at FG start up. The frequency for the other letters and numbers are in the text file $FG_HOME/Export/SaabJ35F-Fr21.txt and can be changed by the user.
Pressing the buttons marked with dash (-) makes it possible to manually set the frequency using the knobs on the two manual units. Changing mode from Normal to Reserv changes sending unit from A to B.
The radio is off at simulation start. Transceiver B uses battery power and transceiver A uses main AC.

'''Autopilot'''

The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold. If plané on altitude selector the autopilot will folow a glide slope of approx 3 degrees.
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''Navigation radio and mode selector'''

Right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, AHK 0, cn manual, Radar lines parked.
*FÖRV: (Preselected) No nav radio, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*STRIL: (Combat control) Activates Route Manager, AHK NYTT MÅL, cn direction to next waypoint, Radar lines parked.
*STRID: (Combat) No nav info, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction line, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR. In plané mode a glideslope will also be shown on radar.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon. In plané mode a glideslope will also be shown on radar.
*LANDN 40: (Landing 40 km) Uses ILS set by the three letters. Radar shows direction line and glide path, AHK LANDA, cn direction to ILS beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters. Radar shows direction line, AHK BARBRO, cn direction to ILS beacon.

'''Important controls and switches'''

* Drag chute handle: (BROMSFALLSKÄRM) Lower left.(15) First use deploys drag chute. Second drops it. It takes approx. 3 seconds to deploy and should be done under 320 km/h and above 200 km/h. The handle can not be used if throttle above 85%.
* Throttle: (GASKRAN) lower left.
* Landing gear: (LAND-STÄLL) lower left.
* Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Landing light switches: (LAND TAXI) Left front canopy rim.(12) Left and right landing light. If switches are in on position the lights will be automatically turned on/off as landing gear are lowered/rised.
*Navigation lights: (LANTERNOR) Right aft panel.(13) Four settings off, bright, blinking and dim.
*Indicator lights: (IND. LAMPOR) Sets full or half intensity of indicator lights and caution panel,
*Instrument lighting: (INST-LYSE) Left side above throttle. (1) Sets the brightness of the red instrument lighting.
*Consol light: (KONS_LYSE) Left side above throttle.(1) Sets the brightness of the consol lights illuminating the left and right consols.
*Cabin light: (KABIN LYSE) Left side above throttle.(1) Turns cabin light on or off.
*Clock ring: Knob right of clock turns the ring. Set pointing to the minutehand before lift off to keep track of flying time.
*Start panel: Lower left instrument panel.(2) Se below.

====== Weapons and sight ======
ADEN 30 mm cannon implemented. Choose AKAN with weapon chooser knob. Right side radar panel(16). If AKAN is selected a gyroscopic gun sight is projected. Use knob on the sights right side(17) to set target wing span and keyboard controls (z/Z) to adjust ring diameter. Nose wheel needs to be up for weapons to function.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* It is neutral in roll at low alpha. Keep an eye on the horizon.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 270 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

Lift off: Rotate at 270 km/h to 10-12 degrees pitch. Lift off at approx 300 km/h. Turn of afterburner at 500 km/h if not needed for climbing. Normal climb speed Mach 0.9.

Landing: Lower speed to 500 km/h. Lower gears and turn on landing lights. Turn to final lowering the speed to 325 km/h. Keep a speed of 300 km/h and a plané of 3 degrees (100 m at 2 km distance), RPM 80-85%. After touchdown raise the nose up to increase drag until speed is 240 km/h. Apply brakes. Lower nose at 160 km/h.

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

{{Saab}}

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engine jets]]

Saab 35 Draken/info

2024-02-11T11:59:03Z

AndersM: Recent improvements

<includeonly>{{infobox aircraft
| name = Saab 35 Draken
| hangar = fgaddon
| aircraft = SaabJ35F
| image = Saab_J35.jpg
| image2 = Saab_J35_cockpit.jpg
| type = Fighter aircraft
| config = Delta-wing aircraft
| propulsion = Single-engine jet
| authors = Anders M (3D model, FDM, Cockpit)
| fdm = JSBSim
| fgname = SaabJ35F
| manufacturer = Saab
| status-fdm = 3
| status-systems = 3
| status-cockpit = 5
| status-model = 4
| status = 0.9.6
| forumtid = 18798
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Saab 35 Draken]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Using listeners and signals with Nasal

2024-02-11T11:22:20Z

AndersM: /* setlistener() */ More reliable code.

{{Template:Nasal Navigation}}

== Behind the Scenes of Listeners ==

Repeatedly calling getprop() to update a property is called polling. Doing that at frame rate (each time a frame is updated) can become pretty expensive and often isn't necessary, especially for properties that are rarely updated.

Polling is only really recommended for properties that change per frame or really often. Otherwise, you will probably want to use listeners or less-frequent polling using a custom timer.

For example, a listener would be quite appropriate for an on/off switch or similar, an update loop for everything that needs to be updated each frame/update (i.e. engine rpm), and if something is changing every frame anyways or is a tied property, you might as well use the update loop for several reasons: besides the fact that it might be necessary, it linearizes your data flow and moves it closer to the use of the data, it makes use of the current known efficiency of getprop(), and I would venture that it seems most familiar to you. I really wouldn't worry about listener efficiency here

The props.Node wrappers are slower than getprop/setprop because there's more Nasal-space overhead. Intuitively, the props.Node stuff should be faster, because of the cached reference - but the getprop()/setprop() code is native C code that uses a heavily optimized algorithm to look up properties (this may change once the props bindings start using the new cppbind framework).

There will certainly be a break-even point, depending on how often properties change - and how many properties are involved. But usually, listeners should be superior to polling at frame rate for properties that do not change per frame.

Keep in mind that listeners are not "background processes" at all - a listener will be triggered by the property tree once a node is accessed, which will invoke the Nasal callback. Timers and listeners are NOT background "processes". They are just invoked by different subsystems, i.e. the property tree (listeners) or the events subsystem (timers). There are other subsystems that can also invoke Nasal handlers, such as the GUI system or the AI code. This all takes place inside the FG main loop (=main thread), not some separate background/worker thread. Which is also the reason why all the Nasal APIs are safe to be used.

It is important to understand that a "listener" is a passive thing, i.e. a "list" (array) of optional functions that are to be invoked whenever a property is modified/written to - thus, once you modify the property, the property tree code will check the size of the "callback list" that contains callbacks that are to be notified (called) when the property is written - and then calls each callback in a foreach() loop.

Which is to say that those performance monitor stats are not necessarily representative when it comes to Nasal callbacks invoked as timers/listeners, which also applies to C++ code using these two APIs (timers & listeners).

Listeners are not actively "listening" at all - there's no "listener watch" running - unlike timers, listeners are totally passive instead - it works basically like this:

* register a listener for some property named "foo", to call some Nasal code
* which just adds a callback to a property specific vector, NOTHING else.
* once setprop("foo", value) is called
* the property tree is updated
* next the property tree checks if any listeners are registered for that branch
* if there are listeners attached, they are all called (there's basically a vector of listeners)

So listeners are not really "processes" at all - neither background nor foreground: Merely their *callbacks* become processes after being invoked. Otherwise, they're just a vector of Nasal callbacks - which are only ever called if the property is modified. In other words, there's basically zero cost. Listener overhead is mainly determined by the callback's payload - not by listening (which is just checking vector.size() != 0 and calling each element), unless the property is updated frequently (in terms of frame rate)

Admittedly, having many callbacks/listeners attached, could also add up quickly.

So for benchmarking purposes, you can just use a closure to wrap your callback and update your systime() object accordingly, you could provide a separate "timed_listener" function or just override setlistener().

== Listeners and Signals ==
The important thing to keep in mind is that custom listeners are generally not about loading or running Nasal files, most of the Nasal files are loaded and executed implicitly during startup. Only the Nasal sub modules (i.e. inside their own [[$FG_ROOT]]/Nasal/ directory) are dynamically loaded using a listener). So listeners are really just a simple way to talk to the property tree:
'''Hey property tree, would you please be so kind to call this Nasal function whenever this property is modified?'''

So, listeners are callback functions that are attached to property nodes. They are triggered whenever the node is written to, or, depending on the listener type, also when children are added or removed, and when children are written to. Unlike polling loops, listeners don't have the least effect on the frame rate when they aren't triggered, which makes them preferable to monitor properties that aren't written to frequently.

To learn more about managing resources like timers and listeners, please see [[Developing and debugging Nasal code#Managing timers and listeners]].

===setlistener() vs. _setlistener() ===
You are requested '''not''' to use the raw _setlistener() function, except in files in [[$FG_ROOT]]/Nasal/ when they are
needed immediately. Only then the raw function is required, as it doesn't rely on props.nas. Using setlistener() once props.nas is loaded allows using high-level objects to reference properties, instead of raw C-objects (called "ghosts").

'''Note:''' Once [[Nasal/CppBind|cppbind]] is used to replace props.nas, _setlistener() will be deprecated because the builtin function will be effectively using the same mechanism as what the wrapper function (the current setlistener()) does right now.

===<tt>When listeners don't work</tt>===
Unfortunately, '''listeners don't work on so-called "tied" properties''' when the node value isn't set via property methods. Tied properties are a semi-deprecated API to allow C++ code to handle the value directly and control getting/setting directly, usually avoiding the property tree altogether. (You can spot such tied properties by Ctrl-clicking the "." entry in the property browser: they are marked with a "T".) The problem comes when the C++ value is written to outside of the property tree, which means that the property tree doesn't receive a notification, even though normal sets via the property tree would still fire the listeners. Most of the FDM properties are "tied", and a few in other subsystems.

Examples of properties where setlistener ''won't'' work:

* /position/elevation-ft
* /ai/models/aircraft/orientation/heading-deg
* /instrumentation/marker-beacon/[inner|middle|outer]
* Any property node created as an alias
* Lots of others

Before working to create a listener, always check whether a listener will work with that property node by control-clicking the "." in property browser to put it into verbose mode, and then checking whether the property node for which you want to set up a listener is marked with a "T" or not.

If you can't set a listener for a particular property, the alternative is to use settimer to set up a timer loop that checks the property value regularly.

Listeners are most efficient for properties that change only occasionally. No code is called at all during frames where the listener function is not called. If the property value changes every frame, setting up a settimer loop with time=0 will execute every frame, just the same as setlistener would, and the settimer loop is more efficient than setting a listener. This is one reason the fact the setlistener doesn't work on certain tied and FDM properties is not a great loss. See the section on timer loops below.

=== <tt>setlistener()</tt> ===

Syntax:

<syntaxhighlight lang="nasal">
var listener_id = setlistener(<property>, <function> [, <startup=0> [, <runtime=1>]]);
</syntaxhighlight>

'''<property>''' The first argument is a property node object (<tt>props.Node()</tt> hash) or a property path. Because the node hash depends on the props.nas module being loaded, <tt>setlistener()</tt> calls need to be deferred when used in an [[$FG_ROOT]]/Nasal/*.nas file, usually by calling them in a <tt>settimer(func {}, 0)</tt> construction. To avoid that, one can use the raw <tt>_setlistener()</tt> function directly, for which <tt>setlistener()</tt> is a wrapper. The raw function does only accept node paths (e.g. "/sim/menubar/visibility"), but not props.Node() objects.

'''<function>''' The second argument is a function object (not a function call!). The function you pass here will be called with the target property node as its sole argument as soon as someone writes to the property.

'''<startup=0>''' The third argument is optional. If it is non-zero, then it causes the listener to be called initially (but not if runtime is 1). This is useful to let the callback function pick up the node value at startup.

'''<runtime=1>''' The fourth argument is optional, and defaults to 1. This means that the callback function will be executed whenever the property is written to, independent of the value.

If the argument is set to 0, then the function will only get triggered if a value other than the current value is written to the node. This is important for cases where a property is written to once per frame, no matter if the value changed or not. YASim, for example, does that for /gear/gear/wow or /gear/launchbar/state.
So, this should be used for properties that are written to in every frame, although the written value is mostly the same. If the argument is 2, then also write access to children will get reported, as well as the creation and removal of children nodes.

For both optional flags 0 means less calls, and 1 means more calls. The first is for startup behavior, and the second for runtime behavior.

Here's a real-life example:

<syntaxhighlight lang="nasal">
setlistener("/gear/launchbar/state", func (node) {
if (node.getValue() == "Engaged")
setprop("/sim/messages/copilot", "Engaged!");
}, 1, 0);
</syntaxhighlight>

YASim writes once per frame the string "Disengaged" to property /gear/launchbar/state. When an aircraft on deck of the aircraft carrier locks into the catapult, this changes to "Engaged", which is then written again in every frame, until the aircraft leaves the catapult. Because the locking in is a bit difficult -- one has to target the sensitive area quite exactly --, it was desirable to get some quick feedback: a screen message that's also spoken by the Festival speech synthesis. With the args 1 and 0, this is done initially (for the unlikely case that we are locked in from the beginning), and then only when the node changes from an arbitrary value to "Engaged".

<tt>setlistener()</tt> returns a unique listener id on success, and <tt>nil</tt> on error. The id is nothing else than a counter that is 0 for the first Nasal listener, 1 for the second etc. You need this id number to remove the listener. Most listeners are never removed, so that one doesn't assign the return value, but simply drop it.

'''Listener callback functions''' can access up to four values via regular function arguments.

The first two of which are property nodes in the form of a <tt>props.Node()</tt> object hash.

The third is a indication of the operation: 0 for changing the value, -1 for removing a child node, and +1 for adding a child.

The fourth indicates whether the event occurred on the node that was listened to and is always 0 if the previous argument is not 0.

Here is the syntax supposing you have set a callback function named ''myCallbackFunc'' via <tt>setlistener</tt> (''setlistener(myNode, myCallbackFunc)''):

<syntaxhighlight lang="nasal">
myCallbackFunc([<changed_node> [, <listened_to_node> [, <operation> [, <is_child_event>]]]])
</syntaxhighlight>

You cannot refer to OOP methods directly -- to do so, enclose the function call in a func() { } block as such:
<syntaxhighlight lang="nasal">
signal.listener = setlistener(node, func() { me.phaseFunc(); }, 0, 0);
</syntaxhighlight>

=== <tt>removelistener()</tt> ===

Syntax:

<syntaxhighlight lang="nasal">
var num_listeners = removelistener(<listener id>);
</syntaxhighlight>

<tt>removelistener()</tt> takes one argument: the unique listener id that a <tt>setlistener()</tt> call returned. It returns the number of remaining active Nasal listeners on success, <tt>nil</tt> on error, or -1 if a listener function applies <tt>removelistener()</tt> to itself. The fact that a listener can remove itself, can be used to implement a one-shot listener function:

<syntaxhighlight lang="nasal">
var L = setlistener("/some/property", func {
print("I can only be triggered once.");
removelistener(L);
});
</syntaxhighlight>

{{FGCquote
|1= For those not following all the cvs logs: I've added a new function to Nasal a few days ago: removelistener(). It takes one argument -- the unique id number of a listener as returned by setlistener(): var foo = setlistener("/sim/foo", die); ... removelistener(foo); This can be used to remove all listeners in an <unload> part that were set by the <load> part of a scenery object: <load> listener = []; append(listener, setlistener("/sim/foo", die)); append(listener, setlistener("/sim/bar", func {}); ... </load> <unload> foreach (l; listener) { removelistener(l) } </unload> screen.nas stores all relevant listener ids in a hash, so that other parts can, for example, remove the mapping of pilot messages to screen and voice): removelistener(screen.listener["pilot"]); The id is 0 for the first listener, 1 for the second etc. removelistener() returns the total number of remaining listeners, or nil on error (i.e. if there was no listener known with this id). This can be used for statistics: id = setlistener("/sim/signals/quit", func {}); # let's not count this one num = removelistener(id); print("there were ", id, " Nasal listeners attached since fgfs was started"); print("of which ", num, " are still active"); m.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/12102466/
| title = <nowiki>[Flightgear-devel] Nasal: new command "removelistener()"</nowiki>
| author = <nowiki>Melchior FRANZ</nowiki>
| date = Mar 2nd, 2006
| added = Mar 2nd, 2006
| script_version = 0.23
}}
}}

=== Listener Examples ===

The following example attaches an anonymous callback function to a "signal". The function will be executed when FlightGear is closed.

<syntaxhighlight lang="nasal">
setlistener("/sim/signals/exit", func { print("bye!") });
</syntaxhighlight>

Instead of an anonymous function, a named function can be used as well:

<syntaxhighlight lang="nasal">
var say_bye = func { print("bye") }
setlistener("/sim/signals/exit", say_bye);
</syntaxhighlight>

Callback functions can, optionally, access up to four parameters which are handed over via regular function arguments. Many times none of these parameters is used at all, as in the above example.

Most often, only the first parameter is used--which gives the node of the changed value.

The following code attaches the monitor_course() function to a gps property, using the argument ''course'' to get the node with the changed value.

<syntaxhighlight lang="nasal">
var monitor_course = func(course) {
print("Monitored course set to ", course.getValue());
}
var i = setlistener("instrumentation/gps/wp/leg-course-deviation-deg", monitor_course);

# here the listener is active

removelistener(i); # remove that listener again
</syntaxhighlight>

Here is code that accesses two arguments--the changed node and the listened-to node (these may be different when monitoring all children of a certain node)--and also shows how to monitor changes to a node including changes to children:

<syntaxhighlight lang="nasal">
var monitor_course = func(course, flightinfo) {
print("One way to get the course setting: ", flightinfo.leg-course-deviation-deg.getValue());
print("Another way to get the same setting ", course.getValue());
}
var i = setlistener("instrumentation/gps/wp", monitor_course, 0, 2);
</syntaxhighlight>

The function object doesn't need to be a separate, external function -- it can also be an anonymous function made directly in the <tt>setlistener()</tt> call:

<syntaxhighlight lang="nasal">
setlistener("/sim/signals/exit", func { print("bye") }); # say "bye" on exit
</syntaxhighlight>

Beware, however, that the contents of a function defined within the <tt>setlistener</tt> call are not evaluated until the call is actually made. If, for instance, local variables change before the setlistener call happens, the call will reflect the current value of those variables ''at the time the callback function is called'', not the value ''at the time the listener was set''.

For example, with this loop, the function will always return the value 10--even if mynode[1], mynode[2], mynode[3] or any of the others is the one that changed. It is because the contents of the setlistener are evaluated after the loop has completed running and at that point, i=10:

<syntaxhighlight lang="nasal">
var output = func(number) {
print("mynode", number, " has changed!"); #This won't work!
}
for(i=1; i <= 10; i = i+1) {
var i = setlistener("mynode["~i~"]", func{ output (i); });
}
</syntaxhighlight>

You can also access the four available function properties (or just one, two, or three of them as you need) in your anonymous function. Here is an example that accesses the first value:

<syntaxhighlight lang="nasal">
for(i=1; i <= 10; i = i+1) {
var i = setlistener("mynode["~i~"]", func (changedNode) { print (changedNode.getPath() ~ " : " ~ changedNode.getValue()); });
}
</syntaxhighlight>

Attaching a function to a node that is specified as <tt>props.Node()</tt> hash:

<syntaxhighlight lang="nasal">
var node = props.globals.getNode("/sim/signals/click", 1);
setlistener(node, func { gui.popupTip("don't click here!") });
</syntaxhighlight>

Sometimes it is desirable to call the listener function initially, so that it can pick up the node value. In the following example a listener watches the view number, and turns the HUD on in cockpit view, and off in all other views. It doesn't only do that on writing to "view-number", but also once when the listener gets attached, thanks to the third argument "1":

<syntaxhighlight lang="nasal">
setlistener("/sim/current-view/view-number", func(n) {
setprop("/sim/hud/visibility[0]", n.getValue() == 0);
}, 1);
</syntaxhighlight>

There's no limit for listeners on a node. Several functions can get attached to one node, just as one function can get attached to several nodes. Listeners may write to the node they are listening to. This will not make the listener call itself causing an endless recursion.

=== Signals ===

In addition to "normal" nodes, there are "signal" nodes that were created solely for the purpose of having listeners attached:

* <tt>/sim/signals/exit</tt> ... set to "true" on quitting FlightGear
* <tt>/sim/signals/reinit</tt> ... set to "true" right before repositioning the aircraft, and to "false" when the teleport has been completed
* <tt>/sim/signals/click</tt> ... set to "true" after a mouse click at the terrain. Hint that the geo coords for the click spot were updated and can be retrieved from /sim/input/click/{longitude-deg,latitude-deg,elevation-ft,elevation-m}
* <tt>/sim/signals/screenshot</tt> ... set to "true" right before the screenshot is taken, and set to "false" after it. Can be used to hide and reveal dialogs etc.
* <tt>/sim/signals/nasal-dir-initialized</tt> ... set to "true" after all Nasal "library" files in [[$FG_ROOT]]/Nasal/ were loaded and executed. It is only set once and can only be used to trigger listener functions that were defined in one of the Nasal files in that directory. After that signal was set Nasal starts loading and executing aircraft Nasal files, and only later are <tt>settimer()</tt> functions called and the next signal is set:
* <tt>/sim/signals/fdm-initialized</tt> ... set to "true" when then FDM has just finished its initialization
* <tt>/sim/signals/reinit-gui</tt> ... set to "true" when the GUI has just been reset (e.g. via Help menu). This is used by the gui.Dialog class to reload Nasal-loaded XML dialogs.
* <tt>/sim/signals/frame</tt> ... triggered at the beginning of each iteration of the main loop (a.k.a. "frame"). This is meant for debugging purposes. Normally, one would just use a settimer() with interval 0 for the same effect. The difference is that the signal is guaranteed to be raised at a defined moment, while the timer call may change when subsystems are re-ordered.

=== Nasal code coupled to the autopilot system ===
{{Callback Disclaimer}}

Some people have a need to run Nasal code at the same rate as the simulation/FDM. Currently, without modifying the source code for FlightGear, the only way to do this is to find a property updated at the right time in the simulation cycle and set a listener on it. From a code quality standpoint, this is less than ideal.

Autopilot rules, FDM and important instruments run at fixed rate of 120Hz and are already _independant_ of frame rate (Note: this does not help those who try to implement APs manually using Nasal, since Nasal can only run at frame rate. But please do use the "autopilot property rule" system for the fast control part of the autopilot - and only do slow stuff in Nasal (such as switching between autopilot modes), which does not require a close coupling to the FDM/autopilot. The 777 is a good example showing this: dynamic part of AP is done by property rules; switching between AP modes, like "hold glideslope" => "flare" is done in Nasal).

The FDM runs 120 times per second (if so configured), but it runs all iterations for a frame one after the other, then waits until the next frame. The FDM runs at 120 hertz and with a fixed time step.

However, we play one small trick to make that happen. We take the time that has elapsed since the last frame, compute how many whole iterations of the
FDM will fit in that time slice (at 1/120th of a second per iteration.) Then we invoke the FDM that many times with a time step of 1/120th of a
second. Finally we save out the remainder and add that into the next time slice.

This can produce a small amount of temporal jitter between the graphics and the fdm if the graphics frame rates are not a diviser of 120. In the best
case scenario, you've locked your graphics frame rate to 60 hz so the FDM runs exactly 2 iterations every time it is invoked and there is no temporal
jitter at all, ever.

One thing to keep in mind is that handing a different size time slice to the FDM every frame (and sometimes that time slice could be 1 second or more?)
can lead to instabilities in the math. So our approach is intended to avoid that potential problem. As far as the FDM is concerned, it *is* running
asyncronously, at a fixed time step. But, we are playing a little trick on the FDM (it doesn't care) in order to handle the unfortunate possibility of
non-fixed and highly variable frame rates on PC hardware running consumer grade operating systems.

Some FDM stuff would like to be tied to the FDM update rate, and that's a desirable goal. What about a callback function then? The FDM subsystem would set /sim/signals/fdm-update, and you could attach a listener to that which does all the things that should interact with the FDM, such as AP, FCS, etc. The rest of Nasal would keep running with the frame rate.

There's just one (minor) problem at the moment. There's no generic FDM update() function where one could put a sig.setDoubleValue(dt).This would have to be done in all FDMs.

Another possibility is to extend the declarative expression logic, which is already supported by the autopilot components, to allow a Nasal expression. Then you mix the declarative components (which you're going to want for most autopilot laws) with some scripted ones.
Since the expression evaluation would be driven by the autopilot subsystem, it would run at whatever frame-rate that itself runs at - which is currently in lock-step with the FDM [http://forum.flightgear.org/viewtopic.php?f=46&t=17069&hilit=nasal+fdm+autopilot&start=15#p165596].

There are several other options, such as 1) Run a second events system and add an additional parameter to Nasal's settimer allowing you to use this new events system. 2) Add in a signal that is fired each simulation step, probably right before the Autopilot system is run:

<syntaxhighlight lang="nasal">
setlistener("/sim/signals/fdm-update", func(n) {
var dt = n.getValue();
# ... and whatever needs to be done at fdm rate
});
</syntaxhighlight>

Some core developers are fairly opposed to the whole idea, i.e. want to avoid *any* Nasal in the fast simulation loop of the FDM, because Nasal execution is slow and non-deterministic because of its GC issue. Running it in the fast simulation loop is the last thing they want[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38172.html].

In addition, the developer and maintainer of the AP system is planning on adding Nasal bindings to the AP code to allow runtime instantiation of ap/property rules and has a Nasal binding for that in mind[http://forum.flightgear.org/viewtopic.php?f=66&t=15189&p=149376&hilit=#p149376].

You can then use Nasal for the high level stuff, and enable/disable/switch the individual controller elements (e.g. in order to automatically switch the autopilot mode when capturing the ILS). There are some nice examples with fgdata/Git aircraft. You could look at the 777.

The big advantage of the property rules is that they don't produce garbage that a garbage collector has to clean up. But as nothing in life comes for free (except FlightGear, of course) XML tends to be much more verbose.

Guideline
* Computing properties from a well defined set of other properties once per frame: use a property rule.
* If there is no other way to get it done: use Nasal.

This is also how such things are done in the real world: controllers aren't implemented in imperative programming languages these days - especially not in scripting languages. People use model-based design and connect controller elements - using graphical tools like MATLAB/Simulink. Obviously, FG is missing a graphical interface to specify the controller rules - but the idea of specifying through XML is the same and specification is straight forward.

Creating an autopilot (or any GNC or system model, for that matter) can be done very effectively with discrete objects such as summers, gains, controllers, filters, switches, etc., much as JSBSim has done with the system components. This is a standard approach in industry, as exemplified by Mathwork's $imulink product.

Scilab/Scicos is similar in concept. Control system topologies are often diagrammed in a way that can lead to a one-to-one correspondence between a
block and a control system object that can be referenced in an XML file, if the control system component library has been defined properly. This, again,
is the way that JSBSim has approached the solution.

Some benefits to such an approach include better testability, more predictability, and easier interface (someday) with a GUI tool, should one
materialize. The downside is that XML can be verbose.

All that being said, it is definitely possible to run Nasal in the FDM update loop, so to make up your own mind, you could try this:
Alternatively, as a short-term solution that does not rely on editing C++ code, you could just trigger off an internal autopilot property.
Which is a pretty clever workaround: trigger a boolean property for each iteration, so that the Nasal listener can pick it up, which will get invoked at FDM update rate that way.

Perhaps we could set up a trigger that is fired by the Autopilot subsystem, immediately before the autopilot executes. However, someone more familiar with FG's code base than me can probably come up with a more elegant solution. I feel like adding a new events system and a parameter to settimer is cleaner than a signal -- and that if a signal is added, the Autopilot subsystem is probably not the place to add it.

Also see:
* http://forum.flightgear.org/viewtopic.php?f=66&t=15189&p=149376&#p149376
* http://forum.flightgear.org/viewtopic.php?f=46&t=17069
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38170.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13022.html
* https://code.google.com/p/flightgear-bugs/issues/detail?id=421

Saab 35 Draken

2023-02-18T15:38:10Z

AndersM: /* Special indicators */ plané info

{{:{{PAGENAME}}/info}}
The '''Saab J35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit images.

=== Special aircraft keys ===
{| class="keytable"
! Key
! Function
|-
| {{key press|Shift|S}}
| Automatic start sequence including all systems. (The aircraft needs to be stationary.)
|-
| {{key press|Shift|L}}
| Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
|-
| {{key press|Ctrl|J}}
| Jettison drop tanks in air.
|-
| {{key press|Ctrl|D}}
| Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks
|-
| {{key press|Shift|Q}}
| Fuel cut off, not normally needed.
|-
| {{key press|Shift|P}}
| Use drag chute handle
|-
| {{key press|e}}
| Fire ADEN 30mm cannon (100 rounds available, 1700 rounds per minute)
|-
| {{key press|z}}
|Sight ring: Decreased distance
|-
| {{key press|Shift|Z}}
| Sight ring: Increased distance
|}

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below.

*HÖJDV: Flashes when autopilot HÖJD (altitude hold) is set and aircraft not at target altitude or vertical speed above 200 m/min. Lit when stable at target altitude. It is recommended to be at target altitude before setting autopilot to HÖJD.
*Landing gear down and locked: (LANDSTÄLL LÅST UTE) Green lights front lower left

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of drop-tanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7). Click for PLANÉ mode.

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Only a limited simulation of the radar is implemented:

* Showing a sweep and antenna azimut. (mode TYST and SÄND)

* In multiplayer the radar shows aircrafts in radar range: dist < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground. (mode SÄND)

Radar Modes. Set by radar panel on the right side of cockpit(16):

FRÅN: Power off

BER: Readies radar for transmission. Takes 20 sec (In reality 3 min)

TILL: Like BER but sights and weapon connections also ready. (Same as BER in the simulation.)

TYST: Everything running but no emissions from antenna.

SÄND: Everything running and antenna emitting.

Yellow lines are navigation indicators used by the navigation system. See below.

Knobs on radar panel set intensity of scope (LJUSSTYRKA FSKOP) and navigation lines (KORSVISARE).

'''Radio'''

The radio equipment consists of two transceiver and one control unit of model Fr-21. They are on the left horizontal panel.(14) In the simulation both transceivers are used for communication. In the real aircraft one was the receiver for combat control data feeding the AHK and other avionics. The letters A-K stores pre set frequencies for transceiver A (closest to the control unit) and the numbers 1-5 stores pre set frequencies for transceiver B. A stores the COM1 frequency at FG start up. Number 1 stores the COM2 frequency at FG start up. The frequency for the other letters and numbers are in the text file Avionics/Fr21.txt and can be changed by the user. Pressing the buttons marked with dash (-) makes it possible to manually set the transceiver’s frequency using the knobs on the unit. The radio is off at simulation start. Transceiver B uses battery power and transceiver A uses main AC.

'''Autopilot'''

The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold. If plané on altitude selector the autopilot will folow a glide slope of approx 3 degrees.
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''Navigation radio and mode selector'''

Right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, AHK 0, cn manual, Radar lines parked.
*FÖRV: (Preselected) No nav radio, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*STRIL: (Combat control) Activates Route Manager, AHK NYTT MÅL, cn direction to next waypoint, Radar lines parked.
*STRID: (Combat) No nav info, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction line, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR. In plané mode a glideslope will also be shown on radar.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon. In plané mode a glideslope will also be shown on radar.
*LANDN 40: (Landing 40 km) Uses ILS set by the three letters. Radar shows direction line and glide path, AHK LANDA, cn direction to ILS beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters. Radar shows direction line, AHK BARBRO, cn direction to ILS beacon.

'''Controls and switches'''

* Drag chute handle: (BROMSFALLSKÄRM) Lower left.(15) First use deploys drag chute. Second drops it. It takes approx. 3 seconds to deploy and should be done under 320 km/h and above 200 km/h. The handle can not be used if throttle above 85%.
* Throttle: (GASKRAN) lower left.
* Landing gear: (LAND-STÄLL) lower left.
* Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Landing light switches: (LAND TAXI) Left front canopy rim.(12) Left and right landing light. If switches are in on position the lights will be automatically turned on/off as landing gear are lowered/rised.
*Navigation lights: (LANTERNOR) Right aft panel.(13) Four settings off, bright, blinking and dim.
*Indicator lights: (IND. LAMPOR) Sets full or half intensity of indicator lights and caution panel,
*Instrument lighting: (INST-LYSE) Left side above throttle. (1) Sets the brightness of the red instrument lighting.
*Consol light: (KONS_LYSE) Left side above throttle.(1) Sets the brightness of the consol lights illuminating the left and right consols.
*Cabin light: (KABIN LYSE) Left side above throttle.(1) Turns cabin light on or off.
*Clock ring: Knob right of clock turns the ring. Set pointing to the minutehand before lift off to keep track of flying time.
*Start panel: Lower left instrument panel.(2) Se below.

====== Weapons and sight ======
ADEN 30 mm cannon implemented. Choose AKAN with weapon chooser knob. Right side radar panel(16). If AKAN is selected a gyroscopic gun sight is projected. Use knob on the sights right side(17) to set target wing span and keyboard controls (z/Z) to adjust ring diameter. Nose wheel needs to be up for weapons to function.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* It is neutral in roll at low alpha. Keep an eye on the horizon.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 270 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

Lift off: Rotate at 270 km/h to 10-12 degrees pitch. Lift off at approx 300 km/h. Turn of afterburner at 500 km/h if not needed for climbing. Normal climb speed Mach 0.9.

Landing: Lower speed to 500 km/h. Lower gears and turn on landing lights. Turn to final lowering the speed to 325 km/h. Keep a speed of 300 km/h and a plané of 3 degrees (100 m at 2 km distance), RPM 80-85%. After touchdown raise the nose up to increase drag until speed is 240 km/h. Apply brakes. Lower nose at 160 km/h.

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

{{Saab}}

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engine jets]]

Saab 35 Draken

2023-02-18T15:21:54Z

AndersM: updated numbering

{{:{{PAGENAME}}/info}}
The '''Saab J35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit images.

=== Special aircraft keys ===
{| class="keytable"
! Key
! Function
|-
| {{key press|Shift|S}}
| Automatic start sequence including all systems. (The aircraft needs to be stationary.)
|-
| {{key press|Shift|L}}
| Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
|-
| {{key press|Ctrl|J}}
| Jettison drop tanks in air.
|-
| {{key press|Ctrl|D}}
| Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks
|-
| {{key press|Shift|Q}}
| Fuel cut off, not normally needed.
|-
| {{key press|Shift|P}}
| Use drag chute handle
|-
| {{key press|e}}
| Fire ADEN 30mm cannon (100 rounds available, 1700 rounds per minute)
|-
| {{key press|z}}
|Sight ring: Decreased distance
|-
| {{key press|Shift|Z}}
| Sight ring: Increased distance
|}

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below.

*HÖJDV: Flashes when autopilot HÖJD (altitude hold) is set and aircraft not at target altitude or vertical speed above 200 m/min. Lit when stable at target altitude. It is recommended to be at target altitude before setting autopilot to HÖJD.
*Landing gear down and locked: (LANDSTÄLL LÅST UTE) Green lights front lower left

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of drop-tanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7)

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Only a limited simulation of the radar is implemented:

* Showing a sweep and antenna azimut. (mode TYST and SÄND)

* In multiplayer the radar shows aircrafts in radar range: dist < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground. (mode SÄND)

Radar Modes. Set by radar panel on the right side of cockpit(16):

FRÅN: Power off

BER: Readies radar for transmission. Takes 20 sec (In reality 3 min)

TILL: Like BER but sights and weapon connections also ready. (Same as BER in the simulation.)

TYST: Everything running but no emissions from antenna.

SÄND: Everything running and antenna emitting.

Yellow lines are navigation indicators used by the navigation system. See below.

Knobs on radar panel set intensity of scope (LJUSSTYRKA FSKOP) and navigation lines (KORSVISARE).

'''Radio'''

The radio equipment consists of two transceiver and one control unit of model Fr-21. They are on the left horizontal panel.(14) In the simulation both transceivers are used for communication. In the real aircraft one was the receiver for combat control data feeding the AHK and other avionics. The letters A-K stores pre set frequencies for transceiver A (closest to the control unit) and the numbers 1-5 stores pre set frequencies for transceiver B. A stores the COM1 frequency at FG start up. Number 1 stores the COM2 frequency at FG start up. The frequency for the other letters and numbers are in the text file Avionics/Fr21.txt and can be changed by the user. Pressing the buttons marked with dash (-) makes it possible to manually set the transceiver’s frequency using the knobs on the unit. The radio is off at simulation start. Transceiver B uses battery power and transceiver A uses main AC.

'''Autopilot'''

The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''Navigation radio and mode selector'''

Right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, AHK 0, cn manual, Radar lines parked.
*FÖRV: (Preselected) No nav radio, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*STRIL: (Combat control) Activates Route Manager, AHK NYTT MÅL, cn direction to next waypoint, Radar lines parked.
*STRID: (Combat) No nav info, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction line, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon.
*LANDN 40: (Landing 40 km) Uses ILS set by the three letters. Radar shows direction line and glide path, AHK LANDA, cn direction to ILS beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters. Radar shows direction line, AHK BARBRO, cn direction to ILS beacon.

'''Controls and switches'''

* Drag chute handle: (BROMSFALLSKÄRM) Lower left.(15) First use deploys drag chute. Second drops it. It takes approx. 3 seconds to deploy and should be done under 320 km/h and above 200 km/h. The handle can not be used if throttle above 85%.
* Throttle: (GASKRAN) lower left.
* Landing gear: (LAND-STÄLL) lower left.
* Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Landing light switches: (LAND TAXI) Left front canopy rim.(12) Left and right landing light. If switches are in on position the lights will be automatically turned on/off as landing gear are lowered/rised.
*Navigation lights: (LANTERNOR) Right aft panel.(13) Four settings off, bright, blinking and dim.
*Indicator lights: (IND. LAMPOR) Sets full or half intensity of indicator lights and caution panel,
*Instrument lighting: (INST-LYSE) Left side above throttle. (1) Sets the brightness of the red instrument lighting.
*Consol light: (KONS_LYSE) Left side above throttle.(1) Sets the brightness of the consol lights illuminating the left and right consols.
*Cabin light: (KABIN LYSE) Left side above throttle.(1) Turns cabin light on or off.
*Clock ring: Knob right of clock turns the ring. Set pointing to the minutehand before lift off to keep track of flying time.
*Start panel: Lower left instrument panel.(2) Se below.

====== Weapons and sight ======
ADEN 30 mm cannon implemented. Choose AKAN with weapon chooser knob. Right side radar panel(16). If AKAN is selected a gyroscopic gun sight is projected. Use knob on the sights right side(17) to set target wing span and keyboard controls (z/Z) to adjust ring diameter. Nose wheel needs to be up for weapons to function.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* It is neutral in roll at low alpha. Keep an eye on the horizon.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 270 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

Lift off: Rotate at 270 km/h to 10-12 degrees pitch. Lift off at approx 300 km/h. Turn of afterburner at 500 km/h if not needed for climbing. Normal climb speed Mach 0.9.

Landing: Lower speed to 500 km/h. Lower gears and turn on landing lights. Turn to final lowering the speed to 325 km/h. Keep a speed of 300 km/h and a plané of 3 degrees (100 m at 2 km distance), RPM 80-85%. After touchdown raise the nose up to increase drag until speed is 240 km/h. Apply brakes. Lower nose at 160 km/h.

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

{{Saab}}

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engine jets]]

File:Saab J35 cockpit.jpg

2023-02-18T15:11:31Z

AndersM: AndersM uploaded a new version of File:Saab J35 cockpit.jpg

=={{int:filedesc}}==
{{Information
|description={{en|1=Cockpit of the [[Saab 35 Draken|Saab J35 Draken]].}}
|date=2013-03-04
|source={{own}}
|author=[[User:Gijs|Gijs]]
|permission=
|other_versions=
|other_fields=
}}

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

[[Category:Saab 35 Draken cockpit screenshots]]

Saab 35 Draken

2023-02-18T14:45:01Z

AndersM: /* Special indicators */ Updated 2023 version of model

{{:{{PAGENAME}}/info}}
The '''Saab J35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit images.

=== Special aircraft keys ===
{| class="keytable"
! Key
! Function
|-
| {{key press|Shift|S}}
| Automatic start sequence including all systems. (The aircraft needs to be stationary.)
|-
| {{key press|Shift|L}}
| Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
|-
| {{key press|Ctrl|J}}
| Jettison drop tanks in air.
|-
| {{key press|Ctrl|D}}
| Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks
|-
| {{key press|Shift|Q}}
| Fuel cut off, not normally needed.
|-
| {{key press|Shift|P}}
| Use drag chute handle
|-
| {{key press|e}}
| Fire ADEN 30mm cannon (100 rounds available, 1700 rounds per minute)
|-
| {{key press|z}}
|Sight ring: Decreased distance
|-
| {{key press|Shift|Z}}
| Sight ring: Increased distance
|}

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below.

*HÖJDV: Flashes when autopilot HÖJD (altitude hold) is set and aircraft not at target altitude or vertical speed above 200 m/min. Lit when stable at target altitude. It is recommended to be at target altitude before setting autopilot to HÖJD.
*Landing gear down and locked: (LANDSTÄLL LÅST UTE) Green lights front lower left

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of drop-tanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7)

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Only a limited simulation of the radar is implemented:

* Showing a sweep and antenna azimut. (mode TYST and SÄND)

* In multiplayer the radar shows aircrafts in radar range: dist < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground. (mode SÄND)

Radar Modes (Set by radar panel on the right side of cockpit):

FRÅN: Power off

BER: Readies radar for transmission. Takes 20 sec (In reality 3 min)

TILL: Like BER but sights and weapon connections also ready. (Same as BER in the simulation.)

TYST: Everything running but no emissions from antenna.

SÄND: Everything running and antenna emitting.

Yellow lines are navigation indicators used by the navigation system. See below.

Knobs on radar panel set intensity of scope (LJUSSTYRKA FSKOP) and navigation lines (KORSVISARE).

'''Radio'''

The radio equipment consists of two transceiver and one control unit of model Fr-21. They are on the left horizontal panel. In the simulation both transceivers are used for communication. In the real aircraft one was the receiver for combat control data feeding the AHK and other avionics. The letters A-K stores pre set frequencies for transceiver A (closest to the control unit) and the numbers 1-5 stores pre set frequencies for transceiver B. A stores the COM1 frequency at FG start up. Number 1 stores the COM2 frequency at FG start up. The frequency for the other letters and numbers are in the text file Avionics/Fr21.txt and can be changed by the user. Pressing the buttons marked with dash (-) makes it possible to manually set the transceiver’s frequency using the knobs on the unit. The radio is off at simulation start. Transceiver B uses battery power and transceiver A uses main AC.

'''Autopilot'''

The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''Navigation radio and mode selector'''

3D model right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, AHK 0, cn manual, Radar lines parked.
*FÖRV: (Preselected) No nav radio, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*STRIL: (Combat control) Activates Route Manager, AHK NYTT MÅL, cn direction to next waypoint, Radar lines parked.
*STRID: (Combat) No nav info, AHK HÖJDÄNDRING, cn manual, Radar lines parked.
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction line, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction line, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon.
*LANDN 40: (Landing 40 km) Uses ILS set by the three letters. Radar shows direction line and glide path, AHK LANDA, cn direction to ILS beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters. Radar shows direction line, AHK BARBRO, cn direction to ILS beacon.

'''Controls and switches'''

* Drag chute handle: (BROMSFALLSKÄRM) Lower left. First use deploys drag chute. Second drops it. It takes approx. 3 seconds to deploy and should be done under 320 km/h and above 200 km/h. The handle can not be used if throttle above 85%.
* Throttle: (GASKRAN) lower left.
* Landing gear: (LAND-STÄLL) lower left.
* Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Landing light switches: (LAND TAXI) Left front canopy rim.(12) Left and right landing light. If switches are in on position the lights will be automatically turned on/off as landing gear are lowered/rised.
*Navigation lights: (LANTERNOR) Right aft panel.(13) Four settings off, bright, blinking and dim.
*Indicator lights: (IND. LAMPOR) Sets full or half intensity of indicator lights and caution panel,
*Instrument lighting: (INST-LYSE) Left side above throttle. (2) Sets the brightness of the red instrument lighting.
*Consol light: (KONS_LYSE) Left side above throttle. Sets the brightness of the consol lights illuminating the left and right consols.
*Cabin light: (KABIN LYSE) Left side above throttle. Turns cabin light on or off.
*Clock ring: Knob right of clock turns the ring. Set pointing to the minutehand before lift off to keep track of flying time.
*Start panel: Lower left instrument panel. Se below.

====== Weapons and sight ======
ADEN 30 mm cannon implemented. Choose AKAN with weapon chooser knob. (Right side radar panel). If AKAN is selected a gyroscopic gun sight is projected. Use knob on the sights right side to set target wing span and keyboard controls (z/Z) to adjust ring diameter. Nose wheel needs to be up for weapons to function.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* It is neutral in roll at low alpha. Keep an eye on the horizon.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 270 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

Lift off: Rotate at 270 km/h to 10-12 degrees pitch. Lift off at approx 300 km/h. Turn of afterburner at 500 km/h if not needed for climbing. Normal climb speed Mach 0.9.

Landing: Lower speed to 500 km/h. Lower gears and turn on landing lights. Turn to final lowering the speed to 325 km/h. Keep a speed of 300 km/h and a plané of 3 degrees (100 m at 2 km distance), RPM 80-85%. After touchdown raise the nose up to increase drag until speed is 240 km/h. Apply brakes. Lower nose at 160 km/h.

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

{{Saab}}

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engine jets]]

Saab 35 Draken

2023-02-18T14:27:36Z

AndersM: /* Special aircraft keys */ Updated

{{:{{PAGENAME}}/info}}
The '''Saab 35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit image.

=== Special aircraft keys ===
{| class="keytable"
! Key
! Function
|-
| {{key press|Shift|S}}
| Automatic start sequence including all systems. (The aircraft needs to be stationary.)
|-
| {{key press|Shift|L}}
| Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
|-
| {{key press|Ctrl|J}}
| Jettison drop tanks in air.
|-
| {{key press|Ctrl|D}}
| Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks
|-
| {{key press|Shift|Q}}
| Fuel cut off, not normally needed.
|-
| {{key press|Shift|P}}
| Use drag chute handle
|-
| {{key press|e}}
| Fire ADEN 30mm cannon (100 rounds available, 1700 rounds per minute)
|-
| {{key press|z}}
|Sight ring: Decreased distance
|-
| {{key press|Shift|Z}}
| Sight ring: Increased distance
|}

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below.

*HÖJDV: Flashes when autopilot HÖJD (altitude hold) is set and aircraft not at target altitude or vertical speed above 200 m/min. Lit when stable at target altitude. It is recommended to be at target altitude before setting autopilot to HÖJD.

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of drop-tanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7)

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Showing a sweep and antenna azimuth as well as navigation indicators.
In multiplayer the radar shows aircraft in radar range: dist. < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground.
Yellow lines are navigation indicators used by the navigation system. See below.
Radar modes are set on the navigation radio.

'''Radio'''

The radio equipment consists of two transceiver and one control unit of model Fr-21. They are on the left horizontal panel (14). In the simulation both transceivers are used for communication. In the real aircraft one was the receiver for combat control data feeding the AHK and other avionics. The letters A-K stores pre set frequencies for transceiver A (closest to the control unit) and the numbers 1-5 stores pre set frequencies fro transceiver B. A stores the COM1 frequency at FG start up, B stores COM1 standby frequency. Number 1 stores the COM2 frequency at FG start up, 2 stores COM2 standby frequency. The frequency for the other letters and numbers are in the text file Avionics/Fr21.txt and can be changed by the user.
Pressing the buttons marked with dash (-) makes it possible to manually set the transceiver’s frequency using the knobs on the unit.
The radio is off at simulation start. Transceiver B uses battery power and transceiver A uses main AC.

'''Autopilot'''

The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''Navigation radio and mode selector'''

3D model right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, Radar off, AHK 0, cn manual
*FÖRV: (Preselected) No nav radio, Radar off, AHK HÖJDÄNDRING, cn manual
*STRIL: (Combat command) Activates Route Manager, Radar scanning, AHK NYTT MÅL, cn direction to next waypoint.
*STRID: (Combat) No nav info, Radar scanning, AHK HÖJDÄNDRING, cn manual
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon.
*LANDN 40: (Landing 40 km) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK LANDA, cn direction to beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters NAV+LANDN. Radar shows glide slope pointers, AHK BARBRO, cn direction to ILS beacon.

'''Special Controls and switches'''
*Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Start panel: Lower left instrument panel.(2) Se below.
*Instrument and panel lighting: Left side knob above throttle.(1) Click to change intensity.
Landing/taxi light switches: Left front canopy rim (12). Left and right landing light. If switches are in on position the lights will be automatically turned on/off as landing gear are lowered/rised.
Navigation lights (sv. "Lanternor"): Right aft panel (13). Three settings are implemented; off, dim and bright.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* It is neutral in roll at low alpha. Keep an eye on the horizon.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 270 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

Lift off: Rotate at 270 km/h to 10-12 degrees pitch. Lift off at approx 300 km/h. Turn of afterburner at 500 km/h if not needed for climbing. Normal climb speed Mach 0.9.

Landing: Lower speed to 500 km/h. Lower gears and turn on landing lights. Turn to final lowering the speed to 325 km/h. Keep a speed of 300 km/h and a plané of 3 degrees (100 m at 2 km distance), RPM 80-85%. After touchdown raise the nose up to increase drag until speed is 240 km/h. Apply brakes. Lower nose at 160 km/h.

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

{{Saab}}

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engine jets]]

Mumble

2023-02-11T13:37:06Z

AndersM: Undo revision 137301 by AndersM (talk)

{{Infobox Software
| title = Mumble
| logo =
| image =
| alt =
| developedby = Various
| initialrelease = 2005
| latestrelease = 1.4.230 (stable)
| writtenin = C++
| os = Windows, OS X, Linux, Android, iOS
| platform = PC, Mac, smartphones
| developmentstatus =
| developmentprogress =
| type = Voice chat software
| license = [https://github.com/mumble-voip/mumble/blob/master/LICENSE Open source]
| website = https://mumble.info
}}

'''Mumble''' is a free, open source VoIP software used by some ATCs and pilots on the multiplayer network.

== Installation and configuration ==
# Download Mumble from its [https://mumble.info official website] (choose the links from the ''Stable Release'' column). If you're on Linux, you can usually install it using your package manager.
# Start it and follow the instructions on your screen to configure the program.
{{tip|We suggest to choose the '''Push-To-Talk''' mode in the '''Voice Activity Detection''' step; if you choose another mode, make sure to calibrate the volume levels correctly (follow the on-screen instructions carefully). This way, your voice will be transmitted only when you mean to, and there will be less background noise on the channel.}}

=== Binding '''Push-To-Talk''' to joystick button on linux ===

On linux you can enable generic input support by editing <code>~/.config/Mumble/Mumble.conf</code>. You need to add the following section:

<syntaxhighlight lang="ini" enclose="div">
[shortcut]
linux\evdev\enable=true
</syntaxhighlight>

''Note: This is correct: add the section as stated above; ignore the fact, that there is already a section [shortcuts].''

Make sure you have permission to access the input devices (typically called <code>/dev/input/event*</code>). You might need to add yourself to the appropriate group (for example <code>input</code>) or configure your device manager to grant access. Consult your OS documentation for details. {{Tip|<code>input-events</code> is a useful tool for troubleshooting.}}

''Note: # usermod YOUR_LOGIN_HERE -aG input should do the trick, where YOUR_LOGIN_HERE should be obviously replaced with obvious. Debianers might want to use # /sbin/usermod.''

''Note: input-events is part of the input-utils package.''

Proceed to launch mumble. If you are using a terminal, watch the output messages. You should see your input device listed, such as:

<code>GlobalShortcutX: /dev/input/event7: Saitek Cyborg Evo Force</code>

Open the settings dialog, go to the shortcuts tab and assign any button you like to the <code>Push-to-Talk</code> function.
{{Note|It may show up as nonsense but that is just a cosmetic issue. For example, one of my joystick buttons appears as {{button|semicolon}}. Nevertheless, it's still the joystick button and typing semicolon on the keyboard has no effect.}}

== Connecting ==
<ol>
<li>Click on {{Menu item|Server|Connect}}.</li>
<li>If this is the first time you connect to the FlightGear Mumble server, click on {{button|Add New...}} at the bottom of the window and input the following parameters, then click {{button|OK}}:
{| class="wikitable"
|-
| '''Label'''
| <tt>FlightGear ATC</tt> (or another descriptive name of your choice)
|-
| '''Address'''
| <tt>radio-mumble.flightgear.fr</tt>
|-
| '''Port'''
| <tt>64738</tt> (the default value)
|-
| '''Username'''
| A username (callsign) of your choice
|}</li>
<li>Select '''FlightGear ATC''' from the server list and click {{button|Connect}}.</li>
</ol>

== Using Mumble ==
When you are connected, Mumble will show a hierarchical list of channels on the right side of the main window.
* To enter an existing channel, right click on it and choose {{Menu item|Join Channel}}.
* To create a new channel (e.g. if you're acting as a controller), right click on the ''FlightGear'' channel and choose {{Menu item|Add}}. Input a name and (optionally) a description, then click {{button|OK}}.
{{note|The new channel is temporary and will be deleted when the last person in it exits the channel.}}
* To mute yourself, click the {{button|Mute}} button in the main toolbar.

=== Extensions ===
* [[FGCom-mumble]]: In addition to using plain mumble, you can also try the FGCom-mumble plugin, which provides realistic radio operation. This works for Mumble >= 1.4.0.

== OpenRadar flickering when using Mumble ==
If you're using Mumble and OpenRadar at the same time, you might notice that the OpenRadar screen flickers. A solution is disabling the Mumble overlay (in Mumble, click on {{Menu item|Configure|Settings}}, open the '''Overlay''' section, deselect '''Enable Overlay''' and click {{button|OK}}).

== See also ==
* [[Discord]]
* [[FGCom]]
* [[FGCom-mumble]]

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

Mumble

2023-02-11T13:34:42Z

AndersM: /* Connecting */ Uppdated server adress

{{Infobox Software
| title = Mumble
| logo =
| image =
| alt =
| developedby = Various
| initialrelease = 2005
| latestrelease = 1.4.230 (stable)
| writtenin = C++
| os = Windows, OS X, Linux, Android, iOS
| platform = PC, Mac, smartphones
| developmentstatus =
| developmentprogress =
| type = Voice chat software
| license = [https://github.com/mumble-voip/mumble/blob/master/LICENSE Open source]
| website = https://mumble.info
}}

'''Mumble''' is a free, open source VoIP software used by some ATCs and pilots on the multiplayer network.

== Installation and configuration ==
# Download Mumble from its [https://mumble.info official website] (choose the links from the ''Stable Release'' column). If you're on Linux, you can usually install it using your package manager.
# Start it and follow the instructions on your screen to configure the program.
{{tip|We suggest to choose the '''Push-To-Talk''' mode in the '''Voice Activity Detection''' step; if you choose another mode, make sure to calibrate the volume levels correctly (follow the on-screen instructions carefully). This way, your voice will be transmitted only when you mean to, and there will be less background noise on the channel.}}

=== Binding '''Push-To-Talk''' to joystick button on linux ===

On linux you can enable generic input support by editing <code>~/.config/Mumble/Mumble.conf</code>. You need to add the following section:

<syntaxhighlight lang="ini" enclose="div">
[shortcut]
linux\evdev\enable=true
</syntaxhighlight>

''Note: This is correct: add the section as stated above; ignore the fact, that there is already a section [shortcuts].''

Make sure you have permission to access the input devices (typically called <code>/dev/input/event*</code>). You might need to add yourself to the appropriate group (for example <code>input</code>) or configure your device manager to grant access. Consult your OS documentation for details. {{Tip|<code>input-events</code> is a useful tool for troubleshooting.}}

''Note: # usermod YOUR_LOGIN_HERE -aG input should do the trick, where YOUR_LOGIN_HERE should be obviously replaced with obvious. Debianers might want to use # /sbin/usermod.''

''Note: input-events is part of the input-utils package.''

Proceed to launch mumble. If you are using a terminal, watch the output messages. You should see your input device listed, such as:

<code>GlobalShortcutX: /dev/input/event7: Saitek Cyborg Evo Force</code>

Open the settings dialog, go to the shortcuts tab and assign any button you like to the <code>Push-to-Talk</code> function.
{{Note|It may show up as nonsense but that is just a cosmetic issue. For example, one of my joystick buttons appears as {{button|semicolon}}. Nevertheless, it's still the joystick button and typing semicolon on the keyboard has no effect.}}

== Connecting ==
<ol>
<li>Click on {{Menu item|Server|Connect}}.</li>
<li>If this is the first time you connect to the FlightGear Mumble server, click on {{button|Add New...}} at the bottom of the window and input the following parameters, then click {{button|OK}}:
{| class="wikitable"
|-
| '''Label'''
| <tt>FlightGear ATC</tt> (or another descriptive name of your choice)
|-
| '''Address'''
| mumble.flightgear.fr
|-
| '''Port'''
| <tt>64738</tt> (the default value)
|-
| '''Username'''
| A username (callsign) of your choice
|}</li>
<li>Select '''FlightGear ATC''' from the server list and click {{button|Connect}}.</li>
</ol>

== Using Mumble ==
When you are connected, Mumble will show a hierarchical list of channels on the right side of the main window.
* To enter an existing channel, right click on it and choose {{Menu item|Join Channel}}.
* To create a new channel (e.g. if you're acting as a controller), right click on the ''FlightGear'' channel and choose {{Menu item|Add}}. Input a name and (optionally) a description, then click {{button|OK}}.
{{note|The new channel is temporary and will be deleted when the last person in it exits the channel.}}
* To mute yourself, click the {{button|Mute}} button in the main toolbar.

=== Extensions ===
* [[FGCom-mumble]]: In addition to using plain mumble, you can also try the FGCom-mumble plugin, which provides realistic radio operation. This works for Mumble >= 1.4.0.

== OpenRadar flickering when using Mumble ==
If you're using Mumble and OpenRadar at the same time, you might notice that the OpenRadar screen flickers. A solution is disabling the Mumble overlay (in Mumble, click on {{Menu item|Configure|Settings}}, open the '''Overlay''' section, deselect '''Enable Overlay''' and click {{button|OK}}).

== See also ==
* [[Discord]]
* [[FGCom]]
* [[FGCom-mumble]]

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

Expressions

2023-02-02T17:46:42Z

AndersM: /* Supported elements */ Added child nodes

{{Stub}}
{{-}}
'''Expressions''' (or '''SGExpressions''') are a feature of the SimGear library and provide a nice way of implementing complex math formulas using XML syntax.
They are supported in many systems within the FlightGear code.

{{caution|Expressions do not check if your math creates floating point exceptions (like division by zero conditions, taking the square root of a negative number, etc.). This can cause undefined behavior and may result in NaNs or even Cascading NaNs.}}

== Usage ==
Expressions are supported in
* [[Autopilot Configuration Reference#Expressions|Autopilot configuration files]]
* Particle system configuration files
* Animations (translate, rotate, scale, range, blend)
* The shader technique

== Sample Expressions ==
This is a sample expression for <code>c = sqrt(a*a + b^2)</code>. Children/arguments are parsed in the order they appear in in the file (or the order in which they are set via property methods).
<syntaxhighlight lang="xml">
<expression>
<sqrt>
<sum>
<product>
<property>/value/a</property>
<property>/value/a</property>
</product>
<pow>
<property>/value/b</property>
<value>2</value>
</pow>
</sum>
</sqrt>
</expression>
</syntaxhighlight>

== Supported elements ==
<syntaxhighlight lang="xml">
<abs> 
<acos>
<asin>
<atan>
<atan2>
<ceil>
<clip> 
<cos>
<cosh>
<difference> 
<div>
<exp>
<floor>
<log>
<log10>
<max>
<min>
<mod>
<pow>
<product> 
<property> 
<rad2deg>
<deg2rad>
<sin>
<sinh>
<sqr>
<sqrt>
<sum>
<table> 
<tan>
<tanh>
<value>
</syntaxhighlight>

=== Table ===
The table expression uses the following syntax, similarly to the <interpolation> element:<syntaxhighlight lang="xml">
<table>

<dep>0.0</dep> 
</entry>
... 
</table>
</syntaxhighlight>

==== Example ====
The table:
{| class="wikitable"
|0.0
|5.0
|-
|0.5
|7.5
|-
|0.9
| -5.0
|-
|1.0
|25.0
|}
translates to the following code:<syntaxhighlight lang="xml">
<table>
<!-- put an input element here, this can be <property> or any other operation
<entry>
<ind>0.0</ind>
<dep>5.0</dep>
</entry>
<entry>
<ind>0.5</ind>
<dep>7.5</dep>
</entry>
<entry>
<ind>0.9</ind>
<dep>-5.0</dep>
</entry>
<entry>
<ind>1.0</ind>
<dep>25.0</dep>
</entry>
</table>
</syntaxhighlight>

===Clip===
An expression to limit e.g. rotation:
<syntaxhighlight lang="xml">
<expression>
<clip>
<clipMin>-45</clipMin>
<clipMax>45</clipMax>
<property>orientation/pitch-deg</property>
</clip>
</expression>
</syntaxhighlight>

== Hints and tips ==
=== Rounding ===
While there is no element for rounding, this workaround can be used for that:
<syntaxhighlight lang="xml">
<expression>
<floor>
<sum>
<property>your/property/here</property>
<value>0.5</value>
</sum>
</floor>
</expression>
</syntaxhighlight>

== Related content ==
=== Wiki articles ===
* [[Conditions]]
* [[PropertyList XML files]]

=== Source code ===
* {{simgear file|simgear/structure/SGExpression.hxx}}
* {{simgear file|simgear/structure/SGExpression.cxx}}

[[Category:XML]]

Expressions

2023-02-02T17:38:37Z

AndersM:

{{Stub}}
{{-}}
'''Expressions''' (or '''SGExpressions''') are a feature of the SimGear library and provide a nice way of implementing complex math formulas using XML syntax.
They are supported in many systems within the FlightGear code.

{{caution|Expressions do not check if your math creates floating point exceptions (like division by zero conditions, taking the square root of a negative number, etc.). This can cause undefined behavior and may result in NaNs or even Cascading NaNs.}}

== Usage ==
Expressions are supported in
* [[Autopilot Configuration Reference#Expressions|Autopilot configuration files]]
* Particle system configuration files
* Animations (translate, rotate, scale, range, blend)
* The shader technique

== Sample Expressions ==
This is a sample expression for <code>c = sqrt(a*a + b^2)</code>. Children/arguments are parsed in the order they appear in in the file (or the order in which they are set via property methods).
<syntaxhighlight lang="xml">
<expression>
<sqrt>
<sum>
<product>
<property>/value/a</property>
<property>/value/a</property>
</product>
<pow>
<property>/value/b</property>
<value>2</value>
</pow>
</sum>
</sqrt>
</expression>
</syntaxhighlight>

== Supported elements ==
<syntaxhighlight lang="xml">
<abs> 
<acos>
<asin>
<atan>
<atan2>
<ceil>
<clip>
<cos>
<cosh>
<difference> 
<div>
<exp>
<floor>
<log>
<log10>
<max>
<min>
<mod>
<pow>
<product> 
<property> 
<rad2deg>
<deg2rad>
<sin>
<sinh>
<sqr>
<sqrt>
<sum>
<table>
<tan>
<tanh>
<value>
</syntaxhighlight>

=== Table ===
The table expression uses the following syntax, similarly to the <interpolation> element:<syntaxhighlight lang="xml">
<table>

<dep>0.0</dep> 
</entry>
... 
</table>
</syntaxhighlight>

==== Example ====
The table:
{| class="wikitable"
|0.0
|5.0
|-
|0.5
|7.5
|-
|0.9
| -5.0
|-
|1.0
|25.0
|}
translates to the following code:<syntaxhighlight lang="xml">
<table>
<!-- put an input element here, this can be <property> or any other operation
<entry>
<ind>0.0</ind>
<dep>5.0</dep>
</entry>
<entry>
<ind>0.5</ind>
<dep>7.5</dep>
</entry>
<entry>
<ind>0.9</ind>
<dep>-5.0</dep>
</entry>
<entry>
<ind>1.0</ind>
<dep>25.0</dep>
</entry>
</table>
</syntaxhighlight>

===Clip===
An expression to limit e.g. rotation:
<syntaxhighlight lang="xml">
<expression>
<clip>
<clipMin>-45</clipMin>
<clipMax>45</clipMax>
<property>orientation/pitch-deg</property>
</clip>
</expression>
</syntaxhighlight>

== Hints and tips ==
=== Rounding ===
While there is no element for rounding, this workaround can be used for that:
<syntaxhighlight lang="xml">
<expression>
<floor>
<sum>
<property>your/property/here</property>
<value>0.5</value>
</sum>
</floor>
</expression>
</syntaxhighlight>

== Related content ==
=== Wiki articles ===
* [[Conditions]]
* [[PropertyList XML files]]

=== Source code ===
* {{simgear file|simgear/structure/SGExpression.hxx}}
* {{simgear file|simgear/structure/SGExpression.cxx}}

[[Category:XML]]

Expressions

2023-02-02T17:33:53Z

AndersM: Added clip example

{{Stub}}
{{-}}
'''Expressions''' (or '''SGExpressions''') are a feature of the SimGear library and provide a nice way of implementing complex math formulas using XML syntax.
They are supported in many systems within the FlightGear code.

{{caution|Expressions do not check if your math creates floating point exceptions (like division by zero conditions, taking the square root of a negative number, etc.). This can cause undefined behavior and may result in NaNs or even Cascading NaNs.}}

== Usage ==
Expressions are supported in
* [[Autopilot Configuration Reference#Expressions|Autopilot configuration files]]
* Particle system configuration files
* Animations (translate, rotate, scale, range, blend)
* The shader technique

== Sample Expressions ==
This is a sample expression for <code>c = sqrt(a*a + b^2)</code>. Children/arguments are parsed in the order they appear in in the file (or the order in which they are set via property methods).
<syntaxhighlight lang="xml">
<expression>
<sqrt>
<sum>
<product>
<property>/value/a</property>
<property>/value/a</property>
</product>
<pow>
<property>/value/b</property>
<value>2</value>
</pow>
</sum>
</sqrt>
</expression>
</syntaxhighlight>

An expression to limit e.g. rotation:
<syntaxhighlight lang="xml">
<expression>
<clip>
<clipMin>-45</clipMin>
<clipMax>45</clipMax>
<property>orientation/pitch-deg</property>
</clip>
</expression>
</syntaxhighlight>

== Supported elements ==
<syntaxhighlight lang="xml">
<abs> 
<acos>
<asin>
<atan>
<atan2>
<ceil>
<clip>
<cos>
<cosh>
<difference> 
<div>
<exp>
<floor>
<log>
<log10>
<max>
<min>
<mod>
<pow>
<product> 
<property> 
<rad2deg>
<deg2rad>
<sin>
<sinh>
<sqr>
<sqrt>
<sum>
<table>
<tan>
<tanh>
<value>
</syntaxhighlight>

=== Table ===
The table expression uses the following syntax, similarly to the <interpolation> element:<syntaxhighlight lang="xml">
<table>

<dep>0.0</dep> 
</entry>
... 
</table>
</syntaxhighlight>

==== Example ====
The table:
{| class="wikitable"
|0.0
|5.0
|-
|0.5
|7.5
|-
|0.9
| -5.0
|-
|1.0
|25.0
|}
translates to the following code:<syntaxhighlight lang="xml">
<table>
<!-- put an input element here, this can be <property> or any other operation
<entry>
<ind>0.0</ind>
<dep>5.0</dep>
</entry>
<entry>
<ind>0.5</ind>
<dep>7.5</dep>
</entry>
<entry>
<ind>0.9</ind>
<dep>-5.0</dep>
</entry>
<entry>
<ind>1.0</ind>
<dep>25.0</dep>
</entry>
</table>
</syntaxhighlight>

== Hints and tips ==
=== Rounding ===
While there is no element for rounding, this workaround can be used for that:
<syntaxhighlight lang="xml">
<expression>
<floor>
<sum>
<property>your/property/here</property>
<value>0.5</value>
</sum>
</floor>
</expression>
</syntaxhighlight>

== Related content ==
=== Wiki articles ===
* [[Conditions]]
* [[PropertyList XML files]]

=== Source code ===
* {{simgear file|simgear/structure/SGExpression.hxx}}
* {{simgear file|simgear/structure/SGExpression.cxx}}

[[Category:XML]]

Talk:FlightGear Qt launcher

2017-12-29T16:45:29Z

AndersM: /* Old and confusing */

== Old and confusing ==
Helping a new FG user I had a reason to check whats in the wiki on Launcher and fgrun etc. This article are not updated and therefore confusing for new users. Would be good if someone with knowledge of the current launcher situation under different OS could update this article.
--[[User:AndersM|AndersM]] ([[User talk:AndersM|talk]]) 11:41, 29 December 2017 (EST)

== To be incorporated ==

You /can/ set the download dir via the launcher, and the default TerraSync dir is $download_dir/TerraSync, so this is intended to make setting the TerraSync dir manually unnecessary.
<ref>{{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34992973/
| title = <nowiki>Re: [Flightgear-devel] Use of QSettings by the Qt launcher for
--terrasync-dir</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Apr 5th, 2016
| added = Apr 5th, 2016
| script_version = 0.25
}}
</ref>

the launcher itself never sets —terrasync-dir, only —download-dir. And if both are set, —terrasync-dir is used of course. So if you set —terrasync-dir manaully in additional settings, its value will be used.
<ref>{{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34992973/
| title = <nowiki>Re: [Flightgear-devel] Use of QSettings by the Qt launcher for
--terrasync-dir</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Apr 5th, 2016
| added = Apr 5th, 2016
| script_version = 0.25
}}
</ref>

{{FGCquote
|1= Based on recent discussion and confusion, I just pushed some changes to the launcher. I would appreciate testing and feedback on the exact wording, I am trying to avoid confusing users and encouraging novice users to change things they should not, while still giving advanced users the flexibility they need. - the ‘add-ons’ dialog is now a fourth page (tab), which solves some odd interaction problems and hopefully makes the ‘where is this setting’ more coherent
* the ‘restore settings’ button on the settings page now explains what it does more clearly, and warns that it will disturb the download and data settings. I *could* tweak the code to preserve the values of those settings but wipe all others, but that seems very baroque, so I prefer to simply warn users what will happen.
* adjusting the data path (which is now described as ’fg-data’) does not affect any other setting - there is more descriptive text in the add-ons page about what the data and download directories are for, and the consequences of changing them.
* Launcher settings are stored in .ini format in $FG_HOME/flightgear.org/FlightGear.ini The one missing piece is if you change the download dir, and hence lose the default / official aircraft hanger, there is is no UI to explain what you only have the C172 and UFO. I intend to add this to the aircraft list as a custom item (which can be dismissed), stating something like: [No aircraft hangars or folders are defined, so only the default aircraft are available. Use the add-ons page to add hangars or select aircraft folders, or <click here> to hide this message] Again, feedback on *all* of this wording is welcome, since what makes sense to me may not make sense to everyone. Please note I will probably reject /any/ wording or language which contains the following ‘path’ (generally I’m using ‘location’) ‘environment variable’ (avoiding mentioning these at all!) ‘executable’ (use ‘application’ or ‘program’ or ‘FlightGear’) ‘directory’ (use ‘folder’) All feedback and testing is much appreciated.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/35001457/
| title = <nowiki>[Flightgear-devel] Launcher add-on handling changes</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Apr 8th, 2016
| added = Apr 8th, 2016
| script_version = 0.25
}}
}}
<references/>

: I've added a remark about the fact that it is now unnecessary to set the TerraSync download directory explicitly and the path change for the launcher settings; I'm not sure, however, how to phrase the <tt>--download-dir</tt> vs. <tt>--terrasync-dir</tt> difference, and I wonder if it's worth including the remarks James made about the '''Restore settings''' button and the FGData path adjustment, as they are meant to be self-explanatory (I fear it only adds complexity to the page). What do you think? -- [[User:Elgaton|ElGaton]] ([[User talk:Elgaton|<tt>talk</tt> to me]]) 05:49, 1 May 2016 (EDT)

== replacing plib UI with Qt5 ==

@Red Leader: The reference used there is referring to the draft published originally (discussed on the devel list), since then, a number of senior contributors have explicitly stated that Qt is intended to always remain optional and that an integrated UI has to be provided for the non Qt use-case (and James confirmed that).

Looking at the current integration, none of the QT code is integrated in a way to be invoked at runtime:
<pre>
GUI/CMakeLists.txt:72:if (HAVE_QT)
GUI/MessageBox.cxx:34:#ifdef HAVE_QT
GUI/MessageBox.cxx:129:#elif defined(HAVE_QT)
GUI/MessageBox.cxx:148:#elif defined(HAVE_QT)
GUI/FileDialog.cxx:44:#if defined(HAVE_QT)
GUI/FileDialog.cxx:154:#elif defined(HAVE_QT)
Main/fg_commands.cxx:61:#if defined(HAVE_QT)
Main/fg_commands.cxx:994:#if defined(HAVE_QT)
Main/options.cxx:58:#if defined(HAVE_QT)
Main/options.cxx:2517:#if defined(HAVE_QT)
Main/options.cxx:2535:#if defined(HAVE_QT)
Main/main.cxx:84:#if defined(HAVE_QT)
Main/main.cxx:445:#if defined(HAVE_QT)
Viewer/WindowBuilder.cxx:28:#if defined(HAVE_QT) && defined(SG_MAC)
Viewer/WindowBuilder.cxx:256:#if defined(HAVE_QT) && defined(SG_MAC)
</pre>

So unless there's been a recent update/consensus here, I don't think the current wording is sufficiently accurate, certainly not in the light of the architecture/threading related observations made by a number of contributors.

The launcher itself is totally separate from the FlightGear main loop, and such does not have any immediate effect on the runtime UI (at least for the time being).
I think, we'd be hard pressed to find specific statements supporting this - so if you want to keep this in the article, it would be a good idea to ask for clarification on the devel list, or at least add supporting statements from other core developers.

In fact, the most recent comments regarding PLIB/PUI reiterate the idea to absorb the relevant PLIB components into SimGear<ref>http://sourceforge.net/p/flightgear/mailman/message/34921429/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/34921495/</ref>, and even James himself continues to make commits that would conflict with a Qt5 runtime UI<ref>http://forum.flightgear.org/viewtopic.php?p=272148#p272148</ref>.

Honestly, with these recent comments, and PUI related commits, in mind, I think it is only fair to suggest that the workload of actually porting the existing UI to Qt5 in its entirety has been hugely underestimated, especially in the light of all this work having to remain entirely optional (see Durk's and Rebecca's comments).

If you are aware of any other developments, I suggest to add the corresponding pointers - I have been maintaining a list of relevant statements at [http://wiki.flightgear.org/Howto:Processing_legacy_PUI_dialogs_using_Canvas#What_about_PUI_.3F]

--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 07:39, 30 April 2016 (EDT)

Talk:FlightGear Qt launcher

2017-12-29T16:41:55Z

AndersM:

== Old and confusing ==
Helping a new FG user I had a reason to check whats in the wiki on Launcher and fgrun etc. This and the fgrun article are not updated and therefore confusing for new users. Would be good if someone with knowledge of the current launcher situation under different OS could update these articles.
--[[User:AndersM|AndersM]] ([[User talk:AndersM|talk]]) 11:41, 29 December 2017 (EST)

== To be incorporated ==

You /can/ set the download dir via the launcher, and the default TerraSync dir is $download_dir/TerraSync, so this is intended to make setting the TerraSync dir manually unnecessary.
<ref>{{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34992973/
| title = <nowiki>Re: [Flightgear-devel] Use of QSettings by the Qt launcher for
--terrasync-dir</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Apr 5th, 2016
| added = Apr 5th, 2016
| script_version = 0.25
}}
</ref>

the launcher itself never sets —terrasync-dir, only —download-dir. And if both are set, —terrasync-dir is used of course. So if you set —terrasync-dir manaully in additional settings, its value will be used.
<ref>{{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34992973/
| title = <nowiki>Re: [Flightgear-devel] Use of QSettings by the Qt launcher for
--terrasync-dir</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Apr 5th, 2016
| added = Apr 5th, 2016
| script_version = 0.25
}}
</ref>

{{FGCquote
|1= Based on recent discussion and confusion, I just pushed some changes to the launcher. I would appreciate testing and feedback on the exact wording, I am trying to avoid confusing users and encouraging novice users to change things they should not, while still giving advanced users the flexibility they need. - the ‘add-ons’ dialog is now a fourth page (tab), which solves some odd interaction problems and hopefully makes the ‘where is this setting’ more coherent
* the ‘restore settings’ button on the settings page now explains what it does more clearly, and warns that it will disturb the download and data settings. I *could* tweak the code to preserve the values of those settings but wipe all others, but that seems very baroque, so I prefer to simply warn users what will happen.
* adjusting the data path (which is now described as ’fg-data’) does not affect any other setting - there is more descriptive text in the add-ons page about what the data and download directories are for, and the consequences of changing them.
* Launcher settings are stored in .ini format in $FG_HOME/flightgear.org/FlightGear.ini The one missing piece is if you change the download dir, and hence lose the default / official aircraft hanger, there is is no UI to explain what you only have the C172 and UFO. I intend to add this to the aircraft list as a custom item (which can be dismissed), stating something like: [No aircraft hangars or folders are defined, so only the default aircraft are available. Use the add-ons page to add hangars or select aircraft folders, or <click here> to hide this message] Again, feedback on *all* of this wording is welcome, since what makes sense to me may not make sense to everyone. Please note I will probably reject /any/ wording or language which contains the following ‘path’ (generally I’m using ‘location’) ‘environment variable’ (avoiding mentioning these at all!) ‘executable’ (use ‘application’ or ‘program’ or ‘FlightGear’) ‘directory’ (use ‘folder’) All feedback and testing is much appreciated.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/35001457/
| title = <nowiki>[Flightgear-devel] Launcher add-on handling changes</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Apr 8th, 2016
| added = Apr 8th, 2016
| script_version = 0.25
}}
}}
<references/>

: I've added a remark about the fact that it is now unnecessary to set the TerraSync download directory explicitly and the path change for the launcher settings; I'm not sure, however, how to phrase the <tt>--download-dir</tt> vs. <tt>--terrasync-dir</tt> difference, and I wonder if it's worth including the remarks James made about the '''Restore settings''' button and the FGData path adjustment, as they are meant to be self-explanatory (I fear it only adds complexity to the page). What do you think? -- [[User:Elgaton|ElGaton]] ([[User talk:Elgaton|<tt>talk</tt> to me]]) 05:49, 1 May 2016 (EDT)

== replacing plib UI with Qt5 ==

@Red Leader: The reference used there is referring to the draft published originally (discussed on the devel list), since then, a number of senior contributors have explicitly stated that Qt is intended to always remain optional and that an integrated UI has to be provided for the non Qt use-case (and James confirmed that).

Looking at the current integration, none of the QT code is integrated in a way to be invoked at runtime:
<pre>
GUI/CMakeLists.txt:72:if (HAVE_QT)
GUI/MessageBox.cxx:34:#ifdef HAVE_QT
GUI/MessageBox.cxx:129:#elif defined(HAVE_QT)
GUI/MessageBox.cxx:148:#elif defined(HAVE_QT)
GUI/FileDialog.cxx:44:#if defined(HAVE_QT)
GUI/FileDialog.cxx:154:#elif defined(HAVE_QT)
Main/fg_commands.cxx:61:#if defined(HAVE_QT)
Main/fg_commands.cxx:994:#if defined(HAVE_QT)
Main/options.cxx:58:#if defined(HAVE_QT)
Main/options.cxx:2517:#if defined(HAVE_QT)
Main/options.cxx:2535:#if defined(HAVE_QT)
Main/main.cxx:84:#if defined(HAVE_QT)
Main/main.cxx:445:#if defined(HAVE_QT)
Viewer/WindowBuilder.cxx:28:#if defined(HAVE_QT) && defined(SG_MAC)
Viewer/WindowBuilder.cxx:256:#if defined(HAVE_QT) && defined(SG_MAC)
</pre>

So unless there's been a recent update/consensus here, I don't think the current wording is sufficiently accurate, certainly not in the light of the architecture/threading related observations made by a number of contributors.

The launcher itself is totally separate from the FlightGear main loop, and such does not have any immediate effect on the runtime UI (at least for the time being).
I think, we'd be hard pressed to find specific statements supporting this - so if you want to keep this in the article, it would be a good idea to ask for clarification on the devel list, or at least add supporting statements from other core developers.

In fact, the most recent comments regarding PLIB/PUI reiterate the idea to absorb the relevant PLIB components into SimGear<ref>http://sourceforge.net/p/flightgear/mailman/message/34921429/</ref><ref>http://sourceforge.net/p/flightgear/mailman/message/34921495/</ref>, and even James himself continues to make commits that would conflict with a Qt5 runtime UI<ref>http://forum.flightgear.org/viewtopic.php?p=272148#p272148</ref>.

Honestly, with these recent comments, and PUI related commits, in mind, I think it is only fair to suggest that the workload of actually porting the existing UI to Qt5 in its entirety has been hugely underestimated, especially in the light of all this work having to remain entirely optional (see Durk's and Rebecca's comments).

If you are aware of any other developments, I suggest to add the corresponding pointers - I have been maintaining a list of relevant statements at [http://wiki.flightgear.org/Howto:Processing_legacy_PUI_dialogs_using_Canvas#What_about_PUI_.3F]

--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 07:39, 30 April 2016 (EDT)

New to FlightGear

2017-12-29T16:22:26Z

AndersM: /* Starting FlightGear */ Edited to be more newbie friendly

'''Welcome to [[FlightGear]]!''' Here we'll try to get you up in the virtual air in the shortest time possible. We'll also introduce you to some of the features of this flight simulator and also a few information on its community.

== Installation and setup ==
=== Hardware requirements ===
For FlightGear to run smoothly, it requires a video card with OpenGL drivers 2.0 or higher. This is usually not a problem, but take a look at [[Hardware Recommendations]] to have a better idea.

Many laptops are known to have issues with FlightGear, as the graphics card(s) on them are usually lower-end. See [[notebooks known to run FlightGear]] for reviews of several laptop systems.

=== Getting FlightGear ===
You may download the latest files from [http://www.flightgear.org/download/ FlightGear Downloads] page. Choose the source or binary files appropriate for your particular system. Most Linux users will find that most distributions have a packaged version of FlightGear (the package name could be <tt>fgfs</tt> or <tt>flightgear</tt>.)

Depending on your technical expertise you may choose the [[Git]] development version of FlightGear, which typically has more features and can be required by some of the latest developmental aircraft, but can be unstable and is more complicated to get for non-Windows users. In general, the development version is not advised to the average user, but if you're willing to do some testing there's a nightly build for Windows or Mac available for download at the [[FlightGear Build Server]],and a daily-updated Ubuntu PPA. If you are using a Git version controlled copy of FlightGear, you may choose to synchronise your aircraft using the version controlled [[FGAddon|FGAddon aircraft development repository]].

You may also order FlightGear on a set of DVDs, available on the [http://www.flightgear.org/dvd/ FlightGear main site].

=== Installing on Windows ===
After you downloaded the installer, Run it and follow its instructions to install FlightGear.

Take care to temporarily disable your antivirus during installation. FlightGear is thought by some antiviruses to have a virus.

With the Windows installer, you may choose where to install FlightGear. The FGROOT directory would be [your chosen directory]/data .

=== Installing on Mac OS X ===
Installing [[FlightGear Mac OS X|FlightGear on Mac OS X]] is very simple. Just drag and drop the FlightGear icon to the <tt>/Applications</tt> folder. That's it.

The first time you launch FlightGear, its icon on the Dock bounces for several seconds while loading aircraft and airport info. When the GUI launcher appears, select an aircraft and and airport by clicking the "Gear" buttons at the right of the names. Pressing "Start flight" will launch the simulator. You can configure more options using the GUI launcher. see the [http://macflightgear.sourceforge.net/home/documents/users-guide/ Users Guide] for more details.

If you'd like to launch FlightGear using command-line, launch <tt>/Applications/Utilities/Terminal.app</tt> and type the following.

cd /Applications/FlightGear.app/Contents/Resources
./fgfs --options.....

The [[$FG ROOT]] and [[$FG SCENERY]] are not set on Mac OS X. If you want to specify these variables yourself for command-line use, run the followings on Terminal.app:

FG_ROOT=/Applications/FlightGear.app/Contents/Resources/data
FG_SCENERY=[[$FG_ROOT]]/Scenery

After launching the GUI launcher, you will have the alias to [[$FG ROOT]] at <tt>$HOME/Documents/Flightgear/<version></tt> so you can browse the data folder using Finder.

Note: Once you have installed FlightGear, mac users can locate their [[$FG_ROOT]] folder by opening their applications folder in Finder, right clicking on FlightGear, and clicking "Show Package Contents". This will take you inside the FlightGear folder. You are now able to access all files including Data/Aircraft for [[Howto: Install aircraft#Macintosh OS X|installing new aircraft]].

=== Configuring OpenGL ===
FlightGear runs best with current [[OpenGL]] video drivers. If you are having trouble running FlightGear, see [[Graphics drivers configuration]] for more information.

=== Getting scenery ===
A limited set of [[scenery]] comes installed with FlightGear, which consists of the area surrounding [[San Francisco International Airport]] (KSFO).

In FlightGear, scenery is generally stored in you [[$FG_ROOT]] directory, and is divided into three kinds of data:
* '''Airports''' holds airport data, like runway usage and parking spots.
* '''Objects''' and '''Models''' are the buildings, bridges and radio towers, etc. that represent three-dimensional structures.
* '''Terrain''' represents the contours, elevations and type of ground you fly/taxi over.

The current way of "installing" new scenery is enabling [[TerraSync]], which will automatically download and update any place you visit - even on the fly! However, some might have problems with that, so you can also manually download and install new scenery parts, either official, the [[World Scenery]], or custom.

The official, although outdated, scenery is available at [http://www.flightgear.org/download/scenery/ the scenery download section] of the FlightGear website, and can be installed following [[Howto: Install scenery]]. You may obtain additional and more up to date scenery objects as they become available through the [http://scenemodels.flightgear.org/ FlightGear Scenery Database]. '''This is recommended for users with weak internet connections or weak computers!'''

Custom Scenery is available in many places. For example, in our forums ([http://forum.flightgear.org forum.flightgear.org]) or on repositories. An internet search should be able to find them.

=== Getting aircraft ===
Additional [[aircraft]] can be downloaded and installed through the launcher. Alternatively, you can go to the FlightGear website and navigate to the [http://www.flightgear.org/download/ download page], then choose the aircraft download link that fits your FlightGear version. For the installation, see [[Howto: Install aircraft]].

== Running FlightGear ==
=== Starting FlightGear ===
The easiest way to start FlightGear is to use the desktop icon; this starts the graphical interface [[FlightGear Qt launcher]] where you can choose aircraft, start position etc.

Many users choose however to start FlightGear directly from the command line. The executable name is <tt>fgfs</tt> and can be run without options. If it's "not found", it is likely not in your [https://en.wikipedia.org/wiki/PATH_(variable) path]. The location depends on your particular system and choices you made during compile and installation. There is a list of [[Command Line Parameters]] which must be used to change many options, like the aircraft you want. The most important:

fgfs --launcher # opens the FlightGear Qt launcher
fgfs --show-aircraft # displays a list of installed aircraft
fgfs --aircraft=c172p # start FG with the aircraft "c172p" (from the list)

=== Using the keyboard and/or mouse ===
Users with limited access to a [[joystick]] or other controllers sometimes use the keyboard or mouse to control their aircraft. Using the keyboard to fly can be difficult and the mouse is recommended over the keyboard for flying, yet even a cheap joystick would improve the experience so much.

To get help with keyboard commands, with FlightGear running, go to the ''Help'' menu, look under ''Basic Keys'' (for simulator related commands) and ''Common Aircraft Keys'' (for commands universal to all aircraft) and ''Aircraft Help'' (for key commands specific to your aircraft).

Coming from an other simulator? Check [[key commands compared to other simulators]] for an overview of the difference between the key commands of that sim and FlightGear and the [[Flightgear dialogs and menubar]].

To use the mouse to fly the aircraft, press tab (the cursor should change to a cross) and move the mouse to direct the aircraft. Tab again to look around (cursor should show a two sided arrow), and tab again to return to normal mode, used to click stuff in the cockpit. In some aircraft, such as the [[A320neo]] and [[A330-200]]/[[A330-300|300]] this unfortunately will not work, so you will have to use right click to look around and mouse mode is disabled. Fortunately, those planes are airliners, which are really stable and easy to fly with the keyboard.

=== First time in the cockpit ===
Finding your way around the cockpit can be daunting the first time.

Where is the "virtual cockpit?" Not all FlightGear aircraft come with an interior actually, some research projects may not even come with an exterior model. A 2D panel may display over the 3D cockpit if one exists. You may turn this off using the ''View'' menu or {{key press|Shift|V}}. Otherwise, you should be sitting in the virtual cockpit when FlightGear starts, as long as the Cockpit View is selected ({{key press|Ctrl|V}}).

You may find it difficult to read some of the displays, dials and gauges on the instrument panel. You can use the ''view'' mode of the mouse (right click until you get a cursor shaped like a double arrow) to pan and the mousewheel to zoom, or pan with the joystick hat and zoom with {{key press|X}} and {{key press|Shift|X}}.

One of the first steps that many take on entering an unfamiliar cockpit is to press {{key press|Ctrl|C}} to highlight all the "hotspots", that is instrument's controls, buttons, knobs, etc. Many aircraft also offer a specific help menu.

Some functions, such as starter or magneto, may be difficult to use or simply lack clickable "hotspots", especially in aircraft models which are in development. In most cases you can go for the equivalent controls on a 2D panel or resort to the keyboard. The keyboard always work according to the assignments listed on the ''Help'' menu, but sometimes these are reassigned by an aircraft or configuration. Again, remember to check all the help dialogs.

=== Starting the engine ===
You're eager to fly, but the engine's off. Well, turning on the engines is not always easy. Some aircraft have an ''autostart'' entry in their custom menu, but here's a general procedure that should work in many cases.

In general to start the engine on a piston-engine type aircraft, you need:
# Fuel: some aircraft start the simulation with no fuel. You can add it in ''Equipment > Fuel and Payload''.
# Correct mixture: this is generally ''rich'', so push the red knob all the way in, or use the key {{key press|m}} to enrich ({{key press|Shift|m}} leans.)
# Magnetos set on ''both'': turn the key or press {{key press|}}} ''three times'' to move through ''R'', ''L'', ''both''.
# Throttle: some engines start better with a little gas.
# Run the starter: click the "start" position of the key on the panel, or press {{key press|s}}. Hold the starter for sufficient time, even 10 seconds.

Starting all engines in a multi-engine aircraft is similar to the single engine--except you must follow the same start sequence for each and every engine. Flightgear provides a convenient way to do this for all engines at once: press {{key press|~}} and all the procedure above will work for all the engines. Note though that the default 2-D panel is connected to ''only one engine'' and the {{key press|~}} trick might not work. Also, give some gas to be sure that all the engines are on.

These instructions may not work for jet aircraft, helicopters, or other types of aircraft with complex start procedures. Check the instructions in the aircraft help menu (Press {{key press|?}}) and/or at [[Aircraft|the aircraft's wiki]]. In general to start the engine on a jet engine type aircraft, you need to:
# Set cutoff ON
# Engage the starter
# Once the engines spools up to approximately 5% N1, set cutoff OFF
# Disengage the starter once the engine has reached operational speed

=== Online multiplayer flying ===
FlightGear has some multiplayer servers that will let you fly in more lively skies, see [[Howto: Multiplayer]]. There are also [[OpenRadar]] and [[ATC-pie]], standalone programs that will let you be an [[Air traffic control|air traffic controller]].

There's also a [[MPMap|multiplayer map]] that lets you see who's online right now,and even what navaids are nearby.

== Making your first flight ==
=== Realism ===
One of the most frequent questions novice pilots ask about any flight sim, but more so to FlightGear, is "why is my aircraft turning left all the time?" Although it could be due to wind gusts crossing the runway, it is more likely due to the [[Understanding Propeller Torque and P-Factor|propeller torque and p-factor]].

In certain other flight simulators, despite marketing slogans to the contrary, some settings are turned down to make the aircraft easier to fly. This reduces effects such as the above. The realism is always turned up in FlightGear.

Here are some of the FlightGear realism points, which may be confusing to first time pilots:
* "Left turning syndrome" for the previously mentioned reasons.
* Compass turning error: A compass, when subjected to the forces of flight, tends to turn in the opposite direction for a brief period before settling on the correct heading. This is not a malfunction ([https://en.wikipedia.org/wiki/Aircraft_compass_turns more on this].)
* The Vertical Speed Indicator (VSI) is also subject to error.
* The Horizontal Situation Indicator (HSI) is driven by a gyroscope (that is why it's sometimes called a Directional Gyroscope), which is subject to ''gyro drift'': the indicator will drift from its current heading and must be periodically (every ~15 minutes) calibrated to agree with the magnetic compass heading.
*You cannot just cancel a turn or climb by centring the yoke or stick. You must turn or push the stick the other way to get to level and level flight. But even then, the plane will not mantain its altitude or heading by itself- a common mistake is trying to find a hands off yoke position. While with trims one could leave the plane for a couple of seconds, one must use autopilot or constantly adjust the yokes.

Many forces act on an aircraft in flight as well as on the [[avionics and instruments]] used for control and navigation, and may be counter-intuitive. Pilots must learn to recognize these phenomena and compensate for their effects. ''FlightGear models instrument errors that exist in the real world''.

=== Airports and navigation aids ===
When you first start FlightGear, whether from the command line or the graphical interface, you may wonder how to determine what airports are available. The launcher displays a list of airports, but you will not see details such as tower or [[ILS]] frequencies. You will not find a map showing [[VOR]]s and their frequencies. What can you do? See [[Getting aeronautical charts]].

In-sim, there is a map you can use in ''Equipment > Map'', which will allow you to see navigation data and the position of airports and aids. For more help with navigation see [[Understanding Navigation]].

=== Flying using the autopilot ===
Some aircraft require you to use the [[autopilot]] available from the ''Autopilot'' menu, which is the original FlightGear autopilot. This is a ''generic'' autopilot and as such, many aircraft come with their own ''specific'' autopilot, frequently a model of the real life one.

For aircraft that provide their own autopilot, you should use the autopilot controls available in the virtual cockpit. This means clicking on the instrument panel in the virtual cockpit. The Autopilot menu will be grayed out and unavailable when the aircraft supplies its own autopilot in some aircraft, including the Airbuses and the [[Cessna 172P|C172P]].

The Cessna 172 comes with a [[Bendix/King KAP140 Autopilot]] in its virtual cockpit. You cannot use the ''Autopilot'' dialog from the menu with this aircraft. You must use the autopilot device in the panel.

== The FlightGear community ==
=== Getting help ===
This page is designed to give the user the essential things they need to know about using FlightGear for the first time. Besides the [[Portal:User|User portal]] of this wiki, there are other pages you may want to read:
* [[Troubleshooting problems]] to help you with the most common issues;
* [[Frequently asked questions]];
...and communication channels that can be used to obtain information or request help:
* The [[FlightGear Manual]], a ''must read'' for beginners;
* [https://forum.flightgear.org FlightGear Forum] and its subforums;
* [[FlightGear IRC channel]], the quickest way to get help;
* [[Mailing list|FlightGear users mailing list]], biggest chance to get in contact with core developers;
* Documents bundled with the release package.

=== Customizing FlightGear without compiling it ===
[http://www.flightgear.org/download/ Our website] offers precompiled binaries for download and install on Windows and Mac OSX, while most Linux distros provide a packaged version in their repositories.

Although the install is binary, most of FlightGear's systems are open to configuration through [[XML]] files and [[NASAL scripting]]. You are free ''and encouraged'' to make changes to aircraft flight models, scenery, textures, OpenGL [[shader]]s and any other feature you wish to change for your personal satisfaction or to share with other FlightGear users. If this is what you intend to do, take a look at the [[Portal:Developer|Developer portal]].

=== How you can help ===
{{Main article|Volunteer}}
FlightGear is an opensource, volunteer based project. That means that whatever you find here comes from passion, spare time and nothing else. This includes the simulator, the scenery, the aircraft, the wiki, the forum and everything else. Volunteers, i.e. ''people that do things'', are fundamental to this project: without them, it wouldn't make a single step forward. So it is essential that contributors have fun in what they do.

If you really plan to contribute to this project, you should take a look at some articles that will give you some hints:
* [[Howto:Understand the FlightGear development process]]
* [[Implementing new features for FlightGear]]
* [[How the FlightGear project works]]

There are never enough people contributing, and the fields where their help would be appreciated are many:
;Testing :
* [[Building Flightgear|Build]] the latest Git code or download snapshots from the [[FlightGear Build Server]]
* [https://sourceforge.net/p/flightgear/codetickets/ File bug reports]
* Running FlightGear via valgrind to track down memory leaks

;Support :
* Help new users with downloading, compiling, installing and running FlightGear (https://forum.flightgear.org or on IRC)
* Provide ideas & suggestions, see: [[Feature Requests / Proposals / Ideas]]
* Help clean up this wiki
* Help provide new contents for missing wiki pages

;Development :
* C/C++ Coding:
** provide source code cleanups (i.e. help in the process of migrating over to a primarily smart pointer-based memory management approach using SGSharedPtr)
** provide bug fixes [[Bugs]] or new features
** get involved in any of the other FlightGear-affiliated projects
* Aircraft development (3D modelling, textures, FDMs, scripting)
* Scenery development (terrain, model, weather)

[[Category:FlightGear]]
[[ca:Nou a FlightGear]]
[[de:Neu bei FlightGear]]
[[es:Nuevo para FlightGear]]
[[fr:Nouveau sur flightgear]]
[[it:Nuovo per FlightGear]]
[[ja:FlightGear入門]]
[[nl:Nieuw bij FlightGear]]
[[pt:Novo no FlightGear]]
[[zh:FlightGear新手]]
[[th:New to FlightGear]]

FGAddon

2017-12-26T18:44:30Z

AndersM: /* Daily usage */ Added update command

[[File:FGAddon logo.png|270px|right]]

The official '''FGAddon''' aircraft hangar is a version control repository, hosted on [[FlightGear|FlightGear's]] [https://sourceforge.net/projects/flightgear/ SourceForge infrastructure], and used for the day-to-day development of FlightGear aircraft. FGAddon is an {{wikipedia|Apache Subversion|noicon=1}} version control repository. These are aircraft that are not part of the base package (the aircraft that are included in the base package — the [[Cessna 172P]] and the [[UFO]] — are kept in the [http://sourceforge.net/p/flightgear/fgdata FGData] repository), but are tagged with each stable release for the [http://www.flightgear.org/download/ FlightGear download pages].

The FGAddon aircraft development repository should be considered unstable. When using a stable FlightGear release, it is best to obtain aircraft with a matching version number from the [http://www.flightgear.org/download/ FlightGear download pages]. However, as stable releases from FlightGear version 3.4 onwards are tagged and present within the FGAddon repository, the Subversion tools can be a convenient way to obtain individual aircraft or the entire official hangar of approximately 500 aircraft. Also, if using the [[FlightGear build server|lastest nightly releases]] or a [[Building FlightGear|self-compiled version of FlightGear]] from FlightGear's [http://sourceforge.net/p/flightgear/_list/git Git version control repositories], using FGAddon allows the aircraft to be updated to the latest development versions.

== History ==
[[File:Image103.gif|thumb|Original Win95 icon]]
The FlightGear project was conceived on April 8, 1996 by David Murr who proposed a new flight simulator to be developed by volunteers<ref>David Murr (Apr 9, 1996). FlightGear proposal 1.0: [https://groups.google.com/forum/#!msg/rec.aviation.simulators/ny8HFBE5_T8/OdtIiGNGJc8J "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@"]. Published on the rec.aviation.simulators newsgroup.</ref><ref>David Murr (1996). FlightGear proposal 2.0: [http://www.flightgear.org/proposal-2.0 FLIGHT GEAR "This truly is as real as it gets!" - a proposal for a new flight simulator - REVISION 2.0].</ref><ref>David Murr (Oct 29, 1996). FlightGear proposal 3.0: [http://www.flightgear.org/proposal-3.0 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here"]. Published on the [http://ftp.igh.cnrs.fr/pub/flightgear/www/old-stuff/flight-gear.9610 flight-gear@infoplane.com mailing list].</ref><ref>David Murr (Sep 11, 1998). FlightGear proposal 3.0.1: [http://www.flightgear.org/proposal-3.0.1 FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here"].</ref>. Part of the initial goals were to develop 2D and 3D graphics routines for the simulator. However this was a huge task that came to an unfinished halt at the start of 1997 as the main developer, Eric Korpela, was finishing his thesis. Therefore starting on May 16, 1997, Curtis Olson relaunched development with a new project based on the OpenGL libraries, allowing a functional flight simulator to be put together in a short period of time<ref>Curtis Olson (Sep 28, 2015). [http://forum.flightgear.org/viewtopic.php?f=42&t=27558&p=259048#p259021 Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@]. Published on the FlightGear forum.</ref>. The first commits were to the original [[FlightGear CVS|flightgear and simgear CVS version control repositories]].

As the project grew, so did the size, quantity, and quality of the FlightGear assets. These assets were not organised and were scattered across different parts of the internet. Therefore it was decided that much of this FlightGear content would be assembled and stored together in a new centralised CVS repository called fgdata, which was created on October 22, 2000. To allow for the legal redistribution of these assets as part of the FlightGear distribution, a GPLv2 only policy was adopted.

In May 2010, development was interrupted by the infamous ''"coffee incident"'' which resulted in the loss of Curtis' home server hosting all of the FlightGear repositories<ref>James Turner (May 20, 2010). [http://thread.gmane.org/gmane.games.flightgear.devel/60340/focus=60341 <nowiki>[Flightgear-devel]</nowiki> Re: Flightgear git repositories (was Re: GIT or CVS - Confusion)] Published on the flightgear-devel mailing list.</ref>. These events resulted in a [[FlightGear CVS|mass migration of all the CVS repositories to Git repositories]]. Due to bandwidth issues, it was decided that the new repositories would be hosted on the Gitorious open source infrastructure.

With time as the project grew, the size and scope of the fgdata repository mushroomed, mainly due to the growing number of aircraft stored in [[$FG_ROOT]]/Aircraft, so that a split was inevitable. A first splitting attempt was organised by Gijs de Rooy and announced on October 18, 2011<ref>Cedric Sodhi (Oct 18, 2011) [http://thread.gmane.org/gmane.games.flightgear.devel/66846 <nowiki>[Flightgear-devel]</nowiki> FGData Split Completed - a.k.a Life after the Split] Published on the flightgear-devel mailing list.</ref>. Each aircraft was placed in its own Git repository and all aircraft linked back to fgdata using a Git submodule approach. However this attempt failed and was abandoned. From this date until the end of 2014, the design of the fgdata split was discussed on the development mailing list and summarised in the [[FlightGear Git: splitting fgdata]] wiki article. In the planning stages, the repositories were known as fgdata-old splitting into [[FGData]] (a.k.a. fgdata-new) and FGAddon (a.k.a. flightgear-aircraft and fgaircraft). After half a decade of planning, it was decided that the best solution for FlightGear aircraft development would be a single centralized Subversion repository. This would facilitate community management and maintenance of the aircraft while at the same time providing modularity and smaller downloads and smaller local repository sizes.

In late 2014, Gitorious, the provider of the open source infrastructure for the FlightGear source code and data repositories announced that it would shut its services down by May 2015 due to its acquisition by GitLab. This catalysed the split of fgdata-old and a switch to the SourceForge open source infrastructure for the hosting of the VC repositories. Other parts of the FlightGear infrastructure were already hosted by SourceForge, making the move a natural one. Sealing the deal, SourceForge agreed in writing to host the huge FlightGear aircraft collection, the size of which is unrivaled in open source circles. Today, the FGAddon SVN repository, together with most of the FlightGear project infrastructure, is hosted on SourceForge.

In August 2015, a new FlightGear policy document was written to codify the unwritten standards of the project<ref>[http://www.flightgear.org/flightgear-policy-document/ FlightGear Policy Document and Roadmap], draft document.</ref>. With this document, the licensing policy for the FlightGear aircraft has been updated from being GPLv2-only to now being a GPLv2+ or GPL-compatible<ref>[http://www.gnu.org/licenses/license-list.en.html GNU license compatibility list].</ref> stance. However, to combat licence proliferation complications for the integrity and good of the FlightGear project, it is strongly recommended that original content be GPLv2+ licensed.



== Obtaining aircraft ==

{{tip|If you are interested in obtaining aircraft for stable FlightGear releases and you are unaware of what version control is, you should visit the [[FlightGear_hangars|FlightGear hangars]] for downloading aircraft.}}
{{caution|If the FlightGear and FGAddon aircraft versions do not match, strange bugs should be expected and the version-mismatch combination will not be supported by the FlightGear community.}}

With access to the Subversion (SVN) tools, the FGAddon version control repository can be a convenient way for obtaining aircraft for using within a specific FlightGear version directly from the official source. When using the [[FlightGear Build Server|nightly builds]] or a [[Building FlightGear|version controlled copy of FlightGear]], the most up to date in-development versions of the aircraft should be used so the versions match. The following describes how to use the official repository to obtain aircraft from the perspective of a FlightGear user.

=== Preparation ===
To use the FGAddon repository, the Subversion tools need to be installed:
* '''MS Windows''': Install one of the [https://subversion.apache.org/packages.html#windows many Subversion clients]. For example [https://sliksvn.com/download/ SlikSVN] is one of the best command line versions and the best for aircraft development, and [http://tortoisesvn.net/ TortoiseSVN] provides a user friendly graphical user interface (GUI) by integrating into Windows Explorer.
* '''Mac OS X''': Install the [https://subversion.apache.org/packages.html#osx official Subversion client].
* '''GNU/Linux''': Install the Subversion client via the package manager. This will usually be in a package called <code>subversion-*.{rpm,deb}</code>.

=== FGAddon directory layout ===
To know how to use the FGAddon repository, an understanding of the repository directory layout is essential.
* <code>/trunk</code>: This base directory is where the in-development versions of the aircraft are located.
* <code>/branches/release-x.y.z/</code>: These directories correspond to the specific stable FlightGear releases.

The [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/ web interface for the FGAddon repository] allows all of the aircraft to be browsed.

=== Download ===
[[File:V22Osprey.jpg|thumb|200px|Aircraft to be downloaded]]
Firstly, choose an aircraft to download. The [[Bell Boeing V-22 Osprey]] will be used in this example.

==== Command line ====

To download the aircraft for FlightGear 3.4, simply type:
{{#tag:syntaxhighlight|
{{fgaddon co|branch=branches/release-3.4.0|path=Aircraft/V22-Osprey|post=}}
| lang = "sh"
}}

To obtain the in-development version, type:
{{#tag:syntaxhighlight|
{{fgaddon co|path=Aircraft/V22-Osprey|post=}}
| lang = "sh"
}}

If all of the ~500 aircraft from the repository are desired - beware that this will be a huge download of over 6 GB - use the following command:
{{#tag:syntaxhighlight|
{{fgaddon co|post=flightgear-fgaddon}}
| lang = "sh"
}}

When using a stable FlightGear release, for example FlightGear 2016.1, to obtain all of the FGAddon aircraft to match the installed FlightGear version, use:
{{#tag:syntaxhighlight|
{{fgaddon co|branch=branches/release-2016.1|post=flightgear-fgaddon}}
| lang = "sh"
}}

==== GUI clients and TortoiseSVN ====

When using one of the Subversion GUIs (graphical user interfaces), simply copy one of the above <code>https://</code> URLs and use that in the GUI (each GUI is different, so see the relevant documentation for help). For the unique TortoiseSVN tool, simply:

* In Windows Explorer, create a new empty folder for the aircraft (or aircraft collection).
* In the new folder, right click and select <code>SVN Checkout...</code>.
* Copy and paste the URL, for example {{fgaddon source|path=Aircraft/V22-Osprey|type=svn|full=1}}, leave all other settings as they are, and import by clicking on <code>OK</code>.

For more details, see the [http://tortoisesvn.net/support.html TortoiseSVN documentation]. Note that there is an option to install the command line tools when installing TortoiseSVN.

=== Flying ===

To use the newly downloaded aircraft, please see the [[Howto:Install aircraft]] article, skipping the instructions for downloading and unzipping the aircraft.

=== Updates ===
With a checked out copy of the <code>/trunk</code> in-development version, the aircraft can be updated to the latest version using the command:
<syntaxhighlight lang="bash">
svn up
</syntaxhighlight>

== Aircraft development ==

{{tip|The FlightGear community encourages aircraft development directly within FGAddon.}}

=== Contact the original aircraft authors ===

The first step for developing and advancing the aircraft of the official FlightGear hangar, or from one of the [[Flightgear_hangars#Aircraft_hangars|private hangars]] for that matter, is to make contact with the original aircraft author(s). Their names can be found within the <code>*-set.xml</code> file, within the <code><authors></code> XML tag. Often the contact email address will be listed in a README file or some other text file in the base aircraft directory. If not, contact can sometimes be established via the [https://lists.sourceforge.net/lists/listinfo/flightgear-devel FlightGear development mailing list]. Contacting the original authors is important to see if the aircraft is currently being actively developed, and if you can join in as part of the development team.

=== SourceForge account ===

To work on the official aircraft collection, a [https://sourceforge.net/user/registration/ SourceForge account] should first be set up. This will allow to either directly commit to the FGAddon repository, if commit access has been been granted, or to work in as part of a SourceForge development team. The registration process is lightning quick and the SourceForge developer infrastructure and developer services will be accessible in under a minute.

=== Commit access ===

Before obtaining commit access, an all-out effort to contact the original author(s) should be made to determine if the aircraft is actively being developed. If this is unsuccessful, sign up for the [https://lists.sourceforge.net/lists/listinfo/flightgear-devel FlightGear development mailing list] and ask for help there. If the aircraft has a current maintainer, you will be directed as to how to proceed with development. Otherwise ask if someone could volunteer to mentor you in the process of becoming an aircraft developer with full commit access.

To obtain commit access, you will first need:
# To demonstrate your capabilities and development skills.
# To show that you understand the [http://article.gmane.org/gmane.games.flightgear.devel/78713 FlightGear policy document]. 
# To show an understanding of the GPL licensing issues, and that you can be trusted not to use copyrighted, non-GPL material.
# To earn the trust of the FlightGear community.

These easy to jump over hurdles are simply designed to protect against repository corruption or pollution of the repository with illegal content.

To have your changes committed into the FGAddon repository, you should discuss and coordinate with the original aircraft author, or your mentor, for the best way to proceed. Depending on the [[#Development_scenarios|development scenario]], this maybe by merge request, file transfer, the primitive patch system, or any other convenient way. Once you believe you have proven your capabilities and you are knowledgeable about GPL licensing issues, you should write a mail to the development mailing list asking if you can be granted commit access, providing your SourceForge username.

=== FGAddon commitlog mailing list ===

To follow all changes which occur in the FGAddon repository, subscribe to the dedicated [https://lists.sourceforge.net/lists/listinfo/flightgear-fgaddon-commitlogs Flightgear FGAddon commitlogs mailing list]. One email is sent per commit, as the commit is made.

== Version control tools ==

To access FGAddon and use it for aircraft development, the Subversion or SVN version control tools are needed. Alternatively git-svn provides an interface for those who prefer the git version control tools.

=== Subversion ===

==== Set up ====
The FGAddon aircraft hangar is stored in a remote Subversion repository located on the SourceForge infrastructure, and therefore it is simplest to use the SVN tools for aircraft development and will cause the least problems. See the [[#Preparation|Subversion installation section]] for setting up the tool chain.

==== Repository checkout ====
The first step is to 'checkout' a copy of either the repository trunk or one of the aircraft in the trunk:
<syntaxhighlight lang="bash">
svn co <url> <dir>
</syntaxhighlight>

For the relevant URL to use, you must chose one of the [[#Development_scenarios|development scenarios]] and find the URL in that section. This command will create a local subversion repository copy in the given <code><dir></code> directory. Note that this will only contain the part of the FGAddon repository specified in the URL. This means that Subversion allows you to checkout either a single file all the way to the entire remote repository.

==== Information and history ====
At any point to see information about the local repository, type:
<syntaxhighlight lang="bash">
svn info
</syntaxhighlight>

To see the history of the checked out copy of the repository, type one of:
<syntaxhighlight lang="bash">
svn log
svn log | less
svn log -v | less
</syntaxhighlight>

==== Daily usage ====
The main Subversion command you will be using is:
<syntaxhighlight lang="bash">
svn add <path>
</syntaxhighlight>

This will register the file or directory <code><path></code> within the local repository to allow it to later be 'committed' and sent to the remote repository. To move or rename a file or directory, use:
<syntaxhighlight lang="bash">
svn mv <path1> <path2>
</syntaxhighlight>

This should be used rather than normal file moving/renaming so that the change is tracked in the local repository. To remove a file from the local repository, type:
<syntaxhighlight lang="bash">
svn rm <path>
</syntaxhighlight>

To see the current status of the local repository, type:
<syntaxhighlight lang="bash">
svn st
</syntaxhighlight>

To update the local repository with changes in the remote repository, type:
<syntaxhighlight lang="bash">
svn up
</syntaxhighlight>

==== Committing changes ====
All of the above operations only occur on the local repository copy - the remote FGAddon repository at SourceForge will know nothing of these changes. To send all your changes to FGAddon, you need to commit the changes:
<syntaxhighlight lang="bash">
svn ci
</syntaxhighlight>

This will open up an editor to allow you to write an informative commit log message. When committing, it is best to make small modular commits so that each commit corresponds to a single purpose. Note that you can only commit to FGAddon if you have [[#Commit access|commit access]].

==== Branching ====
The concept of Subversion branching is currently only used in the FlightGear project for tagging the stable releases. However if you are curious about branching, see the [http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html Branching and Merging chapter of the Subversion manual], and the [https://www.orcaware.com/svn/wiki/Svnmerge.py svnmerge.py script] which can greatly simplify the process.

=== Git-svn ===

The git-svn tool is useful for those who are already familiar with using git repositories, or those who wish to have their own private aircraft development playground. Git-svn provides a bridge between the remote FGAddon Subversion repository and a local git repository. For those unfamiliar with git, the git-svn bridge together with the git repository is far more complicated to use than the native [[#Subversion|Subversion tools]]. For more information on using git, see [[Howto:Start using git]]. The following will assume that only a single aircraft will be stored in the local git repository.

==== Set up ====
The git distributed version control system needs to first be [https://git-scm.com/downloads installed].

==== Cloning a single aircraft ====
The first step is to 'clone' a copy of one of the aircraft in the remote Subversion trunk:
<syntaxhighlight lang="bash">
git svn clone <aircraft_url>
</syntaxhighlight>

For the relevant aircraft URL to use, you must chose one of the [[#Development_scenarios|development scenarios]] and find the URL in that section. The URL depends on your [[#Commit access|FGAddon commit access status]]. The clone command will create a local git repository containing solely the aircraft of interest, and initialise the git-svn bridge.

==== Information and history ====
At any point to see information about the local repository, type:
<syntaxhighlight lang="bash">
git svn info
git branch -vva
git remote -v
</syntaxhighlight>

To see the history of the checked out copy of the repository, type:
<syntaxhighlight lang="bash">
git log
</syntaxhighlight>

==== Daily usage ====
The main git command you will be using is:
<syntaxhighlight lang="bash">
git add <path>
</syntaxhighlight>

This will register the file or directory <code><path></code> within the local repository to allow it to later be 'committed' to the local git repository. To move or rename a file or directory, use:
<syntaxhighlight lang="bash">
git mv <path1> <path2>
</syntaxhighlight>

However note that git history is not as robust as svn history. See the [[#Moving_or_renaming_files|git-svn file moving/renaming deficiency section]] for how to better perform this operation. To remove a file from the local repository, type:
<syntaxhighlight lang="bash">
git rm <path>
</syntaxhighlight>

To see the current status of the local repository, type:
<syntaxhighlight lang="bash">
git status
</syntaxhighlight>

==== Committing changes ====
As git is a distributed version control system, changes are committed to the local git repository.
<syntaxhighlight lang="bash">
git commit
</syntaxhighlight>

This will open up an editor to allow you to write an informative commit log message. The commit is local and will not be sent to FGAddon.

==== Dedicated FGAddon branch ====
In the examples above, only a single branch was assumed in the repository. If interaction with a remote git repository or branching within the local git repository is desired, then a different strategy is required. The reason being that the branch that synchronises with FGAddon must [https://git-scm.com/book/en/v1/Git-and-Other-Systems-Git-and-Subversion#git-svn preserve a linear history]. This means only cherry-picking of the desired changes into that branch is allowed.

In this example, two branches will be set up in the local git repository:
* <code>fgaddon</code>: This branch will be dedicated for FGAddon synchronisation and will preserve a linear history.
* <code>master</code>: A master branch for aircraft development, allowing for mergers and other non-linear history operations.

Assuming a [[#Cloning_a_single_aircraft|newly cloned repository]], create the <code>fgaddon</code> branch with:
<syntaxhighlight lang="bash">
git branch fgaddon
</syntaxhighlight>

And switch to that branch:
<syntaxhighlight lang="bash">
git checkout fgaddon
</syntaxhighlight>

The FGAddon synchronisation can then be performed on this branch. To pull in the developments from the master branch, use cherry-picking to apply a sequentially ordered list of commit hashes:
<syntaxhighlight lang="bash">
git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...
</syntaxhighlight>

To see the list of commits to be sent to FGAddon prior to dcommitting, type:
<syntaxhighlight lang="bash">
git log git-svn..HEAD
</syntaxhighlight>

And to see the changes as a single diff:
<syntaxhighlight lang="bash">
git diff git-svn..HEAD
</syntaxhighlight>

==== Synchronising ====
To send the changes to the remote FGAddon repository, firstly change to the dedicated <code>fgaddon</code> branch:
<syntaxhighlight lang="bash">
git checkout fgaddon
</syntaxhighlight>

Make sure the local git-svn repository is up to date with all changes that have occurred in FGAddon:
<syntaxhighlight lang="bash">
git svn rebase
</syntaxhighlight>

Then push or dcommit the changes to FGAddon with:
<syntaxhighlight lang="bash">
git svn dcommit
</syntaxhighlight>

=== Deficiencies of git-svn ===

{{warning|Performing a <code>git-svn clone</code> of the <code>/trunk/</code> or entire repository is not recommended, as the entire repository history will be downloaded, resulting in a huge local repository, as well as putting a large strain on the FlightGear open source infrastructure.}}

It is important to understand that there are a number of operations in which git-svn is deficient. In many cases, the svn tools should be used instead.

==== Copying files between aircraft ====

{{caution|Git-svn does not maintain the file copying history normally present in a Subversion repository.}}

The most important of these is the copying of content from other FGAddon aircraft. In this case you will need FGAddon commit access and a local svn copy of the repository. Firstly synchronise the repositories by dcommitting all changes back to FGAddon:
<syntaxhighlight lang="bash">
git svn dcommit
</syntaxhighlight>

Then in the local svn repository, copy the file:
<syntaxhighlight lang="bash">
svn cp Aircraft/<aircraft1>/<file_path1> Aircraft/<aircraft2>/<file_path2>
</syntaxhighlight>

And commit the change:
<syntaxhighlight lang="bash">
svn ci
</syntaxhighlight>

Back in the local git-svn repository, pull in the new files:
<syntaxhighlight lang="bash">
git svn rebase
</syntaxhighlight>

Using the subversion tools avoids the FGAddon repository backend from significantly increasing in size, as [http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create svn copies are cheap].

==== Moving or renaming files ====

{{caution|Git-svn does not always maintain the file moving or renaming history normally present in a Subversion repository.}}

This problem stems from the fact that svn history is more robust than that of git. The <code>svn mv</code> and <code>git mv</code> commands are not equivalent. The subversion command stores the move history directly in the repository whereas git does not (git instead uses heuristic methods to try to detect history, after the commit). The result of using git-svn is that often the move will not be detected and the FGAddon history will show one file or directory being deleted and another added. This also causes the repository backend to increase in size, whereas <code>svn mv</code> will not cause any significant size increase. If you wish to have a better historical record in the FGAddon repository and be considerate to the repository backend, it is recommended that you temporarily switch to the subversion tools. Firstly, synchronise the repositories:
<syntaxhighlight lang="bash">
git svn dcommit
</syntaxhighlight>

Then in the local svn repository, move or rename the file:
<syntaxhighlight lang="bash">
svn mv Aircraft/<aircraft>/<file_path1> Aircraft/<aircraft>/<file_path2>
</syntaxhighlight>

And commit the change:
<syntaxhighlight lang="bash">
svn ci
</syntaxhighlight>

Back in the local git-svn repository, pull in the changes with:
<syntaxhighlight lang="bash">
git svn rebase
</syntaxhighlight>

==== Copying files within one aircraft ====

Just as the <code>svn mv</code> command stores the move information directly within the repository, so does <code>svn cp</code> store the copy information. Therefore if you would like to duplicate a text file and modify it, using the native Subversion tools instead of git-svn for this operation allows for the file history to be permanently preserved in the FGAddon repository.

==== Subversion properties ====

{{caution|Git-svn currently only supports the <code>svn:executable</code> property, all other properties are ignored and cannot be added, changed, or removed in a git-svn clone of the aircraft.}}

Internally, Subversion identifies binary files using the <code>svn:mime-type</code> repository property. However as git-svn cannot set this property when using the <code>git add</code> command, the result is that binary files will be treated as text. Binary diffs will be seen when using <code>svn diff</code> or <code>git diff</code>, and a binary diff will be shown in the [[#FGAddon commitlog mailing list|FGAddon commitlog mailing list]] messages. As this issue is not unique to git-svn, to work around this issue please see the [[#Binary diffs|binary diffs]] section.

==== Protocols other than svn+ssh ====

The command <code>git svn init</code> replicates the entire history of an aircraft into a local repository. As part of this process, it generates a git commit ID or hash for every Subversion revision. The problem is that the git commit ID depends on the protocol used to read from the Subversion repository (likely a git bug). Hence:

{{#tag:syntaxhighlight|
{{fgaddon source|cmd=git svn init|protocol=svn+ssh|login=<username>|type=svn|path=Aircraft/<aircraft>|full=1}}
| lang = "sh"
}}

and

{{#tag:syntaxhighlight|
{{fgaddon source|cmd=git svn init|protocol=https|type=svn|path=Aircraft/<aircraft>|full=1}}
| lang = "sh"
}}

will result in two different and incompatible git repositories, even though they contain the same data. The incompatibility is not immediately apparent but it will bite later. Suppose someone with read-only access to FGAddon uses the https method, then asks a FGAddon gatekeeper to commit their changes. The gatekeeper, naturally, uses svn+ssh, as this is the only protocol granting write permissions. When the gatekeeper tries to merge the contributor's https clone into their own svn+ssh clone, git will complain that the two repositories have no history in common, and flag every change as a conflict.

Therefore, if you are planning to make any changes to an aircraft, be sure to use svn+ssh even if you do not yet have commit permissions on FGAddon. svn+ssh does not require write permissions, it only requires a SourceForge user ID.

== FGAddon development concepts ==

=== New aircraft ===

To add a new aircraft to the FGAddon repository, the SVN tools are required. If you encounter <code>svn:mime-type</code> property problems when adding a new aircraft, see the [[#Mime-type problems|mime-type problems section]] for how to resolve the issue. Or if you have a <code>svn:executable</code> property problem, see the [[#Executable flag|executable flag problem section]].

==== svn import ====

{{warning|The <code>svn import</code> command described herein will send all contents of the specified directory directly into FGAddon without warning and without a way to cancel the operation. Therefore special care must be taken when specifying the directory to upload into FGAddon, as well as the target FGAddon directory. See the [[#svn add|svn add]] section below for a safer way to add a new aircraft.}}

The [http://svnbook.red-bean.com/en/1.7/svn.tour.importing.html#svn.tour.importing.import svn import] command is the easiest method to use and does not require a local copy of the repository to be checked out. To start:

# Create an empty local aircraft directory.
# Copy the aircraft files into this directory.
# Carefully check all files to make sure there are no hidden or temporary files that should not be uploaded to FGAddon.

Assuming the Dead Simple Human Powered Airplane (DaSH PA or "DaSH") aircraft as an example, located in the <code>DaSH/</code> directory, on the command line run:
{{#tag:syntaxhighlight|
{{fgaddon source
| cmd = svn import DaSH/
| protocol = svn+ssh
| login = <username>
| type = svn
| path = Aircraft/DaSH/
| post = -m \
| full = 1
}}
"Initial import of the DaSH human powered aircraft.\n\nFor details see the forum thread at http://forum.flightgear.org/viewtopic.php?f=4&t=24495 ."
| lang = "sh"
}}

Where <code><username></code> is the SourceForge user name. This will add all the files into FGAddon with commit log message with the summary line <code>Initial import of the DaSH human powered aircraft.</code>, followed by a blank line, and then a detailed description pointing to the original location or discussion of the aircraft. To see if the aircraft has been successfully added to the repository:
{{#tag:syntaxhighlight|
{{fgaddon source
| cmd = svn list
| protocol = svn+ssh
| login = <username>
| type = svn
| path = Aircraft/DaSH/
| full = 1
}}
| lang = "sh"
}}

Or visit the {{fgaddon source|path=Aircraft|text=FGAddon web interface}}. The aircraft can then be checked out as described in the [[#Development scenarios|Development scenarios section]].

==== svn add ====

If a local copy of the FGAddon trunk is present, then the <code>svn add</code> command can be used instead. This is far safer than the <code>svn import</code> command, as the change can be double checked before committing. In the <code>Aircraft/</code> directory of the local repository, create the <code>DaSH/</code> directory. This can either be empty or contain all files of the initial aircraft. Then on the command line, add the aircraft to the local repository:
<syntaxhighlight lang="bash">
svn add DaSH/
</syntaxhighlight>

Then double check the changes prior to committing:
<syntaxhighlight lang="bash">
svn st
</syntaxhighlight>

And send the changes to FGAddon with:
<syntaxhighlight lang="bash">
svn ci
</syntaxhighlight>

An editor, often vi<ref>[http://www.vim.org/docs.php Vim documentation]</ref>, will open and the commit message can be composed. Alternatively the commit log message can be specified on the command line with:
<syntaxhighlight lang="bash">
svn ci -m "<subject_line>\n\n<detailed_description>"
</syntaxhighlight>

=== Commit blocking by pre-commit hooks ===

Sometimes when committing to FGAddon, the commit will be blocked the following will be printed out:
<pre>
svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
</pre>

This is due to the presence of two repository pre-commit hook scripts which check the quality of the commit, blocking it if a text file is set to a binary file mime-type or if the executable flag is set. These scripts are simply to protect the repository and to keep it clean.

==== Mime-type problems ====

Sometimes when attempting to commit files to FGAddon using the SVN tools, the commit will be blocked with the following message:
<pre>
Sending dash-set.xml
svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:

Aborting the commit, the svn:mime-type property is labelling the following text
files as binary:

dash-set.xml: svn:mime-type=application/xml

Before committing, please remove this property by typing 'svn propdel svn:mime-
type file_name' for all affected files. This will allow the text files to be
treated as text within the FGAddon repository.

To avoid the svn:mime-type property being incorrectly set by your subversion
client, the subversion configuration file at $HOME/.subversion/config or
%appdata%\roaming\subversion\config should be edited and a new entry added to
[auto-props] for each affected file type. In most cases, the problem is with
XML files being labelled as "application/xml" by a library called libmagic. To
override this, add the following to the svn config file:

*.xml = svn:mime-type=text/xml

svn: E165001: Your commit message was left in a temporary file:
svn: E165001: '/flightgear/repo_testing/svn-commit.tmp'
</pre>

Despite messages about adding or sending files, no change will have occurred in the FGAddon repository. This message is created by a repository pre-commit hook script which checks if the Subversion <code>svn:mime-type</code> property is set on a list of known text files and, if the mime-type is set to a binary format, the commit is blocked. The reason for this block is to protect the repository. Newer SVN clients rely on a 3rd party library known as libmagic which will detect the aircraft XML files as the binary mime-type of <code>application/xml</code>. The result is that the XML files are treated as binary files in the repository. This behaviour is completely undesirable, as changes cannot be followed on the [[#FGAddon commitlog mailing list|flightgear-fgaddon-commitlogs mailing list]] or in the repository history, and the size of the commits become orders of magnitude larger. Therefore this buggy behaviour has been blocked for the protection of the FlightGear project. To remove the problem, follow the instructions in the message and, using the command line tools, type:
<syntaxhighlight lang="bash">
svn propdel svn:mime-type <file_name>
</syntaxhighlight>

Repeat this for each text file listed in the error message. Then commit again, using the commit message saved in the <code>svn-commit.tmp</code> file. The message file name will be reported in the commit failure message, but check its contents first:
<syntaxhighlight lang="bash">
cat svn-commit.tmp
</syntaxhighlight>

And reperform the commit:
<syntaxhighlight lang="bash">
svn ci -F svn-commit.tmp
</syntaxhighlight>

===== Subversion config file =====

The automatic property setting of <code>svn:mime-type</code> can be controlled by modifying the Subversion <code>config</code> file. Firstly in the <code>[miscellany]</code> section, make sure that the auto-properties are turned on:
<syntaxhighlight>
enable-auto-props = yes
</syntaxhighlight>

Then in the <code>[auto-props]</code> section, add:
<syntaxhighlight>
*.ac = svn:mime-type=text/plain
*.eff = svn:mime-type=text/xml
*.frag = svn:mime-type=text/plain
*.nas = svn:mime-type=text/plain
*.osgx = svn:mime-type=text/xml
*.svg = svn:mime-type=text/svg+xml
*.txt = svn:mime-type=text/plain
*.vert = svn:mime-type=text/plain
*.xhtml = svn:mime-type=text/xml
*.xml = svn:mime-type=text/xml
*.xsl = svn:mime-type=text/xml
</syntaxhighlight>

These are all the text files that the hook script will check that the mime-type is set to a text format, though new text files will likely be added in the future. These additions can either be to the user configuration file located at <code>~/.subversion/config</code> (or <code>%USERPROFILE%\AppData\Roaming\Subversion\config</code> in Windows) or, if a user configuration file is not set, to the global configuration file at <code>/etc/subversion/config</code> (or <code>%APPDATA%\Subversion\config</code> in Windows).

==== Executable flag ====

Another blocking message when attempting to commit files to FGAddon using the SVN tools is:
<pre>
Adding dash-set.xml
Transmitting file data .svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:

The svn:executable property is set on the files ['dash-set.xml'], aborting the
commit.

The current policy is that no executable files are allowed in FGAddon. Before
committing, please remove this property by typing 'svn propdel svn:executable
file_name' for all affected files. Or to remove it recursively from all files
to be committed, in your aircraft directory type 'svn propdel svn:executable
-R'.

To avoid the svn:executable property being set by your subversion client, on
GNU/Linux and Mac OS X systems simply make sure that the file's execute bit is
not set before adding the file to be committed.

svn: E165001: Your commit message was left in a temporary file:
svn: E165001: '/flightgear/repo_testing/svn-commit.tmp'
</pre>

This will probably only be seen on Mac OS X and GNU/Linux systems. This message is printed by a pre-commit repository hook script that checks if the Subversion <code>svn:executable</code> property is set and, if so, the commit is blocked. This is a security measure, as no aircraft files should be executable. To remove the problem, follow the instructions in the message and, using the command line tools, type:
<syntaxhighlight lang="bash">
svn propdel svn:executable -R
</syntaxhighlight>

Then commit again, using the commit message saved in the <code>svn-commit.tmp</code> file. The message file name will be reported in the commit failure message, but check its contents first:
<syntaxhighlight lang="bash">
cat svn-commit.tmp
</syntaxhighlight>

And the reperform the commit:
<syntaxhighlight lang="bash">
svn ci -F svn-commit.tmp
</syntaxhighlight>

=== Binary diffs ===

{{warning|The incorrect setting or absence of the mime-type property on a binary file will result in a binary diff.}}

When looking at the output of <code>svn diff</code> (or <code>git diff</code> if you are using git-svn) as well as when reading messages from the [[#FGAddon commitlog mailing list|FGAddon commitlog mailing list]], you may see a large number of unrecognisable characters. This is the result of what is known as a binary diff, showing the binary file differences as if it were text. Although this is not a issue for the operation of the repository, the situation is an aesthetic problem which makes it more difficult to perform a review of the changes.

To fix the problem, firstly the binary files with the <code>svn:mime-type</code> property missing need to be identified. The following subversion command can be used:
<syntaxhighlight lang="bash">
svn propget svn:mime-type <file_name>
</syntaxhighlight>

As it can be tedious checking each file individually, the following Python script simplifies and automates the process to identify all binary files with a mime-type issue:

{{collapsible script
| type = Python 2/3 script
| title = Find binary files with no <code>svn:mime-type</code> property set.
| intro = The following script is based on blacklisting text files. Hence false positives are to be expected, and the blacklists can be expanded as needed.
| lang = python
| script =
#! /usr/bin/env python

from os import getcwd, walk
from os.path import join, splitext
from re import search
from subprocess import PIPE, Popen

skip_txt_file_seg = [
'authors',
'copying',
'licen',
'readme'
]

skip_txt_ext = [
'ac',
'css',
'dat',
'eff',
'frag',
'html',
'json',
'log',
'nas',
'osgx',
'svg',
'tex',
'txt',
'vert',
'xhtml',
'xml',
'xsl'
]

skip_bin_prop = [
'application/octet-stream',
'application/pdf',
'application/postscript',
'application/x-dosexec',
'application/x-gzip',
'application/zip',
'audio/x-wav',
'image/gif',
'image/jpeg',
'image/png',
'image/vnd.adobe.photoshop',
'image/tiff',
'image/x-ms-bmp',
'image/x-xcf',
]

# Walk through the directories.
for root, dirs, files in walk(getcwd()):
# Loop over the files in the current directory.
for file in files:
# Skip known text files.
skip = False
for i in range(len(skip_txt_file_seg)):
if search(skip_txt_file_seg[i], file.lower()):
skip = True
if skip:
continue

# The file extension.
file_path, ext = splitext(file)
ext = ext[1:].lower()

# Skip known text file extensions.
if ext in skip_txt_ext:
continue

# The full file path.
path = join(root, file)

# Query the file for svn:mime-type.
cmd = 'svn propget svn:mime-type \"%s\"' % path
pipe = Popen(cmd, shell=True, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=False)
props = []
for line in pipe.stdout.readlines():
props.append(line.strip())

# Byte array conversion (Python3).
for i in range(len(props)):
if hasattr(props[i], 'decode'):
props[i] = props[i].decode()

# Skip binary svn:mime-type values.
if len(props) and props[0] in skip_bin_prop:
continue

# Printout.
if not len(props):
print("%s" % path)
else:
print("%s svn:mime-type=%s" % (path, props[0]))
}}

==== Fixing the problem ====

As [[#Subversion_properties|git-svn cannot set or change]] the <code>svn:mime-type</code> property, a [[#Repository_checkout|svn checkout copy]] of the aircraft is required. The property can then be set to the default Subversion binary mime-type with:
<syntaxhighlight lang="bash">
svn propset svn:mime-type "application/octet-stream" <file_name>
</syntaxhighlight>

Alternatively, the following set of shell commands can be used to automate the process:
{{collapsible script
| type = Shell commands
| title = Set specific <code>svn:mime-type</code> values on a set of known binary files.
| intro = These shell commands will work on GNU/Linux or Mac OS X systems (or on Windows if using cygwin, or if a find command line tool is installed). The list of file types here are those most commonly found in FGAddon. To set the property on a list of binary files, type (or copy and paste):
| lang = bash
| script =
find -iname "*.wav" -exec svn propset svn:mime-type "audio/x-wav" {} \;
find -iname "*.bmp*" -exec svn propset svn:mime-type "image/x-ms-bmp" {} \;
find -iname "*.gif" -exec svn propset svn:mime-type "image/gif" {} \;
find -iname "*.jpg" -exec svn propset svn:mime-type "image/jpeg" {} \;
find -iname "*.png*" -exec svn propset svn:mime-type "image/png" {} \;
find -iname "*.psd" -exec svn propset svn:mime-type "image/vnd.adobe.photoshop" {} \;
find -iname "*.tif" -exec svn propset svn:mime-type "image/tiff" {} \;
find -iname "*.xcf" -exec svn propset svn:mime-type "image/x-xcf" {} \;
find -iname "*.rgb*" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.au" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.*af" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.3ds" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.blend*" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.dds" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.od[gst]" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.onetoc2" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.xlsx" -exec svn propset svn:mime-type "application/octet-stream" {} \;
find -iname "*.pdf" -exec svn propset svn:mime-type "application/pdf" {} \;
find -iname "*.ps" -exec svn propset svn:mime-type "application/postscript" {} \;
find -iname "*.gz" -exec svn propset svn:mime-type "application/x-gzip" {} \;
find -iname "*.mdl" -exec svn propset svn:mime-type "application/x-dosexec" {} \;
find -iname "*.zip" -exec svn propset svn:mime-type "application/zip" {} \;
| conc = Other binary files can safely be set to <code>"application/octet-stream"</code>, the Subversion default for binary files.
}}

== SourceForge developer services ==

The FlightGear project is hosted on the SourceForge open source infrastructure. This developer services section will highlight some of the useful tools you can take advantage of. SourceForge consists of two categories of services:
; Project infrastructure : The FlightGear project uses the project services of SourceForge. These services are for standalone software projects.
; Developer infrastructure : These are services available to anyone with a SourceForge account, and are available via your SourceForge homepage and accessible to all. This includes being able to create multiple version control repositories (svn, git, hg), wikis, forums, development teams, blogs, and ticket trackers (for bugs, support requests, tasks, etc.).

Rather than creating a new project, any development for the FlightGear project should be based on the developer infrastructure.

=== Developer git repository ===

To set up your own remote git repository, here for developing the FGAddon fkdr1 aircraft:
* On your profile page at <span style="color: blue"><tt><nowiki>https://sourceforge.net/u/<username>/profile/</nowiki></tt></span>, go to <code>Admin</code> -> <code>Add New</code> -> <code>Git</code>.
* Set label to <code>fkdr1 FGAddon git-svn repository</code>.
* Set the code path to <code>code-fkdr1</code>. The <code>code-*</code> prefix is to differentiate this from the <code>forum-*</code>, <code>wiki-*</code>, and other directories.

The repository will be located at <span style="color: blue"><tt><nowiki>https://sourceforge.net/u/<username>/code-fkdr1/ci/master/tree/</nowiki></tt></span>.

=== Development teams ===

If you and a group of friends would like to privately develop one of the FGAddon aircraft as a team, assuming that the you have contacted the original aircraft authors and the aircraft is not actively being developed, then you should create a SourceForge development team. A team leader should be appointed to set this up under their SourceForge account. Assuming you wish to develop the "ornithopter" aircraft, the steps are:

* Go to <code>Personal tools</code> -> <code>Admin</code>.
* Click on <code>User Permissions</code>.
* Click on <code>Add a new group</code> at the bottom.
* Set the name to <code>ornithopter</code>, and save.
* Click on <code>Add</code> in the <code>ornithopter</code> group and add the SourceForge names of all your team members.

After setting up a private repository in the team leader's account, as described below, then the development team should be set up for the repository.

* Go to the repository under your SourceForge account.
* Click on <code>Admin - <repository name></code>, then select <code>Permissions</code>.
* In the <code>Write</code> section, remove <code>Developer</code> and add <code>ornithopter</code>.
* Click on <code>Save</code>.

The development team will then have commit access to the private repository.

=== Team communications ===

To help with team development, the SourceForge infrastructure allows for multiple [https://sourceforge.net/p/forge/documentation/Discussion/ dedicated discussion forums] to be created. This can either be within a SourceForge project or under a SourceForge users homepage. This allows the team leader to create a forum dedicated solely to the development of the aircraft of interest. Continuing with the <code>ornithopter</code> example, the steps for the team leader are simple:

* On your profile page at <span style="color: blue"><tt><nowiki>https://sourceforge.net/u/<username>/profile/</nowiki></tt></span>, go to <code>Personal tools</code> -> <code>Admin</code>.
* Click on the <code>Tools</code> option in the left hand menu.
* Click on <code>Discussion</code> in the <code>Click to install</code> section.
* Change the label to <code>Ornithopter forum</code>, and the path to <code>forum-ornithopter</code>, for example. The <code>forum-*</code> prefix is to differentiate this from the <code>code-*</code>, <code>wiki-*</code>, and other directories.
* Click on <code>Save</code>.

More details are given on the [https://sourceforge.net/p/forge/documentation/Discussion/ SourceForge Discussion documentation].

== Development scenarios ==

=== Individual developer ===

{{Note|Development scenario: You are an individual developer and will use the native Subversion tools.}}

This is by far the simplest development scenario and should be used in most cases. If you are using the command line Subversion client, you can checkout an individual aircraft with:
{{#tag:syntaxhighlight|
{{fgaddon co
| login = <username>
| path = Aircraft/wrightFlyer1903
| post =
}}
| lang = "sh"
}}

Where <code><username></code> is your SourceForge user name. Alternatively you can checkout all aircraft with:
{{#tag:syntaxhighlight|
{{fgaddon co
| login = <username>
| post = flightgear-fgaddon
}}
| lang = "sh"
}}

If you do not have commit access, type one of:
{{#tag:syntaxhighlight|
{{fgaddon co
| path = Aircraft/wrightFlyer1903
| post =
}}
{{fgaddon co
| post = flightgear-fgaddon
}}
| lang = "sh"
}}

To use the new local svn repository, see the [[#Subversion|subversion instructions]].

=== Individual developer (git-svn) ===

{{Note|Development scenario: You are an individual developer and will use the git-svn tools.}}

This is more complicated than using the native SVN tools, but can be useful without having FGAddon commit access, as multiple local commits can be made to be sent to the original aircraft authors or to the development mailing list/forum. To clone the aircraft of choice into a new git repository, type:
{{#tag:syntaxhighlight|
{{fgaddon source|cmd=git svn clone|protocol=svn+ssh|login=<username>|type=svn|path=Aircraft/<aircraft>|full=1}}
| lang = "sh"
}}

Where <code><username></code> is your infrastructure user name and <code><aircraft></code> is the directory name in the FGAddon repository. This is valid whether or not you have commit permissions.

To use the new local git repository, see the [[#Git-svn|git-svn instructions]] and [[#Deficiencies_of_git-svn|its deficiencies]].

==== Upload to Sourceforge ====

To share the local developments, the changes can be uploaded to a remote git repository on the SourceForge infrastructure. For this, a [[#Developer_git_repository|developer git repository]] should first be set up under your SourceForge profile. Then add this as a remote:
{{#tag:syntaxhighlight|
{{sourceforge url|cmd=git remote add|opt=origin|protocol=ssh|login=<username>|user=<username>|type=git|repo=code-<aircraft>}}
| lang = "sh"
}}

And send the master branch where developments are located with:
<syntaxhighlight lang="bash">
git push --set-upstream origin master
</syntaxhighlight>

The changes in the new repository will be visible via the web interface at {{#tag:span|{{#tag:tt|{{#tag:nowiki|{{sourceforge url|user=<username>|repo=code-<aircraft>|branch=master}}}}}}| style="color: blue"}}.

=== Sending external git repository changes into FGAddon ===

{{Note|Development scenario: You are an individual developer with FGAddon commit access and wish to transfer the commits in a remote git repository into FGAddon using a temporary local git repository.}}

Firstly clone the FGAddon aircraft into a local git-svn repository with:
{{#tag:syntaxhighlight|
{{fgaddon source|cmd=git svn clone|protocol=svn+ssh|login=<username>|type=svn|path=Aircraft/<aircraft>|full=1}}
| lang = "sh"
}}

This will create a new local git repository linked to FGAddon via git-svn. If the aircraft is new and not present in FGAddon, see the [[#New_aircraft|instructions for adding a new aircraft to FGAddon]]. Next, set up the remote git repository as a remote, and fetch it:
<syntaxhighlight lang="bash">
git remote add <name> <url>
git fetch
</syntaxhighlight>

Where <code><url></code> is the URL of the remote git repository. Finally make an ordered list of all hashes of the commits to be sent into FGAddon, from earliest to latest, and cherry-pick them into the git-svn master branch:
<syntaxhighlight lang="bash">
git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...
</syntaxhighlight>

Note that the git-svn local repository should only have a single <code>master</code> branch and only consist of cherry-picking. To see the changes queued for sending to FGAddon:
<syntaxhighlight lang="bash">
git log git-svn..HEAD
git diff git-svn..HEAD
</syntaxhighlight>

Then to send the changes to FGAddon, firstly pull in any remote changes, and send the commits:
<syntaxhighlight lang="bash">
git svn rebase
git svn dcommit
</syntaxhighlight>

The temporary local repository can then be deleted.

=== Connecting an existing git repository to FGAddon ===

{{Note|Development scenario: You are an individual developer or team leader with FGAddon commit access and wish to connect a pre-existing remote git repository with FGAddon to send all changes back to FGAddon.}}

If a remote git repository containing a developed aircraft already exists, it is possible to connect it to the remote FGAddon repository using the git-svn tools. The following uses the [[#Dedicated_FGAddon_branch|dedicated FGAddon branch technique]]. Firstly, set up the bridge to FGAddon using git-svn in the per-aircraft repository:
{{#tag:syntaxhighlight|
{{fgaddon source|cmd=git svn init|protocol=svn+ssh|login=<username>|type=svn|path=Aircraft/<aircraft>|full=1}}
| lang = "sh"
}}

Where <code><aircraft></code> is the aircraft directory name in FGAddon. Note that this step can be performed without commit access to FGAddon by using a read-only SVN URL instead, but then changes cannot be pushed back to FGAddon ([[#Synchronising|dcommitting]], as it is known in the git-svn terminology). However, this allows upstream FGAddon changes to be integrated into the remote git repository, thus making it easy to prepare changes for submission for FGAddon inclusion using patches sent to the mailing list or sent via other channels.

Now fetch the current state from the remote FGAddon repository:
<syntaxhighlight lang="bash">
git svn fetch
</syntaxhighlight>

The downloaded SVN history is in the remote branch <code>remotes/git-svn</code>. To commit changes to SVN you need a local branch that tracks this remote branch. Create a local <code>fgaddon</code> branch that you will use to commit updates:
<syntaxhighlight lang="bash">
git branch fgaddon remotes/git-svn
</syntaxhighlight>

After committing new stuff to the <code>master</code> branch, to push to FGAddon checkout the <code>fgaddon</code> branch and update it from SVN in case someone else has touched the aircraft in the remote FGAddon repository:
<syntaxhighlight lang="bash">
git checkout fgaddon
git svn rebase
</syntaxhighlight>

Cherry-pick the new commits from <code>master</code> to <code>fgaddon</code> to preserve a linear history:
<syntaxhighlight lang="bash">
git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...
</syntaxhighlight>

To see the changes queued for sending to FGAddon as either commits or a diff, type:
<syntaxhighlight lang="bash">
git log git-svn..HEAD
git diff git-svn..HEAD
</syntaxhighlight>

If everything looks ok, dcommit the local commits on the <code>fgaddon</code> branch to send them to the remote FGAddon SVN repository:
<syntaxhighlight lang="bash">
git svn dcommit
</syntaxhighlight>

Switch back to the master branch for local development:
<syntaxhighlight lang="bash">
git checkout master
</syntaxhighlight>

To get changes from upstream you can either just download them with
<syntaxhighlight lang="bash">
git svn fetch
</syntaxhighlight>

or download them and rebase your <code>fgaddon</code> branch onto them:
<syntaxhighlight lang="bash">
git checkout fgaddon
git svn rebase
</syntaxhighlight>

=== Team development ===

{{Note|Development scenario: All members of the team are acting as gatekeepers, and all commits are made directly to FGAddon, either using svn or git-svn.}}

The simplest way to work as a team is for each developer to either have a [[#Individual developer|svn copy of FGAddon]] or a [[#Individual developer (git-svn)|git-svn copy of FGAddon]], and everyone commits directly to FGAddon. Communication and coordination between the team members can be performed using a [[#Team_communications|team leader organised SourceForge forum]] or using the [http://forum.flightgear.org/ FlightGear forum]. In this scenario, the team needs to take the initiative and everyone apply for FGAddon commit access.

=== Private team development (git-svn) ===

{{Note|Development scenario: One team leader is acting as the gatekeeper on a private git repository hosted on the in-house SourceForge infrastructure, using git-svn to push a fgaddon branch to FGAddon, with team members committing directly to the private git repository or making merge requests from their fork of the private repository.}}

To keep everything in-house, the entire operation will be based on the official infrastructure and remote repositories under each user's SourceForge (SF) profile. Note to the team leader - you must [https://git-scm.com/book/en/v1/Git-and-Other-Systems-Git-and-Subversion#git-svn keep your git-svn history linear] (meaning that a [[#Dedicated_FGAddon_branch|dedicated FGAddon branch]] should be created and changes manually cherry-picked into this branch). In the following, the <code>ornithopter</code> aircraft will be used as an example.

==== The team ====

Firstly, the entire team should sign up for [[#SourceForge account|SourceForge accounts]].

==== Team leader ====

===== Private repository set up =====

These steps are to be taken by the team leader. In your SourceForge user profile, set up a [[#Developer_git_repository| git repository]] with the label <code>Ornithopter FGAddon git-svn repository</code> and code path <code>code-ornithopter</code>. Then create a empty local git repository:
<syntaxhighlight lang="bash">
$ mkdir ornithopter
$ cd ornithopter
$ git init
</syntaxhighlight>

Link the empty repository to the <code>ornithopter</code> aircraft directory in the remote FGAddon repository and pull it in with:
{{#tag:syntaxhighlight|
$ {{fgaddon source|cmd=git svn init|protocol=svn+ssh|login=<username>|type=svn|path=Aircraft/ornithopter|full=1}}
$ git svn fetch
| lang = "sh"
}}

Replace <code><username></code> with your SF user name. Set up a special git-svn branch for FGAddon gatekeeping and dcommitting changes back to the repository:
<syntaxhighlight lang="bash">
$ git branch fgaddon remotes/git-svn
$ git checkout fgaddon
</syntaxhighlight>

And pull in the <code>ornithopter</code> from FGAddon:
<syntaxhighlight lang="bash">
$ git svn rebase
</syntaxhighlight>

To see the current local git-svn repository setup, type:
<syntaxhighlight lang="bash">
$ git branch -vva
$ git remote -v
$ git svn info
</syntaxhighlight>

Then return to the master branch:
<syntaxhighlight lang="bash">
$ git checkout master
</syntaxhighlight>

Finally, set up the remote git repository as a remote:
{{#tag:syntaxhighlight|
$ {{sourceforge url|cmd=git remote add|opt=origin|protocol=ssh|login=<username>|user=<username>|type=git|repo=code-ornithopter}}
| lang = "sh"
}}

And send the master branch to the remote git repository:
<syntaxhighlight lang="bash">
$ git push -u origin master
</syntaxhighlight>

To see the new set up:
<syntaxhighlight lang="bash">
$ git branch -vva
$ git remote -v
</syntaxhighlight>

The repository will be located at {{#tag:span|{{#tag:tt|{{#tag:nowiki|{{sourceforge url|user=<username>|repo=code-ornithopter|branch=master}}}}}}| style="color: blue"}}. Note that the git-svn information stored in the <code>.git/svn</code> directory will not be pushed to remote SoureForge repository, and therefore the link back to FGAddon will only be present in the local copy of the team leader. The git-svn link can be re-established at a later point if necessary.

===== Team setup =====

Set up a [[#Development teams|dedicated development team and grant them access to the git-svn repository]].

===== Pushing to FGAddon =====

Committing to FGAddon is for the local git repository of the team leader. History must be linear in the fgaddon branch, so cherry-picking is the way to go. This is from the [[#Individual developer (git-svn)|Individual developer (git-svn)]] section. In the local git repository, switch to the <code>fgaddon</code> branch:
<syntaxhighlight lang="bash">
git checkout fgaddon
</syntaxhighlight>

Pull in any changes which have occurred in FGAddon:
<syntaxhighlight lang="bash">
git svn rebase
</syntaxhighlight>

To see the commits in the <code>master</code> branch which are not in the <code>fgaddon</code> branch, type one of:
<syntaxhighlight lang="bash">
git log HEAD..master
git log HEAD..master --pretty=oneline
</syntaxhighlight>

Manually select the commits to be sent to FGAddon and cherry-pick them:
<syntaxhighlight lang="bash">
git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...
</syntaxhighlight>

Or to cherry-pick a range of commits:
<syntaxhighlight lang="bash">
git cherry-pick <commit hash 1>^..<commit hash 8>
</syntaxhighlight>

Then check what is to be sent:
<syntaxhighlight lang="bash">
git log git-svn..HEAD
git diff git-svn..HEAD
</syntaxhighlight>

Send the changes to FGAddon, send the git <code>fgaddon</code> branch changes to the remote git repository, and switch back to the master branch:
<syntaxhighlight lang="bash">
git svn dcommit
git push
git checkout master
</syntaxhighlight>

Finally merge in the git svn commits with their new hashes from the <code>fgaddon</code> branch, and send it to the remote git repository:
<syntaxhighlight lang="bash">
git merge fgaddon
git push
</syntaxhighlight>

==== Team members ====

===== Working with the repository =====

Each team member should make a clone of the private git repository:
{{#tag:syntaxhighlight|
$ {{sourceforge source|cmd=git clone|protocol=ssh|login=<username>|user=<username_leader>|type=git|repo=code-ornithopter|post=ornithopter|full=1}}
| lang = "sh"
}}

Replace <code><username></code> with your SourceForge user name, and <code><username_leader></code> is the SourceForge user name of the team leader.

===== Forking and merge requests =====

Alternatively, each team member can fork the git repository under your SourceForge account:
* Go to {{#tag:span|{{#tag:tt|{{#tag:nowiki|{{sourceforge source|user=<username>|repo=code-ornithopter|branch=master|full=1}}}}}}| style="color: blue"}}, where <code><username></code> is the SourceForge user name of the team leader.
* Click on <code>Fork</code>.
* Set the mount point to <code>code-ornithopter</code> and change the label as you wish.

Develop and push to your fork, then make merge requests by clicking on the <code>Request Merge</code> button.

== References ==
<references/>

[[Category:FlightGear]]

[[de:FGAddon]]
[[fr:FGAddon]]

Suggested airports

2017-05-31T17:45:35Z

AndersM: Correct ICAO

Here you will find Airports that are well developed and/or have an outstanding scenery. Thus they are "suggested" especially to be visited and/or used for Multi-player events like FlyIns, TGA, ATC, etc..
<br /><br />
If you are searching for the '''development-status of Airports''' see the wiki [[Developed Airports]].
<br />For further suggestions see [[Suggested Scenery]] and [[Suggested Flights]]
<br /><br />
The overall Airport-Rating (column "R") is based on the TerraSync-Status of the following characteristics:
{| border="0"
|-
! style="text-align:center"| * !!style="text-align:left"|     superior surrounding landscape - although the airport itself is not (yet) developed accordingly
|-
! style="text-align:center"| ** !!style="text-align:left"|     complex modeling of buildings
|-
! style="text-align:center"| *** !!style="text-align:left"|     complex modeling of buildings, taxiways, and aprons
|-
! style="text-align:center"| **** !!style="text-align:left"|     extensive modeling of airport and landscape and/or city
|}
<br />
Further columns to watch for are:
* '''S = Size:''' L= all aircraft, M= midium size aircraft, S= for small aircraft
* '''FGCOM:''' If available one FGCOM frequency is given, followed by the amount of the total available FGCOM frequencies
* '''Parking:''' amount of pre-defined Parking-Lots (otherwise see: [[Initial Starting Positions]])
* '''R/I:''' amount of runways and ILS (e.g. KROC has 3 runway: 04/22 has each 1 ILS, 10/28 has only one ILS on 28, 07/25 has no ILS)
<br />
{| class="wikitable sortable" border="0" cellspacing="0"
! width="40" | ICAO
! width="130" | Name
! width="80" | Country
! width="80" | Continent
! width="30" | R
! width="30" | S
! width="100" | FGCOM
! width="50" | Parking
! width="40" | R/I
! class="unsortable" style="background:#efefef" | Comment
|-
| LKKB || Praha-Kbely || Czech republic || Europe ||align="center"| *** ||align="center"| M ||align="center"| 120.87 ||align="center"| -- ||align="center"| 1/1 || request for develop it - Military Airport
|-
|-
| BKPR || Pristina || Kosovo || Europe ||align="center"| * ||align="center"| M ||align="center"| -- ||align="center"| -- ||align="center"| 1/1 || very nice scenery
|-
| CYVR || [[Vancouver International Airport|Vancouver]] || Canada || America ||align="center"| * ||align="center"| L ||align="center"| 125.650 (6) ||align="center"| many ||align="center"| 5/5 || nice area
|-
| EDDC || [[Dresden Airport|Dresden Airport]] || Germany || Europe ||align="center"| ** ||align="center"| L ||align="center"| -- ||align="center"| - ||align="center"| 2/4 || Terminal, Tower, GA Hangars and many more
|-
| EDDF || [[Frankfurt am Main Airport|Frankfurt am Main]] || Germany || Europe || align="center" | **** || align="center" | L || align="center" | 127.320 (6) || align="center" | many ||align="center"| 4/6 || Fully modeled with [[Signs]] and [[Interactive Traffic]] and unique scycrapers downtown
|-
| EDDH || [[Hamburg Airport|Hamburg]] || Germany || Europe ||align="center"| *** ||align="center"| L ||align="center"| 126.850 (7) ||align="center"| -- ||align="center"| 2/4 || Fully modeled, plus unique buildings downtown|-
|-
| EDDI || [[EDDI|Berlin Tempelhof]] || Germany || Europe ||align="center"| **** ||align="center"| L ||align="center"| 118.100 (10) ||align="center"| 1 ||align="center"| 2/0 || Fully modeled, especially also the City
|-
| EDDK || [[EDDK|Köln/Bonn]] || Germany || Europe ||align="center"| **** ||align="center"| L ||align="center"| 124.97 (5) ||align="center"| -- ||align="center"| 3/3 || Fully modeled airport and surroundings
|-
| EDDL || [[Düsseldorf International Airport|Düsseldorf]] || Germany || Europe ||align="center"| *** ||align="center"| L ||align="center"| 118.300 (4) ||align="center"| -- ||align="center"| 2/4 || Tower and terminal modeled
|-
| EDDP || [[Leipzig/Halle Airport|Leipzig/Halle]] || Germany || Europe ||align="center"| *** ||align="center"| L ||align="center"| 121.100 (5) ||align="center"| 2 ||align="center"| 2/4 || Tower, terminals B and C, large DHL-area modeled, inclusive [[Signs]]
|-
| EDDS || Stuttgart || Germany || Europe ||align="center"| *** ||align="center"| L ||align="center"| 118.800 (8) ||align="center"| -- ||align="center"| 1/2 || Tower, terminal and [[Signs]] are fully modeled
|-
| EDDT || [[Berlin Tegel Airport|Berlin Tegel]] || Germany || Europe ||align="center"| *** ||align="center"| L ||align="center"| 118.700 (11) ||align="center"| 4 ||align="center"| 2/4 || Tower and terminal modeled, inclusive [[Signs]]
|-
| EDDV || [[EDDV|Hannover]] || Germany || Europe ||align="center"| * ||align="center"| L ||align="center"| 120.170 (3)) ||align="center"| 4 ||align="center"| 2/4 || Tower and terminal modeled
|-
| EDDW || Bremen || Germany || Europe ||align="center"| ** ||align="center"| L ||align="center"| 118.500 (7) ||align="center"| -- ||align="center"| 2/2 || very nicely modeled
|-
| EDFH || Frankfurt Hahn || Germany || Europe ||align="center"| ** ||align="center"| L ||align="center"| 119.65 (7) ||align="center"| -- ||align="center"| 1/2 || very nicely model (use Terrasync)
|-
| EDLN || Mönchengladbach || Germany || Europe ||align="center"| *** ||align="center"| L ||align="center"| - ||align="center"| -- ||align="center"| - || very nicely modeled
|-
| EDVE || [[Braunschweig Airport|Braunschweig]] || Germany || Europe ||align="center"| ** ||align="center"| S ||align="center"| 119.350 (2) ||align="center"| -- ||align="center"| 2/1 ||
|-
| EDXW || Westerland Sylt || Germany || Europe ||align="center"| *** ||align="center"| M ||align="center"| 119.75 (2) ||align="center"| -- ||align="center"| 2/1 || very nicely model famous sea-resort (use Terrasync)
|-
| EEKE || Kuressaare || Estonia || Europe ||align="center"| ** ||align="center"| S ||align="center"| 119.700 (4) ||align="center"| -- ||align="center"| 2/0 ||
|-
| EFHF || Helsinki-Malmi || Finland || Europe ||align="center"| ** ||align="center"| S ||align="center"| 119.700 (4) ||align="center"| -- ||align="center"| 2/0 ||
|-
| EFHK || Helsinki || Finland || Europe ||align="center"| ** ||align="center"| L ||align="center"| 119.700 (5) ||align="center"| -- ||align="center"| 3/5 || Nice terminal and city landmarks
|-
| EEPU || Parnu || Estonia || Europe ||align="center"| ** ||align="center"| M ||align="center"| -- ||align="center"| -- ||align="center"| 1/0 || Nice triangle EETN-EETU-EEPU
|-
| EETN || Tallinn || Estonia || Europe ||align="center"| ** ||align="center"| M ||align="center"| -- ||align="center"| -- ||align="center"| 1/2 || Nice triangle EETN-EETU-EEPU
|-
| EETU || Tartu || Estonia || Europe ||align="center"| ** ||align="center"| S ||align="center"| -- ||align="center"| -- ||align="center"| 1/0 || Nice triangle EETN-EETU-EEPU
|-
| EGFF || Cardiff || UK || Europe ||align="center"| ** ||align="center"| M ||align="center"| 125.00 (3) ||align="center"| -- ||align="center"| 1/2 ||
|-
| EGGP || Liverpool || UK || Europe ||align="center"| *** ||align="center"| M ||align="center"| 126.350 (4) ||align="center"| -- ||align="center"| 1/2 ||
|-
| EGGW || Luton || UK || Europe ||align="center"| *** ||align="center"| M ||align="center"| 126.720 (6) ||align="center"| -- ||align="center"| 1/2 ||
|-
| EGKA || Shoreham || UK || Europe ||align="center"| *** ||align="center"| S ||align="center"| 125.400 (3) ||align="center"| -- ||align="center"| 3/0 ||
|-
| EGKK || [[London Gatwick Airport|London-Gatwick]] || UK || Europe ||align="center"| **** ||align="center"| M ||align="center"| 124.220 (8) ||align="center"| 6 ||align="center"| 1/2 ||
|-
| EGLL || London-Heathrow || UK || Europe ||align="center"| *** ||align="center"| L ||align="center"| 118.500 (14) ||align="center"| 3 ||align="center"| 2/4 ||
|-
| EGPH || Edinburgh || UK || Europe ||align="center"| ** ||align="center"| M ||align="center"| 118.700 (4) ||align="center"| -- ||align="center"| 2/2 ||
|-
| EGSH || Norwich || UK || Europe ||align="center"| ** ||align="center"| M ||align="center"| 124.250 (3) ||align="center"| -- ||align="center"| 2/1 ||
|-
| EGUN || RAF Mildenhall || UK || Europe ||align="center"| ** ||align="center"| L ||align="center"| 122.550 (5) ||align="center"| -- ||align="center"| 1/1 || USAF base for tankers and cargo planes near other military air bases like EGUL, EGYM, EGXH,... will have buildings soon. ATC is also provided.
|-
| EHAM || [[Amsterdam Airport Schiphol|Amsterdam]] || Netherlands || Europe ||align="center"| **** ||align="center"| L ||align="center"| 119.220 (1) ||align="center"| many ||align="center"| 6/6 ||One of the best modeled airports in the FlightGear world; most dense AI traffic.
|-
| EHEH || Eindhoven || Netherlands || Europe ||align="center"| ** ||align="center"| M ||align="center"| 131.000 (6) ||align="center"| -- ||align="center"| 1/2 ||
|-
| EHLE || [[Lelystad Airport|Lelystad]] || Netherlands || Europe ||align="center"| *** ||align="center"| S ||align="center"| -- ||align="center"| 1 ||align="center"| 2/1 || Basic scenery models, home of [[FSweekend]].
|-
| EHVK || [[Volkel Air Base|Volkel]] || Netherlands || Europe ||align="center"| ** ||align="center"| L ||align="center"| 123.170 (1) ||align="center"| many ||align="center"| 2/2 ||
|-
| EIDW || [[Dublin Airport|Dublin]] || Ireland || Europe ||align="center"| *** ||align="center"| M ||align="center"| 118.600 (7) ||align="center"| -- ||align="center"| 3/3 ||
|-
| ELLX || Luxembourg || Luxembourg || Europe ||align="center"| ** ||align="center"| L ||align="center"| 118.100 (2) ||align="center"| -- ||align="center"| 1/2 || very nicely model (use Terrasync)
|-
| ENAL || Alesund || Norway || Europe ||align="center"| ** ||align="center"| M ||align="center"| 118.100 (4) ||align="center"| -- ||align="center"| 1/1 ||
|-
| ENSD || Alesund || Norway || Europe ||align="center"| ** ||align="center"| S ||align="center"| -- ||align="center"| -- ||align="center"| 1/0 ||
|-
| ENVA || Trondheim || Norway || Europe ||align="center"| *** ||align="center"| L ||align="center"| 122.100 (6) ||align="center"| -- ||align="center"| 2/2 ||
|-
| ESGP || Göteborg || Sweden || Europe ||align="center"| ** ||align="center"| M ||align="center"| 129.100 (3) ||align="center"| -- ||align="center"| 2/1 ||
|-
| FACT || Cape Town || South Africa || Africa ||align="center"| * ||align="center"| L ||align="center"| 118.100 (4) ||align="center"| many ||align="center"| 2/2 ||nice area
|-
| FAJS || Johannisburg || South Africa || Africa ||align="center"| * ||align="center"| L ||align="center"| 121.900 (3) ||align="center"| many ||align="center"| 2/3 ||high (5000), in mountains
|-
| FHAW || RAF Ascension Island AUX AF || Ascension Island || Africa ||align="center"| * ||align="center"| L ||align="center"| 126.200 (2) ||align="center"| -- ||align="center"| 1/0 ||RAF and USAF auxiliary base. Developed layout, in the middle of the Atlantic Ocean, great place for military flights.
|-
| GCFV || Fuerteventura || Gran Canaria || Africa ||align="center"| * ||align="center"| L ||align="center"| 119.200 (4) ||align="center"| 9 ||align="center"| 1/1 ||nice island area
|-
| KABQ || Albuquerque || USA NM || America ||align="center"| * ||align="center"| L ||align="center"| 120.300 (10) ||align="center"| -- ||align="center"| 4/2 ||
|-
| HECA || Cairo || Egypt || Africa ||align="center"| * ||align="center"| L ||align="center"| 120.300 (10) ||align="center"| -- ||align="center"| 4/2 || near pyramids
|-
| KATL || Atlanta || USA GA || America ||align="center"| * ||align="center"| L ||align="center"| 119.550 (4) ||align="center"| many ||align="center"| 3/4 ||
|-
| KAUS || Austin || USA TX || America ||align="center"| *** ||align="center"| L ||align="center"| 121.00 (10) ||align="center"| -- ||align="center"| 2/4 ||
|-
| KBWI || Baltimore || USA MD || America ||align="center"| *** ||align="center"| L ||align="center"| 119.400 (10) ||align="center"| -- ||align="center"| 4/6 ||
|-
| KCGS || College Park || USA MD || America ||align="center"| ** ||align="center"| S ||align="center"| 119.850 (3) ||align="center"| -- ||align="center"| 2/0 ||
|-
| KDCA || Reagan National || USA VA || America ||align="center"| *** ||align="center"| M ||align="center"| 120.750 (7) ||align="center"| -- ||align="center"| 3/2 ||
|-
| KDEN || [[Denver International Airport|Denver]] || USA CO || America ||align="center"| ** ||align="center"| L ||align="center"| 133.300 (16) ||align="center"| -- ||align="center"| 6/12 ||
|-
| KDTW || Detroit || USA MI || America ||align="center"| ** ||align="center"| L ||align="center"| 118.400 (15) ||align="center"| -- ||align="center"| 6/8 ||
|-
| KFHR || Friday Harbor || USA WA || America ||align="center"| * ||align="center"| S ||align="center"| -- ||align="center"| -- ||align="center"| 1/0 ||
|-
| KHAF || Half Moon Bay || USA CA || America ||align="center"| * ||align="center"| M ||align="center"| 122.800 (2) ||align="center"| 4 ||align="center"| 1/0 ||nice area - near KSFO
|-
| KHWD || Hayward || USA CA || America ||align="center"| ** ||align="center"| S ||align="center"| 122.500 (10) ||align="center"| 9 ||align="center"| 2/1 ||nice area - near KSFO
|-
| KIAD || Washington-Dulles || USA VA || America ||align="center"| * ||align="center"| L ||align="center"| 120.100 (14) ||align="center"| many ||align="center"| 4/3 ||
|-
| KIND || Indianapolis || USA IN || America ||align="center"| *** ||align="center"| L ||align="center"| 127.820 (7) ||align="center"| -- ||align="center"| 3/6 ||
|-
| KJAN || Jackson-Evers || USA MS || America ||align="center"| *** ||align="center"| L ||align="center"| -- ||align="center"| -- ||align="center"| 2/2 ||
|-
| KJFK || [[John F. Kennedy International Airport|John F. Kennedy]] || USA NY || America ||align="center"| *** ||align="center"| L ||align="center"| 119.100 (18) ||align="center"| many ||align="center"| 4/5 ||
|-
| KLAS || Las Vegas || USA NV || America ||align="center"| **** ||align="center"| L ||align="center"| 119.900 (9) ||align="center"| -- ||align="center"| 4/3 || terminal and some casinos modeled
|-
| KLAX || [[Los Angeles International Airport|Los Angeles]] || USA CA || America ||align="center"| *** ||align="center"| L ||align="center"| 133.900 (7) ||align="center"| many ||align="center"| 4/8 ||
|-
| KLSV || [[Nellis Air Force Base|Nellis Air Force]] || USA NV || America ||align="center"| *** ||align="center"| L ||align="center"| 132.550 (6) ||align="center"| -- ||align="center"| 2/1 ||
|-
| KLWD || Lewistown || USA MT || America ||align="center"| ** ||align="center"| M ||align="center"| -- ||align="center"| -- ||align="center"| 3/0 ||
|-
| KMTN || Martin State || USA MD || America ||align="center"| ** ||align="center"| M ||align="center"| 121.300 (4) ||align="center"| -- ||align="center"| 2/2 || airport and terrain modeled
|-
| KNID || China Lake Naval || USA CA || America ||align="center"| ** ||align="center"| M ||align="center"| 120.150 (2) ||align="center"| -- ||align="center"| 3/0 ||
|-
| KNUQ || Moffett Federal AFLD || USA CA || America ||align="center"| ** ||align="center"| M ||align="center"| 119.550 (6) ||align="center"| -- ||align="center"| 2/2 ||
|-
| KOAK || Oakland || USA CA || America ||align="center"| ** ||align="center"| L ||align="center"| 127.200 (7) ||align="center"| many ||align="center"| 4/3 ||
|-
| KORD ||[[O'Hare International Airport|Chicago O'Hare]] || USA IL || America ||align="center"| ** ||align="center"| L ||align="center"| -- ||align="center"| many ||align="center"| 7/14 ||
|-
| KOSH || Wittman Rgl. || USA WI || America ||align="center"| ** ||align="center"| M ||align="center"| 118.500 (4) ||align="center"| -- ||align="center"| 4/1 ||
|-
| KOXB || Ocean City Muni. || USA MD || America ||align="center"| ** ||align="center"| S ||align="center"| -- ||align="center"| -- ||align="center"| 2/0 ||
|-
| KPDX || Portland || USA OR || America ||align="center"| ** ||align="center"| L ||align="center"| -- ||align="center"| -- ||align="center"| 3/5 ||
|-
| KPHX || Phoenix || USA AZ || America ||align="center"| ** ||align="center"| L ||align="center"| 120.900 (6) ||align="center"| -- ||align="center"| 3/5 || most skyscrapers modeled
|-
| KRDU || Raleigh || USA NC || America ||align="center"| ** ||align="center"| L ||align="center"| 119.300 (12) ||align="center"| many ||align="center"| 3/4 ||nice for flying east-coast
|-
| KRNO || Reno/Tahoe || USA NZ || America ||align="center"| ** ||align="center"| M ||align="center"| 118.700 (7) ||align="center"| -- ||align="center"| 3/2 ||High in Clouds
|-
| KSAN || San Diego || USA AZ || America ||align="center"| * ||align="center"| M ||align="center"| 118.300 (7) ||align="center"| many ||align="center"| 1/2 ||Interesting area at boarder to mexico
|-
| KSEA || [[Seattle-Tacoma International Airport|Seattle Tacoma]] || USA WA || America ||align="center"| ** ||align="center"| L ||align="center"| 119.900 (9) ||align="center"| -- ||align="center"| 3/5 || basic terminal model, some skyscrapers modeled
|-
| KSFO || [[San Francisco International Airport|San Francisco]] || USA CA || America ||align="center"| **** ||align="center"| L ||align="center"| 120.500 (7) ||align="center"| many ||align="center"| 4/3 ||FGFS Default -- overcrowded
|-
| KSLC || Salt Lake City || USA UT || America ||align="center"| * ||align="center"| L ||align="center"| 118.300 (13) ||align="center"| -- ||align="center"| 4/6 ||very high in clouds (4227 ft, 1290 m)
|-
| KSJC || [[San Jose International Airport|San Jose]] || USA CA || America ||align="center"| * ||align="center"| M ||align="center"| 124.00 (7) ||align="center"| 14 ||align="center"| 3/2 ||Bay-area near KSFO
|-
| LDSP || Split || Croatia || Europe ||align="center"| ** ||align="center"| M ||align="center"| unknown ||align="center"| -- ||align="center"| 1/1 ||Small civil airport with awesome scenery neighboring.
|-
| LDZU || Udbina || Croatia || Europe ||align="center"| * ||align="center"| M ||align="center"| -- ||align="center"| -- ||align="center"| 1/0 ||interesting airport high in Mountains - no ILS
|-
| LFFE || Enghien Moisselles || France || Europa ||align="center"| *** ||align="center"| S ||align="center"| --- ||align="center"| -- ||align="center"| 2/0 ||nice little Green-Field just north of Paris
|-
| LFML || Marseille || France || Europa ||align="center"| * ||align="center"| M ||align="center"| 118.370 (4) ||align="center"| many ||align="center"| 2/2 ||Mediterranean coast
|-
| LFPG || Paris Charles de Gaulle || France || Europa ||align="center"| **** ||align="center"| L ||align="center"| 123.600 (23) ||align="center"| -- ||align="center"| 4/8 ||very detailed city of Paris near by
|-
| LFPH || Chelles Le Pin || France || Europa ||align="center"| *** ||align="center"| S ||align="center"| -- ||align="center"| -- ||align="center"| 2/0 ||nice little Green-Field just south of Paris
|-
| LFPL || Lognes Emerainville || France || Europa ||align="center"| *** ||align="center"| S ||align="center"| -- ||align="center"| -- ||align="center"| 3/0 ||nice little airport just south of Paris
|-
| LFPO || Paris Orly || France || Europa ||align="center"| **** ||align="center"| M ||align="center"| 120.500 (13) ||align="center"| -- ||align="center"| 3/5 ||the older airport at Paris
|-
| LFPZ || St-Cyr l'Ecole || France || Europa ||align="center"| *** ||align="center"| S ||align="center"| -- ||align="center"| -- ||align="center"| 2/0 ||nice little airport just west of Paris, near Versailles Castle
|-
| LFRJ || Landivisiau || France || Europa ||align="center"| ** ||align="center"| M ||align="center"| 119.700 (2) ||align="center"| -- ||align="center"| 1/1 ||Naval Base
|-
| LFSB || [[EuroAirport_Basel-Mulhouse-Freiburg|Basel-Mulhouse]] || Swiss || Europa ||align="center"| *** ||align="center"| L ||align="center"| 118.300 (7) ||align="center"| 5 ||align="center"| 2/1 || Nice modelling of Terminal.
|-
| LHBP || Budapest || Hungaria || Europa ||align="center"| * ||align="center"| L ||align="center"| 118.100 (4) ||align="center"| many ||align="center"| 2/4 ||in-midst the typical Puszta-area
|-
| LILN || Venegono || Italy || Europa ||align="center"| ** ||align="center"| S ||align="center"| 128.550 (1) ||align="center"| -- ||align="center"| 1/0 ||
|-
| LILV || Valbrembo || Italy || Europa ||align="center"| ** ||align="center"| S ||align="center"| -- ||align="center"| -- ||align="center"| 1/0 ||recreation area: Mountains, tennis, pool, etc.
|-
| LIMC || Milano Malpensa || Italy || Europa ||align="center"| *** ||align="center"| L ||align="center"| 119.000 (11) ||align="center"| -- ||align="center"| 2/3 ||
|-
| LIME || Bergamo-Orio al Serio || Italy || Europa ||align="center"| ** ||align="center"| M ||align="center"| 120.500 (5) ||align="center"| -- ||align="center"| 2/1 ||nice mountain area
|-
| LIML || Milano Limate || Italy || Europa ||align="center"| *** ||align="center"| M ||align="center"| 119.250 (5) ||align="center"| -- ||align="center"| 2/1 ||
|-
| LIMW || Aosta || Italy || Europa ||align="center"| * ||align="center"| M ||align="center"| 119.950 (1) ||align="center"| -- ||align="center"| 1/0 ||in a valley in high mountain area
|-
| LIPA || [[Aviano Air Base]] || Italy || Europe ||align="center"| * ||align="center"| L ||align="center"| 122.100 ||align="center"| -- ||align="center"| 1/1 ||Military airport with various scenery neighboring: Carnic Alps, Po Valley and the Adriatic Sea.
|-
| LJCE || Cerklje || Slovenia || Europe ||align="center"| * ||align="center"| L ||align="center"| - ||align="center"| -- ||align="center"| 1/1 || Military airport with civilian part near Croatia
|-
| LJLJ || Ljubljana Brnik || Slovenia || Europe ||align="center"| * ||align="center"| L ||align="center"| - ||align="center"| -- ||align="center"| 1/1 || capital of Slovenia
|-
| LJPZ || Portorož || Slovenia || Europe ||align="center"| * ||align="center"| L ||align="center"| - ||align="center"| -- ||align="center"| 1/1 || at the adriatic sea
|-
| LPLA || [[Lajes Field]] || Azores, Portugal || Europe ||align="center"| * ||align="center"| L ||align="center"| 122.100 ||align="center"| -- ||align="center"| 1/1 ||Military-Civil airport with various small islands neighboring.
|-
| LQSA || Sarajewo || Bosnia || Europe ||align="center"| * ||align="center"| S ||align="center"| 118.250 (3) ||align="center"| -- ||align="center"| 1/1 ||very nice mountain region: LQSA, LYTV, LYPG
|-
| LOWI || [[Innsbruck Airport|Innsbruck]] || Austria || Europe ||align="center"| **** ||align="center"| S ||align="center"| 120.100 (3) ||align="center"| -- ||align="center"| 1/1 || very nice and difficult approach, wonderful scenery
|-
| LROP || Bucharest || Romania || Europe ||align="center"| ** ||align="center"| M ||align="center"| 121.850 (3) ||align="center"| -- ||align="center"| 2/4 ||
|-
| LSGS || Sion || Swiss || Europe ||align="center"| * ||align="center"| S ||align="center"| 118.217 (5) ||align="center"| -- ||align="center"| 1/1 ||Wonderful surrounded by high mountains
|-
| LSZH || Zürich-Kloten || Swiss || Europe ||align="center"| ** ||align="center"| L ||align="center"| 121.800 ||align="center"| many ||align="center"| 3/4 ||very nice mountain/lake area
|-
| LSZB|| Bern-Belp || Swiss || Europe ||align="center"| ** ||align="center"| M ||align="center"| 121.020 (3) ||align="center"| -- ||align="center"| 2/1 ||
|-
| LSZS|| Samedan || Swiss || Europe ||align="center"| *** ||align="center"| M ||align="center"| 135,320 (3) ||align="center"| -- ||align="center"| 1/0 || Very nice high mountain region, AP at 5600 ft (1700 m)
|-
| PANC|| Anchorage || USA Alaska || America ||align="center"| *** ||align="center"| L ||align="center"| 118.300 (9) ||align="center"| -- ||align="center"| 3/3 ||interesting area
|-
| LYBE || Belgrad || Serbia || Europe ||align="center"| *** ||align="center"| M ||align="center"| 118.100 (2) ||align="center"| -- ||align="center"| 1/2 ||
|-
| LYPG || Podgorica || Montenegro || Europe ||align="center"| * ||align="center"| M ||align="center"| 118.200 (2) ||align="center"| -- ||align="center"| 2/1 || very nice mountain region: LQSA, LYTV, LYPG
|-
| LYTV || Tivat || Montenegro || Europe ||align="center"| * ||align="center"| M ||align="center"| 118.000 (1) ||align="center"| -- ||align="center"| 1/1 || very nice mountain region: LQSA, LYTV, LYPG
|-
| MUHA || Havana || Cuba || America ||align="center"| * ||align="center"| L ||align="center"| 118.100 (4) ||align="center"| many ||align="center"| 1/1 ||nice for island-hopping
|-
| NZAA || Auckland || New Zealand || Oceania ||align="center"| * ||align="center"| M ||align="center"| 118.700 ||align="center"| many ||align="center"| 2/2 ||nice for island-hopping
|-
| OMAA || Abu Dahbi || United AE || Asia ||align="center"| * ||align="center"| L ||align="center"| 119.200 ||align="center"| many ||align="center"| 1/2 ||interesting area
|-
| OOMS || Seeb || United AE || Asia ||align="center"| * ||align="center"| M ||align="center"| 118.400 (5) ||align="center"| many ||align="center"| 2/2 ||nice sea/mountain area
|-
| PHNL || Honolulu || USA Hawaii || America ||align="center"| * ||align="center"| M ||align="center"| 123.900 (5) ||align="center"| many ||align="center"| 4/2 ||wonderful island scenery
|-
| PHOG || Kahului || USA Hawaii || America ||align="center"| * ||align="center"| M ||align="center"| ||align="center"| ||align="center"| 2/1 ||wonderful island scenery
|-
| RJTT || [[Tokyo Haneda International Airport|Tokyo]] || Japan || Asia ||align="center"| *** ||align="center"| L ||align="center"| 126.200 (6) ||align="center"| -- ||align="center"| 3/3 ||interesting area
|-
| RKSI || Seoul || South Korea || Asia ||align="center"| *** ||align="center"| L ||align="center"| 118.800 (6) ||align="center"| -- ||align="center"| 2/4 ||
|-
| RPLL || Manila || Philipines || Asia ||align="center"| *** ||align="center"| L ||align="center"| 118.100 (5) ||align="center"| -- ||align="center"| 2/2 ||
|-
| TDPD || Melville Hall || Dominica || America ||align="center"| ** ||align="center"| L ||align="center"| 118.100 (5) ||align="center"| -- ||align="center"| 2/2 ||nice area
|-
| TFFF || Le Lamentin || Martinique || America ||align="center"| *** ||align="center"| M ||align="center"| 118.500 (5) ||align="center"| -- ||align="center"| 1/1 ||nice area
|-
| TFFG || Grand Case || Anguilla || America ||align="center"| ** ||align="center"| S ||align="center"| 128.940 (3) ||align="center"| -- ||align="center"| 1/0 ||nice area
|-
| TIST || Cyril E King || Virgin Islands || America ||align="center"| ** ||align="center"| S ||align="center"| -- ||align="center"| -- ||align="center"| 1/1 ||nice area
|-
| TJSJ || San Juan || Puerto Rico || America ||align="center"| *** ||align="center"| M ||align="center"| 132.050 (6) ||align="center"| -- ||align="center"| 2/2 ||nice area
|-
| TKPK || Saint Kitts || Guadeloupe || America ||align="center"| ** ||align="center"| M ||align="center"| 118.300 (3) ||align="center"| -- ||align="center"| 1/0 ||nice area
|-
| TNCM || [[Princess Juliana International Airport|Princess Juliana]] || ST Maarten || America ||align="center"| *** ||align="center"| M ||align="center"| 118.700 (2) ||align="center"| -- ||align="center"| 1/0 ||very nice area
|-
| TQPF || Wallblake || Anquilla || America ||align="center"| ** ||align="center"| S ||align="center"| 18.500 (3) ||align="center"| -- ||align="center"| 1/0 ||nice area
|-
| VIDP || New Dehli || India || Asia ||align="center"| ** ||align="center"| L ||align="center"| 119.300 (5) ||align="center"| many ||align="center"| 2/3 ||nice area
|-
| VHHH || Hong Kong || China || Asia ||align="center"| * ||align="center"| L ||align="center"| 118.400 (16) ||align="center"| many ||align="center"| 2/4 ||very nice mountain/sea area
|-
| WSSS || [[Singapore Changi International Airport|Singapore Changi]] || Singapore || Asia ||align="center"| **** ||align="center"| L ||align="center"| 118.600 (8) ||align="center"| many ||align="center"| 2/3 ||Very nice modelled from TheOmegaHangar one. Best in FlightGear
|-
| YBAS || Alice Springs || Australia NT || Oceania ||align="center"| * ||align="center"| M ||align="center"| 118.300 (2) ||align="center"| 26 ||align="center"| 3/1 ||Australian Back-Country
|-
| YBBN || Brisbane || Australia NSW || Oceania ||align="center"| *** ||align="center"| L ||align="center"| 120.500 (11) ||align="center"| many ||align="center"| 3/6 ||
|-
| YPDN || Darwin || Australia NT || Oceania ||align="center"| * ||align="center"| M ||align="center"| 133.100 (8) ||align="center"| many ||align="center"| 2/1 ||
|-
| YSCB || Canberra || Australia NSW || Oceania ||align="center"| * ||align="center"| M ||align="center"| 118.700 (5) ||align="center"| many ||align="center"| 2/1 ||High Mountain region (1800 ft, 550 m)
|-
| YSSY || [[Sydney International Airport|Sydney]] || Australia NSW || Oceania ||align="center"| * ||align="center"| L ||align="center"| 120.500 (11) ||align="center"| many ||align="center"| 3/6 ||
|-
|}

{{suggested}}

[[Category:Airports]]

Saab 35 Draken

2017-05-25T18:52:42Z

AndersM: /* Gauges and instruments */ Added image references

{{:{{PAGENAME}}/info}}
The '''Saab 35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit image.

=== Special aircraft keys ===
{| class="keytable"
! Key
! Function
|-
| {{key press|Shift|S}}
| Automatic start sequence including all systems. (The aircraft needs to be stationary.)
|-
| {{key press|Shift|L}}
| Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
|-
| {{key press|Ctrl|J}}
| Jettison drop tanks in air.
|-
| {{key press|Ctrl|D}}
| Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks
|}

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below.

*HÖJDV: Flashes when autopilot HÖJD (altitude hold) is set and aircraft not at target altitude or vertical speed above 200 m/min. Lit when stable at target altitude. It is recommended to be at target altitude before setting autopilot to HÖJD.

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of drop-tanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7)

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Showing a sweep and antenna azimuth as well as navigation indicators.
In multiplayer the radar shows aircraft in radar range: dist. < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground.
Yellow lines are navigation indicators used by the navigation system. See below.
Radar modes are set on the navigation radio.

'''Radio'''

The radio equipment consists of two transceiver and one control unit of model Fr-21. They are on the left horizontal panel (14). In the simulation both transceivers are used for communication. In the real aircraft one was the receiver for combat control data feeding the AHK and other avionics. The letters A-K stores pre set frequencies for transceiver A (closest to the control unit) and the numbers 1-5 stores pre set frequencies fro transceiver B. A stores the COM1 frequency at FG start up, B stores COM1 standby frequency. Number 1 stores the COM2 frequency at FG start up, 2 stores COM2 standby frequency. The frequency for the other letters and numbers are in the text file Avionics/Fr21.txt and can be changed by the user.
Pressing the buttons marked with dash (-) makes it possible to manually set the transceiver’s frequency using the knobs on the unit.
The radio is off at simulation start. Transceiver B uses battery power and transceiver A uses main AC.

'''Autopilot'''

The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''Navigation radio and mode selector'''

3D model right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, Radar off, AHK 0, cn manual
*FÖRV: (Preselected) No nav radio, Radar off, AHK HÖJDÄNDRING, cn manual
*STRIL: (Combat command) Activates Route Manager, Radar scanning, AHK NYTT MÅL, cn direction to next waypoint.
*STRID: (Combat) No nav info, Radar scanning, AHK HÖJDÄNDRING, cn manual
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon.
*LANDN 40: (Landing 40 km) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK LANDA, cn direction to beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters NAV+LANDN. Radar shows glide slope pointers, AHK BARBRO, cn direction to ILS beacon.

'''Special Controls and switches'''
*Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Start panel: Lower left instrument panel.(2) Se below.
*Instrument and panel lighting: Left side knob above throttle.(1) Click to change intensity.
Landing/taxi light switches: Left front canopy rim (12). Left and right landing light. If switches are in on position the lights will be automatically turned on/off as landing gear are lowered/rised.
Navigation lights (sv. "Lanternor"): Right aft panel (13). Three settings are implemented; off, dim and bright.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* It is neutral in roll at low alpha. Keep an eye on the horizon.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 270 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

Lift off: Rotate at 270 km/h to 10-12 degrees pitch. Lift off at approx 300 km/h. Turn of afterburner at 500 km/h if not needed for climbing. Normal climb speed Mach 0.9.

Landing: Lower speed to 500 km/h. Lower gears and turn on landing lights. Turn to final lowering the speed to 325 km/h. Keep a speed of 300 km/h and a plané of 3 degrees (100 m at 2 km distance), RPM 80-85%. After touchdown raise the nose up to increase drag until speed is 240 km/h. Apply brakes. Lower nose at 160 km/h.

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

{{Saab}}

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engine jets]]

File:Saab J35 cockpit.jpg

2017-05-25T18:47:49Z

AndersM: AndersM uploaded a new version of File:Saab J35 cockpit.jpg

=={{int:filedesc}}==
{{Information
|description={{en|1=Cockpit of the Saab J35 Draken.}}
|date=2013-03-04
|source={{own}}
|author=[[User:Gijs|Gijs]]
|permission=
|other_versions=
|other_fields=
}}

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

[[Category:Screenshots of cockpits]]

File:Saab J35.jpg

2017-05-25T18:08:43Z

AndersM: AndersM uploaded a new version of File:Saab J35.jpg

Saab 35 Draken

2017-05-25T18:02:56Z

AndersM: Updated with Radio info etc.

{{:{{PAGENAME}}/info}}
The '''Saab 35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit image.

=== Special aircraft keys ===
{| class="keytable"
! Key
! Function
|-
| {{key press|Shift|S}}
| Automatic start sequence including all systems. (The aircraft needs to be stationary.)
|-
| {{key press|Shift|L}}
| Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
|-
| {{key press|Ctrl|J}}
| Jettison drop tanks in air.
|-
| {{key press|Ctrl|D}}
| Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks
|}

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below.

*HÖJDV: Flashes when autopilot HÖJD (altitude hold) is set and aircraft not at target altitude or vertical speed above 200 m/min. Lit when stable at target altitude. It is recommended to be at target altitude before setting autopilot to HÖJD.

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of drop-tanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7)

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Showing a sweep and antenna azimuth as well as navigation indicators.
In multiplayer the radar shows aircraft in radar range: dist. < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground.
Yellow lines are navigation indicators used by the navigation system. See below.
Radar modes are set on the navigation radio.

'''Radio'''

The radio equipment consists of two transceiver and one control unit of model Fr-21. They are on the left horizontal panel. In the simulation both transceivers are used for communication. In the real aircraft one was the receiver for combat control data feeding the AHK and other avionics. The letters A-K stores pre set frequencies for transceiver A (closest to the control unit) and the numbers 1-5 stores pre set frequencies fro transceiver B. A stores the COM1 frequency at FG start up, B stores COM1 standby frequency. Number 1 stores the COM2 frequency at FG start up, 2 stores COM2 standby frequency. The frequency for the other letters and numbers are in the text file Avionics/Fr21.txt and can be changed by the user.
Pressing the buttons marked with dash (-) makes it possible to manually set the transceiver’s frequency using the knobs on the unit.
The radio is off at simulation start. Transceiver B uses battery power and transceiver A uses main AC.

'''Autopilot'''

The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''Navigation radio and mode selector'''

3D model right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, Radar off, AHK 0, cn manual
*FÖRV: (Preselected) No nav radio, Radar off, AHK HÖJDÄNDRING, cn manual
*STRIL: (Combat command) Activates Route Manager, Radar scanning, AHK NYTT MÅL, cn direction to next waypoint.
*STRID: (Combat) No nav info, Radar scanning, AHK HÖJDÄNDRING, cn manual
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon.
*LANDN 40: (Landing 40 km) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK LANDA, cn direction to beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters NAV+LANDN. Radar shows glide slope pointers, AHK BARBRO, cn direction to ILS beacon.

'''Special Controls and switches'''
*Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Start panel: Lower left instrument panel.(2) Se below.
*Instrument and panel lighting: Left side knob above throttle.(1) Click to change intensity.
Landing/taxi light switches: Left front canopy rim. Left and right landing light. If switches are in on position the lights will be automatically turned on/off as landing gear are lowered/rised.
Navigation lights (sv. "Lanternor"): Right aft panel. Three settings are implemented; off, dim and bright.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* It is neutral in roll at low alpha. Keep an eye on the horizon.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 270 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

Lift off: Rotate at 270 km/h to 10-12 degrees pitch. Lift off at approx 300 km/h. Turn of afterburner at 500 km/h if not needed for climbing. Normal climb speed Mach 0.9.

Landing: Lower speed to 500 km/h. Lower gears and turn on landing lights. Turn to final lowering the speed to 325 km/h. Keep a speed of 300 km/h and a plané of 3 degrees (100 m at 2 km distance), RPM 80-85%. After touchdown raise the nose up to increase drag until speed is 240 km/h. Apply brakes. Lower nose at 160 km/h.

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

{{Saab}}

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engine jets]]

System dependent instruments

2017-04-29T19:12:53Z

AndersM: /* Static */ Reference to info

The tables below shows the properties that the different {{flightgear source|path=src/Instrumentation|text=standard instrument implementations}} are dependent on.

== Electrical ==

{| class="wikitable"
! Source file !! Instrument !! Property!! Comment
|-
|heading_indicator_dg || Directional Gyro (DG) || /systems/electrical/outputs/DG || drives gyro, > 0.02 to work
|-
| dme || Distance measuring equipment (DME) || /systems/electrical/outputs/dme || any non zero works
|-
| kr_87 || King KR 87 Digital ADF || /systems/electrical/outputs/adf || > 1 to work
|-
| turn_indicator || Turn Indicator || /systems/electrical/outputs/turn-coordinator[n]<ref>https://sourceforge.net/p/flightgear/flightgear/ci/2b9de5ceaa2e59b0a042ac1eea77e97ef2b6b5d3/</ref> || drives gyro, > 0.24 to work
|-
| mrg || master reference gyro || /systems/electrical/outputs/MRG || drives gyro, > 0.5 to work
|-
| gps || GPS || /systems/electrical/outputs/gps || any non zero works
|-
| kt_70 || Transponder || /systems/electrical/outputs/transponder || >1 to work
|-
| adf || ADF ||/systems/electrical/outputs/adf || needs to be >8 to work
|-
| mk_viii || Honeywell MK VIII EGPWS || /systems/electrical/outputs/mk[n] || >=15 to work
|-
| heading_indicator_fg || Flux-gate compass || /systems/electrical/outputs/DG || drives gyro, > 0.02 to work
|-
| transponder || Transponder || /systems/electrical/outputs/transponder || needs to be >8 to work
|-
| tacan || TACAN || systems/electrical/outputs/tacan || any non zero
|-
| navradio || Navigation radios (eg. kx165) || /systems/electrical/outputs/nav[n] || > 1 to work
|-
| marker_beacon || Marker beacon indicator ||/systems/electrical/outputs/nav[0] || > 1 to work
|}

{{Appendix}}

== Vacuum ==
{| class="wikitable"
! Source file !! Instrument !! Property !! Comment
|-
| heading_indicator || Heading indicator || /systems/vacuum/suction-inhg || drives gyro > 0.1 to work
|-
| attitude_indicator || Attitude indicator || /systems/vacuum/suction-inhg" || drives gyro > 0.1 to work
|}

== Static ==
See futher [[FGproperties/Systems/static]]
{| class="wikitable"
! Source file !! Instrument !! Property !! Comment
|-
| altimeter || Altimeter || /systems/static/pressure-inhg || tau default 0.1
|-
| vertical_speed_indicator || VSI || /systems/static/pressure-inhg ||
|-
| airspeed_indicator || Airspeed indicator || /systems/static/pressure-inhg ||
|}

== Pitot ==
See futher [[FGproperties/Systems/Pitot]]
{| class="wikitable"
! Source file !! Instrument !! Property !! Comment
|-
| airspeed_indicator || Airspeed indicator || /systems/pitot/total-pressure-inhg ||
|}

[[Category:Core development]]

System dependent instruments

2017-04-29T19:11:34Z

AndersM: /* Pitot */ reference to info

The tables below shows the properties that the different {{flightgear source|path=src/Instrumentation|text=standard instrument implementations}} are dependent on.

== Electrical ==

{| class="wikitable"
! Source file !! Instrument !! Property!! Comment
|-
|heading_indicator_dg || Directional Gyro (DG) || /systems/electrical/outputs/DG || drives gyro, > 0.02 to work
|-
| dme || Distance measuring equipment (DME) || /systems/electrical/outputs/dme || any non zero works
|-
| kr_87 || King KR 87 Digital ADF || /systems/electrical/outputs/adf || > 1 to work
|-
| turn_indicator || Turn Indicator || /systems/electrical/outputs/turn-coordinator[n]<ref>https://sourceforge.net/p/flightgear/flightgear/ci/2b9de5ceaa2e59b0a042ac1eea77e97ef2b6b5d3/</ref> || drives gyro, > 0.24 to work
|-
| mrg || master reference gyro || /systems/electrical/outputs/MRG || drives gyro, > 0.5 to work
|-
| gps || GPS || /systems/electrical/outputs/gps || any non zero works
|-
| kt_70 || Transponder || /systems/electrical/outputs/transponder || >1 to work
|-
| adf || ADF ||/systems/electrical/outputs/adf || needs to be >8 to work
|-
| mk_viii || Honeywell MK VIII EGPWS || /systems/electrical/outputs/mk[n] || >=15 to work
|-
| heading_indicator_fg || Flux-gate compass || /systems/electrical/outputs/DG || drives gyro, > 0.02 to work
|-
| transponder || Transponder || /systems/electrical/outputs/transponder || needs to be >8 to work
|-
| tacan || TACAN || systems/electrical/outputs/tacan || any non zero
|-
| navradio || Navigation radios (eg. kx165) || /systems/electrical/outputs/nav[n] || > 1 to work
|-
| marker_beacon || Marker beacon indicator ||/systems/electrical/outputs/nav[0] || > 1 to work
|}

{{Appendix}}

== Vacuum ==
{| class="wikitable"
! Source file !! Instrument !! Property !! Comment
|-
| heading_indicator || Heading indicator || /systems/vacuum/suction-inhg || drives gyro > 0.1 to work
|-
| attitude_indicator || Attitude indicator || /systems/vacuum/suction-inhg" || drives gyro > 0.1 to work
|}

== Static ==
{| class="wikitable"
! Source file !! Instrument !! Property !! Comment
|-
| altimeter || Altimeter || /systems/static/pressure-inhg || tau default 0.1
|-
| vertical_speed_indicator || VSI || /systems/static/pressure-inhg ||
|-
| airspeed_indicator || Airspeed indicator || /systems/static/pressure-inhg ||
|}

== Pitot ==
See futher [[FGproperties/Systems/Pitot]]
{| class="wikitable"
! Source file !! Instrument !! Property !! Comment
|-
| airspeed_indicator || Airspeed indicator || /systems/pitot/total-pressure-inhg ||
|}

[[Category:Core development]]

Standard instrument selection

2017-04-29T12:24:35Z

AndersM: added a note about separate fil

By default an aircraft gets access to a number of standard instruments via instrument properties. These instruments are [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Instrumentation/instrument_mgr.cxx C++ coded]. Some of them depends on [[System dependent instruments|different aircraft systems]].

It is possible to override the default selection by adding your own instrument property file listing the standard instruments that you want to use in the aircraft. Eg:

<pre>
<?xml version="1.0"?>

<PropertyList>

<airspeed-indicator>
<name>airspeed-indicator</name>
<number>0</number>
<total-pressure>/systems/pitot/total-pressure-inhg</total-pressure>
<static-pressure>/systems/static/pressure-inhg</static-pressure>
</airspeed-indicator>

<altimeter>
<name>altimeter</name>
<number>0</number>
<static-pressure>/systems/static/pressure-inhg</static-pressure>
<quantum>0</quantum>
<tau>0</tau>
</altimeter>

<magnetic-compass>
<name>magnetic-compass</name>
<number>0</number>
</magnetic-compass>

</PropertyList>
</pre>

Then edit the -set.xml file and add a path to your own instrument file in the sim property-tree:

<pre>
<sim>
(...)
<instrumentation>
<path>Aircraft/MyAircraft/Instrumentation/my-instruments.xml</path>
</instrumentation>
</sim>
</pre>

'''Note:''' Due to how the instrumentation handling is coded you must create a separate file for your instrument list and use the sim/instrumentation/path node.

You can also change the properties that some of the instruments depend on to function. Eg. Changing the attitude indicator to use battery voltage property instead of vacuum suction to drive the gyro:
<pre>
<attitude-indicator>
<name>attitude-indicator</name>
<number>0</number>
<suction>systems/electrical/outputs/battery_voltage</suction>
</attitude-indicator>
</pre>

Standard instrument selection

2017-04-29T12:19:45Z

AndersM: Short info on how to edit the selection of standard instruments for an aircraft

By default an aircraft gets access to a number of standard instruments via instrument properties. These instruments are [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Instrumentation/instrument_mgr.cxx C++ coded]. Some of them depends on [[System dependent instruments|different aircraft systems]].

It is possible to override the default selection by adding your own instrument property file listing the standard instruments that you want to use in the aircraft. Eg:

<pre>
<?xml version="1.0"?>

<PropertyList>

<airspeed-indicator>
<name>airspeed-indicator</name>
<number>0</number>
<total-pressure>/systems/pitot/total-pressure-inhg</total-pressure>
<static-pressure>/systems/static/pressure-inhg</static-pressure>
</airspeed-indicator>

<altimeter>
<name>altimeter</name>
<number>0</number>
<static-pressure>/systems/static/pressure-inhg</static-pressure>
<quantum>0</quantum>
<tau>0</tau>
</altimeter>

<magnetic-compass>
<name>magnetic-compass</name>
<number>0</number>
</magnetic-compass>

</PropertyList>
</pre>

Then edit the -set.xml file and add a path to your own instrument file in the sim property-tree:

<pre>
<sim>
(...)
<instrumentation>
<path>Aircraft/MyAircraft/Instrumentation/my-instruments.xml</path>
</instrumentation>
</sim>
</pre>

You can also change the properties that some of the instruments depend on to function. Eg. Changing the attitude indicator to use battery voltage property instead of vacuum suction to drive the gyro:
<pre>
<attitude-indicator>
<name>attitude-indicator</name>
<number>0</number>
<suction>systems/electrical/outputs/battery_voltage</suction>
</attitude-indicator>
</pre>

ALS technical notes

2017-04-16T21:38:43Z

AndersM: /* Configuring the light */ Showing <use> as property tag

== Quality level mapping ==
The rendering quality of ALS effects is controlled by two main sliders, the landmass effects and transition effects. The transition effects slider regulates the quality of overlaid textured, while the landmass effects slider regulates all other aspects of procedural texturing, such as pixel color post-processing (dust, snow or wet terrain effects) and apparent terrain roughness (bump and parallax mapping).

In addition, specific effects for certain terrain types (water, urban, forest, agriculture, etc.) and models in the scene can be switched on separately. In some cases, this may be needed for a consistent visual impression. For example, if a dust effect is used on the terrain, the water needs to be rendered using a separate water shader, otherwise it will appear dusty as well. Likewise, if the Rayleigh haze is used in the highest quality terrain effect, then the highest quality water effect needs to be used to see the same Rayleigh scattering effect on the water.

For technical reasons (landmass and transition control the same shader code) the settings are sometimes mutually dependent, e.g., if the transition quality is set to level 6, it won't have any effect until the landmass quality is also set to level 6.

=== Transition ===
The mapping of quality to visuals of the transition slider is as follows:

{| class="wikitable"
! Level !! Comments
|-
! scope="row" | 1
| Base texture scheme
|-
! scope="row" | 2
| Alternative hires airport keep effect
|-
! scope="row" | 3
|
* Base and overlay texture, runway effect (if landmass is above level 4)
* Secondary lights on runway and airport keep
|-
! scope="row" | 4
| Base, overlay and hires texture
|-
! scope="row" | 5
| Base, overlay, hires, detail, grain, dot and rock texture (if landmass is level 6)
|}

=== Landmass ===
{{Note|Quality levels 1 and 2 are reserved to represent fixed pipeline rendering and the "default renderer" in an eventually merged rendering GUI. However, ALS is currently switched on per checkbox and not by quality level, and so they do not have a function.}}

{| class="wikitable"
! Level !! Comments
|-
! scope="row" | 1
| ''See note above''
|-
! scope="row" | 2
| ''See note above''
|-
! scope="row" | 3
| ALS-rendered position-differential haze and light, moonlight
|-
! scope="row" | 4
|
* Procedural snow cover on terrain
* Procedural dust and vegetation effects
* Wet terrain effect with approximate reflection half vector
* Patchy fog distribution
|-
! scope="row" | 5
| Noise bump-mapping and parallax mapping of terrain
|-
! scope="row" | 6
| (''Requires transition effect level 6'')
* Wet terrain effect with correct reflection half vector
* Hires bump mapping and snow patchiness
* Variable upper haze layer surface
* Rayleigh haze
* Secondary lights on all terrain types
* Slope line and strata effects
|}

== ALS secondary lights ==
The ALS framework supports a generic implementation of landing lights and a searchlight which are based on a framerate-friendly computation in screen coordinates, i.e., the lights project correctly ''only if the light is close to the viewer'' (typically, that would be from cockpit view). In other words, this is not a full (and rather expensive) computation of light volumes as in Rembrandt, but a much faster test of illuminated screen areas.

[[File:Landing light03.jpg|400px|Cessna 172P using generic ALS landing lights]]

Two landing lights and a searchlight are supported. The landing lights have a fixed position with respect to the aircraft axis (technically, with respect to the default view axis as defined in the respective view), whereas the searchlight follows any offset of the view axis in view mode, i.e., when using the mouse to look around, the searchlight will follow the motion, the landing lights will not. The lights require ALS to run above basic quality level and work on runway and airport keep above transition setting 3 and everywhere else only at highest quality setting. All lights are controlled via properties in <code>/sim/rendering/als-secondary-lights/</code>.

The names of the properties should be self-explanatory, if for instance if <code>/sim/rendering/als-secondary-lights/use-searchlight</code> is set to true, then the searchlight (which always follows the current view axis) is used.

The properties <code>/sim/rendering/als-secondary-lights/landing-light1-offset-deg</code> and <code>/sim/rendering/als-secondary-lights/landing-light2-offset-deg</code> allow to specify angular offsets for the landing light which are then not centered on the view axis. This can be used to simulate one or two landing lights set in the wings.

[[File:Offsetv2.jpg|400px|Secondary lights vertical offset demo]]

A third offset <code>/sim/rendering/als-secondary-lights/landing-light3-offset-deg</code> is available which allows for a vertical offset. This is especially useful for tail dagger aircraft.

[[File:Offsetv.jpg|400px|Secondary lights vertical offset settings]]

The lights can be switched on and off from the [[Property Browser]] for any aircraft without any modifications to the aircraft definition. Implementing them correctly aircraft side thus just involves linking the landing light switches to the ALS control properties and setting the correct angular offsets. Additionally, it is recommended to switch the lights off unless in a cockpit view, as they don't project correctly for any external view.

Range, color, light cone opening angle or intensity of the lights can currently not be configured, and there are no plans to support such a feature in the near future.

All three lights will illuminate fog (if dense enough) and precipitation.

[[File:Als secondary light fog.jpg|400px|ALS generic lights illuminating dense fog]]

== ALS specific features of the model effect ==

In addition to the features supported by the model-combined-deferred effect in all three renderers (normal, light, specular, environment reflection and dirt map), ALS also supports a couple of unique effects (which, if configured, will not have any effect in other renderers.

=== The grain texture ===

ALS supports a grain texture for models. This is a semi-transparent overlay texture that works just as [[Procedural Texturing#The grain texture|its equivalent for terrain texturing]] and provides the option of generating centimeter-scale details such as rust or discoloration on a surface without having to use huge textures. An example of a surface rendered with grain texture is the image of the USS Vinson flightdeck below:

[[File:Grain rain01.jpg|700px|Grain and rain effects on Vinson's flightdeck]]

This is done using the following effect declaration inheriting from '''model-combined-deferred.eff''' as
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<name>flightdeck</name>
<inherits-from>Effects/model-combined-deferred</inherits-from>
<parameters>
<grain-texture-enabled type="int">2</grain-texture-enabled>
<grain-magnification type="float">0.1</grain-magnification>
<rain-enabled type="int">2</rain-enabled>
<texture n="7">
<image>Models/Geometry/Nimitz/rust_texture.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>repeat</wrap-s>
<wrap-t>repeat</wrap-t>
<internal-format>normalized</internal-format>
</texture>
</parameters>

</PropertyList>
</syntaxhighlight>

The grain texture has the number 7 and needs to be enabled by
<syntaxhighlight lang="xml">
<grain-texture-enabled type="int">2</grain-texture-enabled>
</syntaxhighlight>

If the value is set to 1, the grain texture uses the uv-mapping of the underlying surface. If that is very irregular (as in the case of the Vinson flightdeck), alternatively the grain can be mapped in xy-model coordinates if the parameter is set to 2, the uv-mapping of the base texture layer is then discarded.

The resolution of the grain texture with respect to the base coordinate layer is specified by
<syntaxhighlight lang="xml">
<grain-magnification type="float">0.1</grain-magnification>
</syntaxhighlight>

If the number is less than 0, the grain resolution is lower than the base layer. If the parameter is greater than 0, it is higher (note that in the above case, the grain is mapped to (xy) rather than (uv), hence the base size is 1 m, so the grain texture is mapped on a 10x10 m patch on the flightdeck, for which a 1024x1024 pixel texture provides ~1 cm sized details).

=== The rain effect ===

Any number greater than 0 passed to
<syntaxhighlight lang="xml">
<rain-enabled type="int">2</rain-enabled>
</syntaxhighlight>

enables the splash effect of raindrops on the surface if it points upward. The surface does not have to be flat for this to work, the effect checks for the surface normal automatically, see the rain enabled for the Citation Bravo.

Thorsten noted about rain splashes: "Works fine here - runway needs to get really wet though before you see them (put the environment slider to max to achieve this quickly, it will take some waiting with just rain on)."

[[File:Grain rain02.jpg|700px|Rain effect on the Citation Bravo]]

=== Glossy surfaces ===

To better treat the environment reflections on a glossy surface, ALS contains two options not present in the other renderers.

<syntaxhighlight lang="xml">
<reflection-type type="int">1</reflection-type>
</syntaxhighlight>

This parameter can currently be set to 1 or 2 and regulates how the color of the environment reflection is merged with the color of the glossy surface. If set to 1, the shader uses a color mixing as in the other two renderers, if set to 2 it uses a technique called 'grain merge' which gives different weight to the color channels. The reason for introducing type 2 was a grey tint which changed the reflected color in a unrealistic way. With FlightGear 2017.2.0 this will be fixed and type set to 2 should be obsolete then.

<syntaxhighlight lang="xml">
<reflection-fresnel-factor type="float">0.0</reflection-fresnel-factor>
</syntaxhighlight>

This parameter regulates how strong the Fresnel term of a glossy surface is. Many smooth surfaces reflect much more under shallow angles such that an environment reflection is not very prominent when looking under 90 degrees but dominates the visuals when looking under a grazing angle. The parameter sets the relative strength of a Fresnel reflection with respect to the basic reflection definition which is assumed to hold for vertical viewing (i.e. setting the parameter to 0.8 gives you extra glossiness under shallow angles).

The following comparison shows the default color mixing (upper left) for a reflecting white livery and for grain merge (upper right). In addition, note the enhanced Fresnel reflectivity at the tail and the cowling on the pictures. The lower row shows (left) full reflection with default color mixing and (right) for grain merge. Default color mixing is more physically correct, while grain merge is less correct but preserves white color much better.

[[File:Reflect Model default2.jpg|400px|Effect of color mixing in a reflection]]
[[File:Reflect Grain merge2.jpg|400px|Effect of grain merge in reflection]]

[[File:Reflect Model Default Full.jpg|400px|Full reflection with default ]]
[[File:Reflect Grain Merge Full.jpg|400px|Full reflection with grain merge]]

== The exhaust flame effect ==

Rendering proper flames of e.g. afterburners or rocket thrusters with diffuse edges is notoriously difficult - all solutions based on textured models tend to have unnaturally sharp edges. Usually the particle system is used in such cases, however at high velocities this has other issues - particles become easily separated, making flames look disrupted and detached from the exhaust.

ALS includes a dedicated procedural effect in which the flame is rendered by numerically integrating a 3-dim distribution of glowing emitters inside a bounding box (i.e. re-creates the process by which a real flame would be seen). The function which determines the emitter distribution is partially user-controlled so that a wide range of shapes can be generated.

To use the effect, first the bounding box has to be defined. Note that the shape and alignment of the bounding box needs to be standardized for the effect to work, i.e. you need to use either the default bounding box under Aircraft/Generic/Effects/Thruster/ or make a custom one which fits inside the default box at the same location in model coordinates.

To change position, size and orientation of the bounding box to match with the airplane model, translate, scale and rotate animations or model offsets can later be used.

=== Model definition for effect ===
This is a standard XML model definition that needs to specify the geometry, all animations and the effect to use. For the geometry you can use the standard ''Aircraft/Generic/Effects/Thruster/thrust_flame.ac'' or make your own. The F-15 uses a slightly different 3D model to allow for the nozzles. The 3D model needs to be big enough to contain the flame, bearing in mind that the flame is drawn as a cylinder.

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>

<path>Aircraft/Generic/Effects/Thruster/thrust_flame.ac</path>
<nopreview/>
<animation>
<type>scale</type>
<property alias="/params/augmentation-alight"/>
<x-min>0.2</x-min>
<y-min>0.3</y-min>
<z-min>0.3</z-min>
<y-max>1</y-max>
<z-max>1</z-max>
<x-factor>0.472</x-factor>
<y-factor>0.6</y-factor>
<z-factor>0.6</z-factor>
</animation>

<animation>
<type>select</type>
<object-name>Bounding_box</object-name>
<condition>
<greater-than>
<property alias="/params/augmentation-ignition"/>
<value>0.8</value>
</greater-than>
</condition>
</animation>

<effect>
<inherits-from>Aircraft/MyAircraft/Models/Effects/my-flame</inherits-from>
<object-name>Bounding_box</object-name>
</effect>

</PropertyList>
</syntaxhighlight>

=== Effect definition for model ===
To define the effect to apply to the model (as referenced in the ''effect'' section in the model XML) you need to create ''my-flame.eff'' as below. The ''.eff'' file defines the parameters that are passed into the shader and it is these that control how the flame looks.

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<name>AB-flame</name>
<inherits-from>Effects/thrust-flame</inherits-from>
<parameters>
<base_flame_b type="float">0.8</base_flame_b>
<base_flame_density type="float">0.6</base_flame_density>
<base_flame_g type="float">0.9</base_flame_g>
<base_flame_r type="float">0.9</base_flame_r>
<deflection_coeff type="float">0</deflection_coeff>
<flame_color_high_b type="float">0.8</flame_color_high_b>
<flame_color_high_g type="float">0.85</flame_color_high_g>
<flame_color_high_r type="float">0.9</flame_color_high_r>
<flame_color_low_b type="float">0.07</flame_color_low_b>
<flame_color_low_g type="float">0.15</flame_color_low_g>
<flame_color_low_r type="float">0.35</flame_color_low_r>
<flame_radius_fraction type="float">0.8</flame_radius_fraction>
<noise_scale type="float">0.3</noise_scale>
<noise_strength type="float">0.2</noise_strength>
<thrust_collimation type="float">0.1</thrust_collimation>
<thrust_density type="float">0.7</thrust_density>
<use_noise type="int">1</use_noise>
<use_shocks type="int">1</use_shocks>
</parameters>
</PropertyList>
</syntaxhighlight>

There is also a detailed version (utilizing 3d noise and a higher sampling resolution) available. This has to be explicitly requested in a derived effect by overriding the default shader choice with the detailed version, i.e. bu inserting

<syntaxhighlight lang="xml">
<technique n="4">
<pass>
<program>
<fragment-shader n="0">Shaders/thrustflame-ALS-detailed.frag</fragment-shader>
</program>
</pass>
</technique>
</syntaxhighlight>

below the parameter section.

{{Note|The detailed shader uses four times as much performance at least - only use it if you really need it!}}

=== F-15 Afterburner example image ===
The F-15 afterburner flame shown below (at different ambient lighting based on time) uses the parameters above. The main parameters of importance, and therefore to tune, for an aircraft jet engine are the colors, the two densities, the flame radius fraction. The base density is at the start of the flame and this. The F-15 overlays a billboarded image to achieve the diamonds that are interleaved with the ALS drawn flame.

[[File:F-15 afterburner using ALS Thrust Effect.jpg|700px|This shows the F-15 afterburner at different ambient light.]]

The meaning of the parameters are as follows:

<syntaxhighlight lang="xml">
<use_shocks type="int">1</use_shocks>
<use_noise type="int">1</use_noise>
</syntaxhighlight>

<syntaxhighlight lang="xml" inline><use_shocks></syntaxhighlight> and <syntaxhighlight lang="xml" inline><use_noise></syntaxhighlight> are the parameters that control the random noise and the shock diamonds. Both are modestly computationally expensive, i.e. if these effects are not required it is better to switch them off by setting these values to zero.

<syntaxhighlight lang="xml">
<flame_color_low_r type="float">0.95</flame_color_low_r>
<flame_color_high_r type="float">1.0</flame_color_high_r>
<base_flame_r type="float">0.8</base_flame_r>
</syntaxhighlight>

(same for the (g,b) channels) set the color. base_flame refers to the part of the flame which is directly attached to the thruster and usually brightest. flame_color_high refers to the high density part of the flame, flame_color_low refers to the low density parts of the flame. (rgb) values always need to be [0:1]

<syntaxhighlight lang="xml">
<thrust_density type="float">1.0</thrust_density>
<base_flame_density type="float">0.1</base_flame_density>
</syntaxhighlight>

determine the overall emitter density in the flame and in the base directly at the thruster respectively. There's no formal upper limit for the parameters, but a flame with density 1 already appears fairly opaque.

<syntaxhighlight lang="xml">
<flame_radius_fraction type="float">0.8</flame_radius_fraction>
</syntaxhighlight>

governs how much of the bounding box the flame radius at the exhaust nozzle fills. If the flame needs to expand (as for the plume of a thruster operating in vacuum) or needs to bend (as for a flame deflected by the airstream) this parameter needs to be small, if the flame is essentially cylindrical the paramater can be chosen close to 1 to minimize clipping errors. Note that this determines the size of the flame relative to the bounding box - the overall size of the flame should be adjusted by using a scale animation on the bounding box

<syntaxhighlight lang="xml">
<noise_strength type="float">0.2</noise_strength>
<noise_scale type="float">0.3</noise_scale>
</syntaxhighlight>

determined how turbulent the flame looks. noise_strength [0:1] determines how prominently the noise influences the flame and noise_scale (in meters relative to the original bounding box) determines how large the visible patches of turbulence are (given that the original bounding box is not larger than 5 m in the longest direction, the parameter should probably kept between 0.1 and 5).

<syntaxhighlight lang="xml">
<shock_frequency>1.0</shock_frequency>
</syntaxhighlight>

influences at what distance shock diamonds appear in the flame. Useful values are perhaps between 0.2 and 5.

<syntaxhighlight lang="xml">
<thrust_collimation type="float">0.1</thrust_collimation>
</syntaxhighlight>

should take a value of between 0 and 1 and determines how collimated the flame is. For values > 0, the flame is widened - note that this requires a sufficiently small flame radius fraction to avoid clipping errors. For widened flames, the density is automatically lowered and shock diamonds are removed.

<syntaxhighlight lang="xml">
<deflection_coeff type="float">0.</deflection_coeff>
</syntaxhighlight>

should be somewhere between 0 and 0.06 and gives a lateral deflection (such as by an airstream) to the flame. Note that this re-positions the origin of the flame in the bounding box to better utilize the bounding box volume, i.e. if you need a dynamical deflection, you also need a translate animation for the bounding box.

Any of those parameters can be adjusted runtime by replacing the value with <syntaxhighlight lang="xml" inline><use>/my-property</use></syntaxhighlight>. Dependent on how <code>/my-property</code> is created it might be tied though (in particular JSBSim-computed properties are) in which case it is not picked up by the effect framework - you need to copy it via property rule to an untied property then. This allows to render dynamical changes of the flame.

For instance the [[SpaceShuttle - Project Overview|Space Shuttle]] main engines use

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>

<PropertyList>
<name>ssme-flame</name>
<inherits-from>Effects/thrust-flame</inherits-from>
<parameters>
<flame_color_low_r>0.9</flame_color_low_r>
<flame_color_low_g>0.7</flame_color_low_g>
<flame_color_low_b>0.5</flame_color_low_b>
<flame_color_high_r>0.7</flame_color_high_r>
<flame_color_high_g>0.7</flame_color_high_g>
<flame_color_high_b>1.0</flame_color_high_b>
<base_flame_r type="float">0.8</base_flame_r>
<base_flame_g type="float">1.0</base_flame_g>
<base_flame_b type="float">1.0</base_flame_b>
<use_shocks type="int">1</use_shocks>
<use_noise type="int">1</use_noise>
<thrust_collimation><use>/sim/systems/various/ssme-flame-collimation</use></thrust_collimation>
<thrust_density><use>/sim/systems/various/ssme-flame-density</use></thrust_density>
<base_flame_density type="float">1.0</base_flame_density>
<shock_frequency>1.0</shock_frequency>
<noise_strength>0.3</noise_strength>
<noise_scale>0.1</noise_scale>
</parameters>
</PropertyList>
</syntaxhighlight>

to simulate the change of flame geometry in the thin upper atmosphere during ascent:

[[File:Shuttle flame05.jpg|400px|Space Shuttle main engine flames during early ascent]]
[[File:Shuttle flame06.jpg|400px|Space Shuttle main engine flames during late ascent]]

Using the deflection parameter, the curved SRB separation motor flames are rendered using

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>
<name>SRBsep-flame</name>
<inherits-from>Effects/thrust-flame</inherits-from>
<parameters>
<flame_color_low_r type="float">0.95</flame_color_low_r>
<flame_color_low_g type="float">0.55</flame_color_low_g>
<flame_color_low_b type="float">0.1</flame_color_low_b>
<flame_color_high_r type="float">1.0</flame_color_high_r>
<flame_color_high_g type="float">1.0</flame_color_high_g>
<flame_color_high_b type="float">1.0</flame_color_high_b>
<use_shocks type="int">0</use_shocks>
<use_noise type="int">1</use_noise>
<thrust_collimation type="float">0.4</thrust_collimation>
<thrust_density type="float">1.0</thrust_density>
<base_flame_density type="float">0.0</base_flame_density>
<noise_strength type="float">0.7</noise_strength>
<noise_scale type="float">0.4</noise_scale>
<deflection_coeff type="float">-0.06</deflection_coeff>
<flame_radius_fraction type="float">0.1</flame_radius_fraction>
</parameters>
</PropertyList>
</syntaxhighlight>

[[File:Flame_sep.jpg|700px|Space Shuttle SRB separation motor flames]]

Application of the effect is not limited to flames, it can also do heat blur (think a very transparent, high-noise dark emitter distribution) or vapour trails and other smoke.

By itself, the effect does however not compute ambient and diffuse light channels, i.e. for non-emissive distributions lighting is the responsibility of the user. One quick way of obtaining a correct fading of color with light in the scene is to create an untied property based on

<code>/rendering/scene/diffuse/red</code>

and used this to scale all color values.

{{note|Do not use the full (rgb) information in the property tree for ALS, it will produce pronounced color mismatches with the rest of the scene as ALS determines light inside the shader and never uses the properties.}}

== Chute animation effect ==

The chute animation effect is designed to provide a natural appearance of the deformation and the fluttering motion of a piece of cloth under changing stress.

[[File:Chute seq01.jpg|400px|Drag chute separation sequence 1]] [[File:Chute seq03.jpg|400px|Drag chute separation sequence 2]]

=== Coordinate system ===

The shader assumes that the 3d mesh of the chute is oriented in a particular coordinate system. The z-axis (upward) should extend from the zero point where the various ropes come together to the canopy above through the center of the model. The canopy of the chute should therefore roughly be in the xy plane.

To position the chute correctly with the aircraft, you then need to use appropriate offsets and rotations when loading.

=== Effect definition for model ===

To define the effect to apply to the model (as referenced in the ''effect'' section in the model XML) you need to create ''mychute.eff'' as below. The ''.eff'' file defines the parameters that are passed into the shader and it is these that control the behavior.

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<name>mychute</name>
<inherits-from>Effects/chute</inherits-from>
<parameters>
<chute_force><use>Aircraft/MyAircraft/myforce</use></chute_force>
<chute_projection_z>0.0</chute_projection_z>
<chute_fold>0.0</chute_fold>
<chute_bend>0.0</chute_bend>
</parameters>
</PropertyList>
</syntaxhighlight>

The meaning of these parameters is as follows:

<syntaxhighlight lang="xml">
<chute_projection_z>0.0</chute_projection_z>
</syntaxhighlight>

This is the distance of the branching point of the various lines leading to the canopy (at model coordinate zero) to the edge of the canopy. All transformations affecting the shape of the canopy (in particular the collapse of the canopy if the force is gone) will be applied with respect to this reference plane.

<syntaxhighlight lang="xml">
<chute_force><use>Aircraft/MyAircraft/myforce</use></chute_force>
</syntaxhighlight>

This is a normalized force applied to the canopy. The chute should be modeled with a deformation corresponding to a force parameter of 1 - any higher value will narrow the chute's radius, deepen the chute's deformation along the z-axis and increase the motion, any lower value will widen chute radius (compare screenshots above) and lessen its depth and slow down motion. The normal parameter range should be from [0:2], any higher or lower may look odd.

<syntaxhighlight lang="xml">
<chute_fold>0.0</chute_fold>
<chute_bend>0.0</chute_bend>
</syntaxhighlight>

These are deformation modes used to animate a chute after jettison when it is no longer pulled into shape and can flutter through the air. The first one [0:1] is a general collapse into the projection plane with random deformations around, the second one [-1:1] is a gross bending mode of the projection plane itself. Before jettison, these parameters should default to 0.

=== Jettison animation ===

A complete animated jettison sequence is quite complex and would usually require a Nasal sequence taking the chute through a deceleration trajectory (utilizing translation and rotation animations), bending ad folding oscillations and finally some unfolding as it sinks through the air. The Space Shuttle chute uses the following control loop for 10 seconds of jettison dynamics:

<syntaxhighlight lang="nasal">
var drag_chute_jettison_animation = func (time) {

var dt = getprop("/sim/time/delta-sec");
time = time + dt;

# horizontal motion

var x = 0.0;

if (time > 2.0)
{x = -16.0 + 20.0 * time;}
else
{x = 2.0 * time + 5.0 * time * time;}

setprop("/controls/shuttle/drag-chute-dist",x);

# vertical motion

var y = 0.0;
if (time > 5.0)
{
y = -2.5 + 0.6 * (time-5.0) * (time-5.0);
}
else
{
y = -0.2 * time;
}
if (y > 12.5) {y=12.5;}

setprop("/controls/shuttle/drag-chute-down",y);

# fold

var f = 0.5 * time;
if (f> 1.0) {f = 1.0;}
if (time > 9.5)
{f = 0.25 + 1.5 + (time-9.5);}
if (time > 6.0)
{
f = f -0.3* (time-7.0);
if (f<0.1) {f=0.1;}
}
setprop("/controls/shuttle/drag-chute-fold", f);

# rotate

var r = (time - 2.0) * 18.0;
if (r>90.0) {r=90.0;}
if (r<0.0) {r=0.0;}
setprop("/controls/shuttle/drag-chute-slant", r);

# bend

var b = 0;
if (time > 7.5)
{b = 0;}
else if (time >6.0)
{b = 0.75 - 0.5 * (time - 6.0);}
else if (time > 4.5)
{b = (time - 4.5) * 0.5;}
else {b=0;}

setprop("/controls/shuttle/drag-chute-bend", b);

if (time > 10.0)
{
print("Exiting...");
settimer (func { setprop("/controls/shuttle/drag-chute-deploy-timer", 0); }, 0.5);
return;
}

setprop("/test/timer", time);

settimer( func{ drag_chute_jettison_animation (time); }, 0);

}
</syntaxhighlight>

== ALS glass effect ==

As of FlightGear version 3.5, ALS supports a glass effect with dynamic response to the environment which can render, for instance, the splashes of raindrops on the canopy, frost or fogging.

[[File:Glass01.jpg|400px|Frost effect]]
[[File:Glass07.jpg|400px|Raindrop splashes]]

The base effect properties are controlled via inheritance and the environment response run-time via properties residing in <b>/environment/aircraft-effects</b>. Derived effects should inherit from <b>Effects/glass</b>. Any surface using the glass effect will automatically register itself as transparent for use in [[Project Rembrandt| Rembrandt]].

The glass effect is primarily intended for interior views. In particular, no external fog or haze is rendered for the glass, i.e. if the effect is used in an outside view, it is the responsibility of the aircraft modeler to take care (e.g. with LOD settings or range animations) that no problems in bad visibility occur.

=== Why a separate effect for glass seen from inside? ===

Basically because the two situations are rather different. Slight dirt on the glass against the background of the sky from inside is rather prominent, against the background of the cockpit seen from outside it is not. Visuals from inside are dominated by Mie forward scattering of light, leading to a bright glare effect when looking at dirt, frost, fog or scratches close to the sun. From outside, reflected light rather than transmitted light is dominant. The reflection of any external object on the outside of the glass changes as the aircraft moves, this is not the case for the reflection of the cockpit in the glass seen from the inside.

The viewing situation is also different. From the inside, we usually do not focus the eyes on the plane of the glass but look through it, from the outside the focus of the eyes is often close to the glass surface. For something half a meter before the eye, we also need to apply a lot more resolution and details than for an object typically seen from 10+ meters from the outside.

Add to this that atmospheric fog is never relevant for glass seen from inside but for glass seen from outside, and it suddenly makes sense to use a different effect.

The recommended effect for glass surfaces seen from outside is model-combined-transparent.eff.

=== Rain ===
Rain splashes will render automatically when the weather system reports rain via environment/rain-norm. In addition, the user can set rain splashes to render via <code>environment/aircraft-effects/ground-splash-norm</code> (this is intended to allow splashes to be rendered e.g., for water landings of aircraft equipped with floats).

By default, the rain splashes impact from above (more precisely the +z direction in model coordinates). This may be inadequate if the aircraft is moving. However, the shader can not know what the airstream at the glass will be, so the impact vector of rain splashes has to be modeled aircraft-side and set via <code>environment/aircraft-effects/splash-vector-x</code> (<code>splash-vector-y</code>, <code>splash-vector-z</code>). These are likewise in model coordinates.

As long as the length of the splash vector is less than 1, just the impact angle will change, as the length of the vector increases to 2, droplets will also be visibly moving. This allows fine control of the visuals dependent on any number of factors desired. A simple Nasal snipped varying the splash vector with airspeed for the F-16 is given below (but ''do not mindlessly copy and expect to work for any aircraft — it won't!''). This example is for normals pointing outwards, if the normals are pointing inwards the vector needs to be inverted.

<syntaxhighlight lang="nasal">
var splash_vec_loop = func(){
var airspeed = getprop("/velocities/airspeed-kt");

# f16
var airspeed_max = 120;

if (airspeed > airspeed_max) {
airspeed = airspeed_max;
}

airspeed = math.sqrt(airspeed / airspeed_max);

var splash_x = -0.1 - 2 * airspeed;
var splash_y = 0.0;
var splash_z = 1.0 - 1.35 * airspeed;

setprop("/environment/aircraft-effects/splash-vector-x", splash_x);
setprop("/environment/aircraft-effects/splash-vector-y", splash_y);
setprop("/environment/aircraft-effects/splash-vector-z", splash_z);

settimer(func(){
splash_vec_loop();
}, 1);
}
</syntaxhighlight>

Note the timing constant of the loop — running the update per-frame leads to a spurious movement of the coordinate system in which rain is rendered and spoils the effect.

Another method when using JSBSIM would be to use a combination of FCS Functions and Filters.

<syntaxhighlight lang="xml">
<system name="c172p-glass-effects">
<channel name="rain">
<fcs_function name="glass-effects/splashx">
<function>
<difference>
<value>-0.1</value>
<product>
<value>2.0</value>
<sqrt>
<quotient>
<min>
<property>/velocities/airspeed-kt</property>
<value>40</value>
</min>
<value>40</value>
</quotient>
</sqrt>
</product>
</difference>
</function>
</fcs_function>
<fcs_function name="glass-effects/splashz">
<function>
<difference>
<value>1.0</value>
<product>
<value>1.35</value>
<sqrt>
<quotient>
<min>
<property>/velocities/airspeed-kt</property>
<value>40</value>
</min>
<value>40</value>
</quotient>
</sqrt>
</product>
</difference>
</function>
</fcs_function>
</channel>
</system>
</syntaxhighlight>

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<filter>
<name>splashX</name>
<type>gain</type>
<input>
<property>/fdm/jsbsim/glass-effects/splashx</property>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-x</property>
</output>
</filter>
<filter>
<name>splashY</name>
<type>gain</type>
<input>
<value>0.0</value>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-y</property>
</output>
</filter>
<filter>
<name>splashZ</name>
<type>gain</type>
<input>
<property>/fdm/jsbsim/glass-effects/splashz</property>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-z</property>
</output>
</filter>
</PropertyList>
</syntaxhighlight>

You could reduce the above method and eliminate the "filters" by doing the following.
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<system name="c172p-glass-effects">
<channel name="rain">
<fcs_function name="glass-effects/airspeed-clamped-sqrt">
<function>
<sqrt>
<quotient>
<min>
<property>/velocities/airspeed-kt</property>
<value>40</value>
</min>
<value>40</value>
</quotient>
</sqrt>
</function>
</fcs_function>
<fcs_function name="glass-effects/splashx">
<function>
<difference>
<value>-0.1</value>
<product>
<value>2.0</value>
<property>/fdm/jsbsim/glass-effects/airspeed-clamped-sqrt</property>
</product>
</difference>
</function>
<output>/environment/aircraft-effects/splash-vector-x</output>
</fcs_function>
<fcs_function name="glass-effects/splashy">
<function>
<value>0.0</value>
</function>
<output>/environment/aircraft-effects/splash-vector-y</output>
</fcs_function>
<fcs_function name="glass-effects/splashz">
<function>
<difference>
<value>1.0</value>
<product>
<value>1.35</value>
<property>/fdm/jsbsim/glass-effects/airspeed-clamped-sqrt</property>
</product>
</difference>
</function>
<output>/environment/aircraft-effects/splash-vector-z</output>
</fcs_function>
</channel>
</system>
</syntaxhighlight>

Yet another method (currently used in the c172p) limits movement to a range of table entries. This gives the developer the ability to control the behavior even more.
<syntaxhighlight lang="xml">
<PropertyList>
<filter>
<name>splash-xa</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/velocities/airspeed-kt</property>
<entry><ind> 0 </ind><dep> -0.33 </dep></entry>
<entry><ind> 4 </ind><dep> -0.33 </dep></entry>
<entry><ind> 5 </ind><dep> -1.7 </dep></entry>
<entry><ind> 50 </ind><dep> -2.1 </dep></entry>
</table>
</expression>
</input>
<output>
<property>/environment/aircraft-effects/splash-xa</property>
</output>
</filter>
<filter>
<name>splash-za</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/velocities/airspeed-kt</property>
<entry><ind> 0 </ind><dep> 0.82 </dep></entry>
<entry><ind> 4 </ind><dep> 0.82 </dep></entry>
<entry><ind> 5 </ind><dep> -0.17 </dep></entry>
<entry><ind> 50 </ind><dep> -0.35 </dep></entry>
</table>
</expression>
</input>
<output>
<property>/environment/aircraft-effects/splash-za</property>
</output>
</filter>
<filter>
<name>splash-xr</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/engines/active-engine/rpm</property>
<entry><ind> 0 </ind><dep> -0.33 </dep></entry>
<entry><ind> 600 </ind><dep> -0.33 </dep></entry>
<entry><ind> 601 </ind><dep> -1.3 </dep></entry>
<entry><ind> 1500 </ind><dep> -1.9 </dep></entry>
</table>
</expression>
</input>
<output>
<property>/environment/aircraft-effects/splash-xr</property>
</output>
</filter>
<filter>
<name>splash-zr</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/engines/active-engine/rpm</property>
<entry><ind> 0 </ind><dep> 0.82 </dep></entry>
<entry><ind> 600 </ind><dep> 0.82 </dep></entry>
<entry><ind> 601 </ind><dep> 0.127 </dep></entry>
<entry><ind> 1500 </ind><dep> -0.29 </dep></entry>
</table>0
</expression>
</input>
<output>
<property>/environment/aircraft-effects/splash-zr</property>
</output>
</filter>
<filter>
<name>splash-x</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<condition>
<greater-than-equals>
<property>/velocities/airspeed-kt</property>
<value>5</value>
</greater-than-equals>
</condition>
<property>/environment/aircraft-effects/splash-xa</property>
</input>
<input>
<condition>
<less-than>
<property>/velocities/airspeed-kt</property>
<value>5</value>
</less-than>
</condition>
<property>/environment/aircraft-effects/splash-xr</property>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-x</property>
</output>
</filter>
<filter>
<name>splash-y</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<value>0.0</value>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-y</property>
</output>
</filter>
<filter>
<name>splash-z</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<condition>
<greater-than-equals>
<property>/velocities/airspeed-kt</property>
<value>5</value>
</greater-than-equals>
</condition>
<property>/environment/aircraft-effects/splash-za</property>
</input>
<input>
<condition>
<less-than>
<property>/velocities/airspeed-kt</property>
<value>5</value>
</less-than>
</condition>
<property>/environment/aircraft-effects/splash-zr</property>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-z</property>
</output>
</filter>
</PropertyList>
</syntaxhighlight>

=== Frost and fogging ===

Frost on the canopy is rendered when environment/aircraft-effects/frost-level is set in the range from 0 to 1. Again, it is up to the aircraft developer to decide at what exterior conditions frosting should happen and whether the aircraft is equipped with heating to remove the frost again.

Fogging is controlled by environment/aircraft-effects/fog-level in the range 0 to 1. Unless a mask is used, fogging is homogeneous across the whole surface (it is really intended to be used with a mask).

=== Tint ===

Tinted glass can be easily created by changing

<syntaxhighlight lang="xml">
<glass-tint type="vec4d" n="0"> 1.0 1.0 1.0 1.0</glass-tint>
</syntaxhighlight>

to any value desired. This will affect all effects assumed outside of the glass layer (frost and rain splashes) but not fogging inside the glass. Use primarily for development and quick tests, don't misuse the alpha value available here, it has odd side effects.

=== Functional masks ===

If the glass surface is uv-mapped and textured, it is possible to switch on a mask functionality in the inheritance via

<syntaxhighlight lang="xml">
<texture n="2">
<image>my_mask.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>clamp</wrap-s>
<wrap-t>clamp</wrap-t>
<internal-format>normalized</internal-format>
</texture>
<use-mask type="int">1</use-mask>
<overlay-color type="vec3d" n="0">1.0 1.0 1.0</overlay-color>
</syntaxhighlight>

The red channel in my_mask.png controls the strength of fogging, full red corresponds to maximal fogging, no red to zero fogging. This allows to selectively model the position of heaters in the cockpit. Use <b>/environment/aircraft-effects/fog-level</b> to adjust the actual amount of fog runtime.

The green channel of my_mask.png is the amount of reduction of rain in an area. This is intended for airplanes equipped with windshield wipers to partially clear the wiped area of the rain. Whether the windshield wiper is actually on or not is controlled runtime via <b>/environent/aircraft-effects/use-wipers</b> (1 sets wipers to on).

The blue channel of my_mask.png is reserved for an overlay pattern which will be drawn in an optionally specified <overlay-color> vector (white in the example xml above) - the primary function is to render damage on the glass, but with a different color, also dirt or an alternative more finely controlled frost pattern can be used. The strength of the pattern can be adjusted runtime via <b>/environment/aircraft-effects/overlay-alpha</b>, allowing dynamical accumulation of dirt or sudden appearance of damage.

Examples for the result of a fog mask and a damage mask are shown below:

[[File:Glass12.jpg|400px|Crack pattern using a damage mask]]
[[File:Glass11.jpg|400px|Partial fogging using a mask texture]]

<b>Note that by default all the runtime switches for the mask are off / set to zero! Remember to to switch them on when testing the effect!</b>

=== Mie scattering ===

Most glass effects show prominent Mie forward scattering as in reality, i.e. frost patterns or fogging will appear much more prominent when looking almost towards the sun than under any other angle. While the frost pattern is normally not very prominent and one is able to look through unhindered, this changes substantially when looking into the sun, at which point it almost obscures the view.

[[File:Glass08.jpg|400px|Mie scattering of low light on frost]]
[[File:Glass13.jpg|400px|Morning sun Mie scattering on fog]]

For frost and fog, the strength of the effect is set automatically, but for the damage/dirt layer it is under user control at effect design time. Changing the parameter

<syntaxhighlight lang="xml">
<overlay-glare type="float">0.5</overlay-glare>
</syntaxhighlight>

from its default value allows to adjust the strength of the glare when looking through the overlay layer close to the sun.

=== Internal cockpit reflection ===

There is support for a reflection of the cockpit interior.

[[File:Reflect.jpg|640px|Internal glass cube map reflection]]

This needs to be provided as a cubemap specific for the airplane and switched on via the flag <use-reflection> set to 1. The relative strength of the reflection can be optionally via <reflection-strength>. The strength of the reflection in the cockpit is dynamically adjusted for a number of factors, among them balance of direct to indirect light, the approximate amount of light falling on the surface seen in the reflection and the amount of direct sunlight falling into the eye.

If the six cubemap faces are called my_cube_map_??.png, then using an effect file called c172p-reflect.eff the inheritance looks like this:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>

<PropertyList>
<name>c172-reflect</name>
<inherits-from>Effects/glass</inherits-from>
<parameters>
<texture n="3">
<type>cubemap</type>
<images>
<positive-x>my_cube_map_px.png</positive-x>
<negative-x>my_cube_map_nx.png</negative-x>
<positive-y>my_cube_map_py.png</positive-y>
<negative-y>my_cube_map_ny.png</negative-y>
<positive-z>my_cube_map_pz.png</positive-z>
<negative-z>my_cube_map_nz.png</negative-z>
</images>
</texture>
<use-reflection type="int">1</use-reflection>
<reflection-strength type="float">1.0</reflection-strength>
</parameters>
</PropertyList>
</syntaxhighlight>

The inheritance call includes all surface objects that use the effect.

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Aircraft/c172p/Models/Effects/c172p-reflect</inherits-from>
<object-name>glas</object-name>
<object-name>rightwindow</object-name>
<object-name>leftwindow</object-name>
</effect>
</syntaxhighlight>

See below (Interior shading), for details on cube_map creation and orientation.

=== Lightmaps for internal cockpit reflection ===

If the cockpit is illuminated at night, the reflection map will not show this change by default. However,the glass effect supports a lightmap for the reflection, which can be used in parallel with the lightmap for the panels to show the reflection of a lit panel at night.

Since the reflection map is a cube map, the lightmap for it has to be as well, the syntax is hence

<syntaxhighlight lang="xml">
<use-reflection-lightmap type="int">1</use-reflection-lightmap>
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Models/Effects/interior/reflection/light-px.png</positive-x>
<negative-x>Models/Effects/interior/reflection/light-nx.png</negative-x>
<positive-y>Models/Effects/interior/reflection/light-py.png</positive-y>
<negative-y>Models/Effects/interior/reflection/light-ny.png</negative-y>
<positive-z>Models/Effects/interior/reflection/light-pz.png</positive-z>
<negative-z>Models/Effects/interior/reflection/light-nz.png</negative-z>
</images>
</texture>
</syntaxhighlight>

The control parameters of the lightmap otherwise parallel those of the [[Model-combined_effect]] or the model interior effect described below, i.e. up to four channels can be independently specified on the lightmap.

=== Troubleshooting ===

By default, rain and frost are mapped to the shape of the canopy using coordinate systems that adapts to the splash vector and the canopy shape. This requires no particular action aircraft-side except to provide the bare geometry of a canopy/windshield, but may not be satisfactory in all instances - in particular for near vertical cockpit side windows the scheme does poorly.

There are two alternative coordinate maps available in this case, controlled by the parameter

<syntaxhighlight lang="xml">
<surface-mapping-scheme type="int">0</surface-mapping-scheme>
</syntaxhighlight>

If the parameter is changed to 1, the uv-mapping of the surface is used (it has to exist of course). For this to work properly, the uv-mapping needs to be sufficiently regular and roughly preserve the mapped area.

If the parameter is changed to 2, a local orthonormal system based on the normals of the surface is constructed. This no longer takes the splash vector consistently into account and works poorly for surfaces which are flat in the (xy)-plane, but gives decent result for side windows.

== The HUD effect ==

The HUD effect is a variant of the glass effect designed to render the visuals of a head-up display (HUD) closer to real life. This only works if the HUD is custom-created via [[Canvas]], not via the native FG HUD mechanism as the latter by-passes the effect framework.

The effect takes the same configuration options as the glass effect (i.e. it can render frost, damage, scratches, glare,...) but in addition it runs a blur over the HUD image and alters the color distribution of the projected symbols to de-saturate the bright parts in the center. The result looks less monochromatic and more like light projected onto a surface (left: bare canvas right: HUD effect)

[[File:HUD effect.jpg|800px|Comparison between a bare canvas HUD (left) and the ALS HUD shader run over it (right)]]

=== Usage ===

The effect is used from the model file by assigning it to the surface that also carries the canvas texture of the HUD via

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/hud</inherits-from>
<object-name>HUDImage</object-name>
</effect>
</syntaxhighlight>

This should usually work out of the box, but if the HUD brightness should be changeable or the glass properties adjusted, a derived effect needs to be created.

=== Parameters ===

In addition to the parameters supported by the glass shader (which, for instance in the case of rain splashes, may or may not be appropriate for a HUD, this is left at user's discretion), the HUD effect takes the following special parameters:

<syntaxhighlight lang="xml">
<brightness>1.0</brightness>
<sample-res>0.0006</sample-res>
<sample-far>2.5</sample-far>
</syntaxhighlight>

The first one is the relative brightness setting of the HUD (which should equal the alpha value assigned to the canvas image of the symbols). This parameter is used to de-saturate colors in the symbol centers.

Remaining two parameters represent the size and shape of the blur Kernel being used. The sample resolution (sample-res) determines the overall size of the blur region, the farthest sample (sample-far) how far out the tails of the blur region extend.

Note: The number of sampling steps is not computed adaptive to these parameters, if the steps get too coarse, then multiple image echoes instead of a proper blur will be generated - adjust these parameters with care (if at all).

== The ALS interior model effect ==

Since the interior of a cockpit is a large part of what a pilot gets to see in-flight, but this interior represents a rather special situation (light is reduced as it falls through windows, it may have artificial light, there is never any fog or haze,...) ALS offers a separate effect to specifically render the interior of a plane.

This effect also includes optional features which will be available at higher quality settings of the model shader.

=== Interior shadows and tinted glass effect ===

With FlightGear version 3.5 and above, ALS now supports interior shading; i.e. the sun shining through the windows and casting shadows on the panel.

[[File:interior01.jpg|640px|Interior shading effect]]

This effect is based on an opacity map - a cube map of textures which tells the renderer where the cockpit is transparent and where not. The opacity map has to be created beforehand, which allows to make it quite detailed. In this map, white stands for a completely transparent surface, black for an opaque surface, colors for tinted glass which will create a colored light spot in the cockpit, grey hues for partial shadowing allowing to paint dirt effects onto the windows, and caustics can be drawn using the alpha channel: (1-alpha) will be used as an enhancement of the light at a certain spot.

The effect is typically declared as derived by inheritance using an effect file such as c172-interior.eff which looks like this

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>

<PropertyList>
<name>c172-interior-glass</name>
<inherits-from>Effects/model-interior</inherits-from>
<parameters>
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Models/Effects/interior/clr_px.png</positive-x>
<negative-x>Models/Effects/interior/clr_nx.png</negative-x>
<positive-y>Models/Effects/interior/clr_py.png</positive-y>
<negative-y>Models/Effects/interior/clr_ny.png</negative-y>
<positive-z>Models/Effects/interior/clr_pz.png</positive-z>
<negative-z>Models/Effects/interior/clr_nz.png</negative-z>
</images>
</texture>
<opacity-cube-center type="vec3d" n="0"> 0.5 0.0 0.3</opacity-cube-center>
<opacity-cube-scale type="vec3d" n="0"> 1.5 0.5 0.7</opacity-cube-scale>
<opacity-cube-angle type="float">0.0</opacity-cube-angle>
</parameters>
</PropertyList>
</syntaxhighlight>

which is called by inheritance in the model.xml file.

Imagine the opacity map as a box surrounding the cockpit and trying to closely follow its contours. The origin in the box needs to be placed into the center of the cockpit, which is what <b><opacity-cube-center></b> does. Each of the three dimensions then needs to be stretched to roughly fit the layout of the canopy, this is done by <b><opacity-cube-scale></b>.

If opacity map center and scale are wrong, you will still see shadows, but they won't match the real cockpit layout (the lightspot of a window will be seen displaced and at a different size of the real window). Thus, carefully measuring the best box layout in a 3d tool is moderately important.

Aircraft-side the effect is called as

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Aircraft/c172p/Models/Effects/c172p-interior</inherits-from>
<object-name>Plane.010_0</object-name>
<object-name>Plane.010_1</object-name>
<object-name>PilotSeat</object-name>
<object-name>CopilotSeat</object-name>
<object-name>panel_1_1</object-name>
<object-name>InstrumentCover.001</object-name>
<object-name>doorint_right</object-name>
<object-name>doorint_left</object-name>
<object-name>doorhandleint_right</object-name>
<object-name>doorhandleint_left</object-name>
<object-name>Panel_0</object-name>
<object-name>Throttle</object-name>
<object-name>Mixture</object-name>
<object-name>Pedestal</object-name>
<object-name>TrimWheel</object-name>
<object-name>ParkingBrake</object-name>
<object-name>BackSeat</object-name>
<object-name>FuelSelectorFace</object-name>
</effect>
</syntaxhighlight>

Each object that you want the shadow effect to fall on must be included in the inheritance.

Unless you supply a path, the cube_.png's need to reside in the same directory as the model.xml where you added the <effect> tag pair that calls c172-interior.eff, not where you put the aircraft_interior.eff.

The orientation of the faces of each cube have to be adjusted based on the positive and negative axis of the model.

For example, using the c172p model as a reference.

The tail, right wing and top on the model are positive inside Blender. So the cube faces are laid out as follows.

Note: Depending on the image's orientation when photographed the rotation direction will vary. This is assuming the images are being taken from the center of the cockpit looking out. Using compass headings to describe how to rotate the images.

px (tail) rotate 90 deg from N or S to W

nx (nose) rotate 90 deg from N or S to E

py (starboard/right) from N do not rotate

ny (port/left) from N rotate 180 deg to S

pz (top) rotate 90 deg from N or S to W

nz (bottom) rotate 90 deg from N or S to W

[[File:C172p-cube.jpg|640px|Cube map layout of the c172p]]

With Blender, it's pretty easy to create the cubemap.

1. Add a camera where the cubemap will be. Set the FOV to 90 degrees.
2. Set the resolution to 1024x1024 (or any other square, power-of-two size).
3. Hide all lights and windows; disable ambient lighting (set it to black) and turn off ambient occlusion.
4. Set the world color to white.
5. Enable the compositor and add an invert node.
6. Render and save the six views as you would normally.
7. Add dirt, tinted glass color and caustics by hand

This process depends on the model setup but it should work for most aircraft with a few tweaks.

==== Cubemap Kit for Blender ====

[[File:Als-interior-shadow-blender-instructions.png|320px|How to make an interior cubemap with the cubemap kit]]

See [http://chateau-logic.com/content/flightgear-interior-shadow-cubemap-kit flightgear-interior-shadow-cubemap-kit] for a premade kit to create the cubemap and the .eff sample file to use it.

==== Important Notes ====

<b>Important note:</b> Currently (May 2015) the effect does not deal gracefully with child models included into the main model with offsets and/or rotations because these introduce a different coordinate system in which the shadow does not match. The general idea of a code solution is known, but not implemented. Right now this can only be addressed by explicitly positioning child models in the *.ac file and not using any offsets when including them.

=== ALS flashlight ===

This effect is meant to imitate a hand held flashlight for use in getting instruments in the cockpit turned on in dark conditions.
It is almost identical in nature to ALS searchlight only it is applied using interior-model.eff.
It has two user defined light color filters that can be applied and also a user defined light radius setting.

[[File:ALS flashlight.jpg|600px|ALS flashlight effect]]

To implement this effect use
<syntaxhighlight lang="xml"><inherits-from>Effects/model-interior</inherits-from></syntaxhighlight>
A full definition looks like this

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<name>c172-interior</name>
<inherits-from>Effects/model-interior</inherits-from>
<parameters>
<light-filter-one type="vec3d">0.5 0.5 0.5</light-filter-one>
<light-filter-two type="vec3d">0.9 0.2 0.2</light-filter-two>
<light-radius type="float">13</light-radius>
</parameters>
</PropertyList>
</syntaxhighlight>
In the example above light-filter-one is soft white light and light-filter-two is a soft red light.

After defining as above you can turn it on using the following property

/sim/rendering/als-secondary-lights/use-flashlight = 1 is light-filter-one

/sim/rendering/als-secondary-lights/use-flashlight = 2 is light-filter-two

'''Special note:'''
The flashlight effect inherits model-interior, model-interior.eff is setup around the opacity cube map, it won't allow you to go without one, and in the event you try, you get an environment reflection cube map as default which happens to have green grass on it and may cast a greenish hue over applied objects.
A workaround is to create a pseudo cubemap by creating a white.png 64x64 square, and creating the following structure to represent a transparent cubemap.

<syntaxhighlight lang="xml">
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Aircraft/c172p/Models/Effects/interior/white.png</positive-x>
<negative-x>Aircraft/c172p/Models/Effects/interior/white.png</negative-x>
<positive-y>Aircraft/c172p/Models/Effects/interior/white.png</positive-y>
<negative-y>Aircraft/c172p/Models/Effects/interior/white.png</negative-y>
<positive-z>Aircraft/c172p/Models/Effects/interior/white.png</positive-z>
<negative-z>Aircraft/c172p/Models/Effects/interior/white.png</negative-z>
</images>
</texture>
</syntaxhighlight>

=== Implicit lightmap ===

At lowest quality level, the effect supports an implicit lightmap, i.e. a color range of the basic texture can be selected and declared to act as a lightmap. This is specifically useful to render panel backlighting as in the example below:

[[File:Ilightmap.jpg|600px|An implicit lightmap used to simulate a backlit panel]]

The effect is off by default and switched on by setting

<syntaxhighlight lang="xml">
<implicit-lightmap-enabled type="int">1</implicit-lightmap-enabled>
</syntaxhighlight>

The following parameters are available:

<syntaxhighlight lang="xml">
<implicit-lightmap-tag-color type="vec3d">1.0 1.0 1.0</implicit-lightmap-tag-color>
</syntaxhighlight>

This sets the base color to be tagged, i.e. if the panel labels to be illuminated at night are white, the color needs to be set to white.

<syntaxhighlight lang="xml">
<implicit-lightmap-threshold-low type="float">0.5</implicit-lightmap-threshold-low>
<implicit-lightmap-threshold-high type="float">1.5</implicit-lightmap-threshold-high>
</syntaxhighlight>

The thresholds determine how similar a color may be to the base color in order to be still illuminated. The measure is the Euklidean distance of the color vectors. The lower thresholds determines when illumination will start to fade, the higher threshold at what distance in color space illumination will no longer take place. The thresholds have to be adapted to the specific situation - the technique works best for high-contrast panels (white labels on black background) and may not work at all for low contrast panels.

<syntaxhighlight lang="xml">
<implicit-lightmap-emit-color type="vec3d">1.0 1.0 1.0</implicit-lightmap-emit-color>
</syntaxhighlight>

The emit color specifies at which color the pixel will show if it is tagged (see above) and the implicit lightmap is on (see below) - set this to the color of the backlight.

<syntaxhighlight lang="xml">
<implicit-lightmap-intensity type="float">0.0</implicit-lightmap-intensity>
</syntaxhighlight>

Finally, the intensity determines how brightly the illuminated pixel will shine.

Ambiance lighting can be simulated with the following tags.

<syntaxhighlight lang="xml">
<residual-ambience-r type="float"><use>/fdm/jsbsim/systems/light/cockpit-ambience-r</use></residual-ambience-r>
<residual-ambience-g type="float"><use>/fdm/jsbsim/systems/light/cockpit-ambience-g</use></residual-ambience-g>
<residual-ambience-b type="float"><use>/fdm/jsbsim/systems/light/cockpit-ambience-b</use></residual-ambience-b>
</syntaxhighlight>

In the above example note the use of the "use" tag.

<syntaxhighlight lang="xml">
<use>/fdm/jsbsim/systems/light/cockpit-ambience-r</use>
</syntaxhighlight>

This can be any defined property or static value.

'''Special note:'''
The implicit lightmap inherits model-interior, model-interior.eff is setup around the opacity cube map, it won't allow you to go without one, and in the event you try, you get an environment reflection cube map as default which happens to have green grass on it and may cast a greenish hue over applied objects.
A workaround is to create a pseudo cubemap by creating a white.png 64x64 square, and creating the following structure to represent a transparent cubemap.

<syntaxhighlight lang="xml">
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Aircraft/c172p/Models/Effects/interior/white.png</positive-x>
<negative-x>Aircraft/c172p/Models/Effects/interior/white.png</negative-x>
<positive-y>Aircraft/c172p/Models/Effects/interior/white.png</positive-y>
<negative-y>Aircraft/c172p/Models/Effects/interior/white.png</negative-y>
<positive-z>Aircraft/c172p/Models/Effects/interior/white.png</positive-z>
<negative-z>Aircraft/c172p/Models/Effects/interior/white.png</negative-z>
</images>
</texture>
</syntaxhighlight>

=== Irradiance maps ===

<b>Note:</b> This effect requires higher than minimum model shader quality setting.

In the simplest rendering schemes, diffuse and specular light are assumed to be highly directional (i.e. it illuminates lit surfaces only) while ambient light is taken to be omnidirectional.

In reality, that is hardly ever true. In a typical outside location, ambient light is mainly coming from the sky above (which is why the ground underneath a car is dark even in the absence of directional light when the sky is overcast and the sun is not visible). In an enclosed space (like a room, or an aircraft cockpit), ambient light has to fall through the windows, i.e. is mainly not coming above but falling in horizontally.

The directional dependence is not very strong though, yet it leaves measurable effects. In rendering, this can be accounted for by irradiance maps. In the following, the interior of the C-172p is rendered in the first case using omnidirectional ambient light, in the second case using an irradiance map giving the ambient light the directionality of the cabin windows, i.e. the light falls in predominantly horizontally (in addition, a grain map is superimposed to provide structure). Note how the spatial structure of the roof, looking bland when rendered in omnidirectional light is brought out by the irradiance map.

[[File:Als-interior-irradiance01.jpg|400px|C-172p cabin interior rendered without irradiance and grain map]]
[[File:Als-interior-irradiance02.jpg|400px|C-172p cabin interior rendered with irradiance and grain map]]

Irradiance mapping is configured by the following parameters:

<syntaxhighlight lang="xml">
<irradiance-map-type type="int">2</irradiance-map-type>
<irradiance-map-strength type="float">0.5</irradiance-map-strength>
</syntaxhighlight>

There are several pre-configured irradiance map functions which can be chosen by map type.

0: (default) omndirectional light
1: light predominantly coming from above (most appropriate for fighter cockpits)
2: light predominantly coming from the horizon (most appropriate for GA aircraft)

The strength of the irradiance map regulates how pronounced the asymmetry of the map will be. A strength of zero always makes the light omnidirectional, whereas a strength of 1 implies that no light is coming from any direction 90 degree to the main direction (i.e. for the option 2, a strength of 1.0 means that no ambient light will fall in from above or below and that hence horizontal surfaces will appear pitch black unless direct light falls on them)

'''Special note:'''
The irradiance map inherits model-interior, model-interior.eff is setup around the opacity cube map, it won't allow you to go without one, and in the event you try, you get an environment reflection cube map as default which happens to have green grass on it and may cast a greenish hue over applied objects.
A workaround is to create a pseudo cubemap by creating a white.png 64x64 square, and creating the following structure to represent a transparent cubemap.

<syntaxhighlight lang="xml">
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Aircraft/c172p/Models/Effects/interior/white.png</positive-x>
<negative-x>Aircraft/c172p/Models/Effects/interior/white.png</negative-x>
<positive-y>Aircraft/c172p/Models/Effects/interior/white.png</positive-y>
<negative-y>Aircraft/c172p/Models/Effects/interior/white.png</negative-y>
<positive-z>Aircraft/c172p/Models/Effects/interior/white.png</positive-z>
<negative-z>Aircraft/c172p/Models/Effects/interior/white.png</negative-z>
</images>
</texture>
</syntaxhighlight>.

=== Explicit lightmap ===

<b>Note:</b> This effect requires higher than minimum model shader quality setting.

In addition to the implicit lightmap, it is also possible to explicitly specify a lightmap. The syntax for this exactly parallels the syntax of the [[Model-combined_effect]] which supplies lightmaps for the exterior.

For example

<syntaxhighlight lang="xml">
<texture n="3">
<image>Aircraft/MyAircraft/Effects/my_lightmap.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>clamp</wrap-s>
<wrap-t>clamp</wrap-t>
<internal-format>normalized</internal-format>
</texture>
<lightmap-enabled type="int">1</lightmap-enabled>
<lightmap-multi type="int">0</lightmap-multi>
<lightmap-factor type="float" n="0">1.0</lightmap-factor>
<lightmap-color type="vec3d" n="0"> 1.0 1.0 1.0 </lightmap-color>
</syntaxhighlight>

sets up a single channel lightmap in which pixel color times the lightmap color provides the illumination. Using the multi-channel function, up to four different maps can be specified in which the (rgba) values of a pixel encode where the light falls and the associated lightmap color what color the illumination takes. Each of these maps can be switched on and off or dimmed in intensity independently.

=== Grain map ===

<b>Note:</b> This effect requires higher than minimum model shader quality setting.

The grain map sets a repeating hires overlay texture which can supply a very credible illusion of structure to a surface for cheap. The syntax exactly parallels that of the [[Model-combined_effect]] ALS grain feature described above.

For instance, the following

<syntaxhighlight lang="xml">
<texture n="7">
<image>Aircraft/Effects/MyGrainmap.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>repeat</wrap-s>
<wrap-t>repeat</wrap-t>
<internal-format>normalized</internal-format>
</texture>
<grain-texture-enabled type="int">1</grain-texture-enabled>
<grain-magnification type="float">10</grain-magnification>
</syntaxhighlight>

sets up a grain overlay with a 10-time higher resolution over the base texture layer.

== ALS procedural lights ==

The ALS framework supports procedurally generated lights (for instance aircraft position lights, strobe lights,... ) for aircraft and models. Note that the effect produces the visuals of the lights themselves, but they do not illuminate their surroundings.

=== Why procedural lights? ===

Traditionally aircraft position lights have been implemented as billboarded emissive textures. This technique is limited in scope, as it has difficulty producing a directional light or changes in the light appearance (for instance glare) with changed scene lighting. The ALS procedural lights are designed to give visuals consistent with the auto-generated scene lights (runway lighting, street lights) and support configurable directionality, glare and even the illumination of fog by the lights.

=== Basic implementation ===

The base of the light is a texture quad which has Effects/procedural-light.eff assigned. Start from including the template provided into your model as

<syntaxhighlight lang="xml">
<model>
<path>/Models/Effects/procedural_light.xml</path>
<offsets>
<x-m> 0 </x-m>
<y-m> 0 </y-m>
<z-m> 2 </z-m>
</offsets>
</model>
</syntaxhighlight>

and configure from there according to your own needs.

<b>Do not billboard the light via animation!</b> The GLSL code will take care of the billboarding. Use a scale animation to change the size of the light, do not change the quad (the *.ac) itself in size, the shader code requires its geometry to be fixed.

The lights are currently not supported in the default or Rembrandt renderer and will simply be invisible in these frameworks.

=== Configuring the light ===

Make your own derived effect inheriting from Effects/procedural-light.eff and assign it in the xml wrapper of the light.

* the base light color can be set via

<syntaxhighlight lang="xml">
<light_color_base_r type="float">1.0</light_color_base_r>
<light_color_base_g type="float">0.0</light_color_base_g>
<light_color_base_b type="float">0.0</light_color_base_b>
</syntaxhighlight>

These take the normal set of values ranging from 0 to 1.

* how the light appears at full intensity in the center can be set via

<syntaxhighlight lang="xml">
<light_color_center_r type="float">1.0</light_color_center_r>
<light_color_center_g type="float">1.0</light_color_center_g>
<light_color_center_b type="float">1.0</light_color_center_b>
</syntaxhighlight>

The idea behind this is that lights give a better visual appearance if their center is rendered visually brighter and de-saturated, but this occurs only if the light is at full intensity.

There are no sanity checks done, you can assign any center color you like even if this makes no sense - you can change center color or darken it, so use with care.

* to runtime change the light intensity, assign

<syntaxhighlight lang="xml">
<intensity_scale type="float">1.0</intensity_scale>
</syntaxhighlight>

to a property and change that property in the range from 0 to 1. Eg:

<syntaxhighlight lang="xml">
<intensity_scale>
<use>/rendering/nav-lights-factor</use>
</intensity_scale>
</syntaxhighlight>

* for directional lights, you need to assign a pointing vector in aircraft coordinates into which the light cone points and set the directionality flag to true to activate the computations. This is done via:

<syntaxhighlight lang="xml">
<pointing_x type="float">-1.0</pointing_x>
<pointing_y type="float">0.0</pointing_y>
<pointing_z type="float">0.0</pointing_z>
<is_directional type="bool">true</is_directional>
</syntaxhighlight>

It would be customary to pass a normalized vector, but if you don't know how to do it, the shader will do it for you. By assigning properties to the pointing coordinates, the light direction can be changed runtime.

<b>Do not use a rotation animation to change the light direction - it won't work.</b> Make the pointing vector properties and change them to your needs.

* fading of a directional light away from the pointing axis is controlled by passing angles (or rather sines of angles).

<syntaxhighlight lang="xml">
<inner_angle type="float">0.2</inner_angle>
<outer_angle type="float">0.4</outer_angle>
<zero_angle type="float">0.7</zero_angle>
<outer_gain type="float">0.5</outer_gain>
</syntaxhighlight>

Up to inner_angle, the light will have full intensity. From inner to outer angle the light will linearly fade to outer_gain. From outer angle to zero angle, the light intensity will linearly fade to zero.

* to get an automatic strobe effect you can set

<syntaxhighlight lang="xml">
<is_strobe type="bool">true</is_strobe>
</syntaxhighlight>

to true. If you want your own strobe pattern, generate a strobe function and use <b>intensity_scale</b> instead to pass it to the shader.

=== Complete example ===

Here's the left nav light of the C-172p:

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>

<name>procedural-light-nav-left</name>
<inherits-from>Effects/procedural-light</inherits-from>

<parameters>
<light_color_base_r type="float">1.000</light_color_base_r>
<light_color_base_g type="float">0.320</light_color_base_g>
<light_color_base_b type="float">0.320</light_color_base_b>
<light_color_center_r type="float">1.0</light_color_center_r>
<light_color_center_g type="float">1.0</light_color_center_g>
<light_color_center_b type="float">1.0</light_color_center_b>
<intensity_scale type="float">1.0</intensity_scale>


<pointing_x type="float">1.0</pointing_x>
<pointing_y type="float">0.7002075382097097</pointing_y>
<pointing_z type="float">0.0</pointing_z>

<is_directional type="bool">true</is_directional>
<is_strobe type="bool">false</is_strobe>


<inner_angle type="float">0.8191520442889918</inner_angle>
<outer_angle type="float">1.0</outer_angle>
<zero_angle type="float">0.982547593563</zero_angle>
<outer_gain type="float">0.1</outer_gain>
</parameters>

</PropertyList>
</syntaxhighlight>

=== Examples ===
The Cessna 182 by Heiko Schulz and Gilberto Agostinho with procedural lights activated:<br>
:''(To percieve the effect well, you probably have to darken your room and switch to fullscreen)''
[[File:Cessna 182 with procedural lights.jpg|800px]]

== ALS fuselage shadow effect ==
ALS supports the manipulation of a (simplified) ground shadow. This effect uses an existing simplified shadow animation configuration and by default uses the gear-agl-m property to calculate the ground placement of that simplified shadow.

The system, techniques for using it, and several working examples are on [https://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=135 this extensive forum thread about the ALS shadow effects].

[[File:Alsshadow.jpg|800px|ALS Shadow]]

The effect can be applied easily in any aircraft that report the gear-agl-m property by simply adding a declaration inheriting from shadow.eff.

If the aircraft does not support the gear-agl-m property, (notably JSBSim), you need to create a [[Autopilot configuration reference | Property Rule]] to pass a supported AGL data to the gear-agl-m property. In this case we use altitude-agl-ft converted to meters using a property rule configuration file.

For the first example we'll use the "supported gear-agl-m" method for aircraft that don't require a property rule.

Simply add the following inheritance declaration after you declare your shadow animation statement.
<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/shadow</inherits-from>
<object-name>name_of_the_shadow_object</object-name>
</effect>
</syntaxhighlight>
In the non-ALS simplified shadow code you normally use a "translate" animation to position the shadow on the ground.
When using the ALS method you must either remove, comment out, or apply a condition to restrict its use to non ALS shadow applications, because ALS is responsible for computing the shadows ground position.

Here is how we apply a condition to the translation to limit it effect to non-ALS application only.
<syntaxhighlight lang="xml">

<animation>
<type>translate</type>
<object-name>shadow</object-name>
<condition>
<not>
<property>/sim/rendering/shaders/skydome</property>
</not>
</condition>
<property>/position/altitude-agl-ft</property>
<factor>-0.3048</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>0</x>
<y>0</y>
<z>1</z>
</axis>
</animation>
</syntaxhighlight>

A complete shadow animation block looks like this.
<syntaxhighlight lang="xml">
<PropertyList>

<animation>


<object-name>shadow</object-name>
<type>select</type>
<condition>
<not>
<property>/sim/rendering/rembrandt/enabled</property>
</not>
</condition>
</animation>

<effect>
<inherits-from>Effects/shadow</inherits-from>
<object-name>shadow</object-name>
</effect>

<animation>
<type>noshadow</type>
<object-name>shadow</object-name>
</animation>


<animation>
<type>rotate</type>
<object-name>shadow</object-name>
<property>/orientation/pitch-deg</property>
<factor>-1.0</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>


<animation>
<type>rotate</type>
<object-name>shadow</object-name>
<property>/orientation/roll-deg</property>
<factor>1.0</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>


<animation>
<type>translate</type>
<object-name>shadow</object-name>
<condition>
<not>
<property>/sim/rendering/shaders/skydome</property>
</not>
</condition>
<property>/position/altitude-agl-ft</property>
<factor>-0.3048</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>0</x>
<y>0</y>
<z>1</z>
</axis>
</animation>

</PropertyList>
</syntaxhighlight>

For aircraft requiring a [[Autopilot configuration reference | Property Rule]] there are a couple extra steps.

In aircraft-set.xml you add the property rule call to the "configuration file" in between the PropertyList/sim/systems tag pairs.
<syntaxhighlight lang="xml">
<property-rule n="101">
<name>gear_agl-m</name>
<path>Aircraft/c172p/Systems/gearAGL.xml</path>
</property-rule>
</syntaxhighlight>
Note: the n="101" needs to be =+100 as -100 is reserved for system wide property rules.
In the above example 101 was used because 100 was already being used by a previous property rule definition.

The "configuration file" normally goes in /Systems.
In this example we named the configuration file /Systems/gearAGL.xml.

Here is the complete /Systems/gearAGL.xml configuration file.
<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<PropertyList>
<filter>
<type>gain</type>
<gain>0.3048</gain>
<input>/position/altitude-agl-ft</input>
<reference>6</reference>
<output>/position/gear-agl-m</output>
</filter>
</PropertyList>
</syntaxhighlight>
What the configuration file does is convert the input of altitude-agl-ft to the output of (((altitude-agl-ft)-6)*0.3048) or (convert ft-6 to m) and pass it to /position/gear-agl-m.

See [[Autopilot configuration reference | Input and reference properties or values <input> and <reference>]].

== ALS 3d shadow volume effect ==
What might be considered the next level of realism using a relatively "cheap" shadow effect is to use a 3d volume shadow.

[[File:Shadow vol02.jpg|800px|ALS 3d Shadow Volume]]

The procedure to implement the ALS shadow volume is similar to the ALS-shadow above with a few modifications.

First you have to have a 3d shadow volume model of the aircraft you are applying the effect to. This model should be a low poly model that is optimized to be as little of a footprint as possible.

A property rule is required, same as above. This is used to generate the above ground altitude in meters, (altitude-agl-m). The "altitude-agl-m" is used to place the shadow close to the ground in real time at an FDM rate of execution.
{{note|Do not confuse "altitude-agl-m" with the other type of non-3d ALS-shadow property of "gear-agl-m". The shaders involved use these two different properties respectively for the two different effect. They are not interchangeable.}}
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<filter>
<type>gain</type>
<gain>0.3048</gain>
<input>/position/altitude-agl-ft</input>
<reference>1.0</reference>
<output>/position/altitude-agl-m</output>
</filter>
</PropertyList>
</syntaxhighlight>

The other difference from the ALS-shadow above is that it uses a different inherited effect.
Instead of
<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/shadow</inherits-from>
<object-name>shadow</object-name>
</effect>
</syntaxhighlight>
you use
<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/shadow-vol</inherits-from>
<object-name>shadow</object-name>
</effect>
</syntaxhighlight>

To make sure there is no duplicate 3d model shown in other renderers besides ALS it is also important to use a different select animation:
<syntaxhighlight lang="xml">
<animation>

<object-name>shadow</object-name>
<type>select</type>
<condition>
<property>/sim/rendering/shaders/skydome</property>
</condition>
</animation>
</syntaxhighlight>

== Related content ==

* [[Procedural Texturing]]
* [[Atmospheric light scattering]]
* [[ALS infrared vision]]

[[Category:Shader development]]
[[Category:ALS]]

Canvas

2013-05-17T21:11:18Z

AndersM: Mouse events video

{{infobox subsystem
|image =Canvas GUI Demo.png
|name =Canvas Subsystem
|started= 05/2012
|description = Dynamic 2D drawing at runtime using the property tree and scripting (for instruments, HUDs, GUIs)
|status = Under active development as of 02/2013
|maintainers = TheTom
|developers = [[User:TheTom]] (since 02/2012),
|folders = [http://gitorious.org/fg/flightgear/trees/next/src/Canvas $FG_SRC/Canvas]
[http://gitorious.org/fg/simgear/trees/next/simgear/canvas $SG_SRC/simgear/canvas]
|topic-sg= (main repository, next branch)
|topic-fg= (main repository, next branch)
|topic-fgdata= (main repository, master branch; https://gitorious.org/~tomprogs/fg/toms-fgdata/commits/canvas-gui-demo)
|subforum= http://flightgear.org/forums/viewforum.php?f=71
}}

{{Template:Canvas Navigation}}

== Intro ==
The "Canvas" system is a fairly new feature, added in 06/2012 to FlightGear - first available in FlightGear 2.8

In FlightGear, a "canvas" is a dynamically created texture that can be modified (drawn to) at runtime by using the property tree, i.e. via the built-in scripting language [[Nasal]]. Canvas textures can be used for a number of different purposes, such as creating fully scripted avionics (airliner/bizjet -style glass cockpits) but also custom HUDs and eventually also custom GUI textures or even fully interactive GUI widgets (scheduled for FG 3.0+).

The canvas subsystem is entirely implemented on top of the FlightGear [[Property Tree]], it makes use of property listeners to watch a sub tree of the property tree for canvas-related events, so that textures can be dynamically instantiated and modified by setting properties in the property tree. This method is not specific to [[Nasal]] scripting, the same system can be used by other subsystems (such as the [[Telnet]] or HTTP daemons) to create and modify textures without directly using Nasal.

As of 08/2012, the Canvas system is still under active development and nothing is set in stone yet.
See [[Canvas Properties]] for further information.

A first prototype of the canvas system is available in FlightGear 2.8, this lacks some features currently under development (notably the Nasal API)- it is expected that a more feature-rich version will be available in the following release, i.e. FlightGear 3.0+ - possibly replacing the entire GUI with a fully Canvas-driven implementation in scripting space (one of the long-term goals).

Future FlightGear versions will contain reimplementations of currently hard-coded instruments such as the wxradar, tcas or navdisplay using the canvas system, so that these can be easily maintained as part of the base package, and so that the same backend code can be also used for creating complex dialogs using the Canvas system, such as ATC displays like [[ATC-FS]].

Among other advantages, this will also provide for an opportunity to run Canvas-based instruments and GUI elements in another process, or even on another computer, analogous to [[FGPanel]] (see [[FGCanvas]]).

Also, there's currently work ongoing to port the old 2D panel and HUD systems to the new Canvas system, using custom Nasal wrappers reimplementing the old behavior and turning the textures into canvas properties.

== Gallery ==

A short video demonstrating a possible usecase (C-130J AMU):

{{#ev:youtube|A7j-B0LgV-A}}

By using alphablending it can also be used to render the contents of a HUD:

{{#ev:youtube|_oRX53JyXmM}}

In my branch there is now also support for using the canvas in a gui widget:

[[File:Canvas GUI Demo.png|thumb|none|400px|Using the Canvas as a GUI widget]]

With the new ''map'' element it is also very easy to draw maps:

[[File:Demonstration of using the Canvas inside a GUI dialog..png|thumb|none|400px|Simple Map of KSFO]]

Using the new [[Howto:Use_SVG_inside_a_Canvas|''canvas.parsesvg'']] function to use an SVG file to simulate an EICAS display:

{{#ev:youtube|43P7xKNJnV4}}

Demonstrating how the new Canvas GUI wrapper can be used to create entirely custom, scripted GUI widgets using XML, SVG and Nasal:

{{#ev:youtube|1a6wtPVPWc4}}

Experimenting with selecting text and positioning a cursor inside the text. The visualization is all done using Nasal.
{{#ev:youtube|CIS8UyuJLgM}}

Since 07/2012, the canvas system also provides support for full window-drawing:
{{#ev:youtube|Qv-uEX42QZY}}

Omega95 has reimplemented the CDU of the ATR72 using the Canvas system:
{{#ev:youtube|sAaVEKuiF5w}}

Another video demonstrating window stacking and nested canvases:

{{#ev:youtube|llVaasTEf44}}

Using Canvas mouse events to create [http://www.flightgear.org/forums/viewtopic.php?p=183653#p183653 animation of slider, wheel and knob]

{{#ev:youtube|HELiLjEGno8}}

Howto:Write a fuel system in JSBSim

2013-05-14T06:38:14Z

AndersM: Edited for -2.10 compatibility

As of [[FlightGear]] 2.4.0, JSBSim aircraft have a new tank-property: <tt>propulsion/tank[n]/external-flow-rate-pps</tt>. Setting this property will either draw fuel from (value < 0), or insert fuel into (value > 0) the respective tank. By using this property, one can simulate complex fuel systems.

== A fuel system file ==
First we create a system file, in which we will write the actual system. It's advised to save this file as <tt>Aircraft/.../Systems/fuel.xml</tt>.
<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<system name="fuel">

</system>
</syntaxhighlight>

We link the main FDM to this system by adding the following line, somewhere in your aircraft's FDM (I advise to put it below <tt></propulsion></tt>).
<syntaxhighlight lang="xml">
<system file="fuel"/>
</syntaxhighlight>
Notice how "fuel" refers to <tt>Aircraft/.../Systems/fuel.xml</tt>.

== Fuel handling in JSBSim ==
To make JSBSim handle the fuel system during simulation we create one or more channels in the system file. Within these we can use the different control components [http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf available in JSBSim].

When using <tt>propulsion/tank[n]/external-flow-rate-pps</tt> there is no automatic detection if the tank is full or empty. Fuel filling an already full tank will just disappear, creating a "leak". Fuel drawn from an empty tank will make new fuel magically appear in the system. In most cases we will have to make checks to avoid these problems.

Two control components that is useful in a fuel system are summers and switches.

=== Summers ===
To calculate the total fuel-flows to/from each tank, we need to sum up the independent flows. This must be done for each single tank, but the principle is the same every time and simple to understand. Every flow that transports fuel ''from'' a tank should get a minus sign.

This summer calculates the total flow to or from tank[0].
<syntaxhighlight lang="xml">
<summer>
<input>-propulsion/tank[0]/external-flow-rate/jettison</input> 
<input>-propulsion/tank[0]/external-flow-rate/tank[1]</input> 
<input>-propulsion/tank[0]/external-flow-rate/tank[2]</input> 
<input>-propulsion/tank[0]/external-flow-rate/tank[3]</input> 
<input>propulsion/tank[1]/external-flow-rate/tank[0]</input> 
<input>propulsion/tank[2]/external-flow-rate/tank[0]</input> 
<input>propulsion/tank[3]/external-flow-rate/tank[0]</input> 
<output>propulsion/tank[0]/external-flow-rate-pps</output>
</summer>
</syntaxhighlight>

=== Switches ===
To turn the flow on or off we need a switch.

This switch draws 5 lbs/s from tank[0] until its empty as long as the collector vale is open.
<syntaxhighlight lang="xml">
<switch>
<default value="-5"/>
<test logic="OR" value="0">
propulsion/tank[0]/collector-valve EQ 0
propulsion/tank[0]/pct-full LE 0
</test>
<output>propulsion/tank[0]/external-flow-rate-pps</output>
</switch>
</syntaxhighlight>

== Examples ==
=== Jettison switch ===
The /controls/fuel/fuel-to-remain property controls the amount of fuel (in lbs) that should be kept a board. When the total-fuel-level reaches that level, fuel dumping will auomatically stop. Fuel dumping can also be stopped by closing the jettison valves (disable <tt>/controls/fuel/dump-valve</tt>).
<syntaxhighlight lang="xml">
<switch>
<default value="0"/>
<test logic="AND" value="12.25">
/controls/fuel/dump-valve == 1
propulsion/total-fuel-lbs gt /controls/fuel/fuel-to-remain
</test>
<output>propulsion/tank[0]/external-flow-rate/jettison</output>
<output>propulsion/tank[2]/external-flow-rate/jettison</output>
<output>propulsion/tank[3]/external-flow-rate/jettison</output>
<output>propulsion/tank[7]/external-flow-rate/jettison</output>
</switch>
</syntaxhighlight>
The output properties should be added as inputs to the respective summers. Add a minus sign, as the fuel is taken ''from'' the tank.

=== Two tanks and a collector tank ===
A system with two tanks (tank[0] and tank[1]) feeding a collector tank (tank[2]). The engine is fed from the collector tank. There is valves between each of the tanks and the collector that can be set open or closed. Negative Gs cut the supply to the collector.

The system consists of two properties: propulsion/tank[0]/collector-valve and propulsion/tank[1]/collector-valve that represent the valves and a channel that handles the fuel transfer from the tanks to the collector and the necessary checks.

The fuel transfer using external-flow-rate-pps does not check against if tanks are empty or full. This can create fuel when "fuel" is drawn from an empty tank or a "leak" when fuel is pumped into a full tank. The collector tank in the example has the capacity 130 lbs so making the check against collector tank level greater or equal to 129 instead of against 130 is done to avoid the later kind of leak since the collector tank normally receives more fuel every time step than the engine uses. The 1 lb margin creates a buffer for this difference as the value oscillates around 129 lbs as the switch turns on and off the flow.

[[File:Collector-tank-system2.png|thumb|Two tanks and a collector tank]]
<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<system name="Fuel">


<property type="bool" value="1">propulsion/tank[0]/collector-valve</property>
<property type="bool" value="1">propulsion/tank[1]/collector-valve</property>

<channel name="Fuel pumping">

<switch>
<default value="-5"/>
<test logic="OR" value="0">
propulsion/tank[0]/collector-valve EQ 0
propulsion/tank[0]/contents-lbs LE 0
propulsion/tank[2]/contents-lbs GE 129 
accelerations/Nz LE -0.5
</test>
<output>propulsion/tank[0]/external-flow-rate-pps</output>
</switch>

<switch>
<default value="-5"/>
<test logic="OR" value="0">
propulsion/tank[1]/collector-valve EQ 0
propulsion/tank[1]/contents-lbs LE 0
propulsion/tank[2]/contents-lbs GE 129 
accelerations/Nz LE -0.5
</test>
<output>propulsion/tank[1]/external-flow-rate-pps</output>
</switch>

<summer>
<input>-propulsion/tank[0]/external-flow-rate-pps</input>
<input>-propulsion/tank[1]/external-flow-rate-pps</input>
<output>propulsion/tank[2]/external-flow-rate-pps</output>
</summer>

</channel>

</system>

</syntaxhighlight>

=== Spitfire: Carburetor engine ===

Spitfire II fuel system. This systems have properties for damage, leaks and simulates the carburetor as a small tank to handle fuel starvation at negative Gs.
The Spitfire has two interconnected tanks with fuel flowing from an upper tank to a lower and both connected to the engine through cocks. The layout of the system can be seen [http://616sqn.tidesofwar.net/gallery/spitfuelsm.jpg here].

<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<system name="Fuel">

<property type="bool" value="0"> /fdm/jsbsim/fuel/tank_top_cock</property>
<property type="bool" value="0"> /fdm/jsbsim/fuel/tank_bottom_cock</property>
<property type="double" value="1"> /fdm/jsbsim/fuel/damage</property>
<property type="double" value="0"> /fdm/jsbsim/fuel/priming</property>
<property type="double" value="0"> /fdm/jsbsim/fuel/leak_top_tank</property>
<property type="double" value="0"> /fdm/jsbsim/fuel/leak_bottom_tank</property>

<channel name="carburetor">


<summer name="fuel/float_chamber-pps">
<input>fuel/pump_flow_to_float-pps</input>
<input>/fdm/jsbsim/fuel/priming</input>
<input>-propulsion/engine/fuel-flow-rate-pps</input>
<output>propulsion/tank[0]/external-flow-rate-pps</output>
</summer>

</channel>

<channel name="Fuel Pump">


<aerosurface_scale name="fuel/float_throttle-valve-cmd">
<input>propulsion/tank[0]/contents-lbs</input>
<zero_centered>false</zero_centered>
<domain>
<min>0.0</min>
<max>0.5</max>
</domain>
<range>
<min>1.0</min>
<max>0.0</max>
</range>
</aerosurface_scale >


<switch name="fuel/flowing_from_tank">
<default value="0"/>
<test logic="AND" value="fuel/float_throttle-valve-cmd">
accelerations/Nz GE -0.5
<test logic="OR">
<test logic="AND">
fuel/tank_top_cock EQ 1
propulsion/tank[1]/contents-lbs GT 0
</test>
<test logic="AND">
fuel/tank_bottom_cock EQ 1
propulsion/tank[2]/contents-lbs GT 0
</test>
</test>
</test>
</switch>

<fcs_function name="fuel/pump_flow_to_float-pps">
<function>
<product>
<property>fuel/flowing_from_tank</property>
<table> 
<independentVar>propulsion/engine/engine-rpm</independentVar>
<tableData> 
0 0
100 1
3000 10
</tableData>
</table>
<property>fuel/damage</property>
<value>0.12</value> 
</product>
</function>
<output>fuel/pump_flow_to_float-pps</output>
</fcs_function>

</channel>

<channel name="Tanks">


<fcs_function name="fuel/flow_from_tank">
<function>
<quotient>
<property>fuel/pump_flow_to_float-pps</property>
<sum>
<property>fuel/tank_top_cock</property>
<property>fuel/tank_bottom_cock</property>
</sum>
</quotient>
</function>
<output>fuel/flow_from_tank</output>
</fcs_function>

</channel>

<channel name="Top Tank">


<switch name="fuel/top_bottom_transfer">
<default value="0"/>
<test logic="AND" value="1">
propulsion/tank[1]/contents-lbs GT 0
propulsion/tank[2]/contents-lbs LT 322
accelerations/Nz GE -0.5
</test>
</switch>


<fcs_function name="fuel/top_bottom_transfer-pps">
<function>
<product>
<property>fuel/top_bottom_transfer</property>
<sum>
<property>fuel/from_bottom_tank</property>
<table> 
<independentVar>propulsion/tank[2]/contents-lbs</independentVar>
<tableData>
319 1
322 0
</tableData>
</table>
</sum>
</product>
</function>
<output>fuel/top_bottom_transfer-pps</output>
</fcs_function>


<switch name="fuel/from_top_tank">
<default value="0"/>
<test logic="AND" value="fuel/flow_from_tank">
fuel/tank_top_cock EQ 1
accelerations/Nz GE -0.5
</test>
</switch>


<summer name="fuel/total_from_top_tank-pps">
<input>-fuel/top_bottom_transfer-pps</input>
<input>-fuel/from_top_tank</input>
<input>-fuel/leak_top_tank</input>
<output>propulsion/tank[1]/external-flow-rate-pps</output>
</summer>

</channel>

<channel name="Bottom Tank">


<switch name="fuel/from_bottom_tank">
<default value="0"/>
<test logic="AND" value="fuel/flow_from_tank">
fuel/tank_bottom_cock EQ 1
accelerations/Nz GE -0.5
</test>
</switch>


<summer name="fuel/total_from_bottom_tank-pps">
<input>fuel/top_bottom_transfer-pps</input>
<input>-/fdm/jsbsim/fuel/priming</input>
<input>-fuel/from_bottom_tank</input>
<input>-fuel/leak_bottom_tank</input>
<output>propulsion/tank[2]/external-flow-rate-pps</output>
</summer>

</channel>

</system>
</syntaxhighlight>

=== Douglas DC3 (2 engines, 4 tanks) ===
The real aircraft has two engines and four tanks.Two tank selectors (one per engine) allows each engine to be fed by each tank, separately and one tank at a time for a given engine. The diagram of the fuel system can be seen [http://www.theaviatornetwork.com/pdf/GTM-05-050130-Fuel-System.pdf at the end of this document].
For FG, the engines are numbered [0] and (1], the 'true' feed tanks [0], [1], [2], [3]. Each tank selector is a 5-positions ('OFF' + 4 tanks) rotary switch. Its positions are numbered -1 (OFF), 0, 1, 2, 3, for 'no tank selected', tank[0], [1], [2], [3] respectively.

'''Prerequisite''': A nasal code logic says:
* if an engine[N] boost-pump is "ON", and fuel-level > 4 lbs in the tank selected for this engine[N] ==> fuel-pressure = 16 psi
* else, if engine[N] is running, and fuel-level > 4 lbs in the tank selected for this engine[N] ==> fuel-pressure = 14.5
* else of all that, fuel-pressure = 0
Hence, fuel pressure is a a good criteria to tell that an engine is fed ot not, i.e. if it is connected to a tank, if this tank is filled, with a running pump (or not).
(This function could probably be implemented by XML)

'''For the fuel system presented here''', two small collector tanks 4 and 5 (each collector tank feeding one engine) have been added. These collector tanks are necessary to have each engine be separately fed by its selected 'true' tank and selectively stop if the tank runs out of fuel. The collector tanks are fed by the selected tanks (rotary switches) and have their level kept constant. This functionning is close to a constant level carburetor.

'''The FDM''' contains the following lines which set the tanks.
Notice that the engines are written as fed by the collector tanks ((4 and 5), which themselves will be fed by the selected 'true' tanks (0 to 3).
<syntaxhighlight lang="xml">
<propulsion>
<engine file="DC3_engine"> 
.........
<feed>4</feed>
.........
</engine>

<engine file="DC3_engine"> 
.........
<feed>5</feed>
.........
</engine>

<tank type="FUEL" number="0">
.........
<capacity unit="LBS"> 1202 </capacity>
<contents unit="LBS"> 600 </contents>
</tank>

<tank type="FUEL" number="1">
...........
<capacity unit="LBS"> 1210 </capacity>
<contents unit="LBS"> 600 </contents>
</tank>

<tank type="FUEL" number="2">
...........
<capacity unit="LBS"> 1210 </capacity>
<contents unit="LBS"> 600 </contents>
</tank>

<tank type="FUEL" number="3">
...............
<capacity unit="LBS"> 1202 </capacity>
<contents unit="LBS"> 600 </contents>
</tank>

<tank type="FUEL" number="4">

...........
<capacity unit="LBS"> 0.5 </capacity>
<contents unit="LBS"> 0 </contents>
</tank>

<tank type="FUEL" number="5">


..............
<capacity unit="LBS"> 0.5 </capacity>
<contents unit="LBS"> 0 </contents>
</tank>

</propulsion>
</syntaxhighlight>

The '''Fuel system XML file''' itself is (can be named fuel.xml, see at the top of this document for how to link the FDM to it):
<syntaxhighlight lang="xml">
<?xml version="1.0"?>



<system name="fuel">





<channel name="Engine 0 Rotary Left Valve Logic">



<switch name="fuel/through-left-valve">
<default value="0"/>
<test logic="AND" value="0.5">
/controls/fuel/left-valve EQ 0
propulsion/tank[0]/contents-lbs GT 0
/consumables/fuel/tank[4]/level-lbs LT 0.25
/engines/engine[0]/fuel-psi-norm GT 5
</test>
<test logic="AND" value="0.5">
/controls/fuel/left-valve EQ 1
propulsion/tank[1]/contents-lbs GT 0
/consumables/fuel/tank[4]/level-lbs LT 0.25
/engines/engine[0]/fuel-psi-norm GT 5
</test>
<test logic="AND" value="0.5">
/controls/fuel/left-valve EQ 2
propulsion/tank[2]/contents-lbs GT 0
/consumables/fuel/tank[4]/level-lbs LT 0.25
/engines/engine[0]/fuel-psi-norm GT 5
</test>
<test logic="AND" value="0.5">
/controls/fuel/left-valve EQ 3
propulsion/tank[3]/contents-lbs GT 0
/consumables/fuel/tank[4]/level-lbs LT 0.25
/engines/engine[0]/fuel-psi-norm GT 5
</test>
<output>propulsion/tank[4]/external-flow-rate-pps</output>
</switch>


<switch name="fuel/eng0-from-tank0">
<default value="0"/>
<test value="-fuel/through-left-valve">
/controls/fuel/left-valve EQ 0
</test>
</switch>


<switch name="fuel/eng0-from-tank1">
<default value="0"/>
<test value="-fuel/through-left-valve">
/controls/fuel/left-valve EQ 1
</test>
</switch>


<switch name="fuel/eng0-from-tank2">
<default value="0"/>
<test value="-fuel/through-left-valve">
/controls/fuel/left-valve EQ 2
</test>
</switch>


<switch name="fuel/eng0-from-tank3">
<default value="0"/>
<test value="-fuel/through-left-valve">
/controls/fuel/left-valve EQ 3
</test>
</switch>

</channel>





<channel name="Engine 1 Rotary Right Valve Logic">



<switch name="fuel/through-right-valve">
<default value="0"/>
<test logic="AND" value="0.5">
/controls/fuel/right-valve EQ 0
propulsion/tank[0]/contents-lbs GT 0
/consumables/fuel/tank[5]/level-lbs LT 0.25
/engines/engine[1]/fuel-psi-norm GT 5
</test>
<test logic="AND" value="0.5">
/controls/fuel/right-valve EQ 1
propulsion/tank[1]/contents-lbs GT 0
/consumables/fuel/tank[5]/level-lbs LT 0.25
/engines/engine[1]/fuel-psi-norm GT 5
</test>
<test logic="AND" value="0.5">
/controls/fuel/right-valve EQ 2
propulsion/tank[2]/contents-lbs GT 0
/consumables/fuel/tank[5]/level-lbs LT 0.25
/engines/engine[1]/fuel-psi-norm GT 5
</test>
<test logic="AND" value="0.5">
/controls/fuel/right-valve EQ 3
propulsion/tank[3]/contents-lbs GT 0
/consumables/fuel/tank[5]/level-lbs LT 0.25
/engines/engine[1]/fuel-psi-norm GT 5
</test>
<output>propulsion/tank[5]/external-flow-rate-pps</output>
</switch>


<switch name="fuel/eng1-from-tank0">
<default value="0"/>
<test value="-fuel/through-right-valve">
/controls/fuel/right-valve EQ 0
</test>
</switch>


<switch name="fuel/eng1-from-tank1">
<default value="0"/>
<test value="-fuel/through-right-valve">
/controls/fuel/right-valve EQ 1
</test>
</switch>


<switch name="fuel/eng1-from-tank2">
<default value="0"/>
<test value="-fuel/through-right-valve">
/controls/fuel/right-valve EQ 2
</test>
</switch>


<switch name="fuel/eng1-from-tank3">
<default value="0"/>
<test value="-fuel/through-right-valve">
/controls/fuel/right-valve EQ 3
</test>
</switch>

</channel>





<channel name="Total flow rates">

<summer name="fuel/tank0-flow-rate">
<input>fuel/eng0-from-tank0</input>
<input>fuel/eng1-from-tank0</input>
<output>propulsion/tank[0]/external-flow-rate-pps</output>
</summer>

<summer name="fuel/tank1-flow-rate">
<input>fuel/eng0-from-tank1</input>
<input>fuel/eng1-from-tank1</input>
<output>propulsion/tank[1]/external-flow-rate-pps</output>
</summer>

<summer name="fuel/tank2-flow-rate">
<input>fuel/eng0-from-tank2</input>
<input>fuel/eng1-from-tank2</input>
<output>propulsion/tank[2]/external-flow-rate-pps</output>
</summer>

<summer name="fuel/tank3-flow-rate">
<input>fuel/eng0-from-tank3</input>
<input>fuel/eng1-from-tank3</input>
<output>propulsion/tank[3]/external-flow-rate-pps</output>
</summer>

</channel>

</system>
</syntaxhighlight>

{{JSBSim}}

[[Category:Aircraft enhancement|Fuel system JSBSim]]
[[Category:Howto|Fuel system JSBSim]]

Saab 35 Draken

2013-05-09T19:41:10Z

AndersM: /* Gauges and instruments */

{{aero-stub}}

{{infobox Aircraft
|image = Saab_J35.jpg
|image2 = Saab_J35_cockpit.jpg
|name = Saab 35 Draken
|type = Fighter aircraft
|fdm = JSBSim
|status-fdm = 3
|status-systems = 2
|status-cockpit = 3
|status-model = 3
|authors = Oliver Reischl (3D model), Anders M (FDM, Cockpit)
|fgname = SaabJ35F
}}
The '''Saab 35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit image.

=== Special aircraft keys ===

*Shift-S Automatic start sequence including all systems. (The aircraft needs to be stationary.)
*Shift_L Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
*Ctrl-J Jettison drop tanks in air.
*Ctrl-D Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below.

*HÖJDV: Autopilot indicator. Flashes as long as aircraft not at target altitude. Lit when stable at target altitude.

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of droptanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7)

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Showing a sweep and antenna azimut as well as navigation indicators.
In multiplayer the radar shows aircraft in radar range: dist. < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground.

Radar modes are set by the navigation radio.

'''Autopilot'''

The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''Navigation radio and mode selector'''

3D model right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, Radar off, AHK 0, cn manual
*FÖRV: (Preselected) No nav radio, Radar off, AHK HÖJDÄNDRING, cn manual
*STRIL: (Combat command) Activates Route Manager, Radar scanning, AHK NYTT MÅL, cn direction to next waypoint.
*STRID: (Combat) No nav info, Radar scanning, AHK HÖJDÄNDRING, cn manual
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon.
*LANDN 40: (Landing 40 km) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK LANDA, cn direction to beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters NAV+LANDN. Radar shows glide slope pointers, AHK BARBRO, cn direction to ILS beacon.

'''Special Controls and switches'''
*Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Start panel: Lower left instrument panel.(2) Se below.
*Instrument and panel lighting: Left side knob above throttle.(1) Click to change intensity.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 250 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engined jets]]

Saab 35 Draken

2013-05-09T19:38:24Z

AndersM: /* Flying */ Start panel image

{{aero-stub}}

{{infobox Aircraft
|image = Saab_J35.jpg
|image2 = Saab_J35_cockpit.jpg
|name = Saab 35 Draken
|type = Fighter aircraft
|fdm = JSBSim
|status-fdm = 3
|status-systems = 2
|status-cockpit = 3
|status-model = 3
|authors = Oliver Reischl (3D model), Anders M (FDM, Cockpit)
|fgname = SaabJ35F
}}
The '''Saab 35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit image.

=== Special aircraft keys ===

*Shift-S Automatic start sequence including all systems. (The aircraft needs to be stationary.)
*Shift_L Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
*Ctrl-J Jettison drop tanks in air.
*Ctrl-D Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below.

*HÖJDV: Autopilot indicator. Flashes as long as aircraft not at target altitude. Lit when stable at target altitude.

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of droptanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7)

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Showing a sweep and antenna azimut as well as navigation indicators.
In multiplayer the radar shows aircraft in radar range: dist. < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground.

Radar modes are set by the navigation radio.

'''Autopilot'''
The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''
Navigation radio and mode selector'''

3D model right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, Radar off, AHK 0, cn manual
*FÖRV: (Preselected) No nav radio, Radar off, AHK HÖJDÄNDRING, cn manual
*STRIL: (Combat command) Activates Route Manager, Radar scanning, AHK NYTT MÅL, cn direction to next waypoint.
*STRID: (Combat) No nav info, Radar scanning, AHK HÖJDÄNDRING, cn manual
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon.
*LANDN 40: (Landing 40 km) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK LANDA, cn direction to beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters NAV+LANDN. Radar shows glide slope pointers, AHK BARBRO, cn direction to ILS beacon.

'''Special Controls and switches'''
*Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Start panel: Lower left instrument panel.(2) Se below.
*Instrument and panel lighting: Left side knob above throttle.(1) Click to change intensity.

=== Flying ===
[[File:J35 Draken start panel.jpg|thumb|Start panel]]
'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel.(no. 1) Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.(no. 2)
* Turn on afterburner fuel pump. Leftmost switch on the start panel.(no. 3) The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.(no. 4)
* Switch on the generator when engine at 30%. The switch next to the start button.(no. 5)
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 250 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engined jets]]

File:J35 Draken start panel.jpg

2013-05-09T19:35:14Z

AndersM:

=={{int:filedesc}}==
{{Information
|description={{en|1=Start panel J25 Draken}}
|date=2013-05-09
|source={{own}}
|author=[[User:AndersM|AndersM]]
|permission=
|other_versions=
|other_fields=
}}

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

Saab 35 Draken

2013-05-09T19:31:29Z

AndersM: Updated to describe current version

{{aero-stub}}

{{infobox Aircraft
|image = Saab_J35.jpg
|image2 = Saab_J35_cockpit.jpg
|name = Saab 35 Draken
|type = Fighter aircraft
|fdm = JSBSim
|status-fdm = 3
|status-systems = 2
|status-cockpit = 3
|status-model = 3
|authors = Oliver Reischl (3D model), Anders M (FDM, Cockpit)
|fgname = SaabJ35F
}}
The '''Saab 35 Draken''' (Dragon) is a Swedish supersonic interceptor developed in the 1950s. The model F was delivered between 1965 and 1972 and is the model that the FG plane is based on.

== Description of the features ==
Number in parenthesis refers to the cockpit image.

=== Special aircraft keys ===

*Shift-S Automatic start sequence including all systems. (The aircraft needs to be stationary.)
*Shift_L Attach or remove drop tanks on ground. (Stationary and drop tank selector off)
*Ctrl-J Jettison drop tanks in air.
*Ctrl-D Unlocks and opens/closes and locks canopy. Closed and locked canopy - first press unlocks second opens canopy. Closed and unlocked canopy at simulation start - first press locks. Open canopy - first press closes canopy second locks

=== Special indicators ===

*GLÖM EJ LAND-STÄLL: ("Do not forget landing gear") flashes if altitude < 1450 m, airspeed < 450 km/h and throttle < 85%

*HUVUDVARN.: Main caution light. Indicates important system warnings. See below.

*HÖJDV: Autopilot indicator. Flashes as long as aircraft not at target altitude. Lit when stable at target altitude.

=== Gauges and instruments ===

'''Fuel gauge'''

Shows percent of droptanks left until they are empty if attached. Otherwise percent of internal fuel remaining. The two needles shows left/front and right/rear tank level. The engine is supplied by the two tanks alternating if not on afterburner, therefore the needles will chase each other down the scale.

'''G-gauge'''

Max G-force is displayed by a striped needle. Reset by clicking the small reset pin on the right side of the instrument.

'''Altitude gauge'''

Pressure setting is done by clicking left or right side of the setting knob (lower left of he instrument).

'''Altitude selector'''

Right side below secondary AI. Sets target altitude for autopilot. (7)

'''Course selector'''

Below Heading indicator. Sets course needle on the heading indicator (compass).

'''AHK'''

The real AHK (swe.Avstånd Höjd Kommando, eng. distance altitude command), on the right side of the radar, was an instrument connected to the Swedish air combat control centres (The system is part of "STRIL60"). It gave tactical information to the pilot by 20 different commands, displayed as words at the top of the instrument, and also by the distance scale and the arrow needle on the height scale. Some of the commands are reused as instrument modes.(6)

In all modes the "HÖJD" (altitude) scale shows pressure-altitude. Dot-needle from 0-2000 m and tape-needle from 0-20000 m.

Modes:

*0: (Off) Only altitude shown
*HÖJDÄNDRING: Arrow shows height reached in one minute at current vertical speed. Scale 0-20000 m. "AVST" tape shows distance over ground to change altitude 1000 m at current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*LANDA: Arrow shows height reached in one minute at current vertical speed. Scale 0-2000 m.
"AVST" tape shows distance over ground until tuchdown at sealevel and current vertical speed. Speed over ground calculated from IAS using standard atmosphere.
*AVST. 400: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-400 km.
*AVSTÅND 40: Arrow shows height reached in one minute at current vertical speed. AVST tape shows distance to beacon 0-40 km.
*BARBRO: Arrow shows height reached in one minute at current vertical speed, scale 0-2000 m. AVST tape shows distance to beacon 0-40 km.
*NYTT MÅL: Arrow shows Route Manager cruise altitude 0- 20000 m. AVST shows distance 0-400 km to next Route Manager waypoint.

'''Caution panel'''

Lower right.(9) Shows system cautions and warnings.
Those with ! in front triggers main caution light:

*!BRAND MOTOR: (fire engine) not implemented
*!BRAND EBK P: (fire afterburner pump) not implemented
*STYR AUT: (autopilot) autopilot off
*MOTOR IS: (engine ice) engine deicing on not implemented yet
*!TANK LUFT: (tank air) airpressure fault in fuel system. Not implemented
*!OLJE TRYCK: (oil pressure) low oil pressure.
*EBK: (afterburner) Indicates that the exhaust nozzle is working as AB is turned off or on
or open when idle on the ground to keep engine from overheating. (Not lit constantly when using AB.)
*!SYR GAS: (oxygen pressure) not implemented
*!EL FEL: (electric fault) fault in AC circuit or generator off.
*!HYDR I, HYDR II: (hydraulic I and II) Low pressure in hydraulic circuit
*!KABIN TRYCK: (cabin pressure) Cabin pressure too low. Not implemented.
*!HUV LÅS: (canopy lock) canopy not locked.

TANK LUFT, OLJE TRYCK, EL FEL, HYDR I and HYDR II will be lit when generator off. But should go off during engine start up.

'''Radar'''

Showing a sweep and antenna azimut as well as navigation indicators.
In multiplayer the radar shows aircraft in radar range: dist. < 40 km, +-60 deg in yaw, +-30 deg in pitch and > 100 m above ground.

Radar modes are set by the navigation radio.

'''Autopilot'''
The autopilot is on the right side of the seat (11) and has the following functions and controls:
*HÖJD: Altitude hold
*ATTITYD: Attitude hold- pitch and roll
*DÄMPN: Pitch and yaw-damper on. This is on in all normal flight conditions
*SVÄNG: Banks the aircraft in attitude mode
*NOS: Pitch setting in attitude mode
*FRÅN TILL: Main autopilot switch. Normally left on. Triggers caution light if off.
*ROLL: Roll trim elevon setting
*GIR: Rudder trim setting
*Middle mouse button zeros the slider/knob.

''IMPORTANT:'' The autopilot has an automatic switch to only damping if airspeed is Mach 0.95-1.05 or G-force is above 4 G or below -0.5 G. No warning is given.

At present the autopilot is not as stable as it should be, especially altitude hold.

'''
Navigation radio and mode selector'''

3D model right side panel below cautions.(10) Main mode selector for navigation, AHK and radar.

Draken does not have ordinary navigation instruments. It has a special system that was integrated in the combat command and navigation system of the Swedish airforce. A letter code was used to select navigation beacons and airbase landing system. There was two parts of the system: Anita - general navigation and Barbro - landing guidance.

To simulate this and still be compatible with FG there is a file beacons.txt in the aircraft's directory. In that file you write a line for each beacon you want to use. The format is a comma separated list: letter code,type,frequenzy,note
*letter code: Three letters A-P that identifies the beacon. Anita (VOR, NDB) does only use the first two (you can set the last to any character you want). Barbro (ILS) uses all three.
*type: VOR, NDB or ILS.
*frequency: The beacons frequency VOR/ILS in MHz, NDB in kHz.
*note: Descriptive note. Must have at least one character.

The selected mode sets input to course needle (cn), radar and AHK:
*FRÅN: (Off) No nav radio, Radar off, AHK 0, cn manual
*FÖRV: (Preselected) No nav radio, Radar off, AHK HÖJDÄNDRING, cn manual
*STRIL: (Combat command) Activates Route Manager, Radar scanning, AHK NYTT MÅL, cn direction to next waypoint.
*STRID: (Combat) No nav info, Radar scanning, AHK HÖJDÄNDRING, cn manual
*NAVRIKTN: (Navigation direction) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK HÖJDÄNDRING, cn ADF.
*NAV 400: (Navigation 400 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVST. 400 (shows 0 if NDB), cn direction to VOR.
*NAV 40: (Navigation 40 km) Uses VOR/NDB set by the two letters NAV. Radar shows direction pointer, AHK AVSTÅND 40 (shows 0 if NDB), cn direction to beacon.
*LANDN 40: (Landing 40 km) Uses NDB/VOR set by the two letters NAV. Radar shows direction pointer, AHK LANDA, cn direction to beacon.
*BARBRO: (Barbro) Uses ILS set by the three letters NAV+LANDN. Radar shows glide slope pointers, AHK BARBRO, cn direction to ILS beacon.

'''Special Controls and switches'''
*Droptank fuel valve: Right front canopy rim.(8) Set to on (forward) when using drop tanks.
*Parking brake: Center console below instrument panel to the right.(5)
*Jettison droptanks: Left side with red protection ring.(4)
*Canopy handle: Left side(3)
*Start panel: Lower left instrument panel.(2) Se below.
*Instrument and panel lighting: Left side knob above throttle.(1) Click to change intensity.

=== Flying ===

'''Starting the aircraft'''

Either press Shift-S and let the automatic start make the work or follow the check list below.

* Battery switch on. The smaller covered switch on the start panel. Click cover to open and then switch.
* Lock canopy. Click handle. The HUV LÅS caution should now go out.
* Turn on main fuel pump. Under the large cover on he start panel.
* Turn on afterburner fuel pump. Leftmost switch on the start panel. The red light on the start panel is now off.
* Turn on drop tanks fuel valve. The yellow light on the start panel is now unlit.
* Press START button on the start panel and wait until the engine is ignited.
* Switch on the generator when engine at 30%. The switch next to the start button.
All caution lights should now be unlit in a few seconds.

'''Normal operations'''
* Draken has elevons, combined ailerons and elevators. Large elevon deflections decreases the available aileron difference.
* The aircraft has non-linear control response in elevation to lessen effect of small stick movements.
* To avoid accidents on landing is it not possible to retract landing gears if throttle < 90 %
* Rotation 250 km/h
* Max airspeed(Vne) 1350 km/h. Max speed with gear extended 500 km/h.
* Touch down speed ca. 300 km/h. 12 degrees AoA
* Too long with negative G causes fuel starvation.
* Watch alpha and speed. Drag increases fast with increasing alpha and pitch can occur at alpha > 25 deg

== External link ==
* [http://en.wikipedia.org/wiki/Saab_35_Draken Saab 35 Draken] (Wikipedia)

[[Category:Delta-wing aircraft]]
[[Category:Fighter aircraft]]
[[Category:Single-engined jets]]

File:Saab J35 cockpit.jpg

2013-05-09T18:27:53Z

AndersM: uploaded a new version of "File:Saab J35 cockpit.jpg": Updated to newest GIT version

Bindings

2013-05-05T13:32:26Z

AndersM: /* Commands */ link to source

'''Bindings''' define what happens when a user:
* [[Howto: Make a clickable panel#Pick|clicks an object]] in the [[scenery]] or an [[aircraft]]
* press a key on the keyboard or [[joystick]]
* clicks a [[menu]] item
* click a buttons or fields in a dialog
You can assign multiple bindings to one object/button/key.

All give codes are examples, found on various places in the [[FlightGear]] package.

== Commands ==

Below are a number of useful commands. See further [http://mapserver.flightgear.org/git/?p=flightgear;a=blob;f=src/Main/fg_commands.cxx;h=4c3272916f56a3180e29b9d8457e697bb71cfecb;hb=HEAD#l1555 fg_commands.cxx].

=== dialog-close ===
Closes the active dialog.
<binding>
<command>dialog-close</command>
</binding>

=== dialog-show ===
Shows a dialog, which should be present in <tt>[[$FG ROOT]]/gui/dialogs</tt>. Starting with FlightGear 2.7 dialog files located in <tt><Current aircraft directory>/gui/dialogs</tt> are also loaded. This should be used for dialogs specific to a certain aircraft.
<binding>
<command>dialog-show</command>
<dialog-name>location-in-air</dialog-name>
</binding>
* '''dialog-name:''' the name of the dialog, as designated in its .xml file.

=== nasal ===
[[Nasal]] is frequently used for complicated systems.
<binding>
<command>nasal</command>
<script>b777.afds.input(0,1);</script>
</binding>

=== property-adjust ===
Increases or decreases a property's value with a given step. Maximum and minimum values are optional.
<binding>
<command>property-adjust</command>
<property>/controls/lighting/panel-norm</property>
<step>-0.05</step>
<min>0</min>
<max>1</max>
</binding>

=== property-assign ===
One of the most important commands. It sets a property to a predefined value.
<binding>
<command>property-assign</command>
<property>/autopilot/settings/target-speed-kt</property>
<value>0</value>
</binding>

=== property-cycle ===
Cycles between a list of values and assigns one to a property. The value-list can vary in length. If the current value is "value1", it will change to "value2"; if it is "value2", it will change to "value3", and so on, wrapping around the end. If the current value is not in the list, it will jump to the first one.
<binding>
<command>property-cycle</command>
<property>/autopilot/autobrake/setting</property>
<value type="string">ARM</value>
<value type="string">DISARM</value>
<value type="string">OFF</value>
</binding>

=== property-interpolate ===
Interpolates to a value with a given rate of change (per second).
<syntaxhighlight lang="xml">
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<value type="double">0</value>
<rate>0.5</rate>
</binding>
</syntaxhighlight>

Instead of using <rate>, one could use <time>, to specify the time (in seconds) it takes to go to the new value, independent of the current value.
<syntaxhighlight lang="xml">
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<value type="double">0</value>
<time>2</time>
</binding>
</syntaxhighlight>

You can also interpolate to a value given by a property.
<syntaxhighlight lang="xml">
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<property>/controls/flight/default-aileron-trim</property>
<rate>0.5</rate>
</binding>
</syntaxhighlight>

=== property-multiply ===
Multiply the value of a property by a given factor.
<binding>
<command>property-multiply</command>
<property>/controls/flight/aileron</property>
<factor>0.5</factor>
<min>-1</min>
<max>1</max>
<mask>all</mask>
<wrap>true</wrap>
</binding>
*'''factor:''' the amount to multiply by.
*'''min:''' minimum value.
*'''max:''' maximum value.
*'''mask:'''
** '''integer:''' mutiply only left of the decimal point.
** '''decimal:''' multiply only the right of the decimal point.
** '''all:''' multiply the entire value.
*'''wrap:''' true if the value should be wrapped if it passes min/max. It is required to set both min and max in that case.

=== property-randomize ===
Assigns a random value (between min and max) to a property.
<binding>
<command>property-randomize</command>
<property>/orientation/pitch-deg</property>
<min>0</min>
<max>360</max>
</binding>

=== property-scale ===
Sett the value of a property based on an axis, often used in [[joystick]] configuration files.
<binding>
<command>property-scale</command>
<property>/controls/flight/aileron</property>
<offset>0.001</offset>
<factor>-1</factor>
<power>3</power>
</binding>

* '''offset:''' the offset to shift by, before applying the factor.
* '''factor:''' the factor to multiply by (use negative to reverse).
* '''squared:''' if true will square the resulting value (same as power=2).
* '''power:''' the resulting value will be taken to the power of this integer value (overrides squared).

Remember: <tt>((property+offset)*factor)^power=result</tt>

=== property-swap ===
Swaps the values of two properties, useful for radio panels.
<binding>
<command>property-swap</command>
<property>/instrumentation/comm/frequencies/selected-mhz</property>
<property>/instrumentation/comm/frequencies/standby-mhz</property>
</binding>

=== property-toggle ===
Toggles the value of a property on each click, between true (1) and false (0).
<binding>
<command>property-toggle</command>
<property>/controls/gear/gear-down</property>
</binding>
Or - if defined - it toggles between two custom values.
<binding>
<command>property-toggle</command>
<property>/controls/gear/gear-down</property>
<value>2</value>
<value>3</value>
</binding>

== Related content ==
* <tt>[[$FG_ROOT]]/Docs/README.commands</tt> [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.commands view online]
* [[Howto: Make a clickable panel]]

[[Category:Development]]

Bindings

2013-05-05T08:42:42Z

AndersM: /* property-multiply */ property-interpolate

'''Bindings''' define what happens when a user:
* [[Howto: Make a clickable panel#Pick|clicks an object]] in the [[scenery]] or an [[aircraft]]
* press a key on the keyboard or [[joystick]]
* clicks a [[menu]] item
* click a buttons or fields in a dialog
You can assign multiple bindings to one object/button/key.

All give codes are examples, found on various places in the [[FlightGear]] package.

== Commands ==
=== dialog-close ===
Closes the active dialog.
<binding>
<command>dialog-close</command>
</binding>

=== dialog-show ===
Shows a dialog, which should be present in <tt>[[$FG ROOT]]/gui/dialogs</tt>. Starting with FlightGear 2.7 dialog files located in <tt><Current aircraft directory>/gui/dialogs</tt> are also loaded. This should be used for dialogs specific to a certain aircraft.
<binding>
<command>dialog-show</command>
<dialog-name>location-in-air</dialog-name>
</binding>
* '''dialog-name:''' the name of the dialog, as designated in its .xml file.

=== nasal ===
[[Nasal]] is frequently used for complicated systems.
<binding>
<command>nasal</command>
<script>b777.afds.input(0,1);</script>
</binding>

=== property-adjust ===
Increases or decreases a property's value with a given step. Maximum and minimum values are optional.
<binding>
<command>property-adjust</command>
<property>/controls/lighting/panel-norm</property>
<step>-0.05</step>
<min>0</min>
<max>1</max>
</binding>

=== property-assign ===
One of the most important commands. It sets a property to a predefined value.
<binding>
<command>property-assign</command>
<property>/autopilot/settings/target-speed-kt</property>
<value>0</value>
</binding>

=== property-cycle ===
Cycles between a list of values and assigns one to a property. The value-list can vary in length. If the current value is "value1", it will change to "value2"; if it is "value2", it will change to "value3", and so on, wrapping around the end. If the current value is not in the list, it will jump to the first one.
<binding>
<command>property-cycle</command>
<property>/autopilot/autobrake/setting</property>
<value type="string">ARM</value>
<value type="string">DISARM</value>
<value type="string">OFF</value>
</binding>

=== property-interpolate ===
Interpolates to a value with a given rate of change.
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<value type="double">0</value>
<rate>0.5</rate>
</binding>

You can also interpolate to a value given by a property.
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<property>/controls/flight/default-aileron-trim</property>
<rate>0.5</rate>
</binding>

=== property-multiply ===
Multiply the value of a property by a given factor.
<binding>
<command>property-multiply</command>
<property>/controls/flight/aileron</property>
<factor>0.5</factor>
<min>-1</min>
<max>1</max>
<mask>all</mask>
<wrap>true</wrap>
</binding>
*'''factor:''' the amount to multiply by.
*'''min:''' minimum value.
*'''max:''' maximum value.
*'''mask:'''
** '''integer:''' mutiply only left of the decimal point.
** '''decimal:''' multiply only the right of the decimal point.
** '''all:''' multiply the entire value.
*'''wrap:''' true if the value should be wrapped if it passes min/max. It is required to set both min and max in that case.

=== property-randomize ===
Assigns a random value (between min and max) to a property.
<binding>
<command>property-randomize</command>
<property>/orientation/pitch-deg</property>
<min>0</min>
<max>360</max>
</binding>

=== property-scale ===
Sett the value of a property based on an axis, often used in [[joystick]] configuration files.
<binding>
<command>property-scale</command>
<property>/controls/flight/aileron</property>
<offset>0.001</offset>
<factor>-1</factor>
<power>3</power>
</binding>

* '''offset:''' the offset to shift by, before applying the factor.
* '''factor:''' the factor to multiply by (use negative to reverse).
* '''squared:''' if true will square the resulting value (same as power=2).
* '''power:''' the resulting value will be taken to the power of this integer value (overrides squared).

Remember: <tt>((property+offset)*factor)^power=result</tt>

=== property-swap ===
Swaps the values of two properties, useful for radio panels.
<binding>
<command>property-swap</command>
<property>/instrumentation/comm/frequencies/selected-mhz</property>
<property>/instrumentation/comm/frequencies/standby-mhz</property>
</binding>

=== property-toggle ===
Toggles the value of a property on each click, between true (1) and false (0).
<binding>
<command>property-toggle</command>
<property>/controls/gear/gear-down</property>
</binding>
Or - if defined - it toggles between two custom values.
<binding>
<command>property-toggle</command>
<property>/controls/gear/gear-down</property>
<value>2</value>
<value>3</value>
</binding>

== Related content ==
* <tt>[[$FG_ROOT]]/Docs/README.commands</tt> [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.commands view online]
* [[Howto: Make a clickable panel]]

[[Category:Development]]

Aircraft systems

2013-05-01T18:32:48Z

AndersM: some corrections

Almost all aircraft needs systems of different kinds. Eg. fuel electric, vacuum, hydraulic.

By default an aircraft is supplied with generic systems defined in [https://gitorious.org/fg/fgdata/blobs/master/Aircraft/Generic/generic-systems.xml generic-systems.xml]. The workings of these systems are hard-coded in c++. See the [https://gitorious.org/fg/flightgear/trees/next/src/Systems source code].

Flightgear also has standard implementations of different common aircraft instruments and avionics. These creates useful output properties, found under instrumentation in the property tree. These properties can be used either by directly adding the generic instruments available in Aircraft/Instruments-3d or as input to your own instruments. Many of the standard instrument implementations depend on system properties to work. A list of dependencies are found [[System dependent instruments|here]].

=== Electric ===
The hard-coded electric system implementation is considered deprecated but are still used in many aircrafts. A xml configuration file is used. The generic electrical system configuration is based on that of a small single engine aircraft. For information on configuration see [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.electrical README.electrical] provided in the Doc folder.
As an alternative you can build a Nasal based system.

Here are two engines for Nasal-based electric systems:

Buckaroo's: [http://www.buckarooshangar.com/flightgear/electrical_1.html A Nasal-Based Electrical System for Flightgear]

AndersM's: [[Howto:A system engine in Nasal]]

=== Fuel ===
No hard-coded fuel system is available. The flight dynamics model (FDM) is used for that. For JSBSim based aircrafts you can make fuel systems integrated in the FDM. See [[Howto:Write a fuel system in JSBSim]].

=== Hydraulic ===
No hard-coded hydraulic system is available. For JSBSim based aircrafts you can make hydraulic systems integrated in the FDM.

=== Pitot ===
The hard-coded pitot system is a simple system with two output properties, total-pressure-inhg and measured-total-pressure-inhg.

=== Static ===
The hard-coded static pressure system is a simple system with one output property, pressure-inhg.

=== Vacuum ===
The hard-coded vacuum has one output propery: suction-inhg. This property is used to drive gyros needed in the standard instrument implementation. The generic implementation is based on a piston-engine and the vacuum depends on the engine's rpm:

<pre>
<rpm>/engines/engine[1]/rpm</rpm>
<scale>1.0</scale>
</pre>

You can set another property as source for the vacuum. If rpm times factor is greater than approx. 500 you will have fully functional gyros at all (reasonable) altitudes. Eg using an electric output to drive the gyro vacuum:

<pre>
<rpm>systems/electrical/outputs/inst_ac</rpm>
<scale>50.0</scale>
</pre>

[[Category:Aircraft enhancement]]

Aircraft systems

2013-05-01T14:45:35Z

AndersM: Info on systems

Almost all aircraft needs systems of different kinds. Eg. fuel electric, vacuum, hydraulic.

By default an aircraft is supplied with generic systems defined in [https://gitorious.org/fg/fgdata/blobs/master/Aircraft/Generic/generic-systems.xml generic-systems.xml]. The workings of these systems are hard-coded in c++. See the [https://gitorious.org/fg/flightgear/trees/next/src/Systems source code].

Flightgear also has standard implementations of different common aircraft instruments and avionics. These creates useful output properties, found under instrumentation in the property tree, that can be used either by directly adding the generic instruments available in Aircraft/Instruments-3d or as input to your own instruments. Many of these standard instrument implementations are dependent on system properties to work. A list of dependencies are found [[System dependent instruments|here]].

=== Electric ===
The standard electric system implementation is considered deprecated but are still used in many aircrafts. A xml configuration file is used. The generic electrical system configuration is based on that of a small single engine aircraft. For information on configuration see [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.electrical README.electrical] provided in the Doc folder.
As an alternative you can build a Nasal based system.

Here are two engines for Nasal-based electric systems:

Buckaroo's: [http://www.buckarooshangar.com/flightgear/electrical_1.html A Nasal-Based Electrical System for Flightgear]

AndersM's: [[Howto:A system engine in Nasal]]

=== Fuel ===
For JSBSim based aircrafts you can make fuel systems integrated in the FDM. See [[Howto:Write a fuel system in JSBSim]].

=== Hydraulic ===
No standard hydraulic system is available. For JSBSim based aircrafts you can make hydraulic systems integrated in the FDM.

=== Pitot ===
A simple system with two output properties, total-pressure-inhg and measured-total-pressure-inhg.

=== Static ===
A simple system with one output property, pressure-inhg.

=== Vacuum ===
Vacuum has one output propery: suction-inhg. This property is used to drive gyros needed in the standard instrument implementation. The generic implementation is based on a piston-engine and the vacuum depends on the engine's rpm:

<pre>
<rpm>/engines/engine[1]/rpm</rpm>
<scale>1.0</scale>
</pre>

You can set another property as source for the vacuum. If rpm times factor is greater than approx. 500 you will have fully functional gyros at all (resonable) altitudes. Eg using an electric output to drive the gyro vacuum:

<pre>
<rpm>systems/electrical/outputs/inst_ac</rpm>
<scale>50.0</scale>
</pre>

[[Category:Aircraft enhancement]]

Scripted Compilation on Linux Debian/Ubuntu

2013-04-28T06:01:38Z

AndersM: /* Download */ Note on repository change. Delete when script is changed.

==Description==
The following script takes care of downloading and compiling FlightGear from the git repositories with just one command execution for both 32-bit and 64-bit Debian based systems (Debian, Ubuntu). Pre-existing installed version (if any) of FlightGear are not touched at all since the script builds and installs everything under the directory in which it is launched. You can choose between building all or only specific tools and applications. For redhat-based systems (Fedora, CentOS) you may want to check out [[CentOS]].

Necessary packages are installed via the apt-get system while libraries not included in the repositories are downloaded and compiled on the fly (i.e. [[Plib]], [[Simgear]] and [[OSG]]).

For Hints on Using a RPM based distribution like CentOS, please see [[CentOS]]

=== Disk Space Requirements ===
As of 02/2013, this script will by at least require 24-30 gb of disk space, note that this includes the downloaded source trees and the build files, but also the fgdata checkout (which accounts approx. for 50% of the whole thing).

=== List of compiled programs ===
The script is able to download and compile:
* FlightGear (And all the data needed to use it)
* [[Fgrun]]
* [[FGCOM]]
* [[FGComGui]]
* [[FGo!]]
* [[FGX]]
* [[Atlas]]
* [[Terrasync]]
* [[FlightGear HLA support (High Level Architecture) | OpenRTI]]

Note that openRTI is just another optional dependency for HLA support: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)

For the time being, you should be just fine building without HLA support. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it's probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.

==== Updated list of programs compilation status ====
Keeping in mind that this script compiles bleeding edge software versions, using latest debian derivered distros, it can happen that the program that was successfully compiling last week, today does not.<BR/>
This is a list of what does and does not compile as much updated as possible.<BR>
Date: 19 November 2012
* FlightGear ... OK
* [[Fgrun]] ... OK
* [[FGCOM]] ... OK
* [[FGComGui]] ... OK
* [[FGo!]] ... OK
* [[FGX]] ... OK
* [[Atlas]] ... COMPILATION ERROR
* [[Terrasync]] ... OK
* [[FlightGear HLA support (High Level Architecture) | OpenRTI]] ... OK

== Download ==
You can download the script here:
* Primary site: [http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh download_and_compile.sh]
* Mirror: [http://assistenza.larasrl.net/brisa/fgfs/download_and_compile.sh download_and_compile.sh]

'''Note''' 28/4-13: A change in address to OpenSceneGraph svn must be done before running the script. Se [http://www.flightgear.org/forums/viewtopic.php?p=182239#p182239 Flightgear forum] for more information.

The script is maintained in the FlightGear main repository. Remember to update this script whenever a new FlightGear version is released, so that you'll be able to download the latest stable revision.

There is also another option for building FlightGear and all its dependencies in an automated fashion, please refer to: http://geoffmclane.com/fg/fgfs-052.htm

== Instructions ==
To run download_and_compile.sh, just save it in a directory called for example: ~/fgfs
then execute it (no need to execute it as root).

Here is for example a sequence of commands to get the script:
<pre>
mkdir ~/fgfs
cd ~/fgfs
wget http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh
chmod 755 download_and_compile.sh
</pre>

You have two options now: build the latest ''stable'' FlightGear release or build the ''current development'' version (bleeding edge).

=== Build the latest stable FlightGear release ===
When executing the script, use the "-s" option to build the latest stable release:
<pre>
./download_and_compile.sh -s
</pre>

=== Build the current FlightGear development version ===
When executing the script without any option, the latest development version is built.

'''Warning''': The development version changes on an almost daily basis. It provides the latest features, but is not always guaranteed to work reliably. If you're unfamiliar with software testing, you may prefer to use the latest stable release.

<pre>
./download_and_compile.sh
</pre>

Once the script is finished, you will successfully get Flightgear and Fgrun installed in the ~/fgfs directory.

=== Launching FlightGear ===
When using brisa's script, the various FG dependencies/libs are usually not installed system-wide, but in a custom location (that makes it possible, to easily use different OSG/SG/FG versions on a single system, i.e. for testing purposes - but also to have separate build trees (optimized/debug) ) - which is why you either need to set LD_LIBRARY_PATH or simply use Brisa's script to run everything (something like run_fgfs.sh, which automatically sets up all environment variables according to your build settings).

To run your new git installation of FlightGear you have to launch the ''run_fgfs.sh'' command under the same folder, for example:
<pre>
cd ~/fgfs
sh run_fgfs.sh
</pre>

=== Launching Fgrun ===
[[File:fgrun-page2.jpg|thumb|right]]
For many users it's more comfortable having FlightGear launched by the graphical utility Fgrun which is installed as well in the same folder. You have to launch the ''run_fgrun.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgrun.sh
</pre>

=== Launching Fgo! ===
[[File:Fgo01.jpg|thumb|left]]
This is a graphical utility written in [[python]], You have to launch the ''run_fgo.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgo.sh
</pre>
Remember that the first time you run it, you have to go to preferences and set the binary and fgdata path (Do no set the working directory, you don't need it).

== Additional programs ==
If you wish to get all the other programs, you need to launch the script adding the "ALL" option to the command line:
<pre>
./download_and_compile.sh ALL
</pre>
This, will also install FGCOM, FGComGui and Atlas

=== Launching FGCOM ===
FGCOM is the system used by FlightGear to simulate radio communications between users. Launch it using the ''run_fgcom.sh'' command:
<pre>
cd ~/fgfs
sh run_fgcom.sh -cs
</pre>

=== Launching FGComGui ===
FgComGui is a GUI wrapper to launch fgcom.
<pre>
cd ~/fgfs
sh run_fgcomgui.sh
</pre>

=== Launching Atlas ===
[[File:Atlas.jpg|thumb]]
Atlas provides a map for FlightGear, use it launching: ''run_atlas.sh''
<pre>
cd ~/fgfs
sh run_atlas.sh
</pre>

=== Launching Terrasync ===
Your FlightGear compilation comes with the Terrasync program too, so if you want to use it:
<pre>
cd ~/fgfs
sh run_terrasync.sh -S -p 5500 -d /folder/with/sceneries
</pre>
Where: ''/folder/with/sceneries'' is the folder containing the sceneries data.

Then launch fgfs with the '''--fg-scenery=/folder/with/sceneries --atlas=socket,out,5,localhost,5500,udp''' option

== Troubleshooting ==

=== Compilation errors ===
Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:
# Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
# The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
# One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only fgrun, fgcom or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

== Options ==
The script by default (without any option) will only compile FlightGear and Fgrun. To make it compile all, you need to launch the script with the ''ALL'' parameter. i.e.:
<pre>
./download_and_compile.sh ALL
</pre>

=== Compiling only one program ===
If you wish to recompile only one of the programs you can launch the script with one of the following parameters:
* PLIB (to compile and install only plib)
* OSG (to compile and install only OpenSceneGraph)
* SIMGEAR (to compile and install only Simgear)
* FGFS (to compile and install only FlightGear)
* DATA (to download / update only data files for FlightGear)
* FGRUN (to compile and install only Fgrun)
* FGO (to compile and install only Fgo!)
* FGCOM (to compile and install only Fgcom)
* FGCOMGUI (to compile and install only FgComGui)
* ATLAS (to compile and install only Atlas)

=== Fast updating ===
There is a second parameter ''UPDATE'' that allows you to just update your installation. i.e.:
This will only update FGFS
<pre>
./download_and_compile.sh FGFS UPDATE
</pre>

=== Compiling last stable versions (Experimental) ===
Even if the script fetches data and sources from bleeding edge developers repositories (which sometimes do not compile), you can still force the script to download latest known versions of the software that were compiling successfully by adding the -s option.
<pre>
./download_and_compile.sh -s
</pre>

How does it work? Inside the script there is a small list with latest known versions of successfully compiling revisions, it will download from svn/git those specific revisions, which have been found able to compile together.<BR/>
Warning: If you run this option inside a folder where you previously compiled fgfs, it will probably fail to compile, you better run the script with this option inside an empty folder or a folder whith the same fgfs version compiled previously.

=== Advanced options ===
* Skip download of packages using '''-p n''' option
* Skip compilation of programs using '''-c n''' option
* Skip retrieving software updates using '''-d n''' option
* Skip reconfigure (make clean) using '''-r n''' option

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear do this:
<pre>
./download_and_compile.sh -p n -d n -r n FGFS
</pre>

this will only recompile modifications and reinstall them.

=== Multicore Acceleration ===
Using the option '''-j x''' (where x is the number of your CPU-Cores you wish to assign to the job) will speed up the whole compilation process considerably.

== Disk usage ==
Having both compiled program, source code, and data from git requires some hard disk space: It will take something like 13 GB of space.
If you don't have a fast machine, it will require several hours of compilation time.

== Optimus technology ==
If your computer has a GPU with optimus technology, you need a dedicated script in order to make FG running with the powerful GPU.

After having installed required tools (Bumblebee) you just need to run this command line in your FG installation directory (where you executed ./download_and_compile.sh) :
<pre>
sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
</pre>
Now you can run FG with ./run_fgfs_optirun.sh

[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

Howto:A system engine in Nasal

2013-04-27T17:06:15Z

AndersM: More examples

This page describes an engine for aircraft systems, or rather for staging an impression of such a system. It doesn’t handle potentials, pressures or Kirchhoff's laws. It checks if switches are on or off and if minimum criterions are met.

The system is defined in a text-file with rows of entries, connections. Each connection is a comma separated list consisting of:
depends,limit,in,out,off,ramp

'''depends''': The output depends on the value of this property. Must be of type number or boolean.

'''limit''': A value or property that sets the lower limit. If depends is greater than limit then the state will be considered ''on''.

'''in''': A property or value if the state is on. If in is set to . the depends value is copied to out regardless of state.

'''out''': The output property. Set to in if the state is ''on'' and off if not.

'''off''': A value or property that out is set to if the state is ''off''.

'''ramp''': max change in out per second. Unlimited if 0.

=== Examples ===

An example:

<pre>
engines/engine[0]/n1,27,1,systems/electrical/generator_enabled,0,0
systems/electrical/generator_enabled,0,controls/electric/engine/generator,systems/electrical/generator_on,0,0
systems/electrical/generator_on,0,200,systems/electrical/outputs/main_ac,0,0
systems/electrical/generator_on,0,45,systems/electrical/outputs/inst_ac,0,0
systems/electrical/generator_on,0,29,systems/electrical/battery_voltage,24,0
controls/electric/battery-switch,0,systems/electrical/battery_voltage,systems/electrical/outputs/battery,0,0
systems/electrical/outputs/battery,0,systems/electrical/outputs/main_ac,systems/electrical/outputs/fuel,0,0
systems/electrical/battery_voltage,0,.,systems/electrical/outputs/comm[0],0,0
systems/electrical/outputs/battery,0,.,systems/electrical/outputs/turn-coordinator,0,0
systems/electrical/outputs/battery,0,.,systems/electrical/outputs/nav[0],0,0
systems/electrical/outputs/battery,0,.,systems/electrical/outputs/gps,0,0
systems/electrical/outputs/inst_ac,0,.,systems/electrical/outputs/adf,0,0
</pre>

The first two rows creates a "and-effect". If n1 is larger than 27% and the generator cockpit switch is on, then the property systems/electrical/generator_on is set to 1 otherwise 0. This simulates an automatic disconnect of the generator at engine start or stop.

The next two rows sets the two AC circuits voltage. Both are fed by the generator.

The fifth row sets the battery voltage to 29 V if charged by the generator and 24 if not.

The next row simulates the main battery switch in the cockpit. The property systems/electrical/outputs/battery is the voltage of the main battery bus that feeds most instruments.

The seventh row is another "and-effect". The fuel measurement systems need both battery power and AC power to work.

The rest of the rows copies the main battery bus output to the properties needed for some of the [[System dependent instruments|standard FG instrument]] implementations.

To simulate pumps or other parts that takes time to go from one state to another ramp is useful:

<pre>
systems/electrical/outputs/main_ac,0,5,systems/hydraulic/pumps/pump1,0,2.5
</pre>

The above simulates the hydraulic pump1 go from 0 to 5 (or 5 to 0) in 2 seconds when the main AC is switched on (or off).

An "or-effect" can be created by combining two connections like this:

<pre>
systems/electrical/generator_on,0,200,systems/electrical/outputs/gen_ac,0,0
systems/electrical/emergency_gen_on,0,200,systems/electrical/outputs/main_ac,systems/electrical/outputs/gen_ac,0
</pre>

This makes the main AC bus supplied by either the generator or the emergency generator (or both).

=== The code ===

<syntaxhighlight lang="php">
# Potemkin system

# Connections
#dep: depends on this property.
#limit: value or property, lower limit for true. dep > limit eq. true
#in: input property eg. orientation/pitch-deg or number constant.
# Use . to copy dep value to out.
#out output property eg.instruments/ai/spin
#off: value if not dep true, can be a property to be read
#ramp: max change per second of out, 0 no limit

var Connection = {
new : func(cv) {
var m = {parents:[Connection] };
m.dep=cv[0];
m.limit=cv[1];
m.in=cv[2];
m.out=cv[3];
m.off=cv[4];
m.ramp=num(cv[5]);
return m;
},

};

var System_P = {

new : func(system_file) {
var m = {parents:[System_P] };
m.file=system_file;
m.connections = [];
m.verbose = 2;
m.running=0;
m.dt=0;
m.oldtime=0;
return m;
},

read_connections : func {
if (me.verbose > 0) print("Reading connections");
var fh = io.open(getprop("/sim/aircraft-dir")~"/"~me.file, "r");
var line="";
while (line != nil) {
line = io.readln(fh);
if (line != nil) {
var c_arr=split(",", line);
if (size(c_arr) == 6) {
append(me.connections, Connection.new(c_arr));
if (me.verbose > 1) print("Adding: "~line);
} else if (me.verbose > 1) print("Skipping: "~line);
}
}
io.close(fh);
if (me.verbose > 0) print("Read connections");
},

change_value : func(prop, value, ramp) {
if (ramp == 0) setprop(prop, value);
else {
var ov=num(getprop(prop));
if (ov<value and value-ov > ramp*me.dt) setprop(prop, ov+ramp*me.dt);
else if (ov>value and ov-value > ramp*me.dt) setprop(prop, ov-ramp*me.dt);
else setprop(prop, value);
}
},

update : func {
if (!me.running) return;
var time=getprop("/sim/time/elapsed-sec");
me.dt= time-me.oldtime;
foreach (con; me.connections) {
dp=getprop(con.dep);
if (dp != nil) {
if (num(con.limit) != nil) limit=num(con.limit); else limit=getprop(con.limit);
if (con.in == ".") me.change_value(con.out, dp, con.ramp); #copy dep value to out
else if (dp <= limit) {
if (num(con.off) != nil) me.change_value(con.out, num(con.off), con.ramp);
else me.change_value(con.out, getprop(con.off), con.ramp);
} else {
if (num(con.in) != nil) me.change_value(con.out, num(con.in), con.ramp);
else me.change_value(con.out, getprop(con.in), con.ramp);
}
}
}
me.oldtime=time;
settimer( func me.update(), 0.05);
},

init : func {
me.read_connections();
foreach (con; me.connections) {
if (num(con.off) != nil) setprop(con.out, num(con.off));
else setprop(con.out, getprop(con.off));
}
me.running=1;
me.oldtime= getprop("/sim/time/elapsed-sec");
if (me.verbose > 0) print("Initialized system");
me.update();
},
};
</syntaxhighlight>

Use the system by first creating the system with a reference to the connection file and then init it, eg:

<syntaxhighlight lang="php">
var el = System_P.new("Systems/electric.txt");
el.init();
</syntaxhighlight>

[[Category:Aircraft enhancement|Systems]]
[[Category:Nasal howto]]

Howto:A system engine in Nasal

2013-04-27T14:03:42Z

AndersM: More text

This page describes an engine for aircraft systems, or rather for staging an impression of such a system. It doesn’t handle potentials, pressures or Kirchhoff's laws. It checks if switches are on or off and if minimum criterion’s are met.

The system is defined in a text-file with rows of entries, connections. Each connection consists of a comma separated list consisting of:
depends,limit,in,out,off,ramp

'''depends''': The output depends on the value of this property. Must be of type number or boolean.

'''limit''': A value or property that sets the lower limit. If depends is greater than limit then the state will be considered ''on''.

'''in''': A property or value if the state is on. If in is set to . the depends value is copied to out regardless of state.

'''out''': The output property. Set to in if the state is ''on'' and off if not.

'''off''': A value or property that out is set to if the state is ''off''.

'''ramp''': max change in out per second. Unlimited if 0.

An example:

<pre>
engines/engine[0]/n1,27,1,systems/electrical/generator_enabled,0,0
systems/electrical/generator_enabled,0,controls/electric/engine/generator,systems/electrical/generator_on,0,0
systems/electrical/generator_on,0,200,systems/electrical/outputs/main_ac,0,0
systems/electrical/generator_on,0,45,systems/electrical/outputs/inst_ac,0,0
systems/electrical/generator_on,0,29,systems/electrical/battery_voltage,24,0
controls/electric/battery-switch,0,systems/electrical/battery_voltage,systems/electrical/outputs/battery,0,0
systems/electrical/outputs/battery,0,systems/electrical/outputs/main_ac,systems/electrical/outputs/fuel,0,0
systems/electrical/battery_voltage,0,.,systems/electrical/outputs/comm[0],0,0
systems/electrical/outputs/battery,0,.,systems/electrical/outputs/turn-coordinator,0,0
systems/electrical/outputs/battery,0,.,systems/electrical/outputs/nav[0],0,0
systems/electrical/outputs/battery,0,.,systems/electrical/outputs/gps,0,0
systems/electrical/outputs/inst_ac,0,.,systems/electrical/outputs/adf,0,0
</pre>

The first two rows creates a "and-effect". If n1 is larger than 27% and the generator cockpit switch is on, then the property systems/electrical/generator_on is set to 1 otherwise 0. This simulates an automatic disconnect of the generator at engine start or stop.

The next two rows sets the two AC circuits voltage. Both are fed by the generator.

The fifth row sets the battery voltage to 29 V if charged by the generator and 24 if not.

The next row simulates the main battery switch in the cockpit. The property systems/electrical/outputs/battery is the voltage of the main battery bus that feeds most instruments.

The seventh row is another "and-effect". The fuel measurement systems need both battery power and AC power to work.

The rest of the rows copies the main battery bus output to the properties needed for some of the [[System dependent instruments|standard FG instrument]] implementations.

<syntaxhighlight lang="php">
# Potemkin system

# Connections
#dep: depends on this property.
#limit: value or property, lower limit for true. dep > limit eq. true
#in: input property eg. orientation/pitch-deg or number constant.
# Use . to copy dep value to out.
#out output property eg.instruments/ai/spin
#off: value if not dep true, can be a property to be read
#ramp: max change per second of out, 0 no limit

var Connection = {
new : func(cv) {
var m = {parents:[Connection] };
m.dep=cv[0];
m.limit=cv[1];
m.in=cv[2];
m.out=cv[3];
m.off=cv[4];
m.ramp=num(cv[5]);
return m;
},

};

var System_P = {

new : func(system_file) {
var m = {parents:[System_P] };
m.file=system_file;
m.connections = [];
m.verbose = 2;
m.running=0;
m.dt=0;
m.oldtime=0;
return m;
},

read_connections : func {
if (me.verbose > 0) print("Reading connections");
var fh = io.open(getprop("/sim/aircraft-dir")~"/"~me.file, "r");
var line="";
while (line != nil) {
line = io.readln(fh);
if (line != nil) {
var c_arr=split(",", line);
if (size(c_arr) == 6) {
append(me.connections, Connection.new(c_arr));
if (me.verbose > 1) print("Adding: "~line);
} else if (me.verbose > 1) print("Skipping: "~line);
}
}
io.close(fh);
if (me.verbose > 0) print("Read connections");
},

change_value : func(prop, value, ramp) {
if (ramp == 0) setprop(prop, value);
else {
var ov=num(getprop(prop));
if (ov<value and value-ov > ramp*me.dt) setprop(prop, ov+ramp*me.dt);
else if (ov>value and ov-value > ramp*me.dt) setprop(prop, ov-ramp*me.dt);
else setprop(prop, value);
}
},

update : func {
if (!me.running) return;
var time=getprop("/sim/time/elapsed-sec");
me.dt= time-me.oldtime;
foreach (con; me.connections) {
dp=getprop(con.dep);
if (dp != nil) {
if (num(con.limit) != nil) limit=num(con.limit); else limit=getprop(con.limit);
if (con.in == ".") me.change_value(con.out, dp, con.ramp); #copy dep value to out
else if (dp <= limit) {
if (num(con.off) != nil) me.change_value(con.out, num(con.off), con.ramp);
else me.change_value(con.out, getprop(con.off), con.ramp);
} else {
if (num(con.in) != nil) me.change_value(con.out, num(con.in), con.ramp);
else me.change_value(con.out, getprop(con.in), con.ramp);
}
}
}
me.oldtime=time;
settimer( func me.update(), 0.05);
},

init : func {
me.read_connections();
foreach (con; me.connections) {
if (num(con.off) != nil) setprop(con.out, num(con.off));
else setprop(con.out, getprop(con.off));
}
me.running=1;
me.oldtime= getprop("/sim/time/elapsed-sec");
if (me.verbose > 0) print("Initialized system");
me.update();
},
};
</syntaxhighlight>

Howto:A system engine in Nasal

2013-04-27T13:14:46Z

AndersM: More text

This page describes an engine for aircraft systems, or rather for staging an impression of such a system. It doesn’t handle potentials, pressures or Kirchhoff's laws. It checks if switches are on or off and if minimum criterion’s are met.

The system is defined in a text-file with rows of entries, connections, each connection consists of a comma separated list consisting of:
depends,limit,in,out,off,ramp

'''depends''': The output depends on the value of this property. Must be of type number or boolean.

'''limit''': A value or property that sets the lower limit. If depends is greater than limit then the state will be considered ''on''.

'''in''': A property or value if the state is on. If in is set to . the depends value is copied to out regardless of state.

'''out''': The output property. Set to in if the state is ''on'' and off if not.

'''off''': A value or property that out is set to if the state is ''off''.

'''ramp''': max change in out per second. Unlimited if 0.

An example:

<pre>
engines/engine[0]/n1,27,1,systems/electrical/generator_enabled,0,0
systems/electrical/generator_enabled,0,controls/electric/engine/generator,systems/electrical/generator_on,0,0
systems/electrical/generator_on,0,200,systems/electrical/outputs/main_ac,0,0
systems/electrical/generator_on,0,45,systems/electrical/outputs/inst_ac,0,0
systems/electrical/generator_on,0,29,systems/electrical/battery_voltage,24,0
controls/electric/battery-switch,0,systems/electrical/battery_voltage,systems/electrical/outputs/battery,0,0
systems/electrical/battery_voltage,0,.,systems/electrical/outputs/comm[0],0,0
systems/electrical/outputs/battery,0,systems/electrical/outputs/main_ac,systems/electrical/outputs/fuel,0,0
systems/electrical/outputs/battery,0,.,systems/electrical/outputs/turn-coordinator,0,0
systems/electrical/outputs/battery,0,.,systems/electrical/outputs/nav[0],0,0
systems/electrical/outputs/battery,0,.,systems/electrical/outputs/gps,0,0
systems/electrical/outputs/inst_ac,0,.,systems/electrical/outputs/adf,0,0
</pre>

<syntaxhighlight lang="php">
# Potemkin system

# Connections
#dep: depends on this property.
#limit: value or property, lower limit for true. dep > limit eq. true
#in: input property eg. orientation/pitch-deg or number constant.
# Use . to copy dep value to out.
#out output property eg.instruments/ai/spin
#off: value if not dep true, can be a property to be read
#ramp: max change per second of out, 0 no limit

var Connection = {
new : func(cv) {
var m = {parents:[Connection] };
m.dep=cv[0];
m.limit=cv[1];
m.in=cv[2];
m.out=cv[3];
m.off=cv[4];
m.ramp=num(cv[5]);
return m;
},

};

var System_P = {

new : func(system_file) {
var m = {parents:[System_P] };
m.file=system_file;
m.connections = [];
m.verbose = 2;
m.running=0;
m.dt=0;
m.oldtime=0;
return m;
},

read_connections : func {
if (me.verbose > 0) print("Reading connections");
var fh = io.open(getprop("/sim/aircraft-dir")~"/"~me.file, "r");
var line="";
while (line != nil) {
line = io.readln(fh);
if (line != nil) {
var c_arr=split(",", line);
if (size(c_arr) == 6) {
append(me.connections, Connection.new(c_arr));
if (me.verbose > 1) print("Adding: "~line);
} else if (me.verbose > 1) print("Skipping: "~line);
}
}
io.close(fh);
if (me.verbose > 0) print("Read connections");
},

change_value : func(prop, value, ramp) {
if (ramp == 0) setprop(prop, value);
else {
var ov=num(getprop(prop));
if (ov<value and value-ov > ramp*me.dt) setprop(prop, ov+ramp*me.dt);
else if (ov>value and ov-value > ramp*me.dt) setprop(prop, ov-ramp*me.dt);
else setprop(prop, value);
}
},

update : func {
if (!me.running) return;
var time=getprop("/sim/time/elapsed-sec");
me.dt= time-me.oldtime;
foreach (con; me.connections) {
dp=getprop(con.dep);
if (dp != nil) {
if (num(con.limit) != nil) limit=num(con.limit); else limit=getprop(con.limit);
if (con.in == ".") me.change_value(con.out, dp, con.ramp); #copy dep value to out
else if (dp <= limit) {
if (num(con.off) != nil) me.change_value(con.out, num(con.off), con.ramp);
else me.change_value(con.out, getprop(con.off), con.ramp);
} else {
if (num(con.in) != nil) me.change_value(con.out, num(con.in), con.ramp);
else me.change_value(con.out, getprop(con.in), con.ramp);
}
}
}
me.oldtime=time;
settimer( func me.update(), 0.05);
},

init : func {
me.read_connections();
foreach (con; me.connections) {
if (num(con.off) != nil) setprop(con.out, num(con.off));
else setprop(con.out, getprop(con.off));
}
me.running=1;
me.oldtime= getprop("/sim/time/elapsed-sec");
if (me.verbose > 0) print("Initialized system");
me.update();
},
};
</syntaxhighlight>

Howto:A system engine in Nasal

2013-04-27T12:19:20Z

AndersM: Started on the article

This page describes an engine for aircraft systems, or rather for staging an impression of such a system. It doesn’t handle potentials, pressures or Kirchhoff's laws. It checks if switches are on or off and if minimum criterion’s are met.

<syntaxhighlight lang="php">
# Potemkin system

# Connections
#dep: depends on this property.
#limit: lower limit for true. dep > limit eq. true
#in: input property eg. orientation/pitch-deg or number constant.
# Use . to copy dep value to out.
#out output property eg.instruments/ai/pitch-deg
#off: value if not dep true, can be a property to be read
#ramp: max change per second of out, 0 no limit

var Connection = {
new : func(cv) {
var m = {parents:[Connection] };
m.dep=cv[0];
m.limit=cv[1];
m.in=cv[2];
m.out=cv[3];
m.off=cv[4];
m.ramp=num(cv[5]);
return m;
},

};

var System_P = {

new : func(system_file) {
var m = {parents:[System_P] };
m.file=system_file;
m.connections = [];
m.verbose = 2;
m.running=0;
m.dt=0;
m.oldtime=0;
return m;
},

read_connections : func {
if (me.verbose > 0) print("Reading connections");
var fh = io.open(getprop("/sim/aircraft-dir")~"/"~me.file, "r");
var line="";
while (line != nil) {
line = io.readln(fh);
if (line != nil) {
var c_arr=split(",", line);
if (size(c_arr) == 6) {
append(me.connections, Connection.new(c_arr));
if (me.verbose > 1) print("Adding: "~line);
} else if (me.verbose > 1) print("Skipping: "~line);
}
}
io.close(fh);
if (me.verbose > 0) print("Read connections");
},

change_value : func(prop, value, ramp) {
if (ramp == 0) setprop(prop, value);
else {
var ov=num(getprop(prop));
if (ov<value and value-ov > ramp*me.dt) setprop(prop, ov+ramp*me.dt);
else if (ov>value and ov-value > ramp*me.dt) setprop(prop, ov-ramp*me.dt);
else setprop(prop, value);
}
},

update : func {
if (!me.running) return;
var time=getprop("/sim/time/elapsed-sec");
me.dt= time-me.oldtime;
foreach (con; me.connections) {
dp=getprop(con.dep);
if (dp != nil) {
if (con.in == ".") me.change_value(con.out, dp, con.ramp); #copy dep value to out
else if (dp <= con.limit) {
if (num(con.off) != nil) me.change_value(con.out, num(con.off), con.ramp);
else me.change_value(con.out, getprop(con.off), con.ramp);
} else {
if (num(con.in) != nil) me.change_value(con.out, num(con.in), con.ramp);
else me.change_value(con.out, getprop(con.in), con.ramp);
}
}
}
me.oldtime=time;
settimer( func me.update(), 0.05);
},

init : func {
me.read_connections();
foreach (con; me.connections) {
if (num(con.off) != nil) setprop(con.out, num(con.off));
else setprop(con.out, getprop(con.off));
}
me.running=1;
me.oldtime= getprop("/sim/time/elapsed-sec");
if (me.verbose > 0) print("Initialized system");
me.update();
},
};
</syntaxhighlight>

Howto:Write a fuel system in JSBSim

2013-04-24T08:55:36Z

AndersM: /* Spitfire: Carburetor engine */ Explaining text

Howto:Write a fuel system in JSBSim

2013-04-23T13:48:55Z

AndersM: /* Examples */ Spitfire

Frequently asked questions

2013-04-20T07:26:26Z

AndersM: /* Starting engine in single-engine aircraft */

Thank you for downloading [[FlightGear]]! This '''FAQ''' lists some of the most commonly asked questions. Please create a topic at [http://flightgear.org/forums our forum] if you cannot find the answer on your problem(s).

== The FAQ ==
=== Where can I get the latest version of this FAQ? ===
http://wiki.flightgear.org/index.php/FAQ

=== Who do I contact if I have comments about this FAQ? ===
Add your comment to this FAQ's [[Talk:Frequently asked questions|discussion page]].

=== How old is this document? ===
Check its <span class="plainlinks">[{{fullurl:{{PAGENAME}}|action=history}} history]</span>.

=== What other important documentation should I read? ===
* [http://flightgear.org/Docs/getstart/getstart.html Getting Started Guide]
* [[New to FlightGear]]
* Also see the FlightGear/docs-mini/ directory in the source distribution for various other helpful documents.
* Also see the other [http://www.flightgear.org/Docs/FAQ.shtml FAQ]

== Distribution ==
=== Where can I get FlightGear? ===
The official download page is http://www.flightgear.org/download/. Source code is our primary form of distribution, but precompiled binaries are available for Windows and SGI IRIX.

Alternatively, FlightGear is packaged for Linux by SuSE, Debian and Mandrake, and can be directly installed through those distributions via any package manager.

=== How do I install FlightGear on Ubuntu? ===
FlightGear 2.0.0 can be installed directly from the Synaptic Package Manager for Ubuntu 11.04 onwards. Open Synaptic Package Manager, search for FlightGear and follow instructions.
FlightGear 2.4.0 is available as a [http://www.getdeb.net/welcome/ GetDeb] package for Ubuntu 11.04 onwards. Install GetDeb on your Ubuntu machine and install FlightGear from [http://www.playdeb.net/updates/ubuntu/11.04/?q=flightgear PlayDeb]'s website.

=== What is the password for the FTP server? ===
The FTP server uses standard anonymous login procedures. Login with the username "anonymous" and use your email address as the password. Most FTP clients and web browsers will do this automatically for you.

=== Why won't the FTP server let me in with the right login info? ===
This generally means that the server is at its capacity. You should receive a message saying such, but your FTP client may be hiding it from you. Your options are to keep trying until a slot opens up or try connecting to one of our FTP mirrors listed at http://www.flightgear.org/mirrors.html.

=== Where can I find the latest development source code? ===
{{Main article|Flightgear and Git}}
The latest development code is available for everyone through our Git [http://gitorious.org/fg repository].

=== Why are the aircraft at FlightGear.org out of date? ===
The [http://www.flightgear.org/download/aircraft-v2-4/ official aircraft downloads] are only updated at the time of a new release of FlightGear. This is done because aircraft that are currently in development are usually developed on development/unreleased versions of FlightGear. Those development versions have lots of features that are not supported by the (older) stable release. Would we update the aircraft downloads more often; most aircraft won't work on the stable release of FlightGear.

=== What is SimGear, and why do I need it? ===
[[SimGear]] is a library of supporting code. SimGear is only needed if you plan on compiling FlightGear — it is not needed to run precompiled binaries. For more information see http://www.simgear.org/. Note: When compiling FlightGear it is very important to have the matching version of SimGear.

=== Where can I fly and where do I get the scenery? ===
While the base package only comes with scenery for the San Francisco Bay area, you can currently fly just about anywhere in the world. See the "Additional Scenery" section of http://www.flightgear.org/download/ for more information or go directly to our graphical downloader at http://www.flightgear.org/Downloads/scenery-1.0.1.html

[[Terrasync]] is an option too. It downloads the latest scenery while flying. In 2.4.0 a GUI for enabling/disabing Terrasync can be found at Environment->Scenery Download.

Also visit our "Places to Fly" section of the website (http://www.flightgear.org/places.html) for some help navigating to some awesome locations. (see also [[Installing Scenery]])

=== Where can I get different 3D models for my plane? ===
Official FlightGear aircraft can be found at http://www.flightgear.org/download/aircraft-v2-4/ . Other aircraft in development can be found on [[Git]], and some other aircraft can be found on 3rd party [[FlightGear hangars]].

=== How current is the data in FlightGear compared to the real world? ===
We use the same navaid and airport dataset that X-Plane uses. The current dataset can be found in the <tt>[[$FG ROOT]]/Navaids/</tt> and <tt>[[$FG ROOT]]/Airports/</tt> directories. If you have updates or corrections to the dataset, see http://www.flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html for instructions on contacting the database maintainer.

=== Where is the moving map? ===
A popular moving map display is available under a separate project called [[Atlas]]. Also, [[MPmap]] is an online map for multiplayer.

If you like an alternative to Atlas with updated graphics and mapping provided by the OpenStreetMap project, then check out Flightgear Mapping [http://rubyforge.org/projects/fgmap fgmapping] or [[JMapView]].

=== Why don't you charge money for this? ===
FlightGear can be downloaded for free from many locations including the FlightGear website, but can also be bought on a CD. Although we offer that service (see the website), we encourage other groups to redistribute it for their users, especially within an operating system distribution which makes installation even faster and easier for new users.

Occasionally you may see FlightGear for sale on auction sites or commercial websites under some other name. This can be done quite legitimately as long as the terms of the license are upheld and might be worth the cost if some value-added features such as additional scenery, aircraft or after-sale support are included. Unfortunately, most cases seen to date appear to be just someone trying to make money selling something that is free and providing no real added value.

=== How can I get started with FlightGear ===
The latest release of FlightGear can be downloaded at the [http://www.flightgear.org/download/ download central], but most [[aircraft]] need to be separately downloaded [http://www.flightgear.org/download/aircraft-v2-4/ here] and installed manually. Be aware of system requirements! Also, check out [[New to FlightGear]].

== Compiling ==
{{main article|Building Flightgear}}

=== Why won't FlightGear compile? ===
Well, that depends. First make sure you are using the appropriate versions of FlightGear, [[SimGear]], plib, zlib. If any of the packages are out of sync with the others, compilation may fail. See also [[Building FlightGear]]

The [http://www.flightgear.org/download/ FlightGear Downloads page] should tell you what versions you need if you are trying to compile the latest stable release. If you are using a development snapshot, make sure all three packages are up-to-date.

Also ensure that you have some implementation of OpenGL with glut support with the appropriate header files. Linux users with nVidia cards should make sure you have the latest drivers from nVidia. Other Linux users make sure you have Mesa3D (http://mesa3d.org/) and your X server installed correctly.

If your problems persist, ask in the [http://www.flightgear.org/forums FlightGear Forums], on the [[IRC]] or subscribe to our FlightGear-Users [[mailing list]] and let us know what problem you're having.

== Configuring ==
=== How do I install new scenery? ===
{{Main article|Howto: Install scenery}}
The scenery archive files (ie. w100n30.tar.gz) should be untarred into the Scenery/Terrain directory in your [[$FG_ROOT]].

=== How do I setup my joystick(s)? ===
{{Main article|Joystick}}
FlightGear should come with a helpful program called `fgjs` that can help configure your joystick. Run `fgjs` and then copy the dot file it created into your home directory or add its contents to your existing rc file.

Also, see the <tt>[[$FG_ROOT]]/Docs/README.Joystick</tt> file located in the FlightGear base package and the [[Joystick|joystick page]] on the wiki.

=== What format should my personal .fgfsrc file be in? ===
Your .fgfsrc file should simply be a list of [[Command Line Parameters|command line options]] with one option per line. The file is not an XML file.

If you would rather use an [[XML]] configuration file, you can add something like the following in your .fgfsrc

--config=/path/to/my/config.xml

Almost every option corresponds to a property, so you can choose to use whichever method best suits your needs.

== Running ==
If you get errors in the console (black window), please check [[Howto: Understand console output]] and see if your error is listed (with a solution).

=== Unable to execute file: bin/Win32/fgrun.exe during installation ===
Your system is missing the MSVC runtime libraries required by FlightGear.
Download and install the following vcredist_x86.exe:
* MSVC9 for FG2.4.0 (and earlier): http://www.microsoft.com/download/en/details.aspx?id=26368
* MSVC10 for FG2.6.0 (and later): http://www.microsoft.com/download/en/details.aspx?id=5555

=== Why do I get an error loading libopenal.so.0? ===
With the default installation, libopenal.so.0 is installed into /usr/local/lib. You need to ensure that that path is listed in /etc/ld.so.conf, then run `ldconfig`as root.

=== Why do I get "ssgInit called without a valid OpenGL context"? ===
In short, your GL libraries are broken. So far only Red Hat 7.x users have experienced this (see http://www.redhat.com/bugzilla/show_bug.cgi?id=18867). The only solutions are possibly complicated ones: you can either change distributions (most of us prefer Debian) or upgrade/downgrade your Mesa libs.

Why do some other GL applications work though? Well, Steve Baker (Mr. PLIB) has explained this on the plib-users list (http://www.geocrawler.com/lists/3/SourceForge/1867/0/6470648/).

=== What happened to the panel, keyboard, etc? ===
The problem is almost certainly that your base package is out of sync with FlightGear. Many configurable parts of FlightGear are defined in [[XML]] files contained in the base package.

=== Why doesn't audio work properly under Irix? ===
FlightGear (as of June 2001) uses the Portable Libraries ([[PLIB]]) for playing audio. The audio queue implementation of PLIB is far from optimal (in fact it's just wrong). This seems to work on other platforms quite well, but Irix expects things to be programmed properly.

There has been discussion about using OpenAL (http://www.openal.org/) for the next release of both PLIB and FlightGear. Tests show that the OpenAL audio implementation does the job right, meaning that these audio problems should be gone by then. In the mean time it is best to disable audio on Irix completely (by adding --disable-sound either on the command line or to your $HOME/.fgfsrc file).

=== Why is FlightGear so slow? ===
{{Main article|Howto: Improve Framerates}}
FlightGear supports hardware acceleration, but it seems not to be activated. Make sure you have OpenGL libraries installed and configured properly and make sure you have the latest drivers for your video card.

Linux users: If you are an nVidia user, follow their directions on getting your card working. For most other users, make sure Mesa is installed property and ensure that you have the appropriate kernel device drivers for your card. Most people (and distributions) use modules for their video card device drivers; run `lsmod` as root to see what modules are loaded. You should also make sure that you are loading the appropriate modules in your XF86Config and that your video device section is correct. Now try running an OpenGL application (other than FlightGear) to see how it performs. You can try the gears demo from Mesa or something like Quake3.

=== Why is my SGI machine so slow? ===
First of all, one of the most common mistakes on SGI hardware is to forget to specify --fog-fastest. On most SGI machines the EXP2 shading model isn't hardware supported resulting in frame rates below 1 frame per second (fps).

FlightGear makes extensive use of the OpenGL z-buffer feature,which on most older SGI hardware is only supported in software. This means that the CPU has to do all the z-buffer calculations in addition to the other tasks FlightGear involves (flight dynamics, scenery tracking, pushing commands into the graphics queue, etc). The following features are software rendered on low-end SGI machines (like Indy and Indigo):

* stencil and accumulation buffer
* depth queuing and depth buffering
* fogging, lighting, clipping and transforms
* texturing

This means that running FlightGear with the following options may not even get the desired result:

./runfgfs --fog-disable --shading-flat --disable-skyblend --disable-textures --disable-clouds --disable-sound --disable-panel --enable-hud --disable-anti-alias-hud

I could even imagine that adding --enable-wireframe doesn't work on these machines (I would be happy to be proven wrong though).

On a machine like O2 the following options give an acceptable result:
./runfgfs --fog-fastest --disable-sound

Since I don't have access to other SGI hardware I can't tell which options would be appropriate for your situation.

=== How do I see the Frame Rate? ===
On the in-sim [[menu]] select View > Display Options, then check the box that says "Show frame rate".

=== How do I toggle panel settings? ===
There are two ways. One way is to hide the panel without the HUD showing. To hide the panel, use Shift+P; To make the HUD disappear, use H. The second way is to use the alternative HUD by Shift+I (Use I to switch back).

=== Stuck upside down after "crash"? ===
In his infinite wisdom the FlightGear Grand Master decided that planes were too valuable to allow them to be destroyed by novice pilots who seemed to crash a lot. The fact that nobody has bothered to model crashes may have something to do with it too. :-)

The result of this as you have noticed is that with a little practice an ingenuity you can trim the ship to fly inverted along the ground. The quick answer is to reset the sim, via the <tt>File > Reset</tt> menu. This will place your aircraft back at its starting location.

For the stubborn people out there: The trick to learn is to roll back to normal (non inverted) do this by nursing the elevator to get to about 500 feet or so and use the ailerons to snap roll 180*. This is all good avionics except for the plane not destroying itself. Remember the controls work in reverse when you are inverted and keep that airspeed up!!!

=== Why does FlightGear die on startup saying "time zone reading failed"? ===
This is probably caused by a line-ending problem in the timezone files. Win32 users can resolve the problem by downloading a DOS to UNIX conversion utility available at http://www.nottingham.ac.uk/~eazdluf/d2u.zip. Run as `d2u *.tab` from within the timezone directory to fix your timezone files.

=== Why won't the latest versions of some aircraft work in my (older) version of FlightGear? ===
Often new aircraft development keeps pace with the latest FlightGear code development. New or newly modified aircraft may rely on files (such as new instrument files) or features, only available with newer versions of FlightGear. If you are stuck with an older version of FlightGear, you can try downloading an earlier version of the aircraft at one of the archives:
* [http://www.flightgear.org/Downloads/aircraft-1.9.1/index.shtml Aircraft for 1.9.1]
* [http://flightgear.org/Downloads/aircraft-2.0.0/ Aircraft for 2.0.0]
* [http://ftp.riken.go.jp/pub/FreeBSD/distfiles/flightgear-aircrafts/ Aircraft from various dates]

=== Why are my screenshots black? ===
Make sure you have multithreading disabled in <tt>[[$FG_ROOT]]/preferences.xml</tt>. Enabling it currently breaks the screenshot function.

== Flying ==
=== Why won't my engine(s) start? ===
Aircraft vary in their starting procedure. Some may have an auto-start sequence menu entry or instructions in the aircraft help menu (Press "?") and/or at [[Aircraft|the aircraft's wiki]].

==== Starting engine in single-engine aircraft ====
In general to start the engine on a piston-engine type aircraft, you need:

# Fuel - You can run out of fuel, of course, but for certain aircraft, FlightGear may load it with no fuel, making it impossible to start the engines. Check this in the menu <tt>Equipment > Fuel and Payload</tt>.
# Correct mixture (generally "rich", ie red knob all the way in)
# Magnetos on (R, L, or both--generally select "both")
# Throttle (some engines start better with a little gas)
# Hold starter for sufficient time.

You may be able to do all these functions with the standard 2-D panel or your aircraft's built-in panel. However using the standard key bindings is more reliable:

# Press/hold "m" to set mixture to rich (m=rich, M=lean--if you are at a very high elevation you may need to set it somewhere besides full rich)
# Press "}}}" (three times) to set magneto to R, L, and finally "Both".
# Open throttle a little.
# Press "s" to run the starter. For some aircraft you may have to hold "s" as long as 10 seconds before the engine starts.

These instructions may not work for jet aircraft, helicopters, or other types of aircraft with complex start procedures. Check the instructions in the aircraft help menu (Press "?") and/or at [[Aircraft|the aircraft's wiki]].

In general to start the engine on a jet engine type aircraft, you need to:

# Set cutoff ON
# Engage the starter
# Once the engines spools up to approximately 5% N1, set cutoff OFF
# Disengage the starter once the engine has reached operational speed

==== Starting engine in multi-engine aircraft ====
Starting all engines in a multi-engine aircraft is similar to the single engine--except you must follow the same start sequence for each and every engine. Flightgear provides a convenient way to do this for all engines at once.

Note that the default 2-D panel is connected to ''only one engine''. So if you try to start the engines using the 2-D panel controls you will most likely start only one engine.

Instead, use the keyboard to start all engines at once:

# Press "~" (select all engines)
# Press/hold "m" to set mixture to rich (m=rich, M=lean--if you are at a very high elevation you may need to set the mixture somewhere besides full rich)
# Press "}}}" (three times) to set magnetos to R, L, and finally "Both".
# Open throttle a little (it now controls all engines).
# Press "s" to run the starter (it now runs the starter on all engines). For some aircraft you may have to hold "s" as long as 10 seconds before the engine starts.
# Rev the engines a little with your throttle and check your tachometers and/or visually to be sure all engines are running.

If the engines won't start, make sure you have fuel. Some aircraft have switches to control which fuel tanks feed which engines, so check these. Make sure each engine you want to start is connected to a tank that has fuel. Check fuel tanks in the menu <tt>Equipment > Fuel and Payload</tt>.

These instructions may not work for jet aircraft, helicopters, or other types of aircraft with complex start procedures. Check the instructions in the aircraft help menu (Press "?") and/or at [[Aircraft|the aircraft's wiki]].

=== Where can I learn about instrument flying and navigation? ===
{{Main article|Understanding Navigation}}
* http://www.navfltsm.addr.com/ is a very good site for learning techniques for navigation.
* [http://www.av8n.com/how/ See How It Flies] a very nice book by John S. Denker, freely accessible online

=== What is the difference between Aileron and Rudder? ===
There is a bit of info on aileron vs. rudder in the very same book...

=== Is there support for multi-player flying? ===
{{Main article|Howto: Multiplayer}}
Yes. Both the Windows and *nix versions of FlightGear are capable of multi-player flying on FlightGear servers.

A map showing players aircraft online in real time is available as [[MPmap]].

=== Where are the best places to fly in FlightGear? ===
FlightGear scenery covers the whole world, but thanks to the FlightGear user community, certain airports and areas are more detailed than others. For a full list of airports with buildings available in the default scenery, visit the forum's [http://flightgear.org/forums/viewtopic.php?f=5&t=4700&st=0&sk=t&sd=a|list of improved airports].

* There are a lot of high-quality scenery models around Paris, France.
* EHAM Amsterdam Schiphol, EGKK London Gatwick and LFPG Paris Charles de Gaulle are some of the highest quality airports in FlightGear.
* TNCM St. Maarten is a popular destination, and the surrounding islands (Anguilla, St. Eustatius, Saba, St. Barthélemy, St. Kitts, and Nevis) are all well-modeled.

Furthermore, there is a special wiki page with a list and preview of good [[Places to fly]].

=== Where can I find airport info and aeronautical charts online? ===
{{Main article|Getting aeronautical charts}}
A world-wide database of airports and [[navaids]] can be found at [http://worldaerodata.com World Aero Data].

Two very good US-only sources are
* Airports:
** [http://www.airnav.com/airports/ AirNav.com]
* Charts:
** [http://skyvector.com/ SkyVector.com]

=== Is there support for any military scenarios like dog fighting or bomb dropping? ===
Most of our developers are primarily interested and focused on civilian aviation. We aren't explicitly excluding these features — we just haven't had anyone who has done much development in these areas until recently. Now there are third-party bombing scenarios for the [[A-10]] and other aircraft with armament, like the [[North American OV-10A Bronco]], [[General Dynamics F-16]] and [[F-117 Nighthawk]].

[http://flightgear.org/forums/viewtopic.php?f=2&t=5742 A new add-on (9/2009)] adds support for dogfighting (including multiplayer dogfighting) and bombing scenarios.

=== Why are my controls returning to a particular position? ===
There are several possibilities that can lead to this:
* If your aircraft's [[autopilot]] is enabled, it will take over (some of) your controls. Switch the autopilot off to regain control.
* Some laptops have an onboard gravity sensor, that might be detected by FlightGear as a [[joystick]]. You can set FlightGear to ignore this fake-joystick:
*# Get your accelerometer's name via the in-sim <tt>Help > Joystick Information</tt> dialog.
*# Add this name to your <tt>[[$FG_ROOT]]/Input/Joysticks/Accelerometers/accelerometers.xml</tt> file, enclosed by <tt><name></tt> and <tt></name></tt> tags..
*# Report your device name to #flightgear at [[IRC|irc.flightgear.org]], so it can be included in the "official" accelerometer.xml file.

=== Why does my panel disappear when looking around? ===
2D panels are often only visible while looking in a fixed direction. At FlightGear, we prefer 3D cockpits, so most aircraft have those. The Cessna C172P is an example of an aircraft that has various variants, including a 2D and 3D one. Make sure you pick the 3D one (<tt>--aircraft=c172p</tt>).

== Hacking ==
=== What language is FlightGear written in? ===
Mostly C++ with some supporting C code that's primarily contained within SimGear.

See the [https://www.ohloh.net/p/flightgear/analyses/latest code analyses at Ohloh] for more details on the used languages:
* [https://www.ohloh.net/p/flightgear/analyses/latest FlightGear programm]
* [https://www.ohloh.net/p/flightgeardata/analyses/latest FlightGear data] (aircraft, sounds etc.)

=== How do I design a flight dynamics model for a new aircraft? ===
FlightGear supports various [[flight dynamics model]]s (FDMs), but just two of them are commonly used:
* [[JSBSim]]: see http://jsbsim.sf.net/.
* [[YASim]]: if you want a simpler FDM to work with, try your hand at YASim. For a guide on creating YASim aircraft, look in the FlightGear base package for <tt>[[$FG_ROOT]]/Docs/README.yasim</tt>.

[[UIUC]] is also available, but the main and most used ones are [[JSBSim]] and [[YASim]].

=== How do I import planes from Microsoft Flight Simulator? ===
You can import planes by using the 3D Convert utility which will convert the MSFS 3d model to a format used by FlightGear. You have to add the animations and parts.

Also, although you can import the 3D model and textures, the flight dynamics (the .AIR file) must be completely redone for FlightGear.

If you wish to import a model made with gmax, you will need to convert it to .MDL format using Microsoft's MakeMDL SDK which is available at http://zone.msn.com/flightsim/FS02DevDeskSDK08.asp.

=== How do I design or modify a panel? ===
See the README.xmlpanel file located in the FlightGear/docs-mini/ directory of the source distribution.

=== How do I place objects, like buildings, into FlightGear? ===
{{Main article|Portal:Developer/Scenery}}
First, ensure that you have v0.7.7 or later, the scenery files where you plan to place the object, the actual model, and the longitude and latitude where you plan to place the object.

Now get the altitude for your point. If you don't want to calculate this yourself, start FlightGear at your location and take note of the altitude. Here's an example command:

fgfs --lat=45.50 --lon=-75.73 2>&1 | tee fgfs.log

The altitude is probably in feet, so divide the starting altitude by 3.28.

Search the output log file for the first occurrence of the string "Loading tile" and take note of the filename. In the above example, the output line looks like:

Loading tile /usr/local/Scenery/w080n40/w076n45/1712601

Copy a 3D model in a format that Plib understands to the same directory as the tile file. Edit the text file in that directory consisting of the tile name with the extension ".stg". The file will already exist if there is an airport on the tile; otherwise, you can create it from scratch. In our example, the filename is:

/usr/local/Scenery/w080n40/w076n45/1712601.stg

At the end of the file, add a new entry for your object, consisting of the word "OBJECT_STATIC" followed by the model name, the longitude in degrees, the latitude in degrees, the altitude in meters, and the heading in degrees. In our example the line looks like:

OBJECT_STATIC Towerax.ac -75.73 45.40 60 0

Save the changes to the .stg file, restart FlightGear, and enjoy.

NOTE: The above information was taken from the following mailing list post: http://www.geocrawler.com/archives/3/11854/2001/6/0/5991409/. See that page if this one doesn't make sense.

An alternative approach using PPE is described at http://mail.flightgear.org/pipermail/flightgear-devel/2001-December/002239.html by Norman Vine.

Since Flightgear 0.9.10 there is an easy way for [[Placing 3D Objects with the UFO]].

=== Where can I learn 3D programming and how do I get involved? ===
Contributing to the 2D panel doesn't require any coding at all, just a minimal knowledge of [[XML]] syntax (i.e. five minutes' worth) and good skills with drawing and/or paint programs. Every instrument on the current panel, with the partial exception of the magnetic compass, is defined entirely in XML with no custom C++ code. If you want to get started, take a look at John Check's excellent intro at <tt>[[$FG_ROOT]]/Docs/README.xmlpanel.html</tt>.

Likewise, if you want to create a 3D cockpit for FlightGear, or to create buildings, external aircraft models, etc., your help is *desperately* needed. The only rule is to go easy on the triangles -- a model with 50,000 triangles probably won't be usable in FlightGear, and one with 5,000 triangles, only marginally. If you can design a nice 3D cockpit interior for in a 3D design program such as [[AC3D]], [[Blender]] or [[PPE]] and you can write some XML code, it will be much appreciatted.

If, on the other hand, you really want to get your hands dirty with C++ coding, you'll have to buy a good [[OpenGL]] book eventually. However, FlightGear uses [[OSG]], a high performance 3D graphics toolkit. To get started with 3D C++ coding, you can take a look at the OSG documentation and learn only as much OpenGL as you need, when you need it.

=== How do I add an airport? ===
You can add your airport to the <tt>[[$FG ROOT]]/Airports/default.apt.gz</tt> file, but to get the airport to show up visually, you will have to [[Frequently asked questions#Can I generate my own scenery?|rebuild the scenery]] around the airport. The format of the default.apt file is documented at http://www.flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html.

=== Can I generate my own scenery? ===
{{Main article|TerraGear}}
Yes, though it can be a difficult task. FlightGear's scenery generation is handled by a sister project, [[TerraGear]].

[[Category:FlightGear]]

[[de:FAQ]]
[[es:Preguntas frecuentes]]
[[fr:Foire aux questions]]
[[pl:FAQ]]
[[pt-br:Perguntas frequentes]]

Frequently asked questions

2013-04-20T06:54:02Z

AndersM: /* Starting engine in single-engine aircraft */

Thank you for downloading [[FlightGear]]! This '''FAQ''' lists some of the most commonly asked questions. Please create a topic at [http://flightgear.org/forums our forum] if you cannot find the answer on your problem(s).

== The FAQ ==
=== Where can I get the latest version of this FAQ? ===
http://wiki.flightgear.org/index.php/FAQ

=== Who do I contact if I have comments about this FAQ? ===
Add your comment to this FAQ's [[Talk:Frequently asked questions|discussion page]].

=== How old is this document? ===
Check its <span class="plainlinks">[{{fullurl:{{PAGENAME}}|action=history}} history]</span>.

=== What other important documentation should I read? ===
* [http://flightgear.org/Docs/getstart/getstart.html Getting Started Guide]
* [[New to FlightGear]]
* Also see the FlightGear/docs-mini/ directory in the source distribution for various other helpful documents.
* Also see the other [http://www.flightgear.org/Docs/FAQ.shtml FAQ]

== Distribution ==
=== Where can I get FlightGear? ===
The official download page is http://www.flightgear.org/download/. Source code is our primary form of distribution, but precompiled binaries are available for Windows and SGI IRIX.

Alternatively, FlightGear is packaged for Linux by SuSE, Debian and Mandrake, and can be directly installed through those distributions via any package manager.

=== How do I install FlightGear on Ubuntu? ===
FlightGear 2.0.0 can be installed directly from the Synaptic Package Manager for Ubuntu 11.04 onwards. Open Synaptic Package Manager, search for FlightGear and follow instructions.
FlightGear 2.4.0 is available as a [http://www.getdeb.net/welcome/ GetDeb] package for Ubuntu 11.04 onwards. Install GetDeb on your Ubuntu machine and install FlightGear from [http://www.playdeb.net/updates/ubuntu/11.04/?q=flightgear PlayDeb]'s website.

=== What is the password for the FTP server? ===
The FTP server uses standard anonymous login procedures. Login with the username "anonymous" and use your email address as the password. Most FTP clients and web browsers will do this automatically for you.

=== Why won't the FTP server let me in with the right login info? ===
This generally means that the server is at its capacity. You should receive a message saying such, but your FTP client may be hiding it from you. Your options are to keep trying until a slot opens up or try connecting to one of our FTP mirrors listed at http://www.flightgear.org/mirrors.html.

=== Where can I find the latest development source code? ===
{{Main article|Flightgear and Git}}
The latest development code is available for everyone through our Git [http://gitorious.org/fg repository].

=== Why are the aircraft at FlightGear.org out of date? ===
The [http://www.flightgear.org/download/aircraft-v2-4/ official aircraft downloads] are only updated at the time of a new release of FlightGear. This is done because aircraft that are currently in development are usually developed on development/unreleased versions of FlightGear. Those development versions have lots of features that are not supported by the (older) stable release. Would we update the aircraft downloads more often; most aircraft won't work on the stable release of FlightGear.

=== What is SimGear, and why do I need it? ===
[[SimGear]] is a library of supporting code. SimGear is only needed if you plan on compiling FlightGear — it is not needed to run precompiled binaries. For more information see http://www.simgear.org/. Note: When compiling FlightGear it is very important to have the matching version of SimGear.

=== Where can I fly and where do I get the scenery? ===
While the base package only comes with scenery for the San Francisco Bay area, you can currently fly just about anywhere in the world. See the "Additional Scenery" section of http://www.flightgear.org/download/ for more information or go directly to our graphical downloader at http://www.flightgear.org/Downloads/scenery-1.0.1.html

[[Terrasync]] is an option too. It downloads the latest scenery while flying. In 2.4.0 a GUI for enabling/disabing Terrasync can be found at Environment->Scenery Download.

Also visit our "Places to Fly" section of the website (http://www.flightgear.org/places.html) for some help navigating to some awesome locations. (see also [[Installing Scenery]])

=== Where can I get different 3D models for my plane? ===
Official FlightGear aircraft can be found at http://www.flightgear.org/download/aircraft-v2-4/ . Other aircraft in development can be found on [[Git]], and some other aircraft can be found on 3rd party [[FlightGear hangars]].

=== How current is the data in FlightGear compared to the real world? ===
We use the same navaid and airport dataset that X-Plane uses. The current dataset can be found in the <tt>[[$FG ROOT]]/Navaids/</tt> and <tt>[[$FG ROOT]]/Airports/</tt> directories. If you have updates or corrections to the dataset, see http://www.flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html for instructions on contacting the database maintainer.

=== Where is the moving map? ===
A popular moving map display is available under a separate project called [[Atlas]]. Also, [[MPmap]] is an online map for multiplayer.

If you like an alternative to Atlas with updated graphics and mapping provided by the OpenStreetMap project, then check out Flightgear Mapping [http://rubyforge.org/projects/fgmap fgmapping] or [[JMapView]].

=== Why don't you charge money for this? ===
FlightGear can be downloaded for free from many locations including the FlightGear website, but can also be bought on a CD. Although we offer that service (see the website), we encourage other groups to redistribute it for their users, especially within an operating system distribution which makes installation even faster and easier for new users.

Occasionally you may see FlightGear for sale on auction sites or commercial websites under some other name. This can be done quite legitimately as long as the terms of the license are upheld and might be worth the cost if some value-added features such as additional scenery, aircraft or after-sale support are included. Unfortunately, most cases seen to date appear to be just someone trying to make money selling something that is free and providing no real added value.

=== How can I get started with FlightGear ===
The latest release of FlightGear can be downloaded at the [http://www.flightgear.org/download/ download central], but most [[aircraft]] need to be separately downloaded [http://www.flightgear.org/download/aircraft-v2-4/ here] and installed manually. Be aware of system requirements! Also, check out [[New to FlightGear]].

== Compiling ==
{{main article|Building Flightgear}}

=== Why won't FlightGear compile? ===
Well, that depends. First make sure you are using the appropriate versions of FlightGear, [[SimGear]], plib, zlib. If any of the packages are out of sync with the others, compilation may fail. See also [[Building FlightGear]]

The [http://www.flightgear.org/download/ FlightGear Downloads page] should tell you what versions you need if you are trying to compile the latest stable release. If you are using a development snapshot, make sure all three packages are up-to-date.

Also ensure that you have some implementation of OpenGL with glut support with the appropriate header files. Linux users with nVidia cards should make sure you have the latest drivers from nVidia. Other Linux users make sure you have Mesa3D (http://mesa3d.org/) and your X server installed correctly.

If your problems persist, ask in the [http://www.flightgear.org/forums FlightGear Forums], on the [[IRC]] or subscribe to our FlightGear-Users [[mailing list]] and let us know what problem you're having.

== Configuring ==
=== How do I install new scenery? ===
{{Main article|Howto: Install scenery}}
The scenery archive files (ie. w100n30.tar.gz) should be untarred into the Scenery/Terrain directory in your [[$FG_ROOT]].

=== How do I setup my joystick(s)? ===
{{Main article|Joystick}}
FlightGear should come with a helpful program called `fgjs` that can help configure your joystick. Run `fgjs` and then copy the dot file it created into your home directory or add its contents to your existing rc file.

Also, see the <tt>[[$FG_ROOT]]/Docs/README.Joystick</tt> file located in the FlightGear base package and the [[Joystick|joystick page]] on the wiki.

=== What format should my personal .fgfsrc file be in? ===
Your .fgfsrc file should simply be a list of [[Command Line Parameters|command line options]] with one option per line. The file is not an XML file.

If you would rather use an [[XML]] configuration file, you can add something like the following in your .fgfsrc

--config=/path/to/my/config.xml

Almost every option corresponds to a property, so you can choose to use whichever method best suits your needs.

== Running ==
If you get errors in the console (black window), please check [[Howto: Understand console output]] and see if your error is listed (with a solution).

=== Unable to execute file: bin/Win32/fgrun.exe during installation ===
Your system is missing the MSVC runtime libraries required by FlightGear.
Download and install the following vcredist_x86.exe:
* MSVC9 for FG2.4.0 (and earlier): http://www.microsoft.com/download/en/details.aspx?id=26368
* MSVC10 for FG2.6.0 (and later): http://www.microsoft.com/download/en/details.aspx?id=5555

=== Why do I get an error loading libopenal.so.0? ===
With the default installation, libopenal.so.0 is installed into /usr/local/lib. You need to ensure that that path is listed in /etc/ld.so.conf, then run `ldconfig`as root.

=== Why do I get "ssgInit called without a valid OpenGL context"? ===
In short, your GL libraries are broken. So far only Red Hat 7.x users have experienced this (see http://www.redhat.com/bugzilla/show_bug.cgi?id=18867). The only solutions are possibly complicated ones: you can either change distributions (most of us prefer Debian) or upgrade/downgrade your Mesa libs.

Why do some other GL applications work though? Well, Steve Baker (Mr. PLIB) has explained this on the plib-users list (http://www.geocrawler.com/lists/3/SourceForge/1867/0/6470648/).

=== What happened to the panel, keyboard, etc? ===
The problem is almost certainly that your base package is out of sync with FlightGear. Many configurable parts of FlightGear are defined in [[XML]] files contained in the base package.

=== Why doesn't audio work properly under Irix? ===
FlightGear (as of June 2001) uses the Portable Libraries ([[PLIB]]) for playing audio. The audio queue implementation of PLIB is far from optimal (in fact it's just wrong). This seems to work on other platforms quite well, but Irix expects things to be programmed properly.

There has been discussion about using OpenAL (http://www.openal.org/) for the next release of both PLIB and FlightGear. Tests show that the OpenAL audio implementation does the job right, meaning that these audio problems should be gone by then. In the mean time it is best to disable audio on Irix completely (by adding --disable-sound either on the command line or to your $HOME/.fgfsrc file).

=== Why is FlightGear so slow? ===
{{Main article|Howto: Improve Framerates}}
FlightGear supports hardware acceleration, but it seems not to be activated. Make sure you have OpenGL libraries installed and configured properly and make sure you have the latest drivers for your video card.

Linux users: If you are an nVidia user, follow their directions on getting your card working. For most other users, make sure Mesa is installed property and ensure that you have the appropriate kernel device drivers for your card. Most people (and distributions) use modules for their video card device drivers; run `lsmod` as root to see what modules are loaded. You should also make sure that you are loading the appropriate modules in your XF86Config and that your video device section is correct. Now try running an OpenGL application (other than FlightGear) to see how it performs. You can try the gears demo from Mesa or something like Quake3.

=== Why is my SGI machine so slow? ===
First of all, one of the most common mistakes on SGI hardware is to forget to specify --fog-fastest. On most SGI machines the EXP2 shading model isn't hardware supported resulting in frame rates below 1 frame per second (fps).

FlightGear makes extensive use of the OpenGL z-buffer feature,which on most older SGI hardware is only supported in software. This means that the CPU has to do all the z-buffer calculations in addition to the other tasks FlightGear involves (flight dynamics, scenery tracking, pushing commands into the graphics queue, etc). The following features are software rendered on low-end SGI machines (like Indy and Indigo):

* stencil and accumulation buffer
* depth queuing and depth buffering
* fogging, lighting, clipping and transforms
* texturing

This means that running FlightGear with the following options may not even get the desired result:

./runfgfs --fog-disable --shading-flat --disable-skyblend --disable-textures --disable-clouds --disable-sound --disable-panel --enable-hud --disable-anti-alias-hud

I could even imagine that adding --enable-wireframe doesn't work on these machines (I would be happy to be proven wrong though).

On a machine like O2 the following options give an acceptable result:
./runfgfs --fog-fastest --disable-sound

Since I don't have access to other SGI hardware I can't tell which options would be appropriate for your situation.

=== How do I see the Frame Rate? ===
On the in-sim [[menu]] select View > Display Options, then check the box that says "Show frame rate".

=== How do I toggle panel settings? ===
There are two ways. One way is to hide the panel without the HUD showing. To hide the panel, use Shift+P; To make the HUD disappear, use H. The second way is to use the alternative HUD by Shift+I (Use I to switch back).

=== Stuck upside down after "crash"? ===
In his infinite wisdom the FlightGear Grand Master decided that planes were too valuable to allow them to be destroyed by novice pilots who seemed to crash a lot. The fact that nobody has bothered to model crashes may have something to do with it too. :-)

The result of this as you have noticed is that with a little practice an ingenuity you can trim the ship to fly inverted along the ground. The quick answer is to reset the sim, via the <tt>File > Reset</tt> menu. This will place your aircraft back at its starting location.

For the stubborn people out there: The trick to learn is to roll back to normal (non inverted) do this by nursing the elevator to get to about 500 feet or so and use the ailerons to snap roll 180*. This is all good avionics except for the plane not destroying itself. Remember the controls work in reverse when you are inverted and keep that airspeed up!!!

=== Why does FlightGear die on startup saying "time zone reading failed"? ===
This is probably caused by a line-ending problem in the timezone files. Win32 users can resolve the problem by downloading a DOS to UNIX conversion utility available at http://www.nottingham.ac.uk/~eazdluf/d2u.zip. Run as `d2u *.tab` from within the timezone directory to fix your timezone files.

=== Why won't the latest versions of some aircraft work in my (older) version of FlightGear? ===
Often new aircraft development keeps pace with the latest FlightGear code development. New or newly modified aircraft may rely on files (such as new instrument files) or features, only available with newer versions of FlightGear. If you are stuck with an older version of FlightGear, you can try downloading an earlier version of the aircraft at one of the archives:
* [http://www.flightgear.org/Downloads/aircraft-1.9.1/index.shtml Aircraft for 1.9.1]
* [http://flightgear.org/Downloads/aircraft-2.0.0/ Aircraft for 2.0.0]
* [http://ftp.riken.go.jp/pub/FreeBSD/distfiles/flightgear-aircrafts/ Aircraft from various dates]

=== Why are my screenshots black? ===
Make sure you have multithreading disabled in <tt>[[$FG_ROOT]]/preferences.xml</tt>. Enabling it currently breaks the screenshot function.

== Flying ==
=== Why won't my engine(s) start? ===
Aircraft vary in their starting procedure. Some may have an auto-start sequence menu entry or instructions in the aircraft help menu (Press "?") and/or at [[Aircraft|the aircraft's wiki]].

==== Starting engine in single-engine aircraft ====
In general to start the engine on a piston-engine type aircraft, you need:

# Fuel - You can run out of fuel, of course, but for certain aircraft, FlightGear may load it with no fuel, making it impossible to start the engines. Check this in the menu <tt>Equipment > Fuel and Payload</tt>.
# Correct mixture (generally "rich", ie red knob all the way in)
# Magnetos on (R, L, or both--generally select "both")
# Throttle (some engines start better with a little gas)
# Hold starter for sufficient time.

You may be able to do all these functions with the standard 2-D panel or your aircraft's built-in panel. However using the standard key bindings is more reliable:

# Press/hold "m" to set mixture to rich (m=rich, M=lean--if you are at a very high elevation you may need to set it somewhere besides full rich)
# Press "}}}" (three times) to set magneto to R, L, and finally "Both".
# Open throttle a little.
# Press "s" to run the starter. For some aircraft you may have to hold "s" as long as 10 seconds before the engine starts.

In general to start the engine on a jet engine type aircraft, you need to:

# Set cutoff ON
# Engage the starter
# Once the engines spools up to approximately 5% N1, set cutoff OFF
# Disengage the starter once the engine has reached operational speed

These instructions may not work for jet aircraft, helicopters, or other types of aircraft with complex start procedures. Check the instructions in the aircraft help menu (Press "?") and/or at [[Aircraft|the aircraft's wiki]].

==== Starting engine in multi-engine aircraft ====
Starting all engines in a multi-engine aircraft is similar to the single engine--except you must follow the same start sequence for each and every engine. Flightgear provides a convenient way to do this for all engines at once.

Note that the default 2-D panel is connected to ''only one engine''. So if you try to start the engines using the 2-D panel controls you will most likely start only one engine.

Instead, use the keyboard to start all engines at once:

# Press "~" (select all engines)
# Press/hold "m" to set mixture to rich (m=rich, M=lean--if you are at a very high elevation you may need to set the mixture somewhere besides full rich)
# Press "}}}" (three times) to set magnetos to R, L, and finally "Both".
# Open throttle a little (it now controls all engines).
# Press "s" to run the starter (it now runs the starter on all engines). For some aircraft you may have to hold "s" as long as 10 seconds before the engine starts.
# Rev the engines a little with your throttle and check your tachometers and/or visually to be sure all engines are running.

If the engines won't start, make sure you have fuel. Some aircraft have switches to control which fuel tanks feed which engines, so check these. Make sure each engine you want to start is connected to a tank that has fuel. Check fuel tanks in the menu <tt>Equipment > Fuel and Payload</tt>.

These instructions may not work for jet aircraft, helicopters, or other types of aircraft with complex start procedures. Check the instructions in the aircraft help menu (Press "?") and/or at [[Aircraft|the aircraft's wiki]].

=== Where can I learn about instrument flying and navigation? ===
{{Main article|Understanding Navigation}}
* http://www.navfltsm.addr.com/ is a very good site for learning techniques for navigation.
* [http://www.av8n.com/how/ See How It Flies] a very nice book by John S. Denker, freely accessible online

=== What is the difference between Aileron and Rudder? ===
There is a bit of info on aileron vs. rudder in the very same book...

=== Is there support for multi-player flying? ===
{{Main article|Howto: Multiplayer}}
Yes. Both the Windows and *nix versions of FlightGear are capable of multi-player flying on FlightGear servers.

A map showing players aircraft online in real time is available as [[MPmap]].

=== Where are the best places to fly in FlightGear? ===
FlightGear scenery covers the whole world, but thanks to the FlightGear user community, certain airports and areas are more detailed than others. For a full list of airports with buildings available in the default scenery, visit the forum's [http://flightgear.org/forums/viewtopic.php?f=5&t=4700&st=0&sk=t&sd=a|list of improved airports].

* There are a lot of high-quality scenery models around Paris, France.
* EHAM Amsterdam Schiphol, EGKK London Gatwick and LFPG Paris Charles de Gaulle are some of the highest quality airports in FlightGear.
* TNCM St. Maarten is a popular destination, and the surrounding islands (Anguilla, St. Eustatius, Saba, St. Barthélemy, St. Kitts, and Nevis) are all well-modeled.

Furthermore, there is a special wiki page with a list and preview of good [[Places to fly]].

=== Where can I find airport info and aeronautical charts online? ===
{{Main article|Getting aeronautical charts}}
A world-wide database of airports and [[navaids]] can be found at [http://worldaerodata.com World Aero Data].

Two very good US-only sources are
* Airports:
** [http://www.airnav.com/airports/ AirNav.com]
* Charts:
** [http://skyvector.com/ SkyVector.com]

=== Is there support for any military scenarios like dog fighting or bomb dropping? ===
Most of our developers are primarily interested and focused on civilian aviation. We aren't explicitly excluding these features — we just haven't had anyone who has done much development in these areas until recently. Now there are third-party bombing scenarios for the [[A-10]] and other aircraft with armament, like the [[North American OV-10A Bronco]], [[General Dynamics F-16]] and [[F-117 Nighthawk]].

[http://flightgear.org/forums/viewtopic.php?f=2&t=5742 A new add-on (9/2009)] adds support for dogfighting (including multiplayer dogfighting) and bombing scenarios.

=== Why are my controls returning to a particular position? ===
There are several possibilities that can lead to this:
* If your aircraft's [[autopilot]] is enabled, it will take over (some of) your controls. Switch the autopilot off to regain control.
* Some laptops have an onboard gravity sensor, that might be detected by FlightGear as a [[joystick]]. You can set FlightGear to ignore this fake-joystick:
*# Get your accelerometer's name via the in-sim <tt>Help > Joystick Information</tt> dialog.
*# Add this name to your <tt>[[$FG_ROOT]]/Input/Joysticks/Accelerometers/accelerometers.xml</tt> file, enclosed by <tt><name></tt> and <tt></name></tt> tags..
*# Report your device name to #flightgear at [[IRC|irc.flightgear.org]], so it can be included in the "official" accelerometer.xml file.

=== Why does my panel disappear when looking around? ===
2D panels are often only visible while looking in a fixed direction. At FlightGear, we prefer 3D cockpits, so most aircraft have those. The Cessna C172P is an example of an aircraft that has various variants, including a 2D and 3D one. Make sure you pick the 3D one (<tt>--aircraft=c172p</tt>).

== Hacking ==
=== What language is FlightGear written in? ===
Mostly C++ with some supporting C code that's primarily contained within SimGear.

See the [https://www.ohloh.net/p/flightgear/analyses/latest code analyses at Ohloh] for more details on the used languages:
* [https://www.ohloh.net/p/flightgear/analyses/latest FlightGear programm]
* [https://www.ohloh.net/p/flightgeardata/analyses/latest FlightGear data] (aircraft, sounds etc.)

=== How do I design a flight dynamics model for a new aircraft? ===
FlightGear supports various [[flight dynamics model]]s (FDMs), but just two of them are commonly used:
* [[JSBSim]]: see http://jsbsim.sf.net/.
* [[YASim]]: if you want a simpler FDM to work with, try your hand at YASim. For a guide on creating YASim aircraft, look in the FlightGear base package for <tt>[[$FG_ROOT]]/Docs/README.yasim</tt>.

[[UIUC]] is also available, but the main and most used ones are [[JSBSim]] and [[YASim]].

=== How do I import planes from Microsoft Flight Simulator? ===
You can import planes by using the 3D Convert utility which will convert the MSFS 3d model to a format used by FlightGear. You have to add the animations and parts.

Also, although you can import the 3D model and textures, the flight dynamics (the .AIR file) must be completely redone for FlightGear.

If you wish to import a model made with gmax, you will need to convert it to .MDL format using Microsoft's MakeMDL SDK which is available at http://zone.msn.com/flightsim/FS02DevDeskSDK08.asp.

=== How do I design or modify a panel? ===
See the README.xmlpanel file located in the FlightGear/docs-mini/ directory of the source distribution.

=== How do I place objects, like buildings, into FlightGear? ===
{{Main article|Portal:Developer/Scenery}}
First, ensure that you have v0.7.7 or later, the scenery files where you plan to place the object, the actual model, and the longitude and latitude where you plan to place the object.

Now get the altitude for your point. If you don't want to calculate this yourself, start FlightGear at your location and take note of the altitude. Here's an example command:

fgfs --lat=45.50 --lon=-75.73 2>&1 | tee fgfs.log

The altitude is probably in feet, so divide the starting altitude by 3.28.

Search the output log file for the first occurrence of the string "Loading tile" and take note of the filename. In the above example, the output line looks like:

Loading tile /usr/local/Scenery/w080n40/w076n45/1712601

Copy a 3D model in a format that Plib understands to the same directory as the tile file. Edit the text file in that directory consisting of the tile name with the extension ".stg". The file will already exist if there is an airport on the tile; otherwise, you can create it from scratch. In our example, the filename is:

/usr/local/Scenery/w080n40/w076n45/1712601.stg

At the end of the file, add a new entry for your object, consisting of the word "OBJECT_STATIC" followed by the model name, the longitude in degrees, the latitude in degrees, the altitude in meters, and the heading in degrees. In our example the line looks like:

OBJECT_STATIC Towerax.ac -75.73 45.40 60 0

Save the changes to the .stg file, restart FlightGear, and enjoy.

NOTE: The above information was taken from the following mailing list post: http://www.geocrawler.com/archives/3/11854/2001/6/0/5991409/. See that page if this one doesn't make sense.

An alternative approach using PPE is described at http://mail.flightgear.org/pipermail/flightgear-devel/2001-December/002239.html by Norman Vine.

Since Flightgear 0.9.10 there is an easy way for [[Placing 3D Objects with the UFO]].

=== Where can I learn 3D programming and how do I get involved? ===
Contributing to the 2D panel doesn't require any coding at all, just a minimal knowledge of [[XML]] syntax (i.e. five minutes' worth) and good skills with drawing and/or paint programs. Every instrument on the current panel, with the partial exception of the magnetic compass, is defined entirely in XML with no custom C++ code. If you want to get started, take a look at John Check's excellent intro at <tt>[[$FG_ROOT]]/Docs/README.xmlpanel.html</tt>.

Likewise, if you want to create a 3D cockpit for FlightGear, or to create buildings, external aircraft models, etc., your help is *desperately* needed. The only rule is to go easy on the triangles -- a model with 50,000 triangles probably won't be usable in FlightGear, and one with 5,000 triangles, only marginally. If you can design a nice 3D cockpit interior for in a 3D design program such as [[AC3D]], [[Blender]] or [[PPE]] and you can write some XML code, it will be much appreciatted.

If, on the other hand, you really want to get your hands dirty with C++ coding, you'll have to buy a good [[OpenGL]] book eventually. However, FlightGear uses [[OSG]], a high performance 3D graphics toolkit. To get started with 3D C++ coding, you can take a look at the OSG documentation and learn only as much OpenGL as you need, when you need it.

=== How do I add an airport? ===
You can add your airport to the <tt>[[$FG ROOT]]/Airports/default.apt.gz</tt> file, but to get the airport to show up visually, you will have to [[Frequently asked questions#Can I generate my own scenery?|rebuild the scenery]] around the airport. The format of the default.apt file is documented at http://www.flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html.

=== Can I generate my own scenery? ===
{{Main article|TerraGear}}
Yes, though it can be a difficult task. FlightGear's scenery generation is handled by a sister project, [[TerraGear]].

[[Category:FlightGear]]

[[de:FAQ]]
[[es:Preguntas frecuentes]]
[[fr:Foire aux questions]]
[[pl:FAQ]]
[[pt-br:Perguntas frequentes]]