topic: Aircraft Development

Ground power in X-Plane 12.0.8+

Ground power provides electrical power to a parked aircraft, so its systems can be operated without depleting the battery even if the engine(s) are turned off.

The ground power plug must be plugged into the aircraft first, then a relay can be closed to actually connect an electrical bus to the external power source.

Plugging the power in

Aircraft made for X-Plane 12.07 and earlier always have voltage on the ground power receptacle if the aircraft is stationary (ground speed is less than 1 knot).

Aircraft made for X-Plane 12.0.8 need to call for ground services to have the ground power plugged in. In order to that, preconditions must be met:

  • The aircraft must be stationary (ground speed less than 1 knot)
  • The aircraft must not be on a runway (it needs to be on a ramp or taxiway area, or on grass)

Then, the user can request to “service the aircraft”. This will cause power to become available. Whether an animated ground power unit will show up in the 3d world to service your aircraft depends on

  • the aircraft author must have specified a location for the generator cart to be parked relative to this aircraft. That’s in Plane Maker, in the “dock ports” tab, “has ground power cart” must be checked and the coordinates specified
  • the airport must have a route for ground service vehicles to reach your aircraft parking position

In the absence of the above, the electrical power will still work, but no animated generator cart will be visible.

Making contact

Once the power is available, the available voltage will be readable in the sim/cockpit2/electrical/GPU_generator_volts dataref. If this reads 0, nothing is plugged in. This information can be used by aircraft to power “hot buss” items that might be available even before the switch in the cockpit is activated. This can also be used to indicate the availability of ground power to the pilot, such as the switch lighting up.

Now, the dataref sim/cockpit2/electrical/GPU_generator_on can be used to switch the GPU relay to on. Now, all connected busses will be powered from GPU power, all equipment can be used and the batteries will be getting charged.

Third-party overrides

At some third-party scenery airports, or with some aftermarket aircraft, the use of X-Plane default ground services might be undesirable. For these, the ground power can be overridden by plugin logic, so the third party product can decide ground power availability rather than X-Plane’s ground service system.

To take control of the GPU power, the plugin needs to set sim/operation/override/override_GPU_volts to 1 and then write the desired voltage to sim/cockpit2/electrical/GPU_generator_volts or 0 if the GPU isn’t supposed to be plugged in right now.

In order to not fry any virtual circuits, the plugin should check the dataref sim/aircraft/electrical/acf_nom_gen_volt to find out whether the user aircraft expects 12V, 28V, 110V or anything else.

Leave a comment

X-Plane 3-D HUD

X-Plane 12 features a 3-D HUD – besides drawing HUD markings on top of the 3-d scene, the HUD aligns to the world in 3-d with the same parallax error that a real HUD would have, and looks “far away” to a user in VR.

The HUD consists of three separate authoring elements:

  1. An area of the aircraft’s 3-d panel texture that has HUD markings.
  2. A 3-d mesh in an aircraft attached object with appropriate objects, that will serve as the HUD glass. The HUD image will only appear when the glass covers the screen space area in front of where the pilot “perceives” the HUD to be.
  3. Plane-Maker settings to calibrate the 3-d HUD’s alignment.

Setting Up the HUD in Plane-Maker

Plane-Maker’s viewpoint cockpit screen contains a section “3-D HUD” that requires three types of information:

  1. The field of view angles of the edge of the HUD glass. You may need to calculate these in your 3-d model – it is the number of degrees to the left, right, up and down from from the pilot looking straight ahead at the default pilot viewpoint.
  2. The pixel position on the 3-d texture panel that the HUD image will be taken from. The lower left is 0,0, and the unit is pixels. You will be able to see this rectangle in the panel editor to validate that it is correctly set up, but it must be changed in the viewpoint cockpit screen.
  3. The panel region. If your 3-d cockpit uses panel regions, pick the region number for the HUD here. If your aircraft does not use panel regions, you should leave this as the default “0” value.

Creating the HUD Graphics

In the 3-d panel editor, click the HUD icon in the upper right button bar (just to the left of the “2-D” icon) to view the HUD preview lines. If the panel is set up with a 3-d HUD, you will see:

  • A cyan box showing the edge of the HUD’s image and
  • A HUD ladder showing the horizontal center, horizon, and 2.5 degree vertical increments.

You can use these queue marks to calibrate your HUD graphics.

⚠️ WARNING: as of X-Plane 12.0.8 the “2-d” HUD instruments only work in the 2-d HUD, and the “3-d” HUD instruments only work in the 3-d HUD. We recommend using generic instruments for the 3-d HUD.

Setting Up the 3-d HUD Object

The 3-d HUD needs a glass element in an object, with a special attribute

    ATTR_hud_glass
    TRIS	36 18
    TRIS	54 18
  ATTR_hud_reset

Steps to Debug The HUD

First, confirm the HUD image is present by using the texture browser to view the night panel texture.

Second, confirm the HUD glass is present by temporarily removing the HUD glass attributes and giving it a debug color texture.

Leave a comment

3-D Rain Effects

X-Plane 12 features rain simulation on designated surfaces. This article explains how to enable and tune rain effects, as well as what to look out for to get the best experience.

Enabling Rain

Enabling the base rain effect is extremely easy by going into Plane Maker’s objects panel and setting the lighting mode of the rain surface OBJ to “Outside Rain Glass”. With this enabled, X-Plane will start simulating raindrops on the OBJ and automatically tap into the flight model data to properly calculate forces acting on them. Additionally, X-Plane will also start simulating ice build up on the surface when encountering icing conditions.

General considerations

One “gotcha” with the rain system is the way that raindrops interact with multiple surfaces. If you have enabled “Outside Rain Glass” mode for multiple OBJs, they will each run their own simulation and don’t share results with each other. This means that each additional OBJ will consume additional resources and processing time. Our advice is to try to keep the number of “Outside Rain Glass” OBJs to a minimum, ideally 1. You can achieve this by putting all of your rain receiving surfaces into a single OBJ file.

When multiple surfaces are grouped together into a single OBJ, it’s important that each vertex has a unique UV mapping and that contiguous surfaces are also mapped contiguously in UV space. This is because the rain system actually runs the simulation in 2D UV space to reduce resource usage, so the lens through which it “sees” the world is the UV space of your OBJ.

