The following is a download link for the sources for the Laminar Research default Boeing 737-800 sound bank. The project requires FMOD Studio 2.02.19 or greater. You can download FMOD Studio from the FMOD site.
You can use this project to learn how the sound for the 737 was created and experiment using the Live Reload feature. As the License below explains, you can only use it for learning purposes and you may not redistribute any part of it.
License
LICENSE AGREEMENT: B737 FMOD PROJECT AND SOURCE AUDIO CONTENT
This B737 FMOD Project and Source Audio Content License Agreement
(the "Agreement") is a legal agreement between you and Laminar Research.
By downloading, viewing, and in any way using this B737 FMOD project file
(the "PROJECT"), you agree to be bound by the terms of this Agreement.
If you do not agree with this Agreement, do not use this PROJECT.
All rights not expressly granted to you here are reserved by Laminar
Research. Upon acceptance of this Agreement, Laminar Research grants a license
to you to use this PROJECT expressly for educational or personal purposes only.
This license is granted worldwide and in perpetuity.
This Agreement includes license terms for:
a) The PROJECT, and any .bank files built thereof (altogether, the "FMOD
CONTENT"), and
b) The included .wav sound files (altogether, the "SOURCE AUDIO").
GRANT OF LICENSE:
1. FMOD CONTENT:
You may modify, remix, redesign, and build upon the FMOD CONTENT.
You may NOT share the FMOD CONTENT, original or otherwise modified.
You may NOT broadcast video of the FMOD CONTENT, original or otherwise
modified.
You may NOT use the FMOD CONTENT for commercial or non-commercial purposes.
You may NOT share, copy, or otherwise redistribute the FMOD CONTENT
or any part of it.
2. SOURCE AUDIO:
All SOURCE AUDIO is owned by Laminar Research.
You may NOT share, copy, or otherwise redistribute the SOURCE AUDIO.
You may NOT use the SOURCE AUDIO for any commercial or non-commercial
purposes.
You may modify, remix, redesign, and build upon the SOURCE AUDIO, provided
it is strictly for PERSONAL use.
If you have any questions about this Agreement, please contact Daniela
Rodríguez Careri at <daniela@x-plane.com>.
Starting X-Plane 12.00 you can customize the airport ground vehicles. Since those are part of the APT.dat defined scenery, they are loaded early and separately from DSF scenery, and cannot be replaced via a EXPORT override on the library.txt like other library objects.
This feature allows you to make vehicles that you can include either locally in a custom scenery or as a part of a library to use in one or many of your airports. Bear in mind, though, that the custom vehicles have to be placed manually at each parking location. There’s no global replacement.
Each “Service vehicle parking location” in WED now has a “Custom vehicle” field where you specify your replacement object. The object itself will be moved around at the same speeds as the selected service truck, for the same purpose (crew car, GPU, fuel truck etc), i.e. the behavior itself is not customizable.
All components of the object (sounds, driver object etc) can be customized by the library author by providing suitably named components to go along with the vehicle object.
How to
Create your vehicle 3D model with animations. The datarefs available for animations and sound are those under sim/graphics/animation/ground_traffic/ (see the Dataref list)
On the SND file (see SND file specification) use start/end conditions according to the datarefs mentioned above. You can also use those datarefs as parameters inside FMOD Studio to modulate the events.
Ensure the events are assigned to the Master Bank androuted to the Exterior Processed > Environment bus.
If you need to apply signal processing (reverb, EQ, etc) to the sounds, don’t apply them to the Environment bus itself because they will be overriden by the corresponding aircraft bus processing. Instead, create a subgroup under Environment to do so.
Expose the object on the scenery or library library.txt (see library.txt specification) so WED can use it, via a EXPORT directive. For example
In WED, place a parking location of the kind of vehicle you want to replace (fuel truck, catering, etc) and under the “Custom vehicle” field, enter the virtual path to your custom vehicle from your library. For example
1 – As a first step, you need to put down an exterior facade. You can use any of the facades from lib/airport/hangars/flat/xxx.fac. Make sure the shape is orthogonal (CTRL + Q).
2 – Rotate the polygon (CTRL + R) until you get the first segment (marked with a small circle) to the place where the open doors should be. This is very important for future steps (aligning interior facade and doors)
3 – Set the desired height of the hangar (8, 10, 12, 16, 18, 22, 26, or 30). This is very important because the exact dimensions of openings and related parts may vary based on facade height.
4 – Now set the correct wall types inside vertices. The most important is of course open doors (blue segment). For others, you can use whatever you need (solid walls, windows, etc).
5 – The exterior part is finished. Lock the shape to prevent unwanted edits (turn on the lock icon).
6 – Draw the hangar interior (lib/airport/hangars/flat/parts/interior_xx.fac) following the exact shape of the exterior. Use "snap to vertices" function. You should not break the exterior shape because it is locked.
7 – Make sure WED preview is turned on (menu View / Toggle Preview). Zoom to the hangar corner and use an appropriate isometric view.
8 – Set the corresponding height of the interior (7, 9, 11, 15, 17, 21, or 29). Note the height is one meter shorter than the exterior.
9 – With SHIFT pressed, drag the polygon toward the inside roughly 0.5 meters.
10 – Drag the segment with open doors towards the inside until reaches the end of the opening side. Make sure you're dragging only the single polygon segment (two vertices at a time), not the entire interior polygon.
11 – Add a new vertex (using ALT + click) to the intersection of the polygon with the opening. Do the same on the opposite side of the doors (with an appropriate isometric view angle)
12 – Now rotate polygon segments (Ctrl + R) to get the first segment (white circle) to the corresponding position with the exterior facade polygon. This is very important for the alignment of both facades!
13 – Set the proper wall type to the opening (and other walls eventually). The Interior is done – you can lock the shape.
14 – Choose the door facade you want (lib/airport/hangars/flat/parts/hangar_door_xx.fac) and draw a single-segment polygon. Points should be placed exactly on the border of the exterior facade polygon (blue segment). Use the isometric preview to fit both endpoints.
15 – Set the corresponding height of the doors (matching hangar height levels – 8, 10, 12, 16, 18, 22, 26, or 30) and set the wall type to "Hangar_doors_open". You are done!
NOTE: All standalone door facades also have a wall with closed doors (Hangar_doors). This makes no sense in combination with the interior of course. But you can use it for making any combination of the exterior facade design and doors. In that case, you don't need to worry about the interior facade but everything else above is still true.
The old weather datarefs have been marked as deprecated in X-Plane 12 and replaced with two new sets. The old ones will remain in place but anything referencing them should be changed to use the new ones as soon as possible. The good news is that this should be fairly straightforward.
Previously the values returned in the datarefs were relative to the user's aircraft. This was fine for handling instrumentation but not ideal for working with the wider environment. There are now two similar sets of datarefs, one for the weather at the aircraft's exact position, and one for the surrounding region.
Aircraft
In general, all the old datarefs that lived under sim/aircraft/ have been moved under sim/weather/aircraft/ with very similar names. The only real thing to note here is that in some cases, units have changed. Also, all these aircraft-specific datarefs are read-only. This makes sense; the aircraft's immediate environment is a point sample from the regional weather.
Cloud, wind and turbulence datarefs are no longer represented by individual datarefs with an array-like notation, they are handled as real arrays. This means you should do proper array handling of these by querying the size of the array using XPLMGetDatavf() before your first read, and allocating enough space accordingly. Doing this will allow your code to continue to work with no changes if in the future the array size is changed. Temperature and wind arrays have already been increased to 13 elements from 3.
It's important to remember that the aircraft's immediate environment is a snapshot of a single point in a simulated 3D volume. This volume contains deliberate variations from whatever the base weather is, whether that's a fixed preset coming from the UI or a composite of available real-weather data if this is enabled. You should not, in other words, expect any value reported at the aircraft's position to exactly match any value you may see elsewhere that isn’t based on the aircraft’s position.
Region
New for X-Plane 12, the base weather that defines the aircraft's surrounding region is provided as a distinct set of datarefs under sim/weather/region/. Right now 'region' roughly corresponds to a square degree but this may vary in the future. The region base values determine a starting point for X-Plane's own weather simulation, which gets added on top. As with the aircraft's datarefs, this means that you should not expect any value returned in these datarefs to exactly match any value you see elsewhere since the weather at any given point is taken from the combination of the base weather and the weather simulation, not the starting data for that simulation.
Atmospheric Altitude Levels
Atmospheric temperatures are defined at preset altitudes which can be found in sim/weather/region/atmosphere_alt_levels_m . If you are working with temperatures aloft, please use the altitudes given in this array and don't hard-code them. The altitudes, or the number of layers, may change.
Modifying the Region
Most of the regional datarefs are writeable, meaning that you can use these to change the weather in a large volume surrounding the user's aircraft.
sim/weather/region/change_mode
This controls X-Plane's internal weather simulation, when used with static weather, by setting a general trend over time.
sim/weather/region/variability_pct
This controls the internal weather simulation's variability for those parts which use random noise to generate variation. The base weather also varies with distance from a given reference point. Typically the reference point would be the selected airport if you use the UI to select a weather preset, for example.
sim/weather/region/update_immediately
When this is non-zero, any changes to any regional dataref except clouds will take place immediately. Otherwise, the changes will start to fade in over a short period of time, currently 1-2 minutes. Clouds are handled a little differently because there is a delay between the cloud data being determined and the results of the GPU-based cloud simulation being returned. Even with update_immediately set to true, clouds will generally take a minute or so to update to the new values. When you absolutely, positively got to kill every cumulonimbus in the room, you can use the sim/operation/regen_weather command to trigger an immediate full reset of the current weather.
API Access
For simpler access if you are using a programming language that can use it, the X-Plane SDK contains some basic weather data access functions. These allow you to get a weather snapshot – that is, the equivalent of the aircraft datarefs, the output of the base weather plus the weather simulation – at a specific point.
While you are free to request weather for distant locations, the accuracy of the data returned will drop significantly outside of the current region. Errors are reported via the standard XPLMSetErrorCallback() mechanism.
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:
An area of the aircraft’s 3-d panel texture that has HUD markings.
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.
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:
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.
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.
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.
New 3D trees in X-Plane consist of two main parts.
The first part of a tree definition is a 2-d billboard side view of the tree. These operate almost identically to X-Plane 11 trees. In X-Plane 12, the side billboard always faces the camera and there is only one per tree.
The second part is one or more 3-d models of the tree that are used for close up rendering. X-Plane dynamically animates the 3-d model based on wind parameters.
X-Plane automatically uses the 3-d model of the tree for close rendering and transitions to the 2-d billboard for far views for performance.
The two parts of the tree use separate texture and materials – the 2-d textures and material is shared by all 2-d billboards in the .for file; the 3-d textures and material is shared by all 3-d models in the .for file.
This guide requires some basic Blender knowledge like adding vertex groups and weight painting.
Textures
Both parts use separate textures – one for billboards and another for 3D parts. This is also the main prerequisite – all billboards and all 3D parts for all trees (all species) within a single *.for must be in a single texture sheet. A typical pair of textures may look like this:
X-Plane 12 offers a new type of shader called translucent. It was designed specifically for 3D vegetation. Unlike a typical PBR shader, it has a different usage of the normal map blue channel. Instead of metallic property, it determines translucency. White color means fully translucent (leaves) and black means no translucent (solid parts – trunk). Here is what a typical normal map may look like:
Creating Trees in Blender
In Blender, all parts are organized in a hierarchy and in collections by strict rules. A single tree consists of three (or more) parts. The top-level object is an empty wrapper (Its name is used for the tree name on export). This parent wrapper must have two child objects – a billboard (single vertical quad) and a 3D tree (mesh object).
Each tree can have up to three 3D meshes. The reason is more per-tree LODs that can be additive. The typical use is: the first LOD mesh (0 to 500 m) has all triangles that are facing upward. The second LOD for a shorter distance (0 to 100 m) has all triangles that are facing towards the ground and thus don’t need to be visible for a bigger distance (bottom of branches). This is highly recommended for better performance, in particular when using high polycount on 3D meshes.
Trees are organized into forests using collections and each forest needs two levels. The top-level collection (right under the Scene root collection) is the forest itself. It consists of nothing but other collections. Those collections represent forest layers and all names must start with a numeric value (01, 02, 01-conifers, etc). This value is used as a tree layer index on the export. Obviously, all trees (with all their parts) must belong to some “layer” collection.
Parameters
All important parameters in Blender can be found in the properties editor but they’re spread across various tabs. All parts of a tree must be organized in the proper hierarchy and collection in order to get the options tab visible.
Global forest options can be found on the scene tab. Besides the main “Export” button the most important parameters here are the file name used on export, tree spacing, and global LOD distance. A separate tab for each existing root collection is shown. A collection is treated as a separate *.for on export once it has some filename entered.
The tree root object (empty wrapper) has all options on the objects tab. The “Weighted Importance” value is a relative occurrence of the tree within a forest layer. “Max tree height” is the size limit of the tree. The minimum height is determined from the real size of the tree billboard (in other words, trees are prepared in Blender in their minimum size).
3D tree mesh-specific options are on the object data tab. 3D tree mesh LOD values are set to 0 and 500 by default. This is also the recommended value for all trees that are intended to cast shadows because 500 meters is currently the default max shadow distance in X-Plane. Shorter distances might cause popping shadow artifacts, but for some types of meshes it is not important, such as bottom facing geometry.
In addition, both billboards and 3D meshes have material options on the material tab. It is recommended to use blend hash and normal translucency mode for both materials.
Adding Wind Effects
3D trees can sway in X-Plane’s dynamic wind. In order to do so the mesh needs additional vertex data. In Blender we have three vertex weight data channels: w_stiffness, w_edge_stiffness, and w_phase. These names are mandatory and case sensitive!
The stiffness channel (w_stiffness) is used to displace mesh vertices horizontally in the wind direction. The maximum distance of displacement (in meters) is defined by the stiffness parameter on the mesh data tab. It is a multiplier of the vertex data value.
Edge stiffness (w_edge_stiffness) is used to displace mesh vertices vertically (vertical oscillation or swaying).
Phase data (w_phase) is used to shift various branches’ movement in time. This can avoid uniformity in the look of the whole tree’s movement.
Stiffness and edge stiffness data might look very similar in most cases. Maximum weight value is on the tip of the branch and zero near the trunk. Phase data is different however. The whole branch usually has the same weight (any value in range 0 – 1).
On top of that the whole tree is bent by wind. This bend is calculated automatically from the ground to the top of the tree. The stronger the wind, the greater the bend at the top of the tree. There is a calibration value on the mesh data tab that can tweak the total amount according to tree height.
The default value of 1.0 is calibrated for a 10 meters tall tree. This value might change on the tree shape and the artist’s desires however. Here are a few examples:
10 m tree 1.0
20 m tree 0.5
30 m tree 0.3
5 m tree 1.6
Rock 0.0 (no bend)
Seasons
At this time the exporter has no automatic support for creation of seasons. It has to be done manually. To do so, make a copy of final *.for and change the texture to a different season variant. More info about seasons in different document (link?).
Tips & Tricks
The exporter is still in a very raw stage. Code isn’t error proof so you have to follow strict rules to avoid errors on export.
All parameters in the Blender UI have a tooltip with descriptions.
It is recommended to use one forest per one Blender scene.
Everything except proper forest collections must be turned off (excluded from View Layer) on export time.
Try to avoid extremely high polycounts. A typical big tree mesh can have 1000 – 2000 triangles, or 3000 – 4000 for very big, old trees.
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:
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:
X-Plane 12 runs the FMOD 2.02 engine, but since FMOD provides backwards compatibility, older 1.08 banks will load with no change. Nevertheless, you will NOT be able to use the “live update” feature of FMOD Studio 1.08 with X-Plane 12, because the newer version of the audio engine cannot connect to older Studio versions.
If you’re starting a new project for X-Plane 12…
The “Starter Project” download page now delivers a full FMOD 2.02 version. As you did with X-Plane 11, you must download a fresh “Starter Project” for every new X-Plane 12 project you intend to create.
We recommend you open your old 1.08 Studio project using FMOD Studio 2.02 and saving it as a 2.02 project. This will automatically upgrade your sound bank. Then you’ll need to address the following issues for it to work properly on X-Plane 12.
Output speaker format
You should set your output format as “Surround 5.1 on Desktop” because the master bank that lives in X-Plane now outputs this format by default. Your bank’s output will be automatically downmixed/upmixed for users with a different speaker system. Be sure to properly set your buses to this format both on the input and output of each bus to avoid inadvertently downmixing your sounds. The starter project is already set up for Surround 5.1.
Parameter names
As of FMOD Studio 1.9, some characters are no longer allowed in parameter names. So when you use datarefs as parameter names (on events or snapshots), you should replace
“/” with “.”
“[*]” with “[#]”
Thus, “sim/flightmodel2/engines/engine_rotation_speed_rad_sec[*]” will need to be expressed as “sim.flightmodel2.engines.engine_rotation_speed_rad_sec[#]”. Note that dataref names on the .SND files do not need to be changed, you only need to make this change when they’re used as parameter names inside FMOD Studio.
If you migrated an old 1.08 project to 2.02, you can use this tool to help you bulk convert all the parameter names in your project to the new format so you don’t have to do it manually. Open your 1.08 bank using Studio 2.02, save it, exit Studio and then run the tool.
Live Update
To be able to use “Live Update” you need to use FMOD Studio 2.02. You must enable the “Live Update” connection only after X-Plane has fully loaded your aircraft, or the changes you make to the bank won’t be reflected in the simulator. If you reload your aircraft, be sure to turn off and on “Live Update” again so it picks your external changes.
Limitations
FMOD 2.02 “global parameters” are supported but untested at this time.
The “Highpass”, “Highpass simple”, “Lowpass”, “Lowpass simple” and “Parametric EQ” are considered deprecated on FMOD 2.02. All those are now superseded by the new “Multiband EQ” which has better CPU performance and functionality. We recommend you upgrade those effects if you’re using them.
New polyphonic events
When triggering sound events, X-Plane reuses the event instances to save resources, so if you have an event whose start conditions are satisfied several times in succession, the same instance will be stopped and retriggered each time. This might be undesirable under certain circumstances, such as triggering “clicks” for rotary knobs.
X-Plane 12 introduces the “EVENT_POLYPHONIC” directive for events. This forces X-Plane to disable instance reusing for that event and makes it trigger a new, separate instance of the same. Be sure to limit the “max instances” that can be triggered on the event (suggested 2-5) and the “cooldown time” to maintain low CPU usage and to prevent FMOD from triggering too many sounds at the same time, which could mute other sounds playing at that moment.
Environmental sounds
X-Plane now includes ambient sounds that depend on where the camera is placed in the world and its surroundings, as well as new rain, wind, hail and thunder effects. Ground equipment now produces sound too. All these are routed through the “Exterior Processed / Environment” bus, so it should “just work” with your existing banks.
As with X-Plane 11, it’s the responsibility of the aircraft developer to signal process these sounds when the user is located on the interior of the airplane, according to its sound insulation characteristics, and to do so only on the airplane interior, leaving the bus completely unprocessed when the user is outside (i.e. no mixer snapshot active). Be sure to preserve the 5.1 input/output format on that bus too.
The new environmental sounds that replace the old .WAV files in “Resources/sound/weather” don’t include rain or hail hitting the airframe, because it’s impossible for us to determine what material your aircraft is made of. So the developer should add their own sounds for the exterior and interior rain/hail impact on the airframe. You can use the following datarefs to that effect:
sim/weather/precipitation_on_aircraft_ratio
sim/weather/view/hail_ratio
sim/weather/view/snow_ratio
New copilot NAV radio morse datarefs
In addition to the existing datarefs for triggering the morse code / marker sound events tied to the pilot radio, X-Plane 12 now provides datarefs for the copilot side too. They’re named exactly like their pilot counterparts, but suffixed with “_copilot”:
Remember that sound events related to morse and marker should be routed to the Radios bus. You can look into the Airbus A330 implementation for reference.
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:
Specify the geometry of the HUD in the Plane-Maker viewpoint screen, cockpit tab, 3-d HUD section. You specify both:
The panel texture area to be used as the HUD (in pixels) and
The angle of the HUD from the pilot’s view (as field of view ratios).
Build the HUD image in your 3-d panel in the appropriate area.
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.
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
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.
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:
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.
Constant mach and thrust-vectored props will not auto-adjust the target RPM.
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!
Constant RPM props will not set their pitch.
You can set the prop angle directly via sim/cockpit2/engine/actuators/prop_angle_degrees.
