Bindings

Overview

Sometimes also called input mapping or inputmap.

Bindings define which controls will trigger each action.

For example: the throttle binding binds the up arrow control with the "accelerate" action.

End-users can customize their bindings in the Options > Controls menu.

Some notes:

  • A single control can be bound to several actions (the action maps order will determine which will be triggered).
  • A single action can be triggered by several controls.

File locations

Factory bindings —-==———————-

Factory bindings are those bundled by default.

When you use the Options > Controls > RESET ALL button, they are returned to the factory bindings state.

They are stored in the game folder, in two possible locations:

  • Regular bindings: settings/inputmaps/*.json
  • Vehicle bindings: vehicles/vehicle_directory_name/inputmaps/*.json

User bindings

When end-users customize their bindings, these differences are stored in the Documents folder:

  • Regular bindings: documents/BeamNG.drive/settings/inputmaps/*.diff
  • Vehicle bindings: documents/BeamNG.drive/settings/inputmaps/vehicle_directory_name/*.diff

File names

Binding files have a name and an extension: name.extension.

  • Extension: as seen above, it can be diff or json.
  • Name: determines which controller they belong to.

For example: keyboard.json, c29b046d.diff

Possible generic names to use:

  • Generic names:

    • mouse
    • keyboard
    • xidevice - a controller in xbox mode (such as an xbox gamepad)
    • joystick - joysticks (non-xbox)
    • wheel - steering wheels (non-xbox)
    • gamepad - gamepads (non-xbox)
    • vinput - virtual input, such as our android/ios apps for remote control
  • USB pidvid names:

    • A combination of vendor ID and product ID

USB pidvid names

Important: as a mod creator or end user, you do not need to know about pidvid names - This is handled automatically by BeamNG.drive when you create or modify bindings from the Options > Controls menu.

pidvid is an abbreviation of “Product ID” and “Vendor ID”.

They are standard codes assigned to manufacturers and to the USB products they sell. Using a pidvid allows to tailor bindings to one specific device model (e.g. any Logitech G27), rather than a generic kind of controller (e.g. any wheel).

For example, the pidvid name c29b046d corresponds to a Logitech device (vendor ID 046d), G27 model (product ID c29b).

Note: mice, keyboards and xbox controllers don’t support pidvid nomenclature, only generic names.

File format

Important: as a mod creator or end user, you do not need to know about the file format - You should not be hand-crafting these files manually, instead you should use the Options > Controls menu to define the factory bindings for your mod.

Binding files mostly follow the json format. They must start with { and end with }. Here’s a sample of how the overall structure has to look like:

keyboard.json:
{
  "bindings": [
    {"action": "menu_select", "control": "numpad9"},
    {"action": "menu_back", "control" : "numpad7"},
    // ...
  ]
}

As you can see, it’s a simple list of action <-> control relations.

In some cases, there’s extra information for each binding (such as binding linearity, force feedback parameters, etc). We won’t go into detail about these.

If the file is a .diff file with customized user bindings, they may contain an additional "removed" list inside, like this:

keyboard.diff:
{
  "bindings": [
    {"action": "menu_select", "control": "numpad3"},
    {"action": "accelerate", "control": "up", "filterType": "1"},
  ],
  "removed": [
    {"action": "menu_back", "control" : "numpad7"},
  ]
}

The "bindings" inside a .diff file may overwrite a factory binding with a different control (menu_select in the example above) or different/new parameters (accelerate in the example above).

In addition to "bindings" and "removed", there may be other fields in these files, such as "guid", "name", etc. You don’t need to worry about these.