Here is an example of the default Cessna windows in 3D and UV space. The rain system operates in the flat UV space on the right in order to reduce the computational complexity.

One side effect of this setup is that rain can cross surfaces in unexpected ways. Two objects that are far apart in 3D space might be close to each other in UV space. In this case, a raindrop can potentially migrate from one surface to the other. Similarly, surfaces might be at different orientations to each other, so when a droplet enters the next surface it suddenly is subject to entirely different forces. In those cases, rain drops can move in strange and unexpected ways. An example of this behaviour can be seen here:

If you look at the upper left part of the windshield, you can see streaks that seem to have moved weirdly. In this case the rain drops have entered from the left edge after hopping from a different surface. They carried their momentum with them which moved them further to the right across the windshield. At the same time, they are suddenly exposed to forces that try to push them upwards. As a result, they now arc weirdly.

The way to work around this is to use separate TRIS  commands in your OBJ for each distinct surface. X-Plane tracks draw calls and makes sure to extinguish droplets that hop distinct surfaces that it can track. One “gotcha” here is that X-Plane will also try to merge multiple TRIS  commands into one big command. It only does so if subsequent commands are also drawing subsequent patches of triangles, so a way to work around this is to have them backwards. For example, your original OBJ might look like this:

TRIS 0 1224

TRIS 1224 558

TRIS 1782 558

Because this describes a contiguous range of 2340 triangles, X-Plane will try to helpfully merge them together into one. You can prevent this from happening by reversing the lines like this:

TRIS 1782 558

TRIS 1224 558

TRIS 0 1224

Scaling rain

One general OBJ command that might come in handy is the RAIN_scale  command. If not specified, the default of 1.0 is assumed, but you can put any other parameter in there. If you find that the rain drops are too big or too small for your aircraft, you can use this to tune their size. During development, you can set this to 1 and then use the sim/private/controls/rain/scale  art control to dial this parameter in, in real time. Once you have arrived at a value, you can then bake it into your OBJ.

Combining inside and outside glass

If you have both an outside glass surface with rain, as well as an inside glass surface, you might find that you get draw order problems. In these cases, the inside glass will remove the outside rain effect. The way to make this set up work is to select the “Inside Reflector” lighting mode for the inside glass.

Wipers

A lot of aircraft come with wipers, which can be added to a rain system via the WIPER_texture and WIPER_param  OBJ commands. X-Plane supports up to 4 wipers per OBJ and one wiper texture. The wiper texture, specified with the WIPER_texture  command, describes the path for each wiper using the 4 channels red, green, blue and alpha. The intensity of the channel is  the percentage along the path of the wiper, going from 1 to 255 (0 is reserved to signal no wiper interaction), the wiper moves from 0% to 100% of its path.

The resulting gradient should be increasing at a uniform rate, and an example of this can be seen on the left.

The red channel describes the first wiper, whereas the green channel describes the second one. Note that you can have multiple wipers using the same channel, but you can’t individually drive them.

For each wiper in the wiper texture, you’ll need one WIPER_param  command in your OBJ. The general syntax for that command is:

WIPER_param

The dref  is the name of the dataref you want to use to drive the wiper. Start  and end  provide the values the dataref will have when the wiper is at its first and last position respectively. The nominal_width  parameter is a bit more complicated: It describes the width of the wiper as a fraction of the gradient in the wiper texture. To accurately calculate this parameter, you’ll need to know the pixel density per meter of your texture, as well as the space covered by the wiper gradient and the physical size of the wiper.

Putting it all together, you might end up with something like this to describe 2 wipers:

WIPER_texture    A330_glass_wiper_gradient.png

WIPER_param    sim/flightmodel2/misc/wiper_angle_deg[0]        0.0   70.0        0.02

WIPER_param    sim/flightmodel2/misc/wiper_angle_deg[1]        0.0   70.0        0.02

In this case the datarefs used describe the angle of the wiper, so the start and end are also in degrees. The nominal width is 2% of the gradient.

One method to generate the wiper texture as well as the parameters is to use the XPlane2Blender plugin. The plugin allows you to generate a wiper texture from your OBJ animations.

Thermal sources

Since the rain simulation includes ice build up as well, one common task is to provide deicing mechanisms for rain surfaces, which can be done using thermal sources. A thermal source can be anything applying heat to the surface, for example a vent blowing hot air or an electrical filament embedded into the glass. Thermal sources work very similarly to wipers, they provide THERMAL_texture  and THERMAL_source  OBJ commands and X-Plane supports up to 4 individual thermal sources per OBJ.

Note that thermal textures are only used to drive the visual ice accumulation system, it does not replace the flight models icing simulation. The goal of the thermal texture is to guide the visual system so it can properly show where the heater removes icing. As a result you will still have to setup a proper de-icing system according to Windshield ice and rain protection datarefs. If you don’t provide the underlying flight model simulation with this information, your windows will ice over regardless of the thermal texture and the datarefs driving it.

The THERMAL_texture  also uses per channel gradients to describe where to apply the effect and how strongly. The channel describes the thermal source in question (red is 1, green is 2, blue is 3 and alpha is 4). The intensity of the channel describes the percentage of how much of the heat is applied to that area as a percentage. For a hot air blower, this would most likely look like a dot with an intensity of 255, with a gradient falling off to 0 around it. The dot is where the hot air is concentrated, whereas the gradient around it is the fall off of the hot air.

The THERMAL_source  command has the following syntax:

THERMAL_source <on/off dref>

The first parameter describes the dataref to be used to read temperature of the thermal source, in degrees celsius. The second parameter describes the dataref to be used to check whether the thermal source is on or off (1 or 0 respectively).

A complete example describing 4 heat sources looks like this:

THERMAL_texture    A330_glass_thermal_gradient.png

THERMAL_source   A333/window_temp1  sim/cockpit2/ice/ice_window_heat_on_window[0]

THERMAL_source   A333/window_temp2  sim/cockpit2/ice/ice_window_heat_on_window[1]

