Aircraft profiles

PlaneCommandplanecommand logo

Aircraft profiles

Support for aftermarket aircraft is provided by a "profile" that tells PlaneCommand how to interoperate with the aircraft. PlaneCommand comes with profiles for all built in X-Plane 10 and 11 aircraft, and some popular aftermarket aircraft.

Where to find profiles

Profiles are open source, and developed in public on GitHub in this repository. If you need support for a new aircraft, it's best to check and see if a profile already exists. You can simply download the profile to your X-Plane 11/Resources/plugins/PlaneCommand_3.x.x/data/profiles folder.

If you have a profile you'd like to share with others, you can submit a pull request, or simply email me ( to contribute it.

If the aircraft you're flying isn't supported, perhaps you can add a profile yourself.

Making your own profile - technical details

A profile is a per-aircraft JSON file that describes how PlaneCommand should interact with aircraft. It describes what commands and datarefs should be used to accomplish certain tasks.

Not every command in PlaneCommand can be customized with profiles. I've tried to make several of the commonly varying systems configurable to make most aircraft easy to adapt.

Note: PlaneCommand provides pretty good defaults interally for every system. Profiles override these defaults; you should always prefer using the defaults to writing a new profile. (The internal defaults are designed to work well with the Laminar stock aircraft.)

Getting started

  1. Download and install DataRefTool. (DataRefEditor doesn't show commands, which is why I don't recommend it)
  2. Put PlaneCommand in debug mode. To do this, edit X-Plane 11/Output/preferences/planecommand.json and change the debug property to true.
  3. Download Visual Studio Code to edit the profiles. This isn't absolutely mandatory, but if you have an editor that supports JSON schemas then everything becomes easier.

Profile files

