FlightGear wiki - User contributions [en]

Dicta Boelcke

2024-01-04T22:30:28Z

KJ7RRV: KJ7RRV moved page Dicta Boelcke to Dogfighting tips: This page includes suggestions from other people too

#REDIRECT [[Dogfighting tips]]

Dogfighting tips

2024-01-04T22:30:28Z

KJ7RRV: KJ7RRV moved page Dicta Boelcke to Dogfighting tips: This page includes suggestions from other people too

{{Template:Bombable_Navigation}}

The [[Bombable]] Flightgear add-on was developed with the idea that in a realistic flight simulator environment, the ideas about aerial combat developed by the best skilled pilots of all eras--such as those by World War I aces, below--would naturally develop as a result of the aircrafts' innate capabilities and limitations.

Following these historical rules and guidelines does indeed work in dogfighting with Bombable in FlightGear--whether with AI aircraft or with other real pilots over multiplayer.

[[File:camel-through-wing.jpg|150px|Bombable screen shot]]

===Dicta Boelcke===
Rules for Aerial Combat from the WWI era by the first great
German flying ace of the First World War, Oswald Boelcke

1.Try to secure the upper hand before attacking. If possible, keep the sun
behind you.

2.Always continue with an attack you have begun.

3.Only fire at close range, and then only when the opponent is properly in
your sights.

4.You should always try to keep your eye on your opponent, and never let
yourself be deceived by ruses.

5.In any type of attack, it is essential to assail your opponent from behind.

6.If your opponent dives on you, do not try to get around his attack, but fly
to meet it.

7. When over the enemy's lines, never forget your own line of retreat.

8. Tip for Squadrons: In principle, it is better to attack in groups of four or
six. Avoid two aircraft attacking the same opponent.

===Edward Mannock's rules===
Edward Mannock, the first British WWI flying ace, wrote this set of rules:

* Pilots must dive to attack with zest, and must hold their fire until they
get within one hundred yards (90 m) of their target.

* Achieve surprise by approaching from the East. (From the German side of the
front.)

* Utilise the sun's glare and clouds to achieve surprise.

* Pilots must keep physically fit by exercise and the moderate use of
stimulants.

* Pilots must sight their guns and practise as much as possible as targets are
normally fleeting.

* Pilots must practise spotting machines in the air and recognising them at
long range, and every aeroplane is to be treated as an enemy until it is
certain it is not.

* Pilots must learn where the enemy's blind spots are. Scouts must be attacked
from above and two-seaters from beneath their tails.

* Pilots must practise quick turns, as this manoeuvre is more used than any
other in a fight.

* Pilot must practise judging distances in the air as these are very
deceptive. Decoys must be guarded against — a single enemy is often a decoy —
therefore the air above should be searched before attacking.

* If the day is sunny, machines should be turned with as little bank as
possible, otherwise the sun glistening on the wings will give away their
presence at a long range.

* Pilots must keep turning in a dog fight and never fly straight except when
firing.

* Pilots must never, under any circumstances, dive away from an enemy, as he
gives his opponent a non-deflection shot — bullets are faster than aeroplanes.

* Pilots must keep their eye on their watches during patrols, and on the
direction and strength of the wind.

===Adolph Malan's "TEN OF MY RULES FOR AIR FIGHTING"===

* Wait until you see the whites of his eyes. Fire short bursts of one to two
seconds only when your sights are definitely "ON".

* Whilst shooting think of nothing else, brace the whole of your body: have
both hands on the stick: concentrate on your ring sight.

* Always keep a sharp lookout. "Keep your finger out".

* Height gives you the initiative.

* Always turn and face the attack.

* Make your decisions promptly. It is better to act quickly even though your
tactics are not the best.

* Never fly straight and level for more than 30 seconds in the combat area.
When diving to attack always leave a proportion of your formation above to act
as a top guard.

* INITIATIVE, AGGRESSION, AIR DISCIPLINE, and TEAM WORK are words that MEAN
something in Air Fighting.

* Go in quickly - Punch hard - Get out!

[[Category:Historical aircraft]]

YASim

2023-07-21T22:39:48Z

KJ7RRV:

[[File:yasimlogo.png|thumb]]

'''YASim''' is one of two [[flight dynamics model]]s commonly used in [[FlightGear]], alongside [[JSBSim]]. The flight dynamics model (FDM) determines how the [[aircraft]] moves and flies.