THERMAL_source   A333/window_temp3  sim/cockpit2/ice/ice_window_heat_on_window[2]

THERMAL_source   A333/window_temp4  sim/cockpit2/ice/ice_window_heat_on_window[3]

6 Comments

Rudder auto-coordination in X-Plane 12

Auto-coordination helps users with no hardware rudder pedals fly airplanes when rudder input is required for coordinated turns, to help with asymmetric thrust conditions and to help with crosswind take-offs and landings.

Which aircraft get auto-coordination

Auto coordination is applied only to aircraft, not rotorcraft. For successful operation of a helicopter it is absolutely necessary to have means of operating the anti-torque pedals, through pedals or a twisting joystick.

When is auto-coordination active?

Auto-coordination is active whenever no joystick axis is configured for the “Yaw” input. If actual pedals or a joystick with twist-grip is connected and the axis assigned, auto-coordination will never be applied.

If a plane is equipped with a Yaw Damper and it is turned on by the pilot, has power and is not failed, auto-coordination is not applied, regardless of joystick configuration. The yaw damper is relied upon for coordinated turns and auto-coordination does not interfere with it. Note that that requires the yaw damper to be configured. In testing, we found a number of published aircraft that had yaw damper switches in the cockpit but no configured yaw damper, so the switch would not do anything. In that case (the yaw damper constants being all zero), the yaw damper switch position is ignored as it is a dummy. Please consult the article on autopilot constants to learn how to configure the yaw damper if your airplane needs one.

Auto-coordination for X-Plane 11 aircraft

X-Plane 11 aircraft loaded in X-Plane 12 get the exact same rudder assist as in X-Plane 11. A proverse rudder input of 20% of the aileron input is applied when the user deflects the aileron. No assistance is provided for crosswind or asymmetric thrust.

Auto-coordination for X-Plane 12 aircraft

Aircraft authored with Plane Maker 12 allow configuration of the auto-coordination controller. The auto-coordination controller is a PID controller that seeks to keep beta (sideslip angle) at 0 degrees. That means, it applies rudder to keep the fuselage aligned with the airflow, and in doing so, it works against adverse yaw and helps with coordinated turns. Keeping the slip angle at 0 however also helps cancel P-factor and spiraling slipstream, so you will notice that the auto-coordination applies right rudder in high-power, high-AoA situations in single-engine propeller aircraft, where right rudder is needed to keep the airplane coordinated in climb, which a simple aileron coupling could not achieve. Note that this also works in single-engine flight of a multi-engine aircraft: With a failed engine in a twin, the auto-coordination will step onto the live engine in an effort to compensate for asymmetric thrust. Note that it tries to achieve zero side slip, not zero ball, i.e. it tries to center a yaw string, not the inclinometer. With OEI it will naturally “split the ball” and require a slight bank into the good engine to fly straight.

The controller is a PID controller that gets the beta angle in degrees as input and acts directly on the rudder, like the pilot would with rudder pedals. The controller gains can be tuned in flight in the Developer->Show Autopilot Constants window, in the “yaw” tab. Note that X-Plane does not save those values permanently, so once a good tuning is established, the values must be saved to the aircraft file in Plane Maker.

The beta angle input into the controller changes smoothly from slip angle to crab angle as the aircraft climbs or descends 5 meters from the surface. This is what allows crosswind takeoffs and landings even with no hardware to perform realistic cross-controlling. In a crosswind landing, the controller will try to eliminate crab angle as the aircraft is flared over the runway. This needs to be anticipated by the pilot who needs to apply slight opposite aileron as the auto-coordination kicks out the crab before touchdown.

Comments Off on Rudder auto-coordination in X-Plane 12

Checklist for Updating Aircraft for X-Plane 12

Plane Customization

Navigation Display Scaling

Starting with X-Plane 12 it is possible to independently scale symbols and text of the navdisplay, and also change the relative locations of symbols and labels. Customization of the map display is possible by editing the map_s_HM-1.png, map_s_HM-2.png, map_s_HM-2.png and map_s_HM-4.png graphics and supplying the graphics specific for your aircraft through the library system (the path is cockpit/EFIS/EFIS_maps). These png files can supply alternate symbols, colors or fonts to generate the style of the nav display. Learn more: Navigation Display Scaling

New HUD

X-plane 12 contains a new 3-d HUD system. This system is unrelated to existing tech for a HUD in 2-d panels or in the “forward with HUD” view.

The new HUD works by projecting a region of the 3-d panel in front of the aircraft in the distance, but only drawing it where it intersects a 3-d modeled HUD glass.  This simulates the real-world HUD experience of the HUD being focused at infinity (and aligning with the horizon), while only being visible when the pilot’s head is within a specific 3-d box in the aircraft.

To use the new HUD you will need to do three things:

  1. Specify the geometry of the HUD in the Plane-Maker viewpoint screen, cockpit tab, 3-d HUD section. You specify both:
  1. The panel texture area to be used as the HUD (in pixels) and
  2. The angle of the HUD from the pilot’s view (as field of view ratios).
  1. Build the HUD image in your 3-d panel in the appropriate area.
  2. In one of your objects marked interior glass, use the new ATTR_hud_glass to mark the glass that the HUD “appears on” and make sure that that OBJ is in the “glass reflective” light group in X-Plane.

To calculate the FOV ratios, use the trigonometric tangent function for the angle from center for each side.  So for example, a HUD with 20 degrees below the horizon and 10 degrees above would have an FOV ratio of tan(-20) and tan(10) or -0.364 for the bottom and 0.176 for the top.

For an example of the 3-d HUD, see the F14.

OPEN ISSUE: as of this writing, the HUD light levels are not correctly set.  Future guidance will come when this issue is resolved.

Plane Maker Updates

Airframe and Tail Anti-Ice and De-Icing boots

X-Plane 12 treats the tail surfaces different from the wing surfaces when it comes to ice accumulation and anti- or de-ice measures. Learn more: Airframe and Tail Anti-Ice and De-Icing boots

Autopilot

Navigation Source

This article summarizes X-Plane’s capabilities when it comes to modern integrated approach navigation and sheds light on the new datarefs: Autopilot Navigation Source

Autopilot VNAV modes

