{{notice|Obsolete|See [[bindings]] for the current behavior.}}

[[doomsday]] uses the concept of event bindings to allow player input controls to be configured freely, to the user's control preferences. The same scheme is used whether you are using keyboard, mouse, joystick or any other (or combination) of input devices.

{{note|Some input devices have additional settings which can be used to configure them in-game (eg sensitivity with mouse/joystick and joystick dead-zone).}}


====== Events ======


Events are really "device input events" which Doomsday can respond to. Examples would be a key down event on a keyboard, a mouse wheel scroll event, a joystick trigger down event etc.

Events can be bound to console commands (and aliases) or to special "game actions".

{{note|A game action is a game-specific control (registered by the game at runtime) used to typically control things such as player movement controls which must be responded to quickly (these events are tunneled directly to the game's player control [[responder]]).}}

Binding Classes were introduced in Doomsday1.9.0-beta3 to allow multiple commands/controls to be bound to one input device event. More on those latter in this article.


====== Creating event bindings ======


Binding events to commands/controls is done through the use of various console commands.

Most games that run under Doomsday also offer a graphical interface for configuring the in-game controls. It is recommended that new or novice users should use this interface instead of setting up the controls "manually" via the console.

Here follows a list of the console commands you'll use when setting up event bindings (click the links for information on how to use each command):

  *  [[console_command_reference#bind|bind]]: create a new/change an exisiting binding.
  *  [[console_command_reference#bindr|bindr]]: same as bind but for "repeater" events.
  *  [[console_command_reference#delbind|delbind]]: delete one or more existing bindings.
  *  [[console_command_reference#listbindings|listbindings]]: display a list of all existing event bindings.
  *  [[console_command_reference#listbindclasses|listbindclasses]]: display a list of all registered binding classes.


====== Binding classes ======


Binding classes allow multiple commands/controls to be bound to one event. This is achieved by allowing multiple bindings per event but only one binding per class. Therefore the command/control that is executed when the input event occurs depends on which binding classes are currently active.

Each game that runs under Doomsday will register any binding classes it plans to use on startup, in addition to those created by Doomsday (see the documentation for the game for details of the binding classes it uses).

Currently Doomsday automatically uses the following binding classes for all games:
  *  **game**: the default binding class.
  *  **biaseditor**

{{Note|Doomsday also provides three additional binding classes which users can manage themselves via the [[console_command_reference#enablebindclass|enablebindclass]] command.}}

Any time you must specify a binding class (eg when using the "bind" console command to create a new event binding) you have the option of omitting it, by doing so Doomsday will assume you are referring to the default binding class ("game").

So for example, to create an event binding which creates a new bias light source when you press F5 you would use the following command:

<code>bind biaseditor +F5 blnew  
</code>
Notice that the bind class "biaseditor" is specified in the event binding. This means that pressing F5 to create a new bias light source will ONLY work when the "biaseditor" binding class is active.


===== When are they active? =====


Normally this is something you don't need to think about as a user.

Typically, it is the game's responsibilty to manage the state of binding classes. For example, if the game creates a binding class for an in-game map (such as the automap in jDoom) it follows that the game will make sure this binding class is only active when required.

{{notice|Tip|The [[console_command_reference#enablebindclass|enablebindclass]] console command can show you the status of all registered binding classes at any time}}

However, if you are using the additional binding classes for custom functionality* you will need to manage the custom binding classes manually, via use of the [[console_command_reference#enablebindclass|enablebindclass]] console command (which in turn can be bound to other controls or [[aliases]].


===== Binding Class Stack =====


Normally this is something you don't need to think about as a user.

Typically, it is the responsibility of the game to make sure it registers the binding classes it uses in an appropriate order.

{{note|However, if you are using the additional binding classes for custom functionality their position in the binding class stack becomes a consideration when binding events.((For example, you have a simple six button non-programmable gamepad; you can use the custom binding classes feature to allow you to, for example, change the function of all other buttons when you hold the left trigger.))}}

Binding classes are arranged into a stack internally by the engine. The binding command/control that is chosen for an input event is ALWAYS that of the binding class which is nearest to the top of the stack, which is both active AND has a binding for the event being processed.

For example, player presses the '1' key on their keyboard:
If both of the built-in binding classes "game" and "biaseditor" are active and both have bindings for this class eg:
  bind game +1 +weapon1      // Would change to weapon 1 when pressing '1'
  bind biaseditor +1 blhide  // Would hide the bias editor HUD when pressing '1'
The only time that pressing the '1' key would hide the bias editor HUD would be when the "biaseditor" binding class is active. This is because the "biaseditor" binding class is **above** "game" in the binding class stack.


====== Footnotes ======

<references/>