A profile is a simple JSON file. The format is pretty simple; I'd recommend looking at one of the existing profiles in X-Plane 11/Resources/plugins/planecommand-v3.x.x/data/profiles/*.json to get a feel for it. The examples here are from the x737.json profile. It generally looks something like this:

    "$schema": "",
    "name": "EADT x737",
    "author": "Lee C Baker",
    "name_filter": "B738",
    "author_filter": "Stratmann",
    "config": {
        "<system_name>": {
            "<system_parameter1>" : "<system_value1>",
            "<system_parameter2>" : "<system_value2>",

The header

Each profile requires a few values to be set:

$schemaFixed value: set this to
nameaircraft name to be used for display (ie, what this profile is called).
authorthe name of the person who customized this profile (This is you!)
name_filterUsed to match this profile to an aircraft. A search string (regex) designed to match the X-Plane aircraft name. When a new aircraft is loaded, all aircraft profiles are compared against X-Plane's aircraft name to figure out which profile to load.
author_filterUsed to match this profile to an aircraft. A regular expression designed to match the author name. This has to match the current aircraft, or the profile won't be used.

The name filter and author filter should match the aircraft name and author name as set in PlaneMaker. You can quickly find these on the PlaneCommand debug menu:

This is a good way to check that "name_filter" and "author_filter" are set correctly- load the aircraft and make sure your custom profile is being loaded at the same time.

Customizing on-off systems

On-off systems of the aircraft are systems which can be thought of as being in an on or off state.

They have a state (on or off) reflected in a dataref, a command to turn it off, and a command to turn it on.

An example:

"taxi_light": {

In some situations, you might need assign multiple commands to the on and off actions. For example:

"pitot_heat": {
    "on":["x737/ice_and_rain/PITOTHEAT1_ON", "x737/ice_and_rain/PITOTHEAT2_ON"],
    "off":["x737/ice_and_rain/PITOTHEAT1_OFF", "x737/ice_and_rain/PITOTHEAT2_OFF"]

The status field is either a float or int dataref. When this is 0, the system is considered to be 'off'. When it's nonzero (even negative), the system is considered to be 'on'.

See list of on-off systems

Customizing scalar actions

Scalar actions adjust a parameter either up or down to reach a desired value- things like the altimeter, or heading bug. Here's an example:

"ap_airspeed_knots": {
        "adjustments": [

The up and down commands are used to change the value, until the value dataref indicates the correct value.

But wait, there's more! One additional complication: you may adjust this parameter by differently sized steps by providing more than one up and down, and specifying a step size.

An example: we adjust speed with the 10-knot knob until we get close, then use the 1 knot knob (like a real person would do).

    "ap_airspeed_knots": {
            "adjustments": [

The step size of each adjustment is indicated in PlaneCommand's internal units, which just happen to be knots.

Finally, the 'value' and 'value_step' are a dataref and a scaling value used for measuring the parameter to be set. In 99% of cases, value_step should be 1.

See list of scalar systems

Table: On-off systems

DescriptionSystem nameMinimum version
Landing lights"landing_light"3.0.0
Taxi lights"taxi_light"3.0.0
Strobe lights"strobe_light"3.0.0
Beacon lights"beacon_light"3.0.0
Nav lights"nav_light"3.0.0
No smoking light"smoking_light"3.0.0
Seatbelt light"seatbelt_light"3.0.0
Pitot heat / anti-ice"pitot_heat"3.0.0
Thrust reversers"thrust_reverser"3.0.0
Wheel brakes"brake"3.0.0
Prop sync"prop_sync"3.0.3
Yaw damper"yaw_damper"3.0.3
Battery switch (all)"battery_switch"3.0.3
Battery switch (battery 1)"battery1_switch"3.0.3
Battery switch (battery 2)"battery2_switch"3.0.3
Avionics switch"avionics_switch"3.0.3
Generator/alternator switch"generator_switch"3.0.3
Fuel pump switch(all)"fuel_pump_switch"3.0.3
APU generator"apu_generator"3.1.0
Flight director"flight_director"3.0.0
AP altitude hold"ap_alt_hold"3.0.0
AP vertical speed hold"ap_vert_speed_hold"3.0.0
AP pitch hold"ap_pitch_hold"3.0.0
AP level change"ap_level_change"3.0.0
AP speed hold"ap_speed_hold"3.0.0
AP speed intervention"speed_intervention"3.0.0
AP level change"ap_level_change"3.0.0
AP VNAV"ap_vnav"3.0.0
AP heading hold"ap_heading_hold"3.0.0
AP approach"ap_approach_hold"3.0.0
AP VOR/LOC"ap_vorloc"3.0.0
AP HNAV"ap_hnav"3.0.0
Audio panel COM1"audio_com1"3.0.0
Audio panel COM2"audio_com2"3.0.0
Audio panel NAV1"audio_nav1"3.0.0
Audio panel NAV2"audio_nav2"3.0.0
Audio panel ADF1"audio_adf1"3.0.0
Audio panel ADF2"audio_adf2"3.0.0
Audio panel DME"audio_dme"3.0.0
Audio panel markers"audio_marker"3.0.0

Table: Scalar systems

DescriptionUnitsSystem nameMinimum version
AP airspeed (knots)knots"ap_airspeed_knots"3.0.0
AP airspeed (mach)0.01 mach"ap_airspeed_mach"3.0.0
AP altitudefeet"ap_altitude"3.0.0
AP headingdegrees"ap_heading"3.0.0
AP vertical speedfeet up / down"ap_vspeed"3.0.0
AP altimeter0.01 inHg"altimeter"3.0.0
NAV1 coursedegrees"obs1"3.0.0
NAV2 coursedegrees"obs2"3.0.0
GPS/HSI coursedegrees"obs_hsi"3.0.1
COM1 activeHertz"radio_com1_active"3.1.0
COM1 standbyHertz"radio_com1_standby"3.1.0
COM2 activeHertz"radio_com2_active"3.1.0
COM2 standbyHertz"radio_com2_standby"3.1.0
NAV1 activeHertz"radio_nav1_active"3.1.0
NAV1 standbyHertz"radio_nav1_standby"3.1.0
NAV2 activeHertz"radio_nav2_active"3.1.0
NAV2 standbyHertz"radio_nav2_standby"3.1.0
ADF1 activeHertz"radio_adf1_active"3.1.0
ADF1 standbyHertz"radio_adf1_standby"3.1.0
ADF2 activeHertz"radio_adf2_active"3.1.0
ADF2 standbyHertz"radio_adf2_standby"3.1.0
Decision heightfeet"decision_height"3.2.0
Cabin altitudefeet"cabin_altitude"3.2.0

© 2017-2020 Lee C. Baker/Crosswind Software, LLC • Privacy policy