X-Plane knows two different types of VNAV, which can be described as “GA” and “Airliner”-type VNAV. The main difference is the availability of auto-throttle. “GA” without auto throttle can only do geometric descents – the vertical path is controlled by the autopilot, while the pilot controls the speed by the throttle (or speedbrakes). “Airliner” with auto-throttle uses the auto-throttle to set climb power in climb, hold the selected cruise speed in cruise, and comply with speed restrictions (if physically achievable) in descend.

For a detailed explanation and examples see the article Autopilot VNAV modes and PlaneMaker settings.

Auto-coordination

If your aircraft requires rudder pedal input to operate realistically (especially single engine propeller aircraft and light twins) consider configuring the constants for the new auto-coordination to improve the experience for users with no rudder hardware.

Directional Gyro

X-Plane 12 changes the way directional gyro drift is calculated and the behavior of the directional gyro drift data refs. If your aircraft or plugin adjusts or watches these datarefs, you will want to check whether your code still works with the new drift. Learn more: Directional gyro drift and adjustment datarefs

FADEC Controlled Engines

X-Plane can limit the power output of altitude engines (or flat-rated engines) in order to not overtemp or overtorque them. In addition to thrust or torque limiting, X-Plane 12 can also limit to N1 or EPR values. Learn more: FADEC controlled engines

Flight Control Trim

If your aircraft is configured to have a trimmable horizontal stabilizer, there is no change in behavior from X-Plane 11. X-Plane 12 allows for three distinct ways of trimming the flight controls, and allows assigning different types of trim to different axes, so it is possible to have a trim tab on the elevator, but a pre-loaded centering spring on the rudder, as is common with many general aviation aircraft like the Cessna 182. Learn more: Types of flight control trim

Flight Control Splits

In case of a flight control malfunction where a jam occurs in one system, it is usually possible to split the controls, in some aircraft by pulling a flight control disconnect handle, in others the torque tube shears when a certain (high) load is applied to it. X-Plane simulates both the type of failure and the flight control split to deal with it. Learn more: Flight Control Splits

Helicopter Governors

X-Plane 12 revises the interaction of collective and throttle control in helicopters. Existing helicopters retain the default behavior of X-Plane 11 until modified in Plane Maker 12 to opt into one of the new governor systems. The joystick control assignments for collective and throttle don’t change, but there’s a new joystick curve available for Robinson-style throttle control. Learn more: Helicopter governor and correlator configuration

Hydraulic systems

X-Plane has three hydraulic systems per aircraft that can power a variety of actuators. Most notably, each flight control surface can be powered by any combination of hydraulic actuators. Learn more: Hydraulic systems and flight controls

Gear systems

If you have a three-position gear switch (Up-Off-Down) that you are using custom scripting/animation for, consider checking the new default option: Hydraulic gear systems

Moment of Inertia/Radii of Gyration

If you have customised the radii of gyration to achieve a “more heavy/stable” feel for your aircraft, consider switching to actual payload stations instead to achieve dynamic moment of inertia calculation based on actual load-out: Weight & Balance and Load Stations

Idle speeds

Setting up idle speed is a three-step process:

1. Getting the internal friction right

2. Setting the right amount of throttle to overcome the internal friction

3. Setting the fuel flow for that idle throttle

Learn more: Tuning Idle Speeds.

Pilot and Copilot Flight Control Inputs

X-Plane 12 differentiates between pilot & copilot sides for cockpit animations, joystick hardware, and plugins. Learn more: Pilot and Copilot Flight Control Inputs

Propeller overrides

X-Plane features datarefs that let you override parts of the flightmodel. While these datarefs are often named for the dataref whose value you control when the override is enabled, they really act by removing logic blocks from X-Plane’s flight model and systems simulation. Learn more: override_prop_pitch and override_prop_mode

Single Spool Engines

Aircraft that were using single spool engine types and relying on X-Plane to convert these to double spool engines should correct the engine type to “jet 2 spool” in Engines Specs > Engines 2 tab, then double check performance.

Stabilizer Trim and Servo

X-Plane provides two ways to trim the elevator or stabilizer of a plane: Mechanical or with an electric servo. The presence of an electric servo has consequences to the type of commands you can use to move the trim, and the commands you want to set up for hardware. This article explains the interaction of the commands and X-Plane systems code: Stabilizer Trim and Servo

Windshield ice and rain protection

X-Plane 12 simulates more than one glass surface for looking out. This affects how new 3D rain, icing, defrost, and wipers behave. Learn more: Windshield ice and rain protection datarefs

Radios and Navigation

Changes have been made to standalone DME, TACAN stations, and WAAS reception. Learn more: Changes to Radio Navigation

Weapons

Master Arm

In X-Plane 11 and earlier, the “master arm” command and panel switch had no effect on the sim. In X-Plane 12, master arm now functions: when the master arm switch is off, the only weapons that will fire are flare and chaff.  When the master arm is on, weapons will fire based on their prior selection rules, e.g. if they are either selected in the weapon console or by the various individual arm/disarm datarefs by weapon type.

A new writable dataref sim/cockpit2/weapons/master_arm provides writable access to the switch position.

For compatibility, aircraft are loaded with the master arm switch on, so existing aircraft without a master arm switch will have functioning weapons. If you have this switch you can initialize it to off in a flight-initialized plugin callback.

Sound

FMOD 2.02

X-Plane 12 now runs FMOD 2.02, and while your older, already compiled sound banks will still work on X-Plane 12 with no changes, the workflow for new projects has a few caveats. Learn more: FMOD 2.0 upgrade notes.

6 Comments

Understanding override_prop_pitch and override_prop_mode

X-Plane features datarefs that let you override parts of the flightmodel. While these datarefs are often named for the dataref whose value you control when the override is enabled, they really act by removing logic blocks from X-Plane’s flight model and systems simulation. This article explains the exact effects of overriding the prop_pitch and prop_mode overrides.

Prop Modes In X-Plane for Constant RPM Props.

