X-Plane simulates governors for constant speed propellers that can have various failure modes. Depending on the type of engine/propeller combination on the aircraft, the behavior of the governor in case of an engine failure will be different. X-Plane 11.30 allows you to select the type of governor to simulate, to accommodate a wide range of different engine types. Read More
The _vrconfig.txt file is a text-based configuration file that customizes VR interactions for your aircraft.
VR Configurations are aircraft-specific which means each ACF requires its own configuration file. While VR Configurations are not required, they are strongly encouraged. Aircraft that do not have a VR Configuration will still load and still work, even with VR enabled, however, there will be no hotspots to make it easy for the user to get back into the pilot seat, and there will be no customization allowing the VR controllers to be used to their fullest potential.
The VR Configuration name needs to match the prefix of the ACF file, with _vrconfig.txt appended to the end. For example, to make a VR config for Cessna_172SP.acf, the file needs to be called Cessna_172SP_vrconfig.txt. This file must exist in the same directory as the ACF file.
The _vrconfig.txt file is a text file – Unix or Windows line endings are legal, blank lines are allowed after the header, and the character set should be UTF-8.
The header of the file should be
A
1100
VRCONFIG
followed by the directives listed below.
Hotspots are predefined locations that are used to precisely orient the VR user when selected. They are commonly used on the pilot and co-pilot seats so that users can quickly position themselves accurately in the seats.
Each hotspot block defines a single hotspot on or around the aircraft. You must use a matched pair of BEGIN_TELEPORT_HOTSPOT and END_TELEPORT_HOTSPOT. In this block you must have:
Note: Unless the REF_POINT_ACF directive is set, all units are in Aircraft Coordinates – meters with the origin at the aircraft CG and the positive Z axis pointing aft. This is not the same as the English units used in Plane-Maker.
If this directive appears in the VRCONFIG, the hotspot location origin for AABB and PRESET_XYZ are no longer tied to the aircraft’s CG but instead moves to some offset from the aircraft’s authoring point in Plane-Maker. Typically artists will put the reference point of the aircraft at the tip of the nose or tail and it stays there throughout the aircraft’s existence. This makes it a more useful reference point for coordinates than the aircraft’s CG which might change as authors gather newer and more accurate data to model the aircraft.
There are two main uses of this directive. First, if the VRCONFIG is being done for the very first time, setting this directive tells the sim to just use the authoring point as the origin so it’ll never be tied to the CG. You can leave the Y/Z coordinates blank and the sim will assume you mean 0.0 0.0. The second main use is for VRCONFIGs that have already been done for an aircraft that is now having it’s CG moved. Rather than have to adjust every coordinate in the VRCONFIG, you can use this directive to tell the sim that the origin should be at the OLD CG’s location by telling it where the OLD CG was relative to the aircraft’s authoring point. For example, if the OLD CG was at a Y/Z of 3.28084ft/-6.56168ft (remember, PlaneMaker uses FEET for its units) then you could add REF_POINT_ACF 1.0 -2.0 (which is the old CG location, converted from feet to meters) as a directive to the VRCONFIG which will allow the CG to move but the reference point for the file to stay at the OLD CG.
This begins the definition of a new teleport hotspot. All hotspot properties must be specified after this directive and before the matched END_TELEPORT_HOTSPOT directive. The legal types of hotspots are ‘SITTING’ and ‘STANDING’. A sitting hotspot places the user’s head at the XYZ location. A standing hotspot places the user’s feet at the XYZ location. The name property is useful for debugging purposes.
This defines the end of a given teleport hotspot. Each hotspot must be “ended” before anything else in the file occurs, and before the file ends.
This adds an axis-aligned bounding box (in aircraft coordinates, that is +X = right, +Y = up, +Z = aft) in meters around the CG of the aircraft. When the teleport beam lands inside this box, if the user ends the teleport, this hotspot will be used to position the user.
This sets the location of the user to the location X, Y, Z in meters, relative to the default CG of the aircraft; X is right, Y is up, Z is aft. A sitting hotspot places the user’s head at the XYZ location. A standing hotspot places the user’s feet at the XYZ location.
This sets the rotation orientation (rotating about the Y-axis) of the user’s view in degrees. 0 degrees is facing forward in the aircraft, 90 would look toward the right wing, 180 degrees would be looking back at the tail etc.
This sets the pitch orientation (rotating about the X-axis) of the user’s view in degrees. 0 degrees is level. 90 would look straight up at the sky. -90 would look down at the ground.
This sets the tilt orientation (rotating about the Z-axis) of the user’s view in degrees. 0 degrees is upright. -90 would be like tilting their left ear to their shoulder. 90 would be like tilting their right ear to their shoulder.
Some aircraft manipulators need more information than is currently available in the OBJ itself in order to function optimally with VR Controllers. The most common examples of these are knobs and switches. With a mouse, knobs usually move one detent for each click. With a VR controller, however, X-Plane needs to know how much rotation is necessary in order to move the knob to the next detent. For linear knobs like lighting rheostats, this can be a fraction of a degree. For more coarse knobs like a fuel selector, you may want to require 60 degrees of rotation. There are other reasons to specialize manipulators such as changing their behavior entirely. For example, if the default aircraft manipulator uses commands to increment something by single degrees, but you want a smoother feel to the knob, you may want to redefine the manipulator to use a dataref to increment by fractions of a degree.
It’s important to note that customizations done with this file ONLY affect VR controllers. They will not change mouse or joystick hardware functionality.
This begins the manipulator block that defines the EXISTING aircraft OBJ manipulator to be customized. All manipulator properties must be specified AFTER this directive and before the matched END_MANIP directive. This line essentially contains the unique pieces of the OBJ manipulator for it to be looked up.
The manipulator type needs to match the type specified in the OBJ but without the ‘ATTR_manip_’. For example, if the OBJ has an ATTR_manip_command_axis, the type (for the purposes of this file) should be ‘command_axis’. The cmnd1/dref1 and cmnd2/dref2 should match those that exist in the OBJ manipulator definition. If the manipulator needs only one command/dataref, then cmnd2/dref2 can be omitted completely.
Lastly, to disambiguate two manipulators that have the exact same type and act on the same commands/datarefs, an optional tooltip can be used. This is common with Yoke manipulators since there are usually two yokes for the pilot and copilot and they typically act on the same datarefs. Again, if the tooltip is unnecessary to find a manipulator that is unambiguous and unique, it can be omitted completely.
The manipulator block will match only one manipulator – if more than one manipulator in the OBJ matches the specification, only one will be remapped; use more information (E.g. tooltips) when you need to remap manipulators that are otherwise ambiguous.
This marks the end of a given manipulator block. Each manipulator block must be “ended” before anything else in the file occurs, and before the file ends.
This tells the VR system that this manipulator should be changed to an axis_knob manipulator and used instead of the original manipulator. This is useful if you want to act on the dataref instead of a command in VR mode to have finer control over the knob’s increment/decrement amounts. DX specifies the amount of change applied to the dataref for each action. Use DEG_PER_ACTION to set the amount of wrist rotation needed for an action to fire.
This tells the VR system that this manipulator should be changed to an ATTR_manip_axis_switch_up_down manipulator and used instead of the original manipulator. This is useful if you want to act on a dataref instead of a command in VR mode to have finer control over the Up/Down switch’s increment/decrement amounts. DX specifies the amount of change applied to the dataref for each action. Use SWITCH_THRESHOLD to set the amount of wrist deflection/movement needed for an action to fire.
See ACTION axis_switch_up_down for details. It’s exactly the same except in the horizontal direction.
This tells the VR system that this manipulator should be changed to a drag_xy manipulator and used instead of the original manipulator. This is usually used to override the show/hide Yoke manipulator to instead make it behave as if the user has grabbed the yoke to begin using it.
This tells the VR system that this manipulator should be changed to an ATTR_manip_command_axis manipulator and used instead of the original manipulator. This is useful for mechanical things that have two states that you want to move through with a rest in between. For example, consider an elevator trim switch that’s spring loaded in the up and down positions so it always recenters. This manipulator coupled with a HOLD_MANIP flag will get you that behavior.
This tells the VR system that this manipulator should be changed to an ATTR_manip_command_knob manipulator and used instead of the original manipulator. This is useful if you want the mechanical thing to perform one command in a direction and another command if rotated in the opposite direction.
This tells the VR system that this manipulator should be changed to an ATTR_manip_command_switch_up_down2 manipulator and used instead of the original manipulator. This is useful if you have a single command that toggles rather than requiring two separate commands like ATTR_manip_command_switch_up_down.
This tells the VR system that this manipulator should be changed to an ATTR_manip_command_switch_left_right2 manipulator and used instead of the original manipulator. This is useful if you have a single command that toggles rather than requiring two separate commands like ATTR_manip_command_switch_left_right.
This tells the system how many degrees of wrist rotation is necessary before a knob manipulator will be acted upon. Another way of thinking about it is how far does the VR controller need to be rotated before the manipulator will fire as if the mouse was clicked once.
Similar to DEG_PER_ACTION for knobs, SWITCH_THRESHOLD tells the system how much wrist tilt or motion is necessary to trigger a command. This is useful for things dials like the vertical speed dial on an airliner. The angle in degrees tells the system how many degrees of tilt are necessary before triggering the command. The offset threshold in meters tells the system how much motion should exist before triggering the command. This allows the user to lift/lower their arm to operate the dial instead of tilting their wrist.
This tells the system that the knob manipulator should wrap. Examples of knobs that should wrap would include the course knob or heading bug. Examples of knobs that should not wrap are lighting knobs and volume controls.
This tells the system that the knob/switch manipulator should hold down commands continuously while it is not in motion. Without this, commands are issued once for each ‘click’ of the switch or knob; with this, a command is held until the knob/switch is released or moved again. Do not use this for manipulators that use datarefs. It is only intended for command manipulators.
Starter keys and spring-loaded knobs and switches often require the HOLD_MANIP directive as they will return to the off position when not held.
This tells the system that the knob/switch manipulator should be inverted in the way it processes commands. For example, switches are expected to be UP in the ‘on’ position and DOWN in the ‘off’ position but some switches just aren’t modeled that way or the real switch is actually mounted upside down. With this flag, you can reverse the behavior to match real life without having to change the command order in the OBJ.
This tells the system that it should not draw any kind of feedback visuals during manipulator use. Some manipulators such as axis manipulators visualize the axis while a user interacts with it. With this flag, that drawing will be disabled. This does not affect the drawing of the manipulator geometry BEFORE interaction.
This tells the system that the manipulator is one that should be treated like a real-world joystick control (like those found on Airbuses and the CirrusJet). The data here will only become active if the user has enabled “Realistic” mode for their VR Yokes. The pitch and roll mins and maxes define the range of tilting motion in degrees of the VR controller that should be mapped to the full range of motion of the flight controls.
This tells the system that the manipulator is one that should be treated like a real-world yoke control (like those found on a Cessna 172) where the pitch axis is a translation axis that slides back and forth and the roll axis is a rotation one like a steering wheel that rotates about a centroid. The data here will only become active if the user has enabled “Realistic” mode for their VR Yokes.
Pitch min and max x,y,z are in OBJ units and define the axis of translation for pitch; they can be taken directly from the translation axis used to animate your yoke. The length of the vector between these points defines how far the yoke moves from full nose up to full nose down, and is typically aligned along the Z axis.
Roll centroid x,y,z are also in OBJ units and define the point at which the yoke rotates around. This point should be somewhere on the center of the yoke, and can be taken from the static translation that precedes your yoke’s roll animation.
The roll axis defines the axis about which the yoke rolls, and can be taken from the axis of your roll animation directly. This should be a unit vector, and will typically be about the Z axis.
The roll min and max angles define the maximum travel in either direction from the “level” point, and can be taken from the end key frames of your roll animation.
This tells the system that the manipulator is one that should be treated like a real-world flight stick (like those found in a fighter jet or SuperCub) where the pitch and roll axis are attached to a single stick that is attached to a mount point that can be rotated forward and back as well as left and right about two centroids (that can be co-located).
Pitch and roll centroid x,y,z are in OBJ units and define the centroids about which the pitch and roll axis rotates – you can take them from the static translation that precedes your animation.
Pitch and rolls axis x,y,z define the unit vectors of the rotation axes for pitch and roll; they should be unit vectors and can be taken directly from your pitch and roll animations. Typically the pitch axis will be the X axis and the roll axis will be the Z axis.
The pitch and roll min and max degrees define the maximum amount of rotation that can exist in either direction, for both pitch and roll.
Note that you can use YOKE_MANIP_ROTATE for both flight sticks (like a helicopter or fighter) or for airliner-style column yokes. In the flight stick case, the rotation centroid is at the floor pivot for both axes. For an airliner yoke, the pitch centroid is on the floor but the roll centroid is on the yoke itself.
We do not recommend using YOKE_MANIP_ROTATE for very small side sticks because they are hard to control in VR; prefer JOYSTICK_MANIP instead.
X-Plane always simulated three different methods for getting attitude and heading information in the cockpit, and a total of six separate gyros to use and drive panel instruments:
It is worth noting that none of the gyro systems have any idea where magnetic north actually is. All they can do is keep their orientation within space, so they need to be aligned to magnetic north by using an external reference, such as a magnetic compass or the compass dial painted onto the pavement in the runup area of an airport. Cessna pilots are familiar with the little knob on the bottom left of their directional gyro – it’s what they push and twist in order to set the gyro to the magnetic heading.
Another way to align the directional gyro to magnetic north is by using a sensor that can detect the direction of the earth’s magnetic field. This sensor is called a fluxgate, or sometimes magnetometer, and is usually mounted in the left wing of an aircraft, far away from the engine, other avionics, or any equipment that might generate magnetic disturbances. The fluxgate transmits a signal to the remote gyro unit.
For most HSIs, a remote gyro unit is mounted in the back of the plane. It’s an electric gyro that keeps its orientation once spun up and aligned. The fluxgate signal tells the remote gyro unit where magnetic north is. Thus, the electric gyro can be slaved to the fluxgate, indicating magnetic north without the need for the pilot to align it! It is worth noting that the fluxgate is subject to some, but not all of the errors the magnetic whisky compass is. In particular, while it does not have an acceleration error, it does have a dip error in turns! Thus, the electric gyro is used to get a very reliable course information during a turn, where the fluxgate reading is inaccurate, while in horizontal flight the slaving mechanism takes care of eliminating gyro precession. In other words: the gyro is used to compensate short-term errors of the fluxgate, and the fluxgate is used to compensate long-term errors of the gyro.
Most remote HSIs have a way to free the gyro from the slaving to the fluxgate sensor, and treat it instead like a regular directional gyro. This mode is called “free” mode, and is activated by flipping the remote gyro switch from “slaved” to “free”. Besides a magnetometer failure, a use case for that is when flying with regards to true north reference, instead of magnetic north, which is done for example in northern Canada. In this case, the gyro is freed, and then the slew buttons or rocker switch (which work just like the slewing knob on the old C172’s directional gyro) are used to align the gyro to true north.
In the dataref list of X-Plane 11.10, you can find all these values under the sim/cockpit/gyros/ category. Now that you know what AHARS, elec and vac mean, you just need to remember that psi is the heading, theta the pitch and phi the roll. When you make a 3d instrument for an HSI or DG, be aware of the correct system and dataref to use. The sim/cockpit/gyros/dg_drift_vac(2)_deg data refs allow you to see how far the vacuum gyro has drifted from the magnetic north, and the commands sim/instruments/(copilot_)DG_sync_[down/up] allow you adjust the setting of the vacuum gyro (the push-and-twist). For electric (remote) gyros, the new dataref sim/cockpit/gyros/gyr_free_slaved[] allows you to turn on (1) or off (0) slaving the electric gyros to the fluxgate. In free gyro mode, the new commands sim/instruments/[copilot_]free_gyro_[down/up] allow you to model the slave buttons or the CW/CCW switch on a slaving compensator panel. The respective drift datarefs sim/cockpit/gyros/dg_drift_ele(2)_deg allow you to model the slaving meter gauge. Finally, the new datarefs sim/cockpit/gyros/gyr_flag[] indicate whether the GYRO or HDG warning flag should be shown on the HSI or DG instrument. The new flag dataref not only reacts to low vacuum pressure or failed electric gyros, but it also momentarily shows while a free gyro adjustment is in progress, just like you’d see it on a Bendix/King KCS55A HSI.
Besides the new features mentioned above, X-Plane 11.10 fixes a few problems with how the existing gyro systems interacted with failure modes and electrical systems:
X-Plane’s autopilot always has and always had one channel for a tracker/coupler function, that works on both low-sensitivity sources like VORs and high-sensitivity like LOCalizers. With the HSI source selector, either a VOR/LOC receiver or a GPS/FMS can be selected to feed lateral deviation (what is indicated by a CDI) to the autopilot, whilst the desired track is fed to the autopilot by a number of different sources that can be configured. Thus, there’s only one NAV mode to take care of tracking the GPS flight plan, or intercepting and tracking a VOR radial or localizer.
Depending on the source, the nav mode can be armed before it actually engages, which is done for example in dual-mode intercepting. Dual-mode intercepting allows the autopilot to follow a heading, until a selected VOR radial or localizer course is intercepted, at which point the tracker/coupler takes over from the heading mode. In order to engage, the NAV mode needs either a both falling and less-than-full deflection on an angular offset (VOR, LOC), or an absolute XTK (GPS/FMS). Thus, NAV mode is never engaged directly, but armed (using a command, dataref or 2d panel button).
X-Plane 11.10 now supports a separate autopilot nav mode that works only with GPS steering cues: GPSS. GPSS tracks the GPS or FMS flightplan, with all the benefits you are used to from GPSS: turn anticipation and automatic tracking of arc segments, holdings and procedure turns. However, it works on a separate channel that is hardwired to the GPS/FMS in the plane including for front course (DTK) information.
This mode cannot be armed. If a valid GPS steering cue is available (a waypoint is active) it engages immediately. Otherwise, it just refuses to engage.
What is important is that the GPSS mode is treated like a heading mode when it comes to dual-mode intercepts. Thus, it allows you to arm localizer interception, while tracking a GPS flightplan that for example takes you through an RNAV transition onto the ILS approach. In this case, GPSS is active, the HSI selector can be turned to a VOR/LOC receiver, and then NAV or APPR mode can be armed. The autopilot will follow the GPS flightplan until it intercepts the localizer, at which point tracking will switch from GPSS to NAV (VOR or LOC).
Various X-Plane add-on aircraft have achieved similar functionality through various kinds of plugin trickery in the past. This new mode is now available without plugins.
The new command sim/autopilot/gpss toggles the GPSS mode on or off. Note that the mode will refuse to engage when no waypoint is active in the GPS/FMS. The sim/cockpit/autopilot/autopilot_state flag field now has the flag 2^19=524288 to indicate whether the mode is active, similarly, writing that value toggles the mode. sim/cockpit2/autopilot/heading_mode will read 13 if GPSS is active. Finally, sim/cockpit2/autopilot/gpss_status will return 0 for off and 2 for engaged for the new mode.
X-Plane no longer supports non-sRGB color space images or gammas. This goes for DDS and PNG images. You must create sRGB color space artwork for X-Plane 11. If you have DDS files in 1.8 gamma, re-grind them with the latest X-Grinder. If your PNG files are not saved in the sRGB color space, please convert their color space.
Motivation: non-sRGB color spaces with non-sRGB gamma were supported historically in X-Plane to support authoring on very old versions of Mac OS X. However, since 2009 OS X has supported sRGB as its default gamma, making this unnecessary.
Furthermore, determining gamma from DDS and PNG files has proven to be very difficult; X-Plane’s gamma tag in DDS is non-standard, causing interoperability problems with many standard DDS tools; color space tagging in PNG is unreliable, including PNGs saved by photoshop.
By removing gamma conversion and simply assuming sRGB, we make it more likely that modern content is interpreted with its correct intent; this eliminates all bugs where incorrectly tagged modern sRGB content is treated as a non-standard gamma and processed incorrectly by X-Plane.
You may need to retune the color and alpha of your translucent glass. In almost all cases the right thing to do is to:
– Make the RGB of the window darker – the real window does not add light to the scene, it absorbs some small amount of it. It is not crazy for a tinted window to have a black RGB, with the alpha being more transparent to ‘lighten’ it. Think of a cross fade between a truly clear piece of glass and a black piece of paper.
– Make the alpha of the window more opaque – the linear blending looks like it lets more light through, so once your window is dark enough you may find you need heavier tinting.
See the “X-Plane 11 Material Model” article for a detailed explanation of how the new lighting and material model works.
All reflective surfaces must be marked inside or outside to reflect the correct part of the world. This includes glass for the first time in v11.
You should update the lighting mode of all attached objects in Plane-Maker. Objects marked “glass” in X-Plane 10 will have been auto-updated to “glass exterior” in X-Plane 11; if the glass object is inside the airplane, change it to “glass interior.”
The old v9 GNS430 GPS is gone for good. If you open a plane using it in Plane Maker 11, it is force-upgraded to the new 430 we’ve had since X-Plane 10.30.
For integrating with your panel, you can use the rad_GPS_430_screen or rad_GPS_530_screen instrument depending on your size requirements, or you can drop in the complete G430 or G530 with bezels and buttons and resize as needed. Then refer to the commands.txt and search for the string “g430” to find all commands for the buttons on the GPS bezel. Note that these commands for bezel buttons will work regardless whether you are using the 430 or 530 size instrument. Note also that the commands with “n1” in the name go to the designated “pilot” or “NAV1” unit, and the commands with “n2” in the name go to the designated “copilot” or “NAV2” unit.
The old v9 FMS instrument is also gone for good. If you open a plane using it in Plane Maker 11, you will receive error messages or the panel accordingly. To use the new FMS, drop in the 2d FMS instrument or rad_CDU739 screen instrument for the screen of the new FMS. Refer to the commands.txt and search for the string “FMS” to find all keys and buttons to wire up to your bezel. Note that commands with “FMS2” in the description will go to the designated “copilot” side unit.
Now, the specific fuel consumption values you enter in Plane-Maker at various altitudes for fractional power settings are defined to be the power output fraction compared to max available power or thrust AT THAT ALTITUDE.
So, if you have an 850 hp turboprop engine, even if it is flat-rated so that it has a thermodynamic output well above 850 hp, and can carry 850 hp to well above sea level,
if you are at, say, 28,000 feet and the engine can only GIVE you 600 hp, the SFC for full power will be used when the engine is putting out 600 hp.
This is because 600 hp is, indeed, full throttle at that altitude!
If you reduce power to 300 hp of output at that altitude, then the half-power SFC will be used, because the engine is at half power for that altitude!
So, simply put, look at the power or thrust that the engine is actually putting out, divide that by the max power that it COULD put out, and THAT is the power fraction that is meant for the various SFCs.
NOTE: If the engine is flat-rated to some power setting, then you do, indeed, need to use that flat-rated power as the maximum in the division above.
So if you have a flat-rated engine allowed to only output 850 hp, even though it is thermodynamically good for 1,200 hp, if you are spinning out 850 hp, then that is indeed the max allowable power, and the full-power sfc will indeed be used. So simply divide the current power by the max achievable (and allowable) power at a given altitude, and that is the power fraction for the SFC.
PT-6 engine idle logic is different in X-Plane 11. X-Plane will try to get close with idle ratios, but fine tuning is needed in Plane Maker to get the same numbers as in X-Plane 10. In version 10, the high idle was automatically boosted inside of X-Plane, but now it is not: You have to boost that high idle manually by entering a higher value for high idle in Plane-Maker. You will need to revisit ALL idle ratios for all of your aircraft.
The turbine idle is now floating point like everything in a real PT-6. Move the red knob to move smoothly from low to idle, or hold it partway if you want to keep the engine temps where you want, as you would in reality. For turbines, you will want to enter a higher high idle than low idle now… X-Plane does not do this for you any more, since you can now tune those fuel flows at idle as you like for yourself!
For example, for a king air you probably want 55% ng for lo idle, 70% for hi idle, which works out to about:
HI idle: 1.70
LO idle: 1.00
In other words, our lo idle is just enough to run the engine, at the lowest Ng recommended, and we bump that up by 70% at high idle to spin the generators and air conditioning compressors.
Each real PT-6 is set up differently based on the settings of the engine driven generators!
The jet engine flight model has been modified. Low/high jet engine bypass is gone and we only go off the bypass ratio you enter. Check your aircraft’s thrust curve values in Plane-Maker in the ENGINE window, DESCRIPTION tab, right side of the screen, where we have “thrust power curves with N1”, which you can enter.Then go to the engines window, and then the Jet Curves tab on the right. Set the reference Mach number on the lower left for the inlet on your plane to get the thrust peak right around the top speed for your airplane.
Gear doors options are gone in Plane Maker 11. Add the gear additional frontal area as needed to get the same effect without the hassle
Want VISIBLE gear doors? Then make an OBJ to do them properly for sure!
Transition speed for steering option was intentionally removed from Plane Maker 11. Real airplanes that have two levels of steering don’t have a transition speed at all – they have two controls:
The behavior to transition from wide (tiller) to narrow (rudder) steering based on speed is a hack to allow users with a SINGLE “heading” axis to be able to drive on the ground without tiller hardware, by changing whether the twist axis acts as rudder or tiller based on speed. This transition is no longer part of the aircraft because it’s a hack to allow the user’s particular joystick hardware to work – it’s not aircraft specific at all, it’s USB-hardware specific.
_LIT panel backgrounds are no longer supported. This feature dates back to X-Plane 6 and was deprecated in X-Plane 8. Replacement techniques:
All panels used for 3-d cockpits are rendered as two separate textures, always; a single unlit texture is no longer supported. Panels rendered in two textures has been supported since X-Plane 9. If you use ATTR_cockpit_region or GLOBAL_cockpit_lit, your add-on needs no changes.
If your add-on is using ATTR_cockpit without GLOBAL_cockpit_lit, you will find the lighting on your panel has changed. You will need to:
Plugins that were drawing to a single-texture panel and ignored panel_render_type may see a serious performance problem until they are updated.
2-D overlay panel lighting layers (full panel backgrounds in the 2-d folder with the suffix -2, -3, -4) are no longer supported in 3-d cockpits. You can continue to use these lighting layers to create dynamic 2-d light effects for 2-d panels, but they have no affect on the 3-d cockpit.
3-d cockpits should always use real 3-d lights, either from Plane-Maker or OBJ-based spill lights to achieve spill lighting effects.
In X-Plane 11, the existence of the APU must be specifically marked in Plane Maker’s systems window. Previously we would make a guess based on whether or not the default instrument was used, but X-Plane 11 will not guess.
X-Plane 11 makes extensive use of the metadata filled out in Plane Maker’s author window. Make sure to update these fields following the instructions here.
The new UI also uses icons that can be generated from within X-Plane or by hand following these instructions.
X-Plane 11 supports commands that allow a user to start and shut down the engines automatically. Besides simplifying operation of complex aircraft, these commands are used by X-Plane’s AI to fly complex aircraft.
Some common features of third party aircraft are now built into X-Plane. This just means that X-Plane provides standard, canonical datarefs and commands. By using the standard commands and datarefs, you allow users to share keyboard shortcuts and menu items with all aircraft.
X-Plane 11 provides simulation of up to ten animated aircraft doors – if your aircraft needs more than ten doors, please contact us.
Commands to open and close the doors
sim/flight_controls/door_open_1
sim/flight_controls/door_open_2
sim/flight_controls/door_open_10
sim/flight_controls/door_close_1
sim/flight_controls/door_open_2
sim/flight_controls/door_open_10
Datarefs:
sim/cockpit2/switches/door_open[10] – int, writeable, opens/closes the door
sim/flightmodel2/misc/door_open_ratio[10] – float, read-only, shows its current, animated position.
X-Plane 11 allows the user to hide the yoke in the 3-d cockpit to more easily see the panel.
sim/operation/toggle_yoke – command to toggle yoke visibility
sim/graphics/view/hide_yoke (int, writeable) – indicates yoke visibility, can be edited.
The Navdata files Airports.txt, Navaids.txt, Waypoints.txt and ATS.txt as well as the Proc/ICAO.txt files no longer ship with X-Plane. If your aircraft requires those files, please make sure to notify Navigraph/Aerosoft so they can make a package for you. The default data for X-Plane will no longer contain those files.
You can find information about the default data that ships with X-Plane 11 here: http://developer.x-plane.com/?article=navdata-in-x-plane-11
The weapons SDK is the one area where we have moved temporarily backward from X-Plane 10. X-Plane 11 features a new unified weapons system that takes technology from both X-Plane 10 desktop (for physics) and X-Plane 10 mobile (for multiplayer simulation). Unfortunately, we haven’t had time to create an appropriate dataref interface to these weapons.
Getting the interface to weapons finished is on our short list for after 11.0 ships; expect that the list of datarefs may be different for 11.xx than it was for X-Plane 10. The new system has new capabilities that make the old “fixed index of weapons” model not a great fit.
Unfortunately, this means that if your add-on depends on plugin-controlled weapons, you’re stuck in a holding pattern until we can post a new interface that we can maintain.
FMOD documentation is still pending. There are a lot of details to get right in making an FMOD-enhanced aircraft; please do not ship an FMOD-enhanced aircraft before the docs come out – there’s a very high chance of doing something wrong if you’re just trying to guess how the system works.
What you can do now is learn how to use FMOD! Download the FMOD studio editor (it’s a free download) and start working with its sound design tools.
Pushback trucks and ground service vehicles are new in X-Plane 11. Now, for ground traffic to swirl all about your airplane and service it, you will want to set up the docking ports on your airplane!
For any old V10 airplane or other airplane not yet set up to handle ground traffic, fire up Plane-Maker and go to the STANDARD menu, then VIEWPOINT window.
In there, go over to the last tab on the right, labelled “Location” or more recently “Docking Ports”. There, enter the lat, long, and vertical arm of the docking ports for the various types of service trucks! (Ports should be based on what the plane actually has.) Make the window super-wide to see the airplane on the right side of the screen with the docking ports drawn as little spheres to help you position the docking ports quickly.
Once you have entered a docking port location for, say, a fuel truck, then whenever you ask for service or set “AI Flies Your Plane”, the fuel trucks will go to that location to give service.
Beginning in X-Plane 10.40, Plane Maker added support for a variety of extra “metadata” information in ACF files. X-Plane 10 did not make use of this metadata, but X-Plane 11 uses it extensively. For your aircraft to take advantage of the new filtering & search support in the Flight Configuration screen’s aircraft grid, you’ll want to make sure you include this information.
To add aircraft metadata, open your aircraft in Plane Maker, then go to Standard > Author. There, you can set the following fields used by the X-Plane 11 user interface:
All the fields above are also available in the text search field. So, for instance, if your aircraft has the following fields:
…your aircraft would show up in all of the following searches, based on matches or partial matches for words in those fields:
The new X-Plane 11 UI includes aircraft icons arranged in a grid on the Flight Configuration screen. The new icon style is a simple picture of the aircraft, seen from a particular angle, over a transparent background. By keeping your icons consistent with the X-Plane 11 default icons, your aircraft will both look professional and be identifiable at a glance.
You have two options for creating X-Plane 11 icons for your aircraft:
X-Plane 11 aircraft icons are stored as follows within your aircraft folder:
Note that there are actually two images on disk for each livery: the normal “_icon11.png” and the “_thumb” version. The former is an 800×450 image used when you click “Customize” for an aircraft; the latter is a 174×107 image used in the aircraft grid view. (The smaller size gives you both a better image quality and improved performance when scrolling through the grid.)
X-Plane 11’s Physically Based Rendering (PBR) uses a new material model for solid textured objects and meshes.
The X-Plane lighting and material model divide the light interaction with materials into two categories:
X-Plane 11 conserves energy between diffuse and specular reflection – having a stronger specular reflection reduces the amount of diffuse reflection automatically; in this way highly glossy and reflective materials don’t appear to be overly bright compared to matte materials.
Comparison to X-Plane 10: in X-Plane 10, specularity could be added without reducing diffuse reflectance; this meant that most reflective materials were brighter than non-reflective ones. An artist could choose to manually darken the albedo of a texture to compensate.
The microsurface of a material is considered to be rough or glossy (or some measure in between); roughness and glossiness are measures of how smooth the surface is, not how reflective it is. A surface can be highly reflective and highly rough at the same time.
Roughness serves to spread out specular reflections; a mirror image in a rough surface appears blurry, as each ray of incoming light bounces in several directions.
X-Plane 11 conserves energy as roughness is adjusted; the same amount of energy is reflected in a rough or glossy surface. The difference is that a glossy surface has a highly focused reflection; a light source’s specular reflection will go in one direction on a glossy surface, resulting in a specular highlight that is very bright but small.
By comparison, a rough surface diffuses the specular energy in all directions; the specular reflection is visible over a wide range of angles but is not very strong.
Comparison to X-Plane 10: in X-Plane 10, all surfaces are glossy and only the overall specular reflectance could be changed. Therefore it was impossible in X-Plane 10 to model a surface like asphalt, which is simultaneously very reflective and very rough. An artist could attempt to simulate this by creating a high frequency noise pattern of highly reflective and non-reflective pixels to manually “break up” the reflection, but when zoomed out this effect is incorrect.
Surfaces become more reflective when viewed at glancing angles; this is called the Fresnel effect. X-Plane 11’s rendering engine simulates this automatically. The specular reflectance of a material that is specified by the artist is its minimum reflectance, when the material is viewed directly (e.g. the camera is orthogonal to the surface).
X-Plane 11 automatically decreases diffuse light as the effective reflectivity increases. This avoids materials appearing too bright at glancing angles.
(This is probably a bug – the incoming light is not more glancing based on view angle! The actual effect of fresnel is more complicated because it is affected by the integral of all incoming light.)
Comparison to X-Plane 10: X-Plane 10 does not provide camera-angle-based variable reflectivity; as a result, materials often have to be made too reflective at all angles to make glancing angles look adequately reflective.
The major properties of a material are controlled by two channels of the normal map of a model:
This scheme is opt-in; objects use the NORMAL_METALNESS directive to indicate that the blue channel is suitable for base reflectance. (Since legacy models typically have strong blue values from tangent space normal maps, the blue channel must be ignored in legacy models.)
If metalness is not used, a base reflectance of 0.04 is assigned to the entire material; this is a good approximation for most dielectrics (plastic, wood, concrete, etc.) and also a reasonable backward-compatible value for X-Plane 10 content. The roughness channel is intentionally encoded to have the highest gloss value in X-Plane 11 match the most reflective material in X-Plane 10. (Since X-Plane 10 specular reflections were all highly glossy, this means that at least plastics and matte materials “just work” in X-Plane 11.)
X-Plane 11’s treatment of the albedo color (day texture) changes as base reflectance increases:
The alpha channel of the albedo (day texture) is used to create translucent rendering, e.g. the mesh being drawn is blended with the mesh behind it to create a mixture of both colors. There are two physical interpretations of this alpha effect:
In practice, authors use one effect (alpha blending) for both physical cases (translucency and decals). The meaning of alpha matters for physical correctness.
When alpha means ‘decal’, clear alpha removes all lighting effects from the mesh. This is the correct simulation of the mesh not existing.
When alpha means ‘glass’, clear alpha removes the diffuse but not specular component of lighting effects from the mesh. This is the correct simulation of light passing through the boundary layer from ‘stuff behind the mesh’, rather than being absorbed.
X-Plane 11’s default interpretation is the ‘decal’ interpretation, which:
Authors have the option in X-Plane 11 to use glass alpha as long as:
In this situation, authors can put the BLEND_GLASS directive into an object header; this will cause alpha to make the diffuse channel translucent while keeping specular effects, for reflections on clear glass.
X-Plane has two viewing modes for panels: a forward 2-d view that shows the 2-d panel and a 3-d view that shows the 3-d cockpit (which corresponds to the virtual cockpit in MSFS). Unlike MSFS, X-Plane does not provide multiple 2-d panel views – the 2-d side views may not contain working 2-d panels. X-Plane does not provide native support for popup panels, but it is possible to create them using a plugin or other tricks.
X-Plane’s panel consists of a background image (where alpha creates the transparent windshield) and a gray-scale or RGB overlay image that applies shadowing and some 2-d spot lighting to the panel. While MSFS has “gauges” X-Plane has “instruments” – the individual unit of placement.
The MSFS panel is created using an XML file; gauges can also be coded in C++ and can be in the form of *.dll or MSFS specific *.gau format.
X-Plane panels reside inside the ACF file in binary format (but can be exported as text from Plane-Maker); most panel editing is done using Plane-Maker’s near-WYSIWYG user interface.
X-Plane provides hundreds of types of instruments built in:
Therefore the closest thing to building gauges using the XML file is to build a panel out of multiple generic instruments. Typically a modern panel might be built primarily from generic instruments, but use the pre-built instruments for the moving map and a few other cases.
While MSFS allows a custom gauge to be built via a DLL (where the gauge provides a bitmap of its 2-d image), X-Plane has a slightly more generic mechanism:
X-Plane does not provide a general mechanism to let an author “place” a custom plugin-drawn instrument into a panel using Plane-Maker; typically custom instrumentation is specific to a single plane. Where users have tried to build add-on instruments via plugins, they have had to create ad-hoc mechanisms to place those instruments.
X-Plane’s 3-d cockpit environment is actually a rendering of the entire airplane in 3-d; all of the 3-d modeling work you do for airplane will be visible in the 3-d cockpit, allowing for the user to exit the VC and do a walk-around of the airplane. (See “Camera Restriction” below.)
Therefore the virtual cockpit is is simply modeled in 3-d using OBJ files, which contain meshes. Standard animation is used for instruments like steam-gauge airspeed indicators; this is similar to MSFS where a 3-d animation can be driven off of an animation source. Like MSFS, using “real animated 3-d” is often the fastest path for mechanical instruments.
X-Plane does have one “special” object (the “cockpit object”) that is intended particularly for VC work; it allows a 2-d panel to be UV mapped onto some 3-d surfaces, similar to using a material to indicate a 2-d panel mapping in MSFS. This work-flow is largely the same – you would create a snapshot of the “unwrapped” set of 2-d gauges (Plane-Maker can make this snapshot) and then UV map using it. The precise way to indicate “panel texture” depends on the 3-d editor you use.
Like MSFS, X-Plane provides a separate 2-d panel for the purpose of providing a material/texture for the 3-d virtual cockpit; therefore you can tightly pack this texture even if you want to ship a 2-d panel as well. In X-Plane, 2-d panels scroll and are often 2048 x 2048; it is important for performance to tightly pack the panel that is used in the 3-d cockpit.
Mouse-click interaction in the 3-d cockpit in X-Plane is annotated directly on the 3-d mesh; you mark a sub-section of the mesh with a “manipulator” describing what you want to have happen and the gesture. Typical manipulations include drags in 2-d or in arbitrary 3-d space, clicks, etc. Manipulations typically change an X-Plane dataref or run an X-Plane command (similar to an MSFS sim event) to affect the flight model.
Besides direct 3-d manipulation, you can mark any part of the 3-d mesh that has a panel texture mapped to it as “panel clickable” – this causes 3-d clicks to be passed through to the underlying 2-d panel, where the click operates as expected.
X-Plane can show and hide instruments but it cannot arbitrarily rotate or move them; there may be some XML transformations that are not yet possible in X-Plane. In many cases, a pre-built instrument will exist, and you can simply retexture it.
For any 3-d model in X-Plane, you can tie the level of the emissive (_LIT) texture using ATTR_lit_level, which arbitrarily scales the texture using a dataref. This has application for more realistic baked lighting, but can also be used to create gradual light faders in the 3-d cockpit or even to create instruments. (For example, the gear light LEDs can be made to appear by tying their lighting level to the gear status.)
You can restrict the movement of the camera in the 3-d cockpit by tagging a mesh as solid to the camera; this will stop your user from walking through the walls of the VC.
Use a hidden, simplified, manifold mesh to restrict the camera; the camera restriction will react better and use less CPU power with the simplified mesh.
You can use animations in your camera-restricting mesh. For example, if you animate the doors of your fuselage in the camera-restricting mesh, a user can exit the airplane only when the door is open.
See the default Cessna 172 in X-Plane for an example of this.
Non-Monotone key frames are key frames where the key frame table is not in order. Here are some examples:
N1 ANGLE 0 50 50 270 100 230
This key frame table makes the angle of the needle increase as N1 goes up, but then the needle will reverse and go back down a bit. In this case, “angle” is non-monotone.
In this table for a a rotary;
enum image 0 0 1 2 2 1 4 3 3 4
Both the input and output are non-monotone.
Generally you’ll want non-monotone key frames under two cases:
Plane-maker recognizes that if you have out-of-order non-monotone key framing tables then you are probably intending to use a dataref that EXACTLY hits the key frame, like an int dataref that passes in enums. (You would use this to re-order the mapping between enums and rotary positions.)
In this case Plane-Maker will snap-round the simulated dataref to exact key frames so that you can see a sane preview of the dataref.
If you have done this but the dataref in x-plane is NOT rounded to key frames, you will then see wrong interpolation in x-plane, since we can’t cleanly interpolate non-monotone functions!!