Aircraft profiles

Starting with PlaneCommand 3, support for aftermarket aircraft is provided by a "profile" that tells PlaneCommand how to interoperate with the aircraft. PlaneCommand comes with profiles for all of the built in X-Plane 10 and 11 aircraft, and some of the most popular aftermarket aircraft. See list of supported aircraft

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. First, you'll want a tool to help you find the necessary datarefs and commandrefs. I make a free plugin for this, called DataRefTool, which I would recommend you install. You can also use DataRefEditor, though it won't show commands.
  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. Locate your log file. If you make an error writing a profile, the error will be reported in your X-Plane 11 log file at X-Plane 11/Log.txt

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:

    "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

There are four required fields in the header:

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 from the x737:

"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

Bug in v3.0.0: Scalar support is quite quirky in this version of PlaneCommand, and in particular, the altitude bug doesn't work right a lot of the time

Scalar actions are a bit more complicated. They adjust a parameter either up or down to reach a desired value. This is designed for systems like the autopilot altitude. Here's an example:

"ap_airspeed_knots": {
        "adjustments": [

The up and down commands are 'held down' (by using XPLMCommandBegin() / XPLMCommandEnd()) until the parameter is close to the desired value, and then the last few steps are made with single clicks (XPLMCommandOnce()).

But wait, there's more! One additional complication is the idea that you can adjust this parameter by differently sized steps. So, we use the various adjustments in order from coarse to fine. In this 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). Here's the complete example:

    "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: Supported aircraft

AircraftTested versionStatus
X-Plane 10 built in aircraft10.50All supported with default profile since v3.0.0
X-Plane 11 remaining aircraft11.05All supported with default profile
X-Plane 11 Cessna 17211.10b4Supported since v3.0.3 (laminar_c172.json)
X-Plane 11 King Air11.10b4Supported since v3.0.3 (laminar_king_air.json)
X-Plane 11 737-80011.05Supported since v3.0.0 (laminar_737.json)
X-Plane 11 MD-8011.05Supported since v3.0.0 (laminar_md82.json)
X-Plane 11 74711.05Supported since v3.0.0 (laminar_747.json)
FlyJSim Q4002.1703Uses default profile. (Bug: transponder doesn't work)
EADT x737 737-700 and -800Supported in v3.0.0(x737.json)
JARDesign A320neoSupported in 3.0.2(jardesign_a320neo.json)
FlyJSim 727Supported in 3.0.2 (727.json)
Carenado B1900v1.0Supported in 3.0.1 (carenado_b1900.json)
FlightFactor Boeing 757Coming later

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
Decision heightfeet"decision_height"3.1.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

© 2017-2018 Crosswind Software, LLC • Privacy policy