X-Plane’s prop model features four prop modes for constant-RPM props in sim/flightmodel2/engine/actuators/prop_mode:

  • Feathered (prop_mode = 0): the prop goes to its feathered pitch as set in the .acf file.
  • Alpha range (prop_mode = 1): this is normal operation – a target RPM is set with the blue prop levers.  This is visible via sim/cockpit2/engine/actuators/prop_rotation_speed_rad_sec. The governor tries to adjust pitch within the range of the min and max pitch as set in Plane-Maker to maintain commanded RPM if possible.
  • Beta range (prop_mode = 2): prop pitch is commanded directly with the throttle as it moves through the beta range – the engine is at idle and the prop angle changes. On some planes the prop may even go into a reverse range while in beta mode – this is set in Plane-Maker.
  • Reverse range (prop_mode = 3): prop pitch is commanded directly with the throttle and goes from the beta pitch to reverse pitch, and throttle commands the actual throttle. This can be used to simulate reverse-by-throttle or a range of reverse angles or both.

X-Plane will set the prop target speed with the prop joystick axis if assigned, and the throttle with the throttle axis if assigned. The prop mode is set between reverse/beta/alpha by commands, and feathering happens via a series of on-board systems, e.g. feather when mixture is pulled, auto-feather, or feather when the prop lever is pulled past a detent.

Overriding prop_mode

When sim/operation/override/override_prop_mode is set to 1, X-Plane will not move the prop mode between alpha, beta and reverse when (1) the panel 2-d throttles are dragged or (2) a joystick axis moves into a new range on an aircraft with beta and reverse ranges built into the throttle.  (This is a .acf setting.)

X-Plane will change modes if you write to the dataref or when commands like sim/engines/thrust_reverse_toggle and sim/engines/beta_toggle are run; to ensure complete control of the dataref, override commands that affect beta or reverse.

When prop_mode is overridden and prop_pitch is not overridden, X-Plane will control feathering automatically, and writes of 0 to the prop_mode will be rejected.  Automatic feathering in the sim will still work.

Overriding prop_pitch

When setting sim/operation/override/override_prop_pitch to 1, X-Plane will not change the prop pitch. A bunch of code is bypassed:

  1. The joystick prop axis will not set the prop pitch (for variable pitch props) and will not set the target RPM (for constant RPM props). You must read the axis yourself using sim/joystick/joy_mapped_axis_avail and sim/joystick/joy_mapped_axis_value – array index 8 for a single global prop lever or 24-27 for individual prop levers.
  2. Constant mach and thrust-vectored props will not auto-adjust the target RPM.
  3. Feathering is disabled; you must set the prop mode to feather, and you must set the actual prop angle. Setting a prop mode of 0 and not setting the angle will not result in feathering!
  4. Constant RPM props will not set their pitch.

You can set the prop angle directly via sim/cockpit2/engine/actuators/prop_angle_degrees.

 

Leave a comment

Tuning Idle Speeds

Setting up idle speed is a four-step process:

  1. Setting the minimum “smooth” running speed.
  2. Getting the internal friction right.
  3. Setting the right amount of throttle to overcome the internal friction.
  4. Setting the fuel flow for that idle throttle

The “minimum engine running speed” setting in Plane Maker does NOT set the idle speed itself, but the minimum engine RPM that results in a smooth operation. This speed is lower than what we want the engine to actually idle at. If the RPM falls below the minimum running speed we will experience “stumbling” that manifests in RPM and torque fluctuations. If RPM drops far enough below that minimum speed, combustion itself will be affected and unable to sustain engine operation at all. The engine will come to a halt. The strength of the stumbling effect at lower-than-minimum RPM is determined by the number of cylinders that is set in Plane Maker. A four cylinder engine will exhibit more stumbling than a 6 cylinder engine or a radial engine with even more cylinders.

For a typical flat-four engine, the target idle will be around 600-700 RPM, while the minimum running RPM should be set closer to 500. This provides a good margin to keep the engine running under load from the alternator and at higher altitudes and hotter days where the engine makes less power. If the RPM drops below that setting of 500, expect erratic engine behavior.

The idle throttle setting serves one purpose, and that is overcoming the engine’s internal friction. The idle speed of the engine is determined by the equilibrium of the torque produced by the engine at idle throttle setting and the torque consumed by the engine at idle. That torque that needs to be overcome is the engine’s own internal friction, plus the small torque consumed by the propeller rotating at slow speed, plus any additional loads from the generator the engine needs to turn.

The engine’s internal friction is controlled in Plane Maker with the “engine friction” ratio. X-Plane’s guess at 1.0 works for a big-bore high compression direct-drive engine such as the IO-550 found on a Cirrus or Columbia. Other engines with different compression ratios or gearing will likely require different values here.

A good way to find the right internal friction, if the propeller is set up correctly, is to turn the engine off in flight (by cutting the mixture) and slowing the aircraft down to just above stall speed. The engine should almost stop turning as the airplane approaches stall speed, but rotate practically unaffected at greater air speeds (note that once fully stopped, a disproportionately high airspeed is needed to get the prop turning again).

The suggested process is to tune the sim/aircraft2/engine/engine_friction_ratio dataref in the simulator, take note of the value that produces the desired result, and then set it to the acf permanently in Plane Maker.

Once the internal friction is set, the airplane should be placed at a sea-level airport in standard atmosphere (15C OAT, 1013hPA QNH) and the electrical system loaded up with all electrical loads that are reasonably expected to be on on the ground ready for take-off, that is avionics bus powered, navigation and landing lights on, etc.

Then the idle throttle adjustment (sim/aircraft2/engine/high_idle_ratio) should be made so that the engine runs at a minimum smooth idle RPM with the throttle all the way out.

This will likely be too low to run the generator or alternator enough to charge the battery. That is not a bug, but corresponds to behavior found on many real piston aircraft. Basically all real piston engines require a positive throttle input to run at a high enough RPM to sustain generator load to charge the battery along with other electrical loads.

It is important to let the engine run for a minute or longer, as it might take some time to find the equilibrium between drive torque (generated by the engine) and drag torque (consumed by the engine itself, the propeller, and the generator).

The idle should be tweaked in the simulator with the sim/aircraft2/engine/high_idle_ratio dataref, and the desired value then set permanently in Plane Maker.
Once the engine runs stable at a low RPM in this config, it is up to the user (i.e. pilot, not aircraft developer) to run the throttle up enough to sustain battery charging.