Gary Neely wrote in his [http://www.buckarooshangar.com/flightgear/ introduction to YASim]:

:''The FDM is the mathematical model that controls the physics of flight within the simulator. The physical 3D aircraft model has nothing to do with flight dynamics-- in essence it's just a picture to look at. It's the FDM that dictates how the model flies.''

:''Why YASim? YASim uses the geometry of the aircraft to generate the base flight characteristics. While this suggests a 'realistic' or out-of-the-box approach, it is a only rough approximation that will require much tweaking before you get a result that approaches realism. If you have solid flight data for your aircraft such as wind-tunnel data or you are looking to eventually generate a hyper-realistic simulation, JSBSim is probably a better approach. If you lack such data but know the geometry of the aircraft and have access to the same flight characteristics and limits as a real pilot would, then YASim can provide a solution that is more than sufficient for most simulation needs.''

== Coordinate system notes ==
All positions specified are in metres (which is weird, since all other units in the file are English). The X axis points forward, Y is left, and Z is up. Take your right hand, and hold it like a gun. Your first and second fingers are the X and Y axes, and your upwards-pointing thumb is the Z. This is slightly different from the coordinate system used by [[JSBSim]]. Sorry. The origin can be placed anywhere, so long as you are consistent. I use the nose of the aircraft.

(In the [[JSBSim_Aerodynamics#Frames|JSBSim coordinate system]], X and Z are the same as in YASim, but Y points to the right instead of left.)

=== Checking alignment with Blender ===

Blender can display a '''.ac''' model and a yasim model at the same time, allowing one to check whether the wings, gear contact points etc are aligned correctly. But it seems that Blender ignores any top-level <code>loc <x> <y> <z></code> specification in the '''.ac''' file, which makes it non-trivial to check alignment if such a specification is used.

== YASim design notes ==
Andy Ross's original design notes for YASim can be found in [https://pdfhost.io/v/~iYsLl7xS_alldvi.pdf this PDF file]. These provide some useful background for how YASim works.

== XML Elements ==

=== airplane ===
The top-level element for the file. It contains the following attributes:
* '''mass:''' The empty (no fuel) weight, in pounds. It does include the weight of the engine(s), so when you add the engine weight in its tag, it acts just like a ballast.
* '''version:''' The version attribute is used to maintain compatibility when updating yasim (e.g. bugfixes). If this attribute i not given, the original version will be used. Several bugfixes to YASim were implemented in FlightGear 3.2 (see [[FlightGear Newsletter April 2014]]), some more are fixed in FlightGear 2017.2.
Available versions are:
* <code>YASIM_VERSION_ORIGINAL</code> explicitly use the old buggy calculations (same as no version attribute at all)
* <code>YASIM_VERSION_32</code> enable bugfixes up to version 3.2
* <code>2017.2</code> enable bugfixes up to version 2017.2
* <code>2018.1</code> (FIXME) no bugfixes by now. Use this version if your aircraft makes use of new features in YASim 2018.1 so it will cause at least a warning with older FG versions.
* <code>YASIM_VERSION_CURRENT</code> use latest version compiled into the users FlightGear.
{{Warning| Using YASIM_VERSION_CURRENT might make the aircraft unusable in case of future changes to YASim without updating the aircraft accordingly.}}

'''New in 2018.1'''
* '''mtow-lbs''' and '''mtow-kg:''' use one of them to specify max. takeoff weight. Does not affect the FDM, but is used by CLI tool to calculate some numbers.

=== approach ===
The approach parameters for the aircraft. The solver will generate an aircraft that matches these settings (by adjusting the parameters of the surface like drag and lift). It is extremely important to give parameters which could be really achieved by defined aircraft geometry, otherwise, it gives an unstable or not flyable result. The element can (and should) contain <control> elements indicating pilot input settings, such as flaps and throttle, for the approach.

* '''speed:''' The approach airspeed, in knots TAS.
* '''aoa:''' The approach angle of attack, in degrees
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.

=== cruise ===
The cruise speed and altitude for the solver to match. As above, this should contain <control> elements indicating aircraft configuration. Especially, make sure the engines are generating enough thrust at cruise!
* '''speed:''' The cruise speed, in knots TAS.
* '''alt:''' The cruise altitude, in feet MSL.
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.
=== cockpit ===
The location of the cockpit (pilot eyepoint).
* '''x,y,z:''' eyepoint location (see coordinates note)

=== fuselage ===
This defines a tubelike structure. It will be given an even mass and aerodynamic force distribution by the solver. You can have as many as you like, in any orientation you please.
* '''ax,ay,az:''' One end of the tube (typically the front)
* '''bx,by,bz:''' The other ("back") end.
* '''width:''' The width of the tube, in metres.
* '''taper:''' The approximate radius at the "tips" of the fuselage expressed as a fraction (0-1) of the width value.
* '''midpoint:''' The location of the widest part of the fuselage, expressed as a fraction of the distance between A and B.
* '''idrag:''' Multiplier for the "induced drag" generated by this object. Default is one. With idrag=0 the fuselage generates only drag.
* '''cx,cy,cz:''' Factors for the generated drag in the fuselages "local coordinate system" with x pointing from end to front, z perpendicular to x with y=0 in the aircraft coordinate system. E.g. for a fuselage of a height of 2 times the width you can define cy=2 and (due to the doubled front surface) cx=2.

=== Surfaces ===
==== wing ====
This defines the main wing of the aircraft. You can have only one (but see below about using vstab objects for extra lifting surfaces). The wing should have a <stall> subelement to indicate stall behavior, control surface subelements (flap0, flap1, spoiler, slat) to indicate what and where the control surfaces are, and <control> subelements to map user input properties to the control surfaces.
* '''x,y,z:''' The "base" of the wing, specified as the location of the mid-chord (not leading edge, trailing edge, or aerodynamic center) point at the root of the LEFT (!) wing.
* '''length:''' The length from the midchord point of the base of the wing to the midchord point at the tip. Note that this is not the same thing as span.
* '''chord:''' The chord of the wing at its base, along the X axis (not normal to the leading edge, as it is sometimes defined).
* '''incidence:''' The incidence angle at the wing root, in degrees. Zero is level with the fuselage (as in an aerobatic plane), positive means that the leading edge is higher than the trailing edge (as in a trainer).
* '''twist:''' The difference between the incidence angle at the wing root and the incidence angle at the wing tip. Typically, this is a negative number so that the wing tips have a lower angle of attack and stall after the wing root (washout).
* '''taper:''' The taper fraction, expressed as the tip chord divided by the root chord. A taper of one is a hershey bar wing, and zero would be a wing ending at a point. Defaults to one.
* '''sweep:''' The sweep angle of the wing, in degrees. Zero is no sweep, positive angles are swept back. Defaults to zero. [This looks to be the sweep of the mid-chord of the wing, not the sweep of the leading edge.]
* '''dihedral:''' The dihedral angle of the wing. Positive angles are upward dihedral. Defaults to zero.
* '''idrag:''' Multiplier for the "induced drag" generated by this surface. In general, low aspect wings will generate less induced drag per-AoA than high aspect (glider) wings. This value isn't constrained well by the solution process, and may require tuning to get throttle settings correct in high AoA (approach) situations.
* '''effectiveness:''' Multiplier for the "normal" drag generated by the wing. Defaults to 1. Arbitrary, dimensionless factor.
* '''camber:''' The lift produced by the wing at zero angle of attack, expressed as a fraction of the maximum lift produced at the stall AoA.
* '''flow:''' The flow regime for the wing. Valid values are "SUBSONIC" (default) and "TRANSONIC". Setting surface to transonic adds more lift above mach number 0.6 by applying a Prandl/Glauert correction term to each surface-element. The effect is a more balanced lift/drag distribution reported by the solver. Use for anything that flies faster than mach 0.6 or has supercritical airfoils.
* '''mcrit:''' The critical mach number for the wing. This point defines the begin of exponential drag rise due to mach speed. Default "0.6", only available if flow="TRANSONIC".

'''Wing section support (since 2018.1):'''

Wing section support to define variable geometry (geometry parameters per section)
* More than one <wing>-element is allowed now.
* x, y, z, chord and incidence attribute shall be specifed only for the first <wing> in the XML file. They will be overridden for subsequent <wing>-elements.
* Use '''append="1"''' for additional '''wing''' elements to skip x, y, z, chord and incidence attribute as the will be calculated from previous '''wing''' element tip chord. This workaround is currently needed due to limitations in the XML parser.

==== hstab ====
These define the horizontal stabilizer of the aircraft. Internally, it is just a wing object and therefore works the same in XML.
You are allowed only one hstab object; the solver needs to know which wing's incidence to play with to get the aircraft trimmed correctly.

'''New in 2018.1:'''
* '''hstab''' supports sections in the same way '''wing''' does, but it is still considered as /the/ (only) hstab used by the solver.
* '''incidence-min-deg''' and '''incidence-max-deg''': optional attributes to limit valid result range fore the solver. Use with care or you won't get a solution.

==== vstab ====
A "vertical" stabilizer. Like hstab, this is just another wing, with a few special properties. The surface is not "mirrored" as are wing and hstab objects. If you define a left wing only, you'll only get a left wing. The default dihedral, if unspecified, is 90 degrees instead of zero. But all parameters are equally settable, so there's no requirement that this object be "vertical" at all. You can use it for anything you like, such as extra wings for biplanes. Most importantly, these surfaces are not involved with the solver computation, so you can have none, or as many as you like.

==== mstab ====
A mirrored horizontal stabilizer. Exactly the same as wing, but not involved with the solver computation, so you can have none, or as many as you like.

==== stall ====
A subelement of a wing (or hstab/vstab/mstab) that specifies the stall behavior.
* '''aoa:''' The stall angle (maximum lift) in degrees. Note that this is relative to the wing, not the fuselage (since the wing may have a non-zero incidence angle).
* '''width:''' The "width" of the stall, in degrees. A high value indicates a gentle stall. Low values are viscious for a non-twisted wing, but are acceptable for a twisted one (since the whole wing will not stall at the same time).
* '''peak:''' The height of the lift peak, relative to the post-stall secondary lift peak at 45 degrees. Defaults to 1.5. This one is deep voodoo, and probably doesn't need to change much. Bug me for an explanation if you're curious.

==== flap0, flap1, slat, spoiler ====
These are subelements of wing/hstab/vstab objects, and specify the location and effectiveness of the control surfaces.
* '''start:''' The position along the wing where the control surface begins.Zero is the root, one is the tip.
* '''end:''' The position where the surface ends, as above.
* '''lift:''' The lift multiplier for a flap or slat at full extension. One is a no-op, a typical aileron might be 1.2 or so, a giant jetliner flap 2.0, and a spoiler 0.0. For spoilers, the interpretation is a little different -- they spoil only "prestall" lift. Lift due purely to "flat plate" effects isn't affected. For typical wings that stall at low AoA's essentially all lift is pre-stall and you don't have to care. Jet fighters tend not to have wing spoilers, for exactly this reason. This value is not applicable to slats, which affect stall AoA only.
* '''drag:''' The drag multiplier, as above. Typically should be higher than the lift multiplier for flaps.
* '''aoa:''' Applicable only to slats. This indicates the angle by which the stall AoA is translated by the slat extension.

=== Rotor and rotorgear ===
YASim has also possibility to simulate rotorcraft blades. The number properties of rotor elements are large therefore are spitted to the separate page [[Howto:Make a helicopter#XML%20Elements|howto make a helicopter in YASim]].

=== Engine ===
==== Thruster ====
A very simple "thrust only" engine object. Useful for things like thrust vectoring nozzles. All it does is map its THROTTLE input axis to its output thrust rating. Does not consume fuel, etc...
* '''thrust:''' Maximum thrust in pounds
* '''x,y,z:''' The point on the airframe where thrust will be applied.
* '''vx,vy,vy:''' The direction of the thrust in airframe coordinates. The vector will be normalized automatically, so any non-zero vector will work fine.

Example:

<syntaxhighlight lang="xml" line>
<thruster x="0" y="0" z="0.03" vx="1" vy="0" vz="0" thrust="6.61">
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE" src0="-1" src1="1" dst0="-1" dst1="1"/>
</thruster>
</syntaxhighlight>

==== Jet ====
A turbojet/fan engine. It accepts a <control> subelement to map a property to its throttle setting, and an <actionpt> subelement to place the action point of the thrust at a different position than the mass of the engine.
* '''x,y,z:''' The location of the engine, as a point mass. If no actionpt is specified, this will also be the point of application of thrust.
* '''mass:''' The mass of the engine, in pounds.
* '''thrust:''' The maximum sea-level thrust, in pounds.
* '''afterburner:''' Maximum total thrust with afterburner/reheat, in pounds [defaults to "no additional thrust"].
* '''rotate:''' Vector angle of the thrust in degrees about the Y axis [0].
* '''n1-idle:''' Idling low pressure core / fan speed [55].
* '''n1-max:''' Maximum low pressure core / fan speed [102].
* '''n2-idle:''' Idling high pressure core speed [73].
* '''n2-max:''' Maximum high pressure core speed [103].
* '''tsfc:''' Thrust-specific fuel consumption [0.8]. This should be considerably lower for modern turbofans.
* '''atsfc:''' (version >= 2016.3.1) Thrust specific fuel consumption with afterburner on. When set to zero defaults to older behaviour where it is calculated from dry fuel consumption [0].
* '''egt:''' Exhaust gas temperature at takeoff in K [1050].
* '''epr:''' Engine pressure ratio at takeoff [3.0].
* '''exhaust-speed:''' The maximum exhaust speed in knots [~1555].
* '''spool-time:''' Time, in seconds, for the engine to respond to 90% of a commanded powersetting.

==== Propeller ====
A propeller. This element requires an engine subtag. Currently <piston-engine> and <turbine-engine> are supported.
* '''x,y,z:''' The position of the mass (!) of the engine/propeller combination. If the point of force application is different (and it will be) it should be set with an <actionpt> subelement.
* '''mass:''' The mass of the engine/propeller, in pounds.
* '''moment:''' The moment, in kg-metres^2. This has to be hand calculated and guessed at for now. A more automated system will be forthcoming. Use a negative moment value for counter-rotating ("European" -- CCW as seen from behind the prop) propellers. A good guess for this value is the radius of the prop (in meters) squared times the mass (kg) divided by three; that is the moment of a plain "stick" bolted to the prop shaft.
* '''radius:''' The radius, in meters, or the propeller.
* '''cruise-speed:''' The max efficiency cruise speed of the propeller. Generally not the same as the aircraft's cruise speed.
* '''cruise-rpm:''' The RPM of the propeller at max-eff. cruise.
* '''cruise-power:''' The power sunk by the prop at cruise, in horsepower.
* '''cruise-alt:''' The reference cruise altitude in feet.
* '''takeoff-power:''' The takeoff power required by the propeller...
* '''takeoff-rpm:''' ...at the given takeoff RPM.
* '''gear-ratio:''' The factor by which the engine RPM is multiplied to produce the propeller RPM. Optional (defaults to 1.0).
* '''contra:''' When set (contra="1"), this indicates that the propeller is a contra-rotating pair. It will not contribute to the aircraft's net gyroscopic moment, nor will it produce asymmetric torque on the aircraft body. Asymmetric slipstream effects, when implemented, will also be zero when this is set.

YASim assumes a fixed-pitch propeller by default. If your engine is using a constant-speed propeller, you'll also need to provide these attributes:

* '''min-rpm:''' The minimum operational RPM for a constant speed propeller. This is the speed to which the prop governor will seek when the blue lever is at a minimum. The coarse-stop attribute limits how far the governor can go into trying to reach this RPM.
* '''max-rpm:''' The maximum operational RPM for a constant speed propeller. See above. The fine-stop attribute limits how far the governor can go in trying to reach this RPM.
* '''fine-stop:''' The minimum pitch of the propeller (high RPM) as a ratio of ideal cruise pitch. This is set to 0.25 by default -- a higher value will result in a lower RPM at low power settings (e.g. idle, taxi, and approach).
* '''coarse-stop:''' The maximum pitch of the propeller (low RPM) as a ratio of ideal cruise pitch. This is set to 4.0 by default -- a lower value may result in a higher RPM at high power settings.

===== piston-engine =====

A piston engine definition. This must be a subelement of an enclosing <propeller> tag.

* '''eng-power:''' Maximum BHP of the engine at sea level.
* '''eng-rpm:''' The engine RPM at which eng-power is developed
* '''displacement:''' The engine displacement in cubic inches.
* '''compression:''' The engine compression ratio.

<syntaxhighlight lang="xml" line>
<piston-engine eng-power="2" eng-rpm="3800" displacement="20" >
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/>
<control-input axis="/controls/engines/engine[0]/starter" control="STARTER"/>
<control-input axis="/controls/engines/engine[0]/magnetos" control="MAGNETOS"/>
<control-input axis="/controls/engines/engine[0]/mixture" control="MIXTURE"/>
</piston-engine>
</syntaxhighlight>

===== electric-engine =====

A simplified electric DC engine model. The model is available since the end of April 2020, therefore it is currently available in daily build FlightGear snapshots. This definition must be a subelement of an enclosing <propeller> tag.

* '''Kv''' electric engine constant in revolutions per minute to volt.
* '''voltage''' The voltage applied to the motor e.g. Nominal battery voltage in Volts.
* '''Rm''' The engine winding resistance in Ohms.

Example:

<syntaxhighlight lang="xml" line>
<propeller x="0.02" y="0" z="0.03"
mass="0.05"
moment="0.0006"
radius="0.203"
cruise-speed="26"
cruise-rpm="7000"
cruise-power="0.5"
cruise-alt="2000"
takeoff-power="0.70"
takeoff-rpm="9200"
contra="1">
<actionpt x="0" y="0" z="0.03"/>
<electric-engine Kv="750" voltage="15" Rm="0.02" >
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/>
</electric-engine>
</propeller>
</syntaxhighlight>

=== Landing gear ===
==== gear ====
Defines a landing gear. Accepts <control> subelements to map properties to steering and braking. Can also be used to simulate floats. Although the coefficients are still called ..fric, it is calculated in fluids as a drag (proportional to the square of the speed). In fluids gears are not considered to detect crashes (as on ground).
* '''x,y,z:''' The location of the fully-extended gear tip.
* '''compression:''' The distance in metres along the "up" axis that the gear will compress.
* '''initial-load:''' The initial load of the spring in multiples of compression. Defaults to 0. (With this parameter a lower spring-constants will be used for the gear-> can reduce numerical problems (jitter)) '''Note:''' the spring-constant is varied from 0% compression to 20% compression to get continuous behavior around 0 compression. (could be physically explained by wheel deformation)
* '''upx/upy/upz:''' The direction of compression, defaults to vertical (0,0,1) if unspecified. These are used only for a direction -- the vector need not be normalized, as the length is specified by "compression".
* '''sfric:''' Static (non-skidding) coefficient of friction. Defaults to 0.8.
* '''dfric:''' Dynamic friction. Defaults to 0.7.
* '''stiction:''' Stiction to ground. Defaults to 0. stiction = "1" ensures the gear isn't sliding unintentionally (Note: please correct docu here for more detailed facts, developers didn't document this extension here and this is based on trial and guessing only)
* '''spring:''' A dimensionless multiplier for the automatically generated spring constant. Increase to make the gear stiffer, decrease to make it squishier.
* '''damp:''' A dimensionless multiplier for the automatically generated damping coefficient. Decrease to make the gear "bouncier", increase to make it "slower". Beware of increasing this too far: very high damping forces can make the numerics unstable. If you can't make the gear stop bouncing with this number, try increasing the compression length instead.
* '''on-water:''' if this is set to "0" the gear will be ignored if on water. Defaults to "0"
* '''on-solid:''' if this set to "0" the gear will be ignored if not on water. Defaults to "1"
* '''speed-planing:'''
* '''spring-factor-not-planing:''' At zero speed the spring factor is multiplied by spring-factor-not-planing. Above speed-planing this factor is equal to 1. The idea is, to use this for floats simulating the transition from swimming to planing. speed-planing defaults to 0, spring-factor-not-planing defaults to 1.
* '''reduce-friction-by-extension:''' at full extension the friction is reduced by this relative value. 0.7 means 30% friction at full extension. If you specify a value greater than one, the friction will be zero before reaching full extension. Defaults to "0"
* '''ignored-by-solver:''' with the on-water/on-solid tags you can have more than one set of gears in one aircraft, If the solver (who automatically generates the spring constants) would take all gears into account, the result would be wrong. E. G. set this tag to "1" for all gears, which are not active on runways. Defaults to "0". You can not exclude all gears in the solving process.

Will define two properties associated with compression of landing gear:

* '''compression-norm''' - range from 0..1, 0 means gear fully extended, 1 means fully compressed.
* '''compression-m''' - vertical distance in metres that the wheel has moved in order to be on top of ground; this will usually be different from the animation distance.

<syntaxhighlight lang="xml" line>


<gear x="0.0" y="0.0" z="-0.205"
spring="0.9"
damp="0.8"
dfric="0.9"
sfric="1.1"
compression="0.051">
<control-input axis="/controls/flight/rudder" control="STEER" square="true" src0="-1.0" src1="1.0" dst0="-0.3" dst1="0.3"/>
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/>
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/>
</gear>



<gear x="-0.4" y="0.25" z="-0.205"
spring="0.9"
damp="0.8"
dfric="0.9"
sfric="1.1"
compression="0.051">
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/>
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/>
</gear>

<gear x="-0.4" y="-0.25" z="-0.205"
spring="0.9"
damp="0.8"
dfric="0.9"
sfric="1.1"
compression="0.051">
<control-input axis="/controls/gear/brake-left" control="BRAKE" split="true"/>
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/>
</gear>
</syntaxhighlight>

===== Torus-shaped contact surface on next =====

On next as of 2022-3-19 one can specify a torus-shaped tyre contact surface using these new parameters:

* '''wheel-x'''
* '''wheel-y'''
* '''wheel-z'''
* '''wheel-radius''' (default 0)
* '''tyre-radius''' (default 0)
* '''wheel-axle-x'''
* '''wheel-axle-y'''
* '''wheel-axle-z'''

The contact point will be the lowest point on a torus with radius '''tyre-radius''' wrapped around a wheel with radius '''wheel-radius''' centred on point '''(wheel-x, wheel-y, wheel-z)''' with orientation defined by '''wheel-axle'''. This contact point will depend on the aircraft's orientation relative to the ground.

If not specified, '''wheel-axle''' defaults to (0, 1, 0), giving a conventional vertical wheel in line with the aircraft. Other values may allow modelling of, for example, a Bf109's non-vertical undercarriage.

Default values of zero for wheel-radius and tyre-radius give a fixed contact point at (wheel-x, wheel-y, wheel-z).

If an aircraft also specifies an old-style contact point with '''(x, y, z)''' it will work with both new and old builds of Flightgear.

==== Launchbar ====
Defines a catapult launchbar or strop.
* '''x,y,z:''' The location of the mount point of the launch bar or strop on the aircraft.
* '''length:''' The length of the launch bar from mount point to tip
* '''down-angle:''' The max angle below the horizontal the launchbar can achieve.
* '''up-angle:''' The max angle above the horizontal the launchbar can achieve.
* '''holdback-{x,y,z}:''' The location of the holdback mount point on the aircraft.
* '''holdback-length:''' The length of the holdback from mount point to tip. Note: holdback up-angle and down-angle are the same as those defined for the launchbar and are not specified in the configuration.

=== Fuel ===
==== tank ====
A fuel tank. Tanks in the aircraft are identified numerically (starting from zero), in the order they are defined in the file. If the left tank is first, "tank[0]" will be the left tank.
* '''x,y,z:''' The location of the tank.
* '''capacity:''' The maximum contents of the tank, in pounds. Not gallons -- YASim supports fuels of varying densities.
* '''jet:''' A boolean. If present, this causes the fuel density to be treated as Jet-A. Otherwise, gasoline density is used. A more elaborate density setting (in pounds per gallon, for example) would be easy to implement. Bug me.

=== Center of Gravity ===
==== Ballast ====
This is a mechanism for modifying the mass distribution of the aircraft. A ballast setting specifies that a particular amount of the empty weight of the aircraft must be placed at a given location. The remaining non-ballast weight will be distributed "intelligently" across the fuselage and wing objects. Note again: this does NOT change the empty weight of the aircraft.
* '''x,y,z:''' The location of the ballast.
* '''mass:''' How much mass, in pounds, to put there. Note that this value can be negative. I find that I often need to "lighten" the tail of the aircraft.

<syntaxhighlight lang="xml" line>
<ballast x="-0.24" y="0.0" z="0.33" mass-kg="0.5"/>
</syntaxhighlight>

==== Weight ====
This is an added weight, something not part of the empty weight of the aircraft, like passengers, cargo, or external stores. The actual value of the mass is not specified here, instead, a mapping to a property is used. This allows external code, such as the panel, to control the weight (loading a given cargo configuration from preference files, dropping bombs at runtime, etc...)
* '''x,y,z:''' The location of the weight.
* '''mass-prop:''' The name of the fgfs property containing the mass, in pounds, of this weight.
* '''size:''' The aerodynamic "size", in metres, of the object. This is important for external stores, which will cause drag. For reasonably aerodynamic stuff like bombs, the size should be roughly the width of the object. For other stuff, you're on your own. The default is zero, which results in no aerodynamic force (internal cargo).
* '''solve-weight:''' Subtag of approach and cruise parameters. Used to specify a non-zero setting for a <weight> tag during solution. The default is to assume all weights are zero at the given performance numbers.
* '''idx:''' Index of the weight in the file (starting with zero).
* '''weight:''' Weight setting in pounds.

<syntaxhighlight lang="xml" line>
<weight x="-0.06471" y="0.225" z="-0.2" mass-prop="/sim/weight[0]/weight-kg"/>
</syntaxhighlight>

=== Controls ===
==== control-input ====
This element manages a mapping from fgfs properties (user input) to settable values on the aircraft's objects. Note that the value to be set MUST (!) be valid on the given object type. This is not checked for by the parser, and will cause a runtime crash if you try it. Wing's don't have throttle controls, etc... Note that multiple axes may be set on the same value. They are summed before setting.
* '''axis:''' The name of the double-valued fgfs property "axis" to use as input, such as "/controls/flight/aileron".
* '''control:''' Which control axis to set on the objects. It can have the following values:
** THROTTLE - The throttle on a jet or propeller.
** MIXTURE - The mixture on a propeller.
** REHEAT - The afterburner on a jet
** PROP - The propeller advance
** BRAKE - The brake on a gear.
** STEER - The steering angle on a gear.
** INCIDENCE - The incidence angle of a wing.
** FLAP0 - The flap0 deflection of a wing.
** FLAP1 - The flap1 deflection of a wing.
** SLAT - The slat extension of a wing.
** SPOILER - The spoiler extension for a wing.
** CYCLICAIL - The "aileron" cyclic input of a rotor
** CYCLICELE - The "elevator" cyclic input of a rotor
** COLLECTIVE - The collective input of a rotor
** ROTORENGINEON - If not equal zero the rotor is rotating
** WINCHRELSPEED - The relative winch speed
** {... and many more, see [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/FDM/YASim/ControlMap.cpp#l25 ControlMap.cpp] ...}
* '''invert:''' Negate the value of the property before settling on the object.
* '''split:''' Applicable to wing control surfaces. Sets the normal value on the left-wing, and a negated value on the right-wing.
* '''square:''' Squares the value before setting. Useful for controls like a steering that needs a wide range, yet lots of sensitivity in the center. Obviously only applicable to values that have a range of [-1:1] or [0:1].
* '''src0/src1/dst0/dst1:''' If present, these define a linear mapping from the source to the output value. Input values in the range src0-src1 are mapped linearly to dst0-dst1, with clamping for input values that lie outside the range.

==== control-output ====
This can be used to pass the value of a YASim control axis (after all mapping and summing is applied) back to the property tree.
* '''control:''' Name of the control axis. See above.
* '''prop:''' Property node to receive the value.
* '''side:''' Optional, for split controls. Either "right" or "left"
* '''min/max:''' Clamping applied to output value.

==== control-speed ====
Some controls (most notably flaps and hydraulics) have maximum slew rates and cannot respond instantly to pilot input. This can be implemented with a control-speed tag, which defines a "transition time" required to slew through the full input range. Note that this tag is semi-deprecated, complicated control input filtering can be done much more robustly from a Nasal script.
* '''control:''' Name of the control axis. See above.
* '''transition-time:''' Time in seconds to slew through input range.

==== control-setting ====
This tag is used to define a particular setting for a control axis inside the <cruise> or <approach> tags, where obviously property input is not available. It can be used, for example, to inform the solver that the approach performance values assume full flaps, etc...
* '''axis:''' Name of the control input (i.e. a property name)
* '''value:''' Value of the control axis.

=== Winch and Aerotow ===
==== hitch ====
A hitch, can be used for winch-start (in gliders) or aerotow (in gliders and motor aircraft) or for external cargo with helicopter. You can do aerotow over the net via multiplayer (see j3 and bocian as an example).
* '''name:''' the name of the hitch. must be aerotow if you want to do aerotow via multiplayer. You will find many properties at /sim/hitches/name. Most of them are directly tied to the internal variables, you can modify them as you like. You can add a listener to the property "broken", e. g. for playing a sound.
* '''x,y,z:''' The position of the hitch
* '''force-is-calculated-by-other:''' if you want to simulate aerotowing over the internet, set this value to "1" in the motor aircraft. Don't specify or set this to zero in gliders. In a LAN the time lag might be small enough to set it on both aircraft to "0". It's intended, that this is done automatically in the future.
==== tow ====
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.
* '''length:''' upstretched length in metres
* '''weight-per-meter:''' in kg/metre
* '''elastic-constant:''' lower values give higher elasticity
* '''break-force:''' in N
* '''mp-auto-connect-period:''' the every x seconds a towed multiplayer aircraft is searched. If found, this tow is connected automatically, parameters are copied from the other aircraft. Should be set only in the motor aircraft, not in the glider
==== winch ====
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.
* '''max-tow-length:''' in m
* '''min-tow-length''': in m
* '''initial-tow-length:''' in m. The initial tow length also defines the length/search radius used for the mp-autoconnect feature
* '''max-winch-speed:''' in m/s
* '''power:''' in kW
* '''max-force:''' in N

<syntaxhighlight lang="xml" line>
<hitch name="winch" x="0.0" y="0.0" z="0.0">
<tow length="50" weight-per-meter="0.0035" elastic-constant="40000" break-force="10000"/>

<winch max-tow-length="1000" min-tow-length="1" initial-tow-length="1000" max-winch-speed="20" power="2" max-force="80"/>
<control-input axis="/controls/winch/place" control="PLACEWINCH"/>
</hitch>
<hitch name="aerotow" x="0.0" y="0.0" z="0.0" force-is-calculated-by-other="0">
<tow length="60" weight-per-meter="0.0035" elastic-constant="9000" break-force="100" mp-auto-connect-period="0.0"/>
<winch max-tow-length="1000" min-tow-length="60" initial-tow-length="60"/>
<control-input axis="/controls/aerotow/find-aircraft" control="FINDAITOW"/>
</hitch>
</syntaxhighlight>

== Visualization ==

=== Blender visualization tool ===

[[File:Yasim_visualisation_dc6.png|thumb|dc6 FDM in Blender]]To make the programmed aircraft visible it is possible to load and compare it with the 3D model within [[Blender]]. They applaud for this ''very'' useful script goes to M. Franz, thank you very much!

For Blender versions <= 2.4 the script is located in FlightGears source code {{flightgear file|utils/Modeller/yasim_import.py}}.

For Blender versions newer than 2.4, please see [[Blender YASim import]].

The howto, taken from inside the script:

yasim_import.py loads and visualizes a YASim FDM geometry
=========================================================

It is recommended to load the model superimposed over a greyed out and immutable copy of the aircraft model:

(0) put this script into ~/.blender/scripts/
(1) load or import aircraft model (menu -> "File" -> "Import" -> "AC3D (.ac) ...")
(2) create new *empty* scene (menu -> arrow button left of "SCE:scene1" combobox -> "ADD NEW" -> "empty")
(3) rename scene to yasim (not required)
(4) link to scene1 (F10 -> "Output" tab -> arrow button left of text entry "No Set Scene" -> "scene1")
(5) now load the YASim config file (menu -> "File" -> "Import" -> "YASim (.xml) ...")

This is good enough for simple checks. But if you are working on the YASim configuration, then you need a
quick and convenient way to reload the file. In that case, continue after (4):

(5) switch the button area at the bottom of the blender screen to "Scripts Window" mode (green python snake icon)
(6) load the YASim config file (menu -> "Scripts" -> "Import" -> "YASim (.xml) ...")
(7) make the "Scripts Window" area as small as possible by dragging the area separator down
(8) optionally split the "3D View" area and switch the right part to the "Outliner"
(9) press the "Reload YASim" button in the script area to reload the file

If the 3D model is displaced with respect to the FDM model, then the <offsets> values from the
model animation XML file should be added as comment to the YASim config file, as a line all by
itself, with no spaces surrounding the equal signs. Spaces elsewhere are allowed. For example:

<offsets>
<x-m>3.45</x-m>
<z-m>-0.4</z-m>
<pitch-deg>5</pitch-deg>
</offsets>

becomes:



Possible variables are:

x ... <x-m>
y ... <y-m>
z ... <z-m>
h ... <heading-deg>
p ... <pitch-deg>
r ... <roll-deg>

Of course, absolute FDM coordinates can then no longer directly be read from Blender's 3D view.
The cursor coordinates display in the script area, however, shows the coordinates in YASim space.
Note that object names don't contain XML indices but element numbers. YASim_hstab#2 is the third
hstab in the whole file, not necessarily in its parent XML group. A floating-point part in the
object name (e.g. YASim_hstab#2.004) only means that the geometry has been reloaded that often.
It's an unavoidable consequence of how Blender deals with meshes.

Elements are displayed as follows:

cockpit -> monkey head
fuselage -> blue "tube" (with only 12 sides for less clutter); center at "a"
vstab -> red with yellow flaps
wing/mstab/hstab -> green with yellow flaps/spoilers/slats (always 20 cm deep);
symmetric surfaces are only displayed on the left side
thrusters (jet/propeller/thruster) -> dashed line from center to actionpt;
arrow from actionpt along thrust vector (always 1 m long);
propeller circle
rotor -> radius and rel_len_blade_start circle, direction arrow,
normal and forward vector, one blade at phi0
gear -> contact point and compression vector (no arrow head)
tank -> cube (10 cm side length)
weight -> inverted cone
ballast -> cylinder
hitch -> circle (10 cm diameter)
hook -> dashed line for up angle, T-line for down angle
launchbar -> dashed line for up angles, T-line for down angles
A note about step (0) for Windows users: the mentioned path is inside the folder where Blender lives, something like <code>C:\Program Files\Blender Foundation\Blender\.blender\scripts</code>.

=== Visualize model in OpenSCAD or FreeCAD ===

There exist a possibility to display the YASim XML elements in the OpenSCAD or FreeCAD tools. This could be extremely useful in the case of UAV aircraft development.

* [https://github.com/ThunderFly-aerospace/YASim2SCAD YASim2SCAD] - This tool converts YASim XML to scad file which could be displayed as an overlay in OpenSCAD or FreeCAD project.
* [https://gitlab.com/yasimtoscad/yasimtoscad yasimtoscad] - Another tool to convert YASim XML to scad file which could be displayed as an overlay in OpenSCAD.

=== Visualization tools ===

* [https://github.com/bitwisetech/ysimi YSIMI] Interactive Tuning Tools for FlightGear's YASIM Flight Dynamics Model
* [https://github.com/bitwisetech/yasiVers yasiVers] is a tool for visualization of YASim calculations.

== Export of YASim internals to property tree ==
Ever wondered what is going on inside yasim? See the property tree under /fdm/yasim/

Some information is static and shows what yasim has compiled from your XML.
Other information is "run-time" like forces, speed, acceleration, c.g.

If note noted otherwise:
* expect metric unit (meter, kilogram, newton, ...)
* expect minimum version 2017.2

{| class="wikitable"
|-
! Path !! Description !! Information type !! min. version
|-
| accelerations/ || linear and rot. accelerations in aircraft coord. || run time ||
|-
| debug/ || misc internals, for now subject to change without notice || run time || 2018.1
|-
| forces/ || aerodynamic forces in N || run time ||
|-
| velocities/ || linear and rot. velocities in aircraft coord. || run time ||
|-
| model/cg-x-range-aft || desired CG range || compile time ||
|-
| model/cg-x-range-front || desired CG range || compile time ||
|-
| model/cg-x-max || CG hard limit from gear position || compile time ||
|-
| model/cg-x-min || CG hard limit from gear position || compile time ||
|-
| model/masses || shows the calculated mass points || compile time ||
|-
| model/wings || wing parameters || compile time ||
|}

== Command Line ==
=== Windows ===
By using the standard command line, we can see what the YASim solver is calculating. First, open up Command Prompt, enter in the location of yasim.exe, and then the location of the YASim XML file. For example, here's what you would type in for a standard Windows [[Changelog_2.12|FlightGear 2.12.0]] installation, and viewing the [[F-14_Tomcat|F-14B's]] YASim file.
{{Note|You can copy & paste the examples into Command Prompt by right-clicking on the title and navigate to Edit > Paste. Then, click Enter to execute.}}

<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml"</code>

The results will give many different values.

* '''Drag Coefficient:''' The drag coefficient of the aircraft.
* '''Lift Ratio:''' The lift ratio of the aircraft.
* '''Cruise AoA:''' The cruise AoA, from conditions at [[YASim#cruise|<cruise>]] in the xml file.
* '''Tail Incidence:''' The incidence angle of the tail, "solved" by YASim as a way to stabilize the aircraft.
* '''Approach Elevator:''' The approach elevator, from conditions at [[YASim#approach|<approach>]] in the xml file.
* '''CG:''' Center of gravity of the aircraft in coordinates. Unless it's supposed to be offset, it should always have a Y value of 0.

The YASim standalone solver also has some command line flags that change it's behaviour.

<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 490</code>

* '''-g:''' Instructs YASim to generate space-separated tabular data instead of the usual solver output. This can be redirected to a file and used in various plotting programs to visualize the actual lift, drag, L/D curves. The columns of the output from left to right are: AoA, Lift, Drag, L/D. (aoa in degrees, lift and drag in G's).
* '''-a <altitude in meter:>''' Run the solver at the given altitude in meter.
* '''-s <speed in knots>:''' Also run at the given airspeed in knots.

{{Note|The values generated by this method are for the aircraft taken as a whole, as solved by YASim, so they differ from the values of the wing airfoil.}}

To get the tabular output for the example above at 1000 m and 150 knots, and to redirect this to a file, one would issue:

<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 150 > "C:\Program Files\FlightGear\yasim.txt"</code>

== New features and bugfixes in version 2017.2 ==

=== XML parser ===
==== support for metric and imperial units ====
To make life easier for aircraft developers, the parser supports new additional attributes with a unit suffix, e.g. speed-kt for knots and speed-kmh for kilometers per hour.
* <code><airplane {mass, mass-lbs, mass-kg}="12345" ></code>
* <code><approach {speed, speed-kt, speed-kmh}="123" ></code>
* <code><cruise {speed, speed-kt, speed-kmh}="123" ></code>
* <code><solve-weight {weight, weight-lbs, weight-kg}="123" ></code>
* <code><jet {mass, mass-lbs, mass-kg}="1234" ></code>
* <code><tank {capacity, capacity-lbs, capacity-kg}="12345" ></code>
* <code><ballast {mass, mass-lbs, mass-kg}="1234" ></code>

{{Note|Aircraft using this new attributes will not run on older versions of FlightGear, so it is probably wise to publish those only after a reasonable number of users switched version 2017.2 or newer.}}

==== CG tuning help ====
{{Note| The feature described in this section is not fully implemented yet, however, it may be of some help already.
It is currently implemented for the yasim CLI tool only. It does not affect the airplane behaviour while running FlightGear. }}

New attributes have been added to <airplane> to assist tuning the center of gravity (CG).
The CG position is often expressed relative to the [https://en.wikipedia.org/wiki/Chord_(aeronautics)#Mean_aerodynamic_chord MAC] of the wing in percent. You can specify a desired range for CG in % relative to MAC, it will show up in the output of the yasim CLI tool (see example below):

* cg-min: default 25% (just a guess, better numbers are welcome)
* cg-max: default 30% (just a guess, better numbers are welcome)

{{Note| By convention 0% is leading edge, 100% is trailing edge, however the absolute values on x-axis are the other way round, e.g. nose is +x, tail is -x }}
{{warning|The MAC calculation in version 2017.2 works only on the <wing> element. Numbers will be wrong, if your model uses a combination of <wing> and <mstab> to build a wing with two or more sections.
Section support will be added in version 2018.1}}
YASim will print the leading edge coordinates of the MAC (x,y) and its length.

'''Example output'''
<pre>
$ yasim Citation-II-yasim.xml
This aircraft uses yasim version '2017.2'
==========================
= YASim solution results =
==========================
Iterations: 2210
Drag Coefficient: 12.304669
Lift Ratio: 85.317558
Cruise AoA: 4.016746 deg
Tail Incidence: -3.053278 deg
Approach Elevator: -0.377542

CG: x:-6.543, y:-0.000, z:0.044
Wing MAC (*1): x:-6.00, y:3.83, length:2.0
CG-x rel. MAC: 0.272
CG-x desired: -6.599 < -6.543 < -6.198

Inertia tensor [kg*m^2], origo at CG:

18009.289, -0.000, 7120.470
-0.000, 42459.316, 0.000
7120.470, 0.000, 56980.656

(*1) MAC calculation works on <wing> only! Numbers will be wrong for segmented wings, e.g. <wing>+<mstab>.
</pre>

=== Aircraft developer helpers ===
The command line utility got some new options. For some strange reason, the -a parameter expects altitude in meters instead of ft. This is now visible in the usage message but left unchanged for compatibility.
<syntaxhighlight>Usage:
yasim <aircraft.xml> [-g [-a meters] [-s kts] [-approach | -cruise] ]
yasim <aircraft.xml> [-d [-a meters] [-approach | -cruise] ]
yasim <aircraft.xml> [-m]
-g print lift/drag table: aoa, lift, drag, lift/drag
-d print drag over TAS: kts, drag
-a set altitude in meters!
-s set speed in knots
-m print mass distribution table: id, x, y, z, mass</syntaxhighlight>

=== Bugfixes ===
The following bugfixes require <airplane version="2017.2"> for backward compatibility
* Ground effect: corrected the calculation of the height where g.e. ends
* Stall parameters were set wrong for wings with camber=0

== New features and bugfixes in version 2018.1 ==
The following is under development and hopefully finds its way into FG version 2018.1

=== Wing Section Support ===
Many airliners have wings with a geometry that is just a little more complex than what YASim supported initially (tapered wing with some angles like sweep, dihedral, ...), e.g. they have an inboard section and an outboard section that can be described with YASim wing syntax. You can use a wing + a mstab XML element to describe this geometry but it is easier if YASim can just append more wing sections by simply adding more wing XML elements. This is now (Version 2018.1) possible, yasim will simply append sections if it finds more than one wing or hstab in the XML.
You should use '''<wing append="1" ... >''' for all but the first wing/hstab declaration.
{{Note|YASim will ignore the root point (x,y,z), the chord length and the incidence attributes, if you add "append" and calculate those from the previous wing section. }}
MAC calculation works for the whole wing.

{{warning|Aircrafts using this feature will not work with older versions of flightgear. }}
To keep the aircraft backward compatible for a while, it is recommended to create a copy of its yasim XML file for development.
Once you are happy with the CG and wing parameters you can use the output of the YASim CLI tool to modifiy the original XML.
The tool will output the needed x,y,z etc per wing section to create a XML in old format with (only one) <wing> + <mstab>.

=== More information from CLI tools ===
You should configure the maximum take of weight (MTOW) in your XML file by adding either ''mtow-lbs'' or ''mtow-kg'' attribute to the airplane:

<code> <airplane mass="7500" version="2018.1" mtow-lbs="12500"> </code>

'''Example output'''
<pre>
yasim CRJ700.xml
==========================
= YASim solution results =
==========================
Iterations : 1024
Drag Coefficient : 17.707
Lift Ratio : 145.841
Cruise AoA : -0.11 deg
Tail Incidence : 3.47 deg
Approach Elevator : -0.792

CG : x:-0.046, y:0.000, z:-1.222
Wing MAC : (x:0.79, y:4.99), length:3.4
hard limit CG-x : 14.232 m
soft limit CG-x : -0.058 m
CG-x : -0.046 m
CG-x rel. MAC : 25%
soft limit CG-x : -0.228 m
hard limit CG-x : -0.986 m

wing lever : -0.012 m
tail lever : -13.997 m

max thrust : 157.18 kN
thrust/empty : 0.81
thrust/mtow : 0.49

wing span : 22.64 m
sweep lead. edge : 30.2 .. 30.6 deg
wing area : 58.70 m^2
wing load empty : 336.15 kg/m^2 (Empty 19731 kg)
wing load MTOW : 562.18 kg/m^2 (MTOW 32999 kg)

tail span : 8.533 m
tail area : 14.838 m^2

#wing sections: 2
Section 0 base point (0.450, 1.226, -2.034), chord 5.085, incidence at section root 5.0deg
Section 1 base point (-0.663, 4.754, -1.942), chord 3.204, incidence at section root 3.0deg

Inertia tensor [kg*m^2], origo at CG:

195646, 0, 122265
0, 1757279, 0
122265, 0, 1904528
</pre>

=== Variable tail incidence / elevator trim ===
Small GA aircrafts usually trim with a trim tab on the elevator. For efficiency, airliners normally do not trim the elevator ("flap")
but rotate the whole stabilizer (=tail) wing, e.g. they change the incidence for this wing. While this feature was somehow foreseen,
it was not implemented yet, most likely because the "tail incidence" is one of the free variables used by the YASim solver.
However, it is possible now to use the control="INCIDENCE" within the <hstab> to implement an alternative trim '''while maintaining full elevator authority'''.
<pre>
<hstab ... incidence-min-deg="-13.0" incidence-max-deg="2.0">
...
<control-input axis="/controls/flight/hstab-trim" control="INCIDENCE" />
<control-speed control="INCIDENCE" transition-time="20.0" />
<control-output control="INCIDENCE" prop="/surface-positions/hstab-rad" />
</hstab>
</pre>
{{Note|The control output of INCIDENCE is the angle in radians, not in degree, as that is the unit internally used by YASim.}}
{{warning|The OPTIONAL incidence-min-deg and incidence-max-deg set the limits for the solver. You must make sure to select a sufficiently large range or solver will fail. }}
First experiments with this feature were successful in that the aircraft pitch could be changed as expected but fine tuning will be necessary.

== Related content ==
* [[Howto:Make a helicopter#XML Elements]] – Rotor and rotorgear YASim elements
* [[Towing]]
* [[YASim Development Tools]]

== External links ==
* {{cite web
| url = http://www.buckarooshangar.com/flightgear/yasimtut.html
| title = Guide to YASim
| first = Gary R. "Buckaroo"
| last = Neely
| authorlink = http://www.buckarooshangar.com/flightgear/
| date = 2013
| accessdate = April 16, 2020
}} - A very helpful guide
* {{cite web
| url = https://sourceforge.net/projects/dacpei/
| title = DACPEI
| author = pytoche
| date = February 2012
| publisher = SourceForge
| accessdate = April 16, 2020
}} - A fixed wing light aircraft WYSIWUG concept design suite that can export an YASim FDM to FlightGear.

{{FDM}}

[[Category:Flight Dynamics Model]]

[[fr:YASim]]

FlightGear Newsletter July 2023

2023-07-21T22:32:06Z

KJ7RRV: /* Create photoreal scenery in 10 minutes (simplified) */ an~adir traduccio`n a espan~ol / add translation to spanish

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

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

== Development news ==






=== VIDEOTUTORIAL - (EASY) ===
=== Create photoreal scenery in 10 minutes (simplified) ===
Taking as a reference the extensive documentation published by Adriano Bassignana [[Julia photoscenery generator|Julia Photoscenery Generator]], in this video tutorial '''I have simplified the tasks in such a way that anyone without experience can create the local scenery they want,''' and in a few minutes it will appear auto-installed in Flightgear. '''AS SIMPLE AS THAT!!'''

https://youtu.be/PbYAvxmAkIc

(Subtitles in Spanish, French and English / Sous-titres en espagnol, français et anglais / Subtítulos en español, francés, y inglés)

== In the hangar ==


=== A new Mirage IIIE continues to advance! ===
[[File:Base Profile Screenshot 2023.07.13 - 16.09.24.61.png|thumb|375x375px|Mirage IIIEE preview]]

===[https://youtu.be/HKnQm0lrTvU VIDEO new Mirage IIIE flying over LECO]===
[[File:Base Profile Screenshot 2023.07.13 - 16.08.32.53.png|thumb|375x375px|Spanish Mirage IIIEE (1970) with a Matra R-530 missile and a pair of Sidewinders AIM-9B]]
==== These are the new improvements introduced during the last days: ====

* UV readjustment and '''texture improvement'''
*'''Fixed dimensions''' of the fuselage and wings
* Added '''cannons''' and their fairings (already non firing)
* Added several air inlets and outlets at the bottom of the fuselage
* Improvement (almost from scratch) of the '''atomic bomb AN-52''' (already non bombable)
* New detailed models of the '''Matra R-530 missile''' and '''AIM-9B Sidewinder''', and their mounts, accessible via the menu.
* Improvement of the '''500 L supersonic tanks'''
* New models of '''RP62 and RP30 tanks of 1300 and 1700 L'''
* Readjustment of position and navigation light positions to now exactly match the model

==== The following (finally) tasks are: ====

* Integrate particular elements to unify it with the existing versions of Mirage III NG and Mirage V
* Update configuration documents to a new version of E. Baranger, including autostart, procedural lights, new afterburner effects, etc.
* Integrate a new improved cockpit with realistic textures
* Auxiliary air intakes must open and close simultaneously with the landing gear
* Complete the actual upgrade of landing gear
* Correct location of lower airbrakes
* Add detail to the landing gear wells and covers
* New textures or "liveries" for France and Spain. Probably later for Argentina and South Africa
* Continue to refine the model and add minor details.
* New sound files, if possible obtained from the SNECMA-ATAR 9C engine

Greetings from Manuel ACE







== Scenery corner ==

=== VIDEOTUTORIAL - (EASY) ===

=== Create photoreal scenery in 10 minutes (simplified) ===
Taking as a reference the extensive documentation published by Adriano Bassignana [[Julia photoscenery generator|Julia Photoscenery Generator]], in this video tutorial '''I have simplified the tasks in such a way that anyone without experience can create the local scenery they want,''' and in a few minutes it will appear auto-installed in Flightgear. '''As simple as that!!'''

https://youtu.be/PbYAvxmAkIc















== Help wanted ==
{{Help wanted}}

== AI ==


The AI team makes FlightGear more realistic, colorful and lively every month. You can support the development of ''Interactive Traffic'' and contribute at the FlightGear {{forum link|title=AI|f=23}}.



== Community news ==








=== FlightGear on Facebook ===
Since early December 2010, FlightGear has an [https://www.facebook.com/FlightGear official Facebook page]. If you have a Facebook account please feel free to join the page.

=== FlightGear on Instagram ===
In January 2018 the [https://www.instagram.com/flightgear_sim/ @flightgear_sim Instagram account] was brought back to life. If you've got nice screenshots to be featured, feel free to {{forum link|text=contact the maintainer|t=33636}}.

=== FlightGear on FlightSim.com ===
FlightGear has also a [https://www.flightsim.com/vbfs/forumdisplay.php?102-FlightGear sub-forum] on flightsim.com - just like the commercial flight sims. It is an opportunity to showcase what FG can do, get people curious and answer any questions they may have with regard to the software or the project.

== Multiplayer events ==









== Contributing ==
=== Translators needed ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====

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

''Thanks for reading {{PAGENAME}}!''

{{Appendix}}


[[Category:Changes after 2020.3]]
[[Category:FlightGear Newsletter|2023 07]]

Howto:Build a yoke in 5 minutes

2023-07-17T02:06:20Z

KJ7RRV:

[[File:Mouse yoke.jpg|thumb|270px]]
Using some every-day equipment and an optical mouse, you can '''build a''' (basic) '''yoke in just five minutes'''! The yoke can be directly used in [[FlightGear]].

== Original version ==

=== Required components ===

* The right sized cardboard box
* 1 empty paper towel/gladwrap/foil roll
* 1 piece of packing foam that loosely resembles a yoke
* 1 optical mouse
* 1 roll of sticky tape
* 1 pencil
* A pairing knife

=== Instructions ===

# Using your roll (now referred to as the control column) as a guide, mark and cut a hole in the front and rear of the box for the control column to slide through.
# Mark out the centre of your foam yoke, but cut the hole slightly smaller and force the yoke on to the control column. There should be enough friction for it to not need glue.
# Place the mouse on top of the box, with the mouse backwards to how you'd normally use it (so that the buttons are facing you), mark its outline on the box, and cut a hole.
# Insert the control column/yoke assembly through the holes you made, place the mouse into the cut out you made for it and tape it in, taping around the edge of the mouse so that it won't rock sideways.
# The final step in construction is to limit the control throw. (This is not pictured in the photo. It is not technically necessary, but without it, you must be careful not to exceed the limit of control throw in FlightGear.) Use your knife to drill two small holes in the top and bottom of the end of the control column that is protruding from the back of the box. Insert a pencil through them so that most of the pencil is in the air, and just the tip is pointing downwards. This will stop the control column from coming out with too much up elevator, and will also limit the aileron when the pencil hits the desk. Full aileron will be just over 90 degrees, which is the same as a Cessna, so it'll be pretty realistic.
# You'll also need to reduce your mouse (control mode) sensitivity in FG so that it can never reach full aileron or elevator. This is very important, because if you don't it'll go out of alignment as soon as you reach it.
# It will also go out of alignment after a while, especially if you make very fast control inputs on a slow computer, so configure a mouse button to centre the controls. When it goes out of alignment, just centre your yoke and tap the mouse button.
# Make sure your yoke is centred when you start the sim.

== KJ7RRV's version ==

I made a yoke based on this design, but with a few changes.

=== Required components ===

* 1-inch or larger wooden dowel rod, as straight as possible (exact diameter is not important)
* Cardboard box large enough to run the dowel through while leaving at least an inch or so on each side
* Something to use as a yoke (a piece of cardboard works but is not ideal)
* An optical mouse that you're willing to take apart (it won't work as a mouse when you're done)
* A pencil
* A knife to cut the box
* Hot glue

=== Instructions ===

# Cut circular holes with the same diameter as the dowel rod centered in the front and back of the box. Choose one side to be the back, and cut a small notch at the bottom of the hole in the back.
# Cut a hole the size of the dowel rod in the center of your yoke. Unless your yoke is made of foam or a similar material, you will probably need to use glue.
# Disassemble the mouse and take the circuit board out, leaving the cable connected. If there are optics left in the case, cut down the mouse case to just the part needed to hold the optics and circuit board together. Use some tape to hold the board to the case if needed.
# Put the mouse board in the box and run the cable out the back.
# Insert the control column/yoke assembly through the holes you made in the box. Make sure the mouse cord goes in the notch in the back hole.
# Use hot glue to hold the mouse board to the side of the box with it touching the control column. Make sure the buttons are facing toward the yoke, and that the board is straight.
# The same issues with centering apply to this design. I have not yet limited the control throw in this design.

== Resources ==
* [https://forum.flightgear.org/viewtopic.php?f=3&t=1956 FlightGear forum topic for original design]

[[Category:Cockpit building|yoke Build a in 5 minutes]]
[[Category:Howto|yoke Build a in 5 minutes]]

Fr/Howto:Carrier

2023-07-14T18:23:19Z

KJ7RRV:

Au cours des années, [[Fr/FlightGear|FlightGear]] a reçu de plus en plus d'avion capable d'apponter sur un porte-avion et d'en décoller. Ce qui permet au pilote de simuler la plupart des opérations liées a un porte avion, que cela soit un appontage, un catapultage ou même utiliser les ascenseur pour déplacer l'avion dans le hangar, tout cela est possible !

==Fonctionalités==
[[File:Carrier3.jpg|thumb|300px|Le porte-avion Nimitz dans la baie de San Francisco]]

* Demarer le jeu avec votre avion directement poser sur un porte-avion de votre choix
* Catapultage des avions
* Possibilité de contrôler le porte-avion pour qu'il se place au mieux en fonction du vent
* Utiliser le système de navigation militaire '''TACAN''' pour se diriger vers le porte avion et facilité l'approche
* Appontage et freinage a l'aide des câble du pont et du crochet d'arrimage de l'appareil.
* Pouvoir utiliser l’ascenseur pour placer son appareil dans le hangar sous le pont du porte-avion.

== Commencer sur un porte-avion ==
Il faut noter que seulement certains avions sont compatibles la simulation de porte avion, mais toutefois le [[Hawker Seahawk|Seahawk]] fait parti des plus simple pour cette tache, idéal pour un débutant. Vous pouvez lancez FlightGear avec une ligne de commande ou avec l'interface graphique de lancement du jeu.

=== Avec la ligne de commande ===
Pour positionner votre avion sur le porte-avion dès le démarage, utilisez les commandes suivantes aux cotés de vos options habituelles. Ces commandes permettent de lancer le jeu en activant le scénario du '''Nimitz''' puis de commencer directement sur ce porte-avion avec le '''Seahawk''' comme avion (dans l'exemple qui suit). Vous pouvez simplement copier coller cette commande, les slash mettrons le tout sur la même ligne de commande :
--ai-scenario=nimitz_demo \
--carrier=Nimitz \
--aircraft=seahawk \

Pensez a bien mettre un "'''N'''" majuscule dans la commande <tt>--carrier=Nimitz</tt>.

Les positions de départ (optionnelles) sont aussi disponibles :
--parkpos=cat-1
--parkpos=cat-2
--parkpos=cat-3
--parkpos=cat-4
--parkpos=park-1

=== Interface de lancement graphique pour Mac OS X ===
Si vous utilisez l'Interface de lancement graphique pour Mac OS X pour lancer FlightGear, vous devriez trouver une zone de saisie de texte dans l'interface graphique qui vous permet de rajouter des lignes de commandes optionelles, c'est ici qu'il faudra rajouter les commandes que nous avons vues un peu plus haut.

=== Interface de lancement graphique pour Windows ===
Depuis FlightGear 1.0.0 il y a désormer une zone spéciale pervu pour les porte avion sur la page de sélection des aéroports de l'interface de lancement. Tapez <tt>Nimitz</tt> dans la zone de saisie prévu a cet effet et selectionez <tt>nimitz_demo</tt> dans la liste des scénario sur la prochaine page.

== Décollage ==
[[File:Carrier1.jpg|thumb|300px|Le [[Hawker Seahawk|Seahawk]] prêt pour le décollage]]

Une fois que FlightGear est lancé, vous devez vous assurer que les freins de parking sont désactivés, puis placez votre avion sur la zone de catapultage et pressez {{key press|Shift}}+{{key press|L}} pour activer la barre de lancement et l'arrimage a la catapulte jusqu’à voir le message "'''Enable'''" s'afficher en haut de l'écran en guise de confirmation de votre arrimage a la catapulte. Si l'alignement avec la rampe de catapultage n'est pas parfait, l'avion sera placer correctement après avoir pressé les touches requise pour l’arrimage a la catapulte. Bien entendu, cela ne fonctionnera seulement que si votre appareil est suffisamment proche de la rampe de catapultage .

Pour placer le porte-avion dans les meilleurs conditions de lancement, cliquez sur le menu suivant "'''IA > Contrôle de porte-avion'''" puis cocher la case "'''Turn to lauch course'''", ce qui aura pour effet de placer le porte-avion de manière a facilité le décollage (par rapport au a la direction du vent).

Après avoir cocher cette case, le porte-avion se tournera lentement mais sûrement dans la direction adéquate, il faudra dans ce cas atteindre la fin de la manœuvre avant dallez plus en avant.

[[Image:Carrier6.jpg|thumb|300px|'''1:''' La zone de décollage du porte-avion avec ses catapultes de lancement
'''2:''' La zone d'appontage du porte-avion avec les câbles d’arrêts]]
[[File:F-14-multiple-cat-launch.jpg|300px|thumb|Plusieurs F-14 décollent de l'USS Carl Vinson]]
[[File:F14 Nimitz locked in catapult.jpg|300px|thumb|Sur le Nimitz: un F14 arrimé a la catapulte de lancement avec la postcombustion activée, volet baissés, prêt a décoller]]

En étant arrimé a la catapulte de lancement, vous devez mettre les gaz a pleine puissance, vous assurer que vos freins de parking ne son pas engagés et que votre avion est prêt au décollage (notamment en terme de volets). lorsque que vous serez prêt, pressez {{key press|Shift}}+{{key press|C}} pour que la catapulte de lancement propulse votre zinc a toute vitesse !!! Pensez a faire attention a préserver une bonne stabilité lors de cette phase cruciale afin d'éviter un décrochage fatal !

== Localiser le porte-avion ==
Localiser une porte avion au beau milieu d'une vaste étendu d'eau peu s’avérer une tache plutôt ardue, surtout lorsque la visibilité est mauvaise. Pour nous faciliter la tache, les porte avion sont équipé de systèmes de guidage par radio militaire '''TACAN''', ce qui permet aux appareils (généralement militaires) qui sont correctement équipés, tel que le '''Seahawk''' ou le '''F14''', de recevoir des indication de cap et de distance par rapport a notre porte-avion et même de nous indiquer la bonne approche à la manière des systèmes d’approches '''ILS''' des aéroports civils.

Pour ce faire, vous devez d'abord vous régler sur le canal '''TACAN''' approprié, '''029Y''' par exemple, dans l'interface de configuration radio ({{key press|Ctrl}}+{{key press|r}} ou depuis le menu "'''Equipement > Paramètres'''" radio. Lorsque vous serez a portée du signal radio, vous verrez sur votre instrument '''DME''' la distance qui vous sépare du porte avion et sur l'instrument '''ADF''' (a coté de l'instrument '''DME''' sur le '''Seahawk''') la direction a prendre pour rejoindre le navire. Virez de bord jusqu’à vous alignez sur le cap indiquer par votre instrument '''ADF''', en faisant comme ceci, votre instrument '''DME''' devrait indiqué que vous vous rapprochez du porte-avion.

{|
| '''Porte-avions''' || '''Scenario''' || '''TACAN''' || '''Situation géographique'''
|-
| '''Nimitz''' || nimitz_demo || '''029Y''' || Volez Est-Nord-Est depuis '''KSFO'''
|-
| '''Eisenhower''' || nimitz_demo || '''030Y''' || Volez a l'Est depuis '''KNTU'''
|-
|-
| '''Clemenceau''' || clemenceau_demo || '''026Y''' || Volez au Sud depuis '''LFTH'''
|-
| '''Foch''' || foch_demo || '''026X''' || Volez au Sud depuis '''LFTH'''
|}
<br />

== Appontage ==
Comme dans la vrais vie, c'est l'opération la plus difficile en ce qui concerne les porte-avions.

Pour faire simple, vous devez utiliser le système '''TACAN''' pour localiser le porte-avion de votre choix et vous aligner avec l'arrière son pont. Noter que la zone d'appontage n'est pas exactement aligner avec le cap du porte-avion, vous devrez donc ajuster légèrement votre cap lors de votre approche. Assurez-vous aussi que votre appareil est dans sa bonne configuration pour tenter un appontage (le menu "'''Aide > Aide de l'aéronef'''" devrait être utile ici afin d'obtenir diverses informations sur votre appareil, notamment les procédures atterrissages/appontages), et n'oubliez pas de déployer le crochet d’arrêt de votre appareil.

Un bon paramétrage est crucial pour une approche de porte-avion; par exemple, un '''F-14''' a 6 miles marin de notre porte avion devrait être a 1200 pieds d'altitude et maintenir ce niveau de vol jusqu’à l'interception de l'aide a l'alignement de descente fourni par le '''TACAN''' du navire a environ 3 miles marins. Pour parvenir a un bon appontage, il faut maintenir l'avion synchroniser avec les indications fournies par le '''TACAN''', ralentir autant que cela est possible sans décrocher (en combinant aérofrein et volets) et a constamment ajuster sa vitesse pour que l’appareil reste contrôlable dans la descente vers le porte-avion. Il faut en sorte faire que l'appareil ai le nez légèrement surélevé par rapport au pont pour permettre au crochet d’arrêt d'intercepter un câble d’arrêt de la zone d'appontage du porte avion, ce qui aura pour effet de stopper net l’appareil sur le pont. Si vous ne parvenez pas a intercepter un câble, mettez les gaz a pleine puissance et tentez une nouvelle approche !

[[File:Carrier5.jpg|thumb|300px|Le système "Fresnel Lens Optical landing System"]]
A mesure que vous approchez, vous devriez voir sur le coté gauche du pont, un système composé de plusieurs lumières aux couleurs vives répondants au nom de Fresnel '''Lens Optical landing System''' ('''FLOLS'''). Ce système indique votre position par rapport a l'approche '''TACAN'''. Vous verrez une rangée de lumières verte, et lorsque vous êtes a peu près aligner avec l'approche '''TACAN''', une lumière orange sera visible, alignée approximativement avec la rangée de lumière verte. Lorsque l'approche est correcte, cette lumière est parfaitement alignée avec la rangée verte. Si cet indicateur deviens rouge, c'est que vous avez une mauvaise approche (trop haut ou trop bas).

Ne vous découragez pas si vous ne réussissez pas au premier coup, apponter n'est pas une tache facile a maîtriser. Mais si, au bout d'un certain temps vous trouvez le '''Seahawk''' trop simple a manœuvrer, libre a vous d'utiliser d'autres avion compatible tel que le '''F-14''' pour plus de challenge.

[[File:F14 approaching Nimitz.jpg|300px|thumb|Un F-14 approchant le porte avion : volets déployés, crochet d’arrêt descendu, avec le FLOLS en arrière plan]]

=== Ascenseurs de pont ===
Si vous le désirez, vous pouvez actionner les ascenseurs de pont depuis le menu contrôle du porte-avion en cochant la case "'''Operate deck elevators'''". Placez votre avion sur l'ascenseur, et décochez la case même case pour descendre et ranger votre avion dans le hangar du navire. A noter que l'ascenseur est très lent...

[[File:F14 Nimitz going down with elevator.jpg|300px|thumb|Un F-14 utilisant en route vers le pont inférieur]]

[[de:Flugzeugträger]]
[[en:Howto: Carrier]]
[[es:Cómo:Portaviones]]
[[pl:Lotniskowiec]]

[[Category:Howto|Carrier]]

Time in FlightGear

2023-07-12T21:50:18Z

KJ7RRV: KJ7RRV moved page Time in FlightGear to Time

#REDIRECT [[Time]]

Time

2023-07-12T21:50:18Z

KJ7RRV: KJ7RRV moved page Time in FlightGear to Time

[[File:PropertyBrowser-showing-sim-time.png|right|thumb|The [[property browser]] showing the <code>/sim/time/</code> subtree]]
[[File:Pui-time-dialog.png|right|thumb|The ''Time Settings'' dialog]]
[[File:Time.png|thumb|New Time dialog in FlightGear]]
[[File:Time-dialog-via-pui2canvas.png|thumb|approximation of the FlightGear [[Time in FlightGear|Time]] dialog via [[Howto:Processing legacy PUI dialogs using Canvas|pui2canvas]] parser]]

The '''time in FlightGear''' and the properties affecting it are represented internally as properties in the <code>/sim/time/</code> property subtree. The time can be manipulated using ''simulation rate''/''speed-up'', to increase or decrease the speed of the simulation, and ''time warp''/''warp delta'', to speed up or reverse local and UTC time.

The terminology used in FlightGear is a bit inconsistent even within the GUI. For the one used in this article, see [[#Terms used in this article]].

== Key bindings ==
{| class="wikitable"
! colspan="2" | Keys !! Binding !! Remarks
|-
| {{key press|A}} || {{key press|Shift|A}} || Increase / decrease simulation rate
| Affects <code>/sim/speed-up</code>
|-
| {{key press|W}} || {{key press|Shift|W}} || Increase / decrease the warp offset
| Affects <code>/sim/time/warp</code>
|-
| {{key press|T}} || {{key press|Shift|T}} || Increase / decrease time warp in steps
| Affects <code>/sim/time/warp-delta</code>
|}

== Simulation rate vs. time warp ==
Simulation rate and time warp manipulates the speed of the simulation and time in FlightGear. The simulation rate affects how much faster or slower the FDM appears to run and the time warp affects how fast local and UTC time changes. Neither simulation rate or time warp will affect for example the airspeed of the aircraft.

=== Simulation rate ===
When the simulation is sped up and slowed down, the integer factor <code>/sim/speed-up</code> will increase and decrease. The aircraft will appear to fly <code>/sim/speed-up</code> times faster over the terrain. When running FlightGear at normal simulation rate <code>/sim/speed-up</code> is one.

This will only affect the speed of the simulation, not the local and UTC time.

=== FDM rate ===
{{FGCquote
|1= 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.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/15645370/
| title = <nowiki>Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes</nowiki>
| author = <nowiki>Curtis Olson</nowiki>
| date = Oct 24th, 2007
| added = Oct 24th, 2007
| script_version = 0.25
}}
}}

{{FGCquote
|1= the autopilot in FG should be running at a fixed framrate (/sim/model-h) these days. That is, fixed in simulated time, which is all that should matter. (As an aside our time management is still pretty messy and lots of things that ought to use simulated time seems to be using real time instead - try increasing the simulation rate and see how many virtual things that do not speed up...)
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/28195667/
| title = <nowiki>Re: [Flightgear-devel] autopilot frame rate</nowiki>
| author = <nowiki>Anders Gidenstam</nowiki>
| date = Oct 7th, 2011
| added = Oct 7th, 2011
| script_version = 0.25
}}
}}

=== Time warp ===
When time of day is sped up or reversed using time warp, <code>/sim/time/warp-delta</code> seconds are added or subtracted to <code>/sim/time/warp</code> each second. In essence, the former is not a factor and the latter is an offset. When running FlightGear at normal time warp <code>/sim/time/warp-delta</code> is zero, and when running in real time, <code>/sim/time/warp</code> is also zero.

This will only affect the local and UTC time, not the speed of the simulation. The aircraft will fly just as fast over the terrain, but the sun and clock hands will speed up or reverse.

{{FGCquote
|1= /sim/speed-up is now included in dt, unless you use ‘real dt’ - which is only for user-interface and other things that should work while paused? (I have a long-standing task to make view direction animation use real-dt so you can look around at normal rate while paused or using sim/speed-up)
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34883671/
| title = <nowiki>Re: [Flightgear-devel] Time speedup</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Feb 25th, 2016
| added = Feb 25th, 2016
| script_version = 0.25
}}
}}

{{FGCquote
|1= Note the /sim/time/warp value may not be completely accurate, but should be close enough for what it’s used for (time of day), but to cumulative rounding as that is updated each frame. But the actual dt values should be completely accurate.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34883671/
| title = <nowiki>Re: [Flightgear-devel] Time speedup</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Feb 25th, 2016
| added = Feb 25th, 2016
| script_version = 0.25
}}
}}

=== Warp vs. speedup ===
{{FGCquote
|1= I find two separate concepts exposed in two different properties: sim/time/warp & sim/time/speed-up. The difference is also made in the user interface, where you can set time warping and speed-up independently. Apparently, speed-up affects the aircraft only (physics & instrumentation), and warp affects the environment only (ephemeris, for example). This effectively establishes two independent timelines inside and outside the aircraft, so there is no single value for "elapsed simulated time", i.e. it depends whether we are talking in or out the plane!
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/31578793/
| title = <nowiki>[Flightgear-devel] Time warping</nowiki>
| author = <nowiki>Anton Gomez Alvedro</nowiki>
| date = Oct 30th, 2013
| added = Oct 30th, 2013
| script_version = 0.25
}}
}}

{{FGCquote
|1= speed-up is primarily related to the rate the FDM sees; instruments and autopilot also see the increase since I moved them to run in lock-step with the FDM (to avoid AP instability when using speed-ups which otherwise break the PID parameters). Speed-up is used to speed-up or slow-down how fast the simulation engine is running the local aircraft, in effect, but anything written in Nasal would need to handle it explicitly. We probably *could* factor sim/speed-up into simDt, but this would need to be done with great care since there's probably code using it which does not expect to see a speed-up. None of the above cares about 'wall clock times' or 'dates', only about dt intervals. - warp is about how fast we're updating our simulate 'time+date of the world'. Hence it affects things that refer to time of day such as ephemeris. The goal, I guess, was interactive adjustment of the calendar time to fly in the evening/morning, and indeed that's what the dialog suggests. Warp is really a warp-rate and a warp-offset - the offset is exactly the delta from system clock time to simulated world time, and we adjust it by the warp-rate each frame/update.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/31578949/
| title = <nowiki>Re: [Flightgear-devel] Time warping</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Oct 30th, 2013
| added = Oct 30th, 2013
| script_version = 0.25
}}
}}

=== Framerate throttling ===
{{FGCquote
|1= There is also a frame rate throttling option, but it's pretty buried /sim/frame-rate-throttle-h Also consider setting your "sync to vblank" option in your video hardware. That can help limit FlightGear to run at your display's refresh rate.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/28197283/
| title = <nowiki>Re: [Flightgear-devel] autopilot frame rate</nowiki>
| author = <nowiki>Curtis Olson</nowiki>
| date = Oct 7th, 2011
| added = Oct 7th, 2011
| script_version = 0.25
}}
}}

{{FGCquote
|1= If you sync to the vblank signal in FlightGear (and have enough cpu/graphics hp) you can run at a very solid 60h (or whatever rate your display refreshes at.) If you don't quite have that amount of hp consistently for all situations, there is a throttle-hz property you can set to force a slower update rate (maybe 30 or 20 fps ... ideally you want an even divider into your display update rate.) If consistent frame rates are your goal, there are ways to achieve that. However, because of the variability of systems and personal preferences, we don't turn a lot of this on by default.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/23257288/
| title = <nowiki>Re: [Flightgear-devel] Multithreading support</nowiki>
| author = <nowiki>Curtis Olson</nowiki>
| date = Aug 5th, 2009
| added = Aug 5th, 2009
| script_version = 0.25
}}
}}

=== News ===
{{FGCquote
|1= First the good news : I have managed to generalise the existing ‘speed up’ function (accessed via a/A keys) to work for many more parts of the simulator than before. (This is the feature which allows time to run faster or slower than normal) This should make flying with speed up on autopilot more reliable, and solves my specific use-case of the testing the AI traffic code easier, since I can speed up how fast the AI aircraft move and update. This also allowed various special cases in the instruments and Nasal to be removed. For those who care about details, the ‘dt’ value passed to subsystems is now scaled by the speed-up factor. This is consistent with the existing behaviour when paused (dt = 0, no sim time is passing). If you are working code which needs the ‘real’ dt, typically because you want to animate something while the sim is paused, the ‘real dt’ is available as it always way. However, any such code in this category would already have been incorrect when froen / paused, so I’m not too worried about such cases. Now the question: as well as sim/speed-up, we have the /sim/time/warp property which defines the offset in seconds from system time to simulator time. This is how we implement the various time of day options, and with Richard’s change, adjusting the date as well.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34745068/
| title = <nowiki>[Flightgear-devel] Speed-up vs time-warp</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Jan 6th, 2016
| added = Jan 6th, 2016
| script_version = 0.23
}}
}}

== Precision ==
As of October 2015 there is only one floating point property, <code>/sim/time/elapsed-sec</code>, which tells how long FlightGear has been running. This property is not affected by simulation rate or time warp. Most of the other properties are integers, thus only able to show full seconds.

=== Getting sub-second local and UTC time ===
{{note|Yet to be tested}}

Sometimes you could want sub-second precision time that is affected by time warp. This could for example be if you want a cockpit clock to have a sweeping second hand or if you are logging test data in smaller intervals than one second while wanting those times to correlate to other data.

As clock hands often only use elapsed seconds to animate the hands, the following example will produce two such properties.

One way to get sub-second precision UTC and local time could be by declaring two floating point properties and a property rule in the [[aircraft-set.xml]] file for example like below. Using property rules will update the values at frame rate, while using autopilot functions would update them at FDM rate.

<syntaxhighlight lang="xml>
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>

<sim>

<time>

<utc-sec type="double">0</local-sec>
<local-sec type="double">0</local-sec>
<time>

<systems>

<property-rule n="100"> 
<name>Sub-second precision UTC and local time</name>
<path>Systems/precision-time.xml</path>
</property-rule>

</systems>
</sim>

<PropertyList>
</syntaxhighlight>

Add property rules/autopilot filters adding <code>/sim/time/elapsed-sec</code>, <code>/sim/time/warp</code> and <code>/sim/time/offset-local</code> like below:

<syntaxhighlight lang="xml>
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>

<filter>
<name type="string">Sub-second precision UTC time</name>
<type>gain</type>
<gain>1</gain>
<input>
<expression>
<sum>
<property>/sim/time/elapsed-sec</property> 
<property>/sim/time/warp</property> 
</sum>
</expression>
</input>
<output>/sim/time/utc-sec</output>
</filter>

<filter>
<name type="string">Sub-second precision local time</name>
<type>gain</type>
<gain>1</gain>
<input>
<expression>
<sum>
<property>/sim/time/utc-sec</property> 
<property>/sim/time/local-offset</property> 
</sum>
</expression>
</input>
<output>/sim/time/local-sec</output>
</filter>

<PropertyList>
</syntaxhighlight>

== Terms used in this article ==
The terms used in the source code, keyboard binding descriptions and ''Time Settings'' dialog labels are a bit inconsistent. Therefore, in this article these terms (mostly from the ''Time Settings'' dialog) will be used:

; clock time
: The local system time as represented by the <code>/sim/time/real/</code> property subtree.
; local time
: The in-sim local time as represented by <code>/sim/time/gmt</code> + the offset represented by <code>/sim/time/local-offset</code>.
; real time
: When running FlightGear with zero warp, so that local time is equal to clock time, and zero time warp so that local time is at the same speed as clock time.
; simulation rate
: Simulation rate speed-up factor as represented by <code>/sim/speed-up</code>. This is not related to the FDM rate, the speed at which the flight dynamics model is run.
; time warp
: Local and UTC time change rate as represented by <code>/sim/time/warp-delta</code>.
; UTC time
: The in-sim UTC time as represented by <code>/sim/time/gmt</code> and the <code>/sim/time/utc</code> property subtree. In essence the time shown on many cockpit clocks.
; warp
: The offset between local time and clock time as represented by <code>/sim/time/warp</code>.

== Nasal scripting ==
* {{func link|maketimer()}}
* {{func link|settimer()}}
* FDM coupled

== Ongoing Developments ==
=== Date selector ===
{{Note|See also {{Merge-request|project=fgdata|id=42}}}}
{{FGCquote
|1= sad that it is pretty difficult to set another date while in-simulator (via property menu), so I took the time selector and changed it a bit to have a date selector.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=269399#p269399
| title = <nowiki>Date selector</nowiki>
| author = <nowiki>D-ECHO</nowiki>
| date = Dec 20th, 2015
| added = Dec 20th, 2015
| script_version = 0.23
}}
}}
{{FGCquote
|1= What do you all think about adding a date control to the Time Settings dialog in the Environment menu (and then maybe rename it to "Time and Date Settings")? Currently the only way to set the date while in sim is via the property editor using "/sim/time/gmt". This would as useful as having time controls to play with the amount of daylight since the date influences the position and maximal height of the sun, particularly in very northern or southern places. Personally, I think it would be great to give users the chance to set it in sim without fussing with the debug tools, just like we currently do with time.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34735814/
| title = <nowiki>[Flightgear-devel] Time settings dialog</nowiki>
| author = <nowiki>Gilberto Agostinho</nowiki>
| date = Jan 3rd, 2016
| added = Jan 3rd, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= I ran into a problem: the property that needs to be altered to change the year, month and day, as well as time, is "/sim/time/gmt", and its value is a single string. Unfortunately my knowledge of XML as well as of the capabilities of our dialogs isn't very fancy (I just did some simple things for the c172p so far), and I really don't know how could I create several buttons to change the date parameters individually and then have them concatenated into a single string in the format required by the mentioned property... If we had a single property for each parameter this would be easy peasy, but I am kind of stuck right now.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34736360/
| title = <nowiki>Re: [Flightgear-devel] Time settings dialog</nowiki>
| author = <nowiki>Gilberto Agostinho</nowiki>
| date = Jan 3rd, 2016
| added = Jan 3rd, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= I've just added some text input boxes to the dialog for year,month,day to the dialog https://sourceforge.net/u/r-harrison/fgdata/ci/3e667c0b443a06d167d63c9447b6d8442f6aca57/ Merge request created. https://sourceforge.net/p/flightgear/fgdata/merge-requests/39/ (Not quite sure why it says 0 commits on the request - maybe I was a bit quick creating the merge request as possibly it hadn't finished pushing). I can redo the merge request if needed. Also added a checkbox for the warp easing as I'm always having to do this with the property tree.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34737165/
| title = <nowiki>Re: [Flightgear-devel] Time settings dialog</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Jan 4th, 2016
| added = Jan 4th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= I've been working on the time dialog. At first it was a quick fix just to add date entry, but it's grown from that. This is what it is currently: http://i.imgur.com/QDuyDLD.png I wasn't sure about sliders on year,month,date at first, but the sliders actually work really effectively - which surprised me. IMHO this approach works better than the dropdown calendar that we've all seen before. The day of month is limited to the maximum number of days for the currently selected month and it takes leap years into account. I prefer to run with easing turned off which is another reason I added a checkbox for easing. I rather suspect I'm not alone in this view. The time slider partially removes the need for the warping. It's also neat adjusting the date with the sliders and seeing the effect changes can be found here: https://sourceforge.net/u/r-harrison/fgdata/ci/435b81bf2464b4c64b6e69ec966406ea45fea797/tree/gui/dialogs/timeofday.xml I've limited the range for the year from 1971 to 2037 (i.e. within completely safe 32bit time_t range).
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34747721/
| title = <nowiki>Re: [Flightgear-devel] Speed-up vs time-warp</nowiki>
| author = <nowiki>Richard Harrison</nowiki>
| date = Jan 7th, 2016
| added = Jan 7th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= [we] are debating his proposed changes to the time dialog: https://sourceforge.net/p/flightgear/fgdata/merge-requests/42/ I’m fine with functionality (mostly) but don’t like his choice of widgets, although as ever he is constrained by what PUI does and doesn’t offer. Can some other people, ideally with UX experience, review and comment? I don’t want to make a unilateral decision since I’m aware I’m usually at one extreme end of the ‘less is more’ Johnny Ive school of interface design :D As ever I would ask people reviewing to apply the UI learnability measure of ‘if I’d never seen this screen before or used FlightGear for more than five minutes, would the choices and controls in this dialog make sense to me? If not, what could be added / changed so they do?'
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34747748/
| title = <nowiki>[Flightgear-devel] Additional perspectives needed on time dialog</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Jan 7th, 2016
| added = Jan 7th, 2016
| script_version = 0.23
}}
}}

== Related content ==
=== Wiki articles ===
* [[Autopilot configuration reference]]
* [[Property browser]]
* [[Property tree]]

=== Forum topics ===
* [http://forum.flightgear.org/viewtopic.php?f=25&t=20756 Link Simulation Rate and Time Warp together?]

=== Issues ===
* {{Ticket|421}}

=== Source files ===
* {{fgdata file|keyboard.xml}}
* {{fgdata file|Nasal/controls.nas}}
* {{fgdata file|Timezone/}}

* {{simgear file|simgear/timing/}}

* {{flightgear file|src/Time/}}

[[Category:FlightGear]]

Howto:Build a yoke in 5 minutes

2023-07-12T18:38:40Z

KJ7RRV:

[[File:Mouse yoke.jpg|thumb|270px]]
Using some every-day equipment and an optical mouse, you can '''build a''' (basic) '''yoke in just five minutes'''! The yoke can be directly used in [[FlightGear]].

=== Required components ===

* The right sized cardboard box
* 1 empty paper towel/gladwrap/foil roll
* 1 piece of packing foam that loosely resembles a yoke
* 1 optical mouse
* 1 roll of sticky tape
* 1 pencil
* A pairing knife

=== Instructions ===

# Using your roll (now referred to as the control column) as a guide, mark and cut a hole in the front and rear of the box for the control column to slide through.
# Mark out the centre of your foam yoke, but cut the hole slightly smaller and force the yoke on to the control column. There should be enough friction for it to not need glue.
# Place the mouse on top of the box, with the mouse backwards to how you'd normally use it (so that the buttons are facing you), mark its outline on the box, and cut a hole.
# Insert the control column/yoke assembly through the holes you made, place the mouse into the cut out you made for it and tape it in, taping around the edge of the mouse so that it won't rock sideways.
# The final step in construction is to limit the control throw. (This is not pictured in the photo. It is not technically necessary, but without it, you must be careful not to exceed the limit of control throw in FlightGear.) Use your knife to drill two small holes in the top and bottom of the end of the control column that is protruding from the back of the box. Insert a pencil through them so that most of the pencil is in the air, and just the tip is pointing downwards. This will stop the control column from coming out with too much up elevator, and will also limit the aileron when the pencil hits the desk. Full aileron will be just over 90 degrees, which is the same as a Cessna, so it'll be pretty realistic.
# You'll also need to reduce your mouse (control mode) sensitivity in FG so that it can never reach full aileron or elevator. This is very important, because if you don't it'll go out of alignment as soon as you reach it.
# It will also go out of alignment after a while, especially if you make very fast control inputs on a slow computer, so configure a mouse button to centre the controls. When it goes out of alignment, just centre your yoke and tap the mouse button.
# Make sure your yoke is centred when you start the sim.

== KJ7RRV's version ==

I made a yoke based on this design, but with a few changes.

=== Required components ===

* 1-inch or larger wooden dowel rod, as straight as possible (exact diameter is not important)
* Cardboard box large enough to run the dowel through while leaving at least an inch or so on each side
* Something to use as a yoke (a piece of cardboard works but is not ideal)
* An optical mouse that you're willing to take apart (it won't work as a mouse when you're done)
* A pencil
* A knife to cut the box
* Hot glue

=== Instructions ===

# Cut circular holes with the same diameter as the dowel rod centered in the front and back of the box. Choose one side to be the back, and cut a small notch at the bottom of the hole in the back.
# Cut a hole the size of the dowel rod in the center of your yoke. Unless your yoke is made of foam or a similar material, you will probably need to use glue.
# Disassemble the mouse and take the circuit board out, leaving the cable connected. If there are optics left in the case, cut down the mouse case to just the part needed to hold the optics and circuit board together. Use some tape to hold the board to the case if needed.
# Put the mouse board in the box and run the cable out the back.
# Insert the control column/yoke assembly through the holes you made in the box. Make sure the mouse cord goes in the notch in the back hole.
# Use hot glue to hold the mouse board to the side of the box with it touching the control column. Make sure the buttons are facing toward the yoke, and that the board is straight.
# The same issues with centering apply to this design. I have not yet limited the control throw in this design.

== Resources ==
* [https://forum.flightgear.org/viewtopic.php?f=3&t=1956 FlightGear forum topic for original design]

[[Category:Cockpit building|yoke Build a in 5 minutes]]
[[Category:Howto|yoke Build a in 5 minutes]]

Howto:Build a yoke in 5 minutes

2023-07-12T17:38:09Z

KJ7RRV: