The bindings subsystem is at the core of the engine's input handling. It determines what happens when input events are received.

There are two kinds of bindings:

• Event bindings map a specific input event (such as “Control Key pressed”) to a console command. When the correct event is received, the engine executes the bound command.
• Control bindings map input device state to player controls. For instance, the state of the Up Arrow key might be bound to the Walk control, which determines if the player is walking forward and backward.

The bindings subsystem has a stack of binding contexts. Each context contains a set of event and control bindings. The contexts have a fixed priority order and can be activated and deactivated individually. The listbcontexts command shows you the context stack:

>listbcontexts
11 binding contexts defined:
[  0] "global" (active)
[  1] "deui" (inactive)
[  2] "console" (active)
[  3] "message" (inactive)
[  4] "chat" (inactive)
[  5] "shortcut" (active)
[  6] "gameui" (active)
[  7] "menu" (inactive)
[  8] "finale" (active)
[  9] "map-freepan" (inactive)
[ 10] "map" (inactive)
[ 11] "game" (active)

When an input event is received from the windowing system, it is offered to each of the active contexts in the order shown above. When a binding is found matching the event, it will not be offered to any further contexts.

Some contexts use special “acquire all” modes that prevent events from being offered to any further contexts. The “console” context is one of these: if the console is open, all keyboard events are used up by it and none of the lower-priority contexts get the events.

Since 1.9.7 it is not possible to add new contexts.

• Console command activatebcontext
• Console command deactivatebcontext