Finally, the desired fuel flow at this setting can be adjusted with the dataref sim/aircraft/overflow/ff_rat_idle_PRP in the simulator and permanently saved to the acf in Plane Maker on the SFC (specific fuel consumption) tab.

Note that setting the engine up like this corresponds to a sea-level setup as would be performed on most aircraft.

Taking this aircraft to a high elevation airport such as Leadville, CO, will result in the engine stumbling or maybe even stopping at idle in a very short period of time. That is not a bug, but corresponds to how a real aircraft would behave at high density altitudes. It is absolutely necessary to lean the mixture and increase the throttle to sustain a good idle at high density altitudes, both in the real world and in X-Plane. In practice, the pilot will add throttle to keep the engine running, then slowly pull out the mixture control and watch the tachometer, to lean the engine to peak RPM, then reduce the throttle again to the desired RPM as dictated by electrical needs.

Comments Off on Tuning Idle Speeds

Airframe and Tail Anti-Ice and De-Icing boots

X-Plane previous to version 12 treated all flying surfaces (wing, tail, horizontal and vertical stabilizer) as one when it came to ice accumulation and anti- or de-ice measures. Newer versions treat the tail surfaces different from the wing surfaces.

Tail surface ice datarefs

Now the wing surfaces are separate from the tail surfaces. Each tail and wing surface can accumulate ice separately. The new datarefs for ice on the tail are
sim/flightmodel/failures/tail_ice float y ratio Ratio of icing on tailplane (hstab and vstab) - left side
sim/flightmodel/failures/tail_ice2 float y ratio Ratio of icing on tailplane (hstab and vstab) - right side

The new dataref that decides what to do with the tail is:
sim/cockpit2/ice/ice_tailplane_man int y enum De-ice tailplane automatically with wing/airframe deice, or separately with new datarefs. 0 = Auto, Default: Tail is deiced with whatever acts on the wings. 1 = Man: Tailplane de-ice is no longer slaved and must be turned on with separate datarefs.

Legacy aircraft use the “0” default setting, so all surface de-ice will automatically de-ice the tail as well, to preserve behavior from previous versions that did not distinguish between wing and tail surfaces.

Tail anti- and de-ice

For the tail, you now have the set of datarefs for the same options as for the wings:
sim/cockpit2/ice/ice_tail_heat_left_on int y boolean De-ice switch, 0 or 1. Anto-ice – electric heat. This switch engages electrically heated leading edges. (Left tailplanes)
sim/cockpit2/ice/ice_tail_heat_right_on int y boolean De-ice switch, 0 or 1. Anti-ice – electric heat. This switch engages electrically heated leading edges. (Right tailplanes)
sim/cockpit2/ice/ice_tail_boot_on int y enum De-ice switch, 0, 1, 2, 3. De-ice – pneumatic. This switch inflates flexible bladders on the wing leading edges to pop off accumulated ice. 0 = Off, 1 = Continuous, 2 = Single/Auto (deflates automatically), 3 = Man (deflates when switch let go) (All tailplanes)
sim/cockpit2/ice/ice_tail_boot_left_on int y enum De-ice switch, 0, 1, 2, 3. De-ice – pneumatic. This switch inflates flexible bladders on the wing leading edges to pop off accumulated ice. 0 = Off, 1 = Continuous, 2 = Single/Auto (deflates automatically), 3 = Man (deflates when switch let go) (Left tailplanes)
sim/cockpit2/ice/ice_tail_boot_right_on int y enum De-ice switch, 0, 1, 2, 3. De-ice – pneumatic. This switch inflates flexible bladders on the wing leading edges to pop off accumulated ice. 0 = Off, 1 = Continuous, 2 = Single/Auto (deflates automatically), 3 = Man (deflates when switch let go) (Right tailplanes)
sim/cockpit2/ice/ice_tail_hot_bleed_air_on int y boolean De-ice switch, 0 or 1. Anti-ice – bleed air. This switch directs warm air from the engines into the tailplane leading edges to keep them free of ice. (All tailplanes)
sim/cockpit2/ice/ice_tail_hot_bleed_air_left_on int y boolean De-ice switch, 0 or 1. Anti-ice – bleed air. This switch directs warm air from the engines into the tailplane leading edges to keep them free of ice. (Left tailplanes)
sim/cockpit2/ice/ice_tail_hot_bleed_air_right_on int y boolean De-ice switch, 0 or 1. Anti-ice – bleed air. This switch directs warm air from the engines into the tailplane leading edges to keep them free of ice. (Right tailplanes)
sim/cockpit2/ice/ice_tail_tks_on int y enum De-ice switch, 0, 1, or 2. Anti-ice – TKS fluid. This switch activates the pump for the weeping wing, dissipating TKS fluid on the leading edges to keep them free of ice. 0 = Off, 1 = Norm, 2 = High. (All tailplanes)
sim/cockpit2/ice/ice_tail_tks_left_on int y enum De-ice switch, 0, 1, or 2. Anti-ice – TKS fluid. This switch activates the pump for the weeping wing, dissipating TKS fluid on the leading edges to keep them free of ice. 0 = Off, 1 = Norm, 2 = High. (Left tailplanes)
sim/cockpit2/ice/ice_tail_tks_right_on int y enum De-ice switch, 0, 1, or 2. Anti-ice – TKS fluid. This switch activates the pump for the weeping wing, dissipating TKS fluid on the leading edges to keep them free of ice. 0 = Off, 1 = Norm, 2 = High. (Right tailplanes)

By default ( ice_tailplane_man == 0) all these are slaved to the wing counterparts – so if you switch anything on the wing on, the tail counterpart will go on, to preserve the old behavior. Also, the bleed air, TKS fluid, etc usage is tweaked so that it stays unchanged if both tail and wing are switched on (i.e. with both tail and wing on resource use equals former use of wing only).
If you chose to set the tailplane to manual (1) you can use all the new datarefs independently.

Pneumatic De-icing boots operation and animation

