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 (lee@planecommand.com) 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": "https://planecommand.com/schema/aircraft_profile_v3.1.json",
    "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:

"https://planecommand.com/schema/aircraft_profile_v3.1.json"

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": {
    "status":"x737/systems/exteriorLights/taxiLightsSwitch",
    "on":"x737/exteriorLights/TAXILIGHT_ON",
    "off":"x737/exteriorLights/TAXILIGHT_OFF"
}

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

"pitot_heat": {
    "status":"x737/ovh/antiIce/leftProbeHeat_state",
    "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": {
        "value":"x737/systems/athr/MCPSPD_spdkias",
        "value_step":1,
        "adjustments": [
            {
                "up":"x737/mcp/MCPSPD+1",
                "down":"x737/mcp/MCPSPD-1",
                "step":1
            }
        ]
    }
}

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": {
            "value":"x737/systems/athr/MCPSPD_spdkias",
            "value_step":1,
            "adjustments": [
                {
                    "up":"x737/mcp/MCPSPD+1",
                    "down":"x737/mcp/MCPSPD-1",
                    "step":1
                },
                {
                    "up":"x737/mcp/MCPSPD+10",
                    "down":"x737/mcp/MCPSPD-10",
                    "step":10
                }
            ]
        }
    }
    

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

Table: Scalar systems