For the boots themselves: Two new datarefs exist for the inflation – these could be used to animate actual boots:
sim/cockpit2/ice/ice_wing_boots_inflation float[2] y ratio De-icing boots inflation ratio, left and right wing
sim/cockpit2/ice/ice_tail_boots_inflation float[2] y ratio De-icing boots inflation ratio, left and right tailplane

The boots take 6 seconds to inflate fully, and about three to be sucked empty again by vacuum. Note that the de-ice failure affects inflation, while lack of vacuum effects deflation.
Each boot switch dataref now has four settings:
0 = Off
1 = Continuous – this is to provide compatibility with 11.30. The boots are repeatedly cycled in auto mode whenever ice up to 0.2 has accumulated.
2 = Auto/Single – this initiates a six second inflation followed by a 3 second deflation regardless whether switch is sprung back or held in position.
3 = Man – this initiates an inflation and keeps the boots inflated for as long as the switch is held. Upon switching back to 0, deflation happens with vacuum.

The following commands are new to satisfy the new switch positions and act as if the switch is spring-loaded (the existing commands work for 0/Off and 1/Continuous for compatibility):
"sim/ice/wing_boot_single" ,"Anti-ice: all wing, de-icing boots single auto."
"sim/ice/wing_boot0_single" ,"Anti-ice: left wing, de-icing boots single auto."
"sim/ice/wing_boot1_single" ,"Anti-ice: right wing, de-icing boots single auto."

"sim/ice/wing_boot_man" ,"Anti-ice: all wing, de-icing boots manual."
"sim/ice/wing_boot0_man" ,"Anti-ice: left wing, de-icing boots manual."
"sim/ice/wing_boot1_man" ,"Anti-ice: right wing, de-icing boots manual."

All commands now have counterparts for tail:
"sim/ice/tail_heat_on" ,"Anti-ice: all tail, anti-ice heat on."
"sim/ice/tail_heat0_on" ,"Anti-ice: left tail, anti-ice heat on."
"sim/ice/tail_heat1_on" ,"Anti-ice: right tail, anti-ice heat on."

"sim/ice/tail_heat_off" ,"Anti-ice: all tail, anti-ice heat off."
"sim/ice/tail_heat0_off" ,"Anti-ice: left tail, anti-ice heat off."
"sim/ice/tail_heat1_off" ,"Anti-ice: right tail, anti-ice heat off."

"sim/ice/tail_heat_tog" ,"Anti-ice: all tail, anti-ice heat toggle."
"sim/ice/tail_heat0_tog" ,"Anti-ice: left tail, anti-ice heat toggle."
"sim/ice/tail_heat1_tog" ,"Anti-ice: right tail, anti-ice heat toggle."
"sim/ice/tail_boot_on" ,"Anti-ice: all tail, de-icing boots on schedule."
"sim/ice/tail_boot0_on" ,"Anti-ice: left tail, de-icing boots on schedule."
"sim/ice/tail_boot1_on" ,"Anti-ice: right tail, de-icing boots on schedule."

"sim/ice/tail_boot_off" ,"Anti-ice: all tail, de-icing boots off."
"sim/ice/tail_boot0_off" ,"Anti-ice: left tail, de-icing boots off."
"sim/ice/tail_boot1_off" ,"Anti-ice: right tail, de-icing boots off."

"sim/ice/tail_boot_tog" ,"Anti-ice: all tail, de-icing boots toggle."
"sim/ice/tail_boot0_tog" ,"Anti-ice: left tail, de-icing boots toggle."
"sim/ice/tail_boot1_tog" ,"Anti-ice: right tail, de-icing boots toggle."

"sim/ice/tail_boot_single" ,"Anti-ice: all tail, de-icing boots single auto.",
"sim/ice/tail_boot0_single" ,"Anti-ice: left tail, de-icing boots single auto."
"sim/ice/tail_boot1_single" ,"Anti-ice: right tail, de-icing boots single auto."

"sim/ice/tail_boot_man" ,"Anti-ice: all tail, de-icing boots manual.",
"sim/ice/tail_boot0_man" ,"Anti-ice: left tail, de-icing boots manual."
"sim/ice/tail_boot1_man" ,"Anti-ice: right tail, de-icing boots manual."
"sim/ice/tail_tai_on" ,"Anti-ice: all tail, bleed anti-ice on."
"sim/ice/tail_tai0_on" ,"Anti-ice: left tail, bleed anti-ice on."
"sim/ice/tail_tai1_on" ,"Anti-ice: right tail, bleed anti-ice on."

"sim/ice/tail_tai_off" ,"Anti-ice: all tail, bleed anti-ice off."
"sim/ice/tail_tai0_off" ,"Anti-ice: left tail, bleed anti-ice off."
"sim/ice/tail_tai1_off" ,"Anti-ice: right tail, bleed anti-ice off."

"sim/ice/tail_tai_tog" ,"Anti-ice: all tail, bleed anti-ice toggle."
"sim/ice/tail_tai0_tog" ,"Anti-ice: left tail, bleed anti-ice toggle."
"sim/ice/tail_tai1_tog" ,"Anti-ice: right tail, bleed anti-ice toggle."
"sim/ice/tail_tks_on" ,"Anti-ice: all tail, TKS de-ice normal."
"sim/ice/tail_tks0_on" ,"Anti-ice: left tail, TKS de-ice normal."
"sim/ice/tail_tks1_on" ,"Anti-ice: right tail, TKS de-ice normal."

"sim/ice/tail_tks_high" ,"Anti-ice: all tail, TKS de-ice high."
"sim/ice/tail_tks0_high" ,"Anti-ice: left tail, TKS de-ice high."
"sim/ice/tail_tks1_high" ,"Anti-ice: right tail, TKS de-ice high."

"sim/ice/tail_tks_off" ,"Anti-ice: all tail, TKS de-ice off."
"sim/ice/tail_tks0_off" ,"Anti-ice: left tail, TKS de-ice off."
"sim/ice/tail_tks1_off" ,"Anti-ice: right tail, TKS de-ice off."

"sim/ice/tail_tks_tog" ,"Anti-ice: all tail, TKS de-ice toggle."
"sim/ice/tail_tks0_tog" ,"Anti-ice: left tail, TKS de-ice toggle."
"sim/ice/tail_tks1_tog" ,"Anti-ice: right tail, TKS de-ice toggle."

Comments Off on Airframe and Tail Anti-Ice and De-Icing boots

Stabilizer Trim and Servo

X-Plane provides two ways to trim the elevator or stabilizer of a plane: Mechanical or with an electric servo. The presence of an electric servo has consequences to the type of commands you can use the move the trim, and the commands you want to set up for hardware. This article explains the interaction of the commands and X-Plane systems code.

Trim commands for pilots – how to configure your flight control hardware

X-Plane provides separate commands for electric and mechanical trim, and a catch-all command for trim that would work with either system. Most of the time, you’d want your flight control yoke or joystick to trigger the generic command, so you can fly with any type of aircraft:

sim/flight_controls/pitch_trim_up
sim/flight_controls/pitch_trim_down

will dispatch the command to an electric trim servo, if the plane has one, and to moving the trim wheel, if that’s the only way of trimming the plane has.

If you have a more advanced setup involving more hardware, you can easily configure your yoke trim rocker to actuate the electric commands, while a switch on your throttle console acts on the mechanical commands. This way, you can realistically deal with a servo failure in a plane that has one: As long as the servo is on, you trim with your thumb on your yoke, and if the servo is off, you can still “grab the wheel” on your console to move the trim. This obviously also works if you have an actual hardware wheel which you assign to an axis instead of a button. The respective commands are:

sim/flight_controls/pitch_trim_up_elec
sim/flight_controls/pitch_trim_down_elec
sim/flight_controls/pitch_trim_up_mech
sim/flight_controls/pitch_trim_down_mech

an even more advanced yoke might also have split trim switches where both channels need to be active in order to trim. Commands for this are:

sim/flight_controls/pitch_trimA_up
sim/flight_controls/pitch_trimA_down
sim/flight_controls/pitch_trimB_up
sim/flight_controls/pitch_trimB_down

Another important difference is that electric trim by pilot action will necessarily trim-interrupt and disconnect the autopilot, while displacing the mechanical trim wheel (by command or by axis) will not!

Trim commands for airplane creators

A legacy aircraft will detect the type of trim system based on the presence of an autopilot: A plane with a single-axis autopilot is assumed to have no electric trim servo. A plane equipped with a dual-axis or better autopilot is assumed to have an electric trim servo and use it as primary means of trim.
New aircraft can specify the trim servo with the option “electric trim servo equipped” in Plane Maker on the trim controls page.

When you have an electric trim servo it can be switched on or off with the dataref

sim/cockpit2/autopilot/electric_trim_on

switching it off will not only prevent the autopilot from using it, but also cause electric trim commands to no longer work. The same thing happens when the “Elevator trim actuator” failure is triggered – the servo will fail and you can only trim mechanically.

If your plane does not have an electric servo (by means of not having selected one, or by being a legacy plane with a single-axis auto-pilot), assigning any bus or amperage to the trim actuator does nothing. The failure of the trim actuator then refers to a jamming of the mechanism, rather than a servo failure.

Make sure to assign the “Elevator trim actuator” a bus and an amperage in Plane Maker, so it only runs when the correct electrical system is powered.

When it comes to the 3D cockpit, assign the manipulator of the physical wheel to either the _mech commands, or to the trim dataref. Assign the _elec commands to rocker switches. Since you know which system your specific aircraft has, you should never need to assign the catch-all commands to anything in your 3D cockpit.

Comments Off on Stabilizer Trim and Servo

Windshield ice and rain protection datarefs

X-Plane historically had only one windshield for the 2d cockpit, on which effects for icing, rain or wipers were displayed. With the advent of more sophisticated 3d effects, it has become necessary to simulate more than one glass surface for looking out.

Index conventions

X-Plane 12 has four distinct window surfaces. They are numbered as follows:

  1. Pilot front windshield
  2. Copilot front windshield
  3. Pilot side window
  4. Copilot side window

Even numbers refer to the left side (0 being even) and odd numbers to the right side.

Ice and defrost

Depending on temperature and weather conditions around the airplane, ice can form on the windows. The amount of ice is tracked as a ratio from 0..1 and available as an array dataref, index as per above
sim/flightmodel/failures/window_ice_per_window float[4]
The pilot can turn on electric heating for each window (a real airplane might not have heat for every window, in which case there simply wouldn’t be switches for some of the dataref indices).
sim/cockpit2/ice/ice_window_heat_on_window int[4]
controls the electric switches, which will then consume the amps set in Plane Maker for
De-ice: window heat, De-ice: window heat copilot, De-ice: l side window heat and De-ice: r side window heat respectively.
The heating elements can be failed by their respective bus, or the failure datarefs
sim/operation/failures/rel_ice_window_heat
sim/operation/failures/rel_ice_window_heat_cop
sim/operation/failures/rel_ice_window_heat_l_side
sim/operation/failures/rel_ice_window_heat_r_side

Wipers

X-Plane has two wiper speed controllers, acting on the left (even numbered) wipers and right (odd numbered wipers).
sim/cockpit2/switches/wiper_speed_switch int[2] y enum 0=park, 1=25%speed,2=50%speed,3=100%speed
Wiper speed 0 is aliased to the old wiper_speed dataref for backward compatibility for the pilot windshield.

Four wipers can be defined in Plane Maker and assigned min and max deflection angles. If your aircraft has less than four wipers, simply assign the unnecessary wipers so that angle 1 == angle 2, in which case no movement will be generated.

At runtime,
sim/flightmodel2/misc/wiper_angle_deg float[4] n degrees
tells you the deflection of each wiper and this dataref will be used to wipe the 3d rain off the windshield in the 3d cockpit as well.

Rain repellent

Some business jets don’t have wipers, and instead rely on airflow alone to run the water off of specially coated windshields.

On the ground, a blower is used to generate an airflow over the windshield, to run off water when airspeed is insufficient to do so. In X-Plane, you can turn on two blowers for left and right side with the dataref
sim/cockpit2/switches/rain_repellent_switch int[2] y boolean
This will use electric power to generate the airflow.

Comments Off on Windshield ice and rain protection datarefs