InputProcess

StaticEventHandler

bool InputProcess (InputEvent e)

Usage

This virtual function can be used in an event handler to catch and potentially override player's input.

Passed values

The following values are passed from the InputEvent struct to this event, and can be read if preceded with the e. prefix:

• EGenericEvent Type

Determines the type of the input.

• InputEvent.Type_None - No input event.
• InputEvent.Type_KeyDown - key is pressed
• InputEvent.Type_KeyUp - key is let go
• InputEvent.Type_Mouse - mouse event
• InputEvent.Type_GUI - unused
• InputEvent.Type_DeviceChange - An input device has been inserted or removed while GZDoom is running.

• int KeyScan

The internal ASCII value of the pressed key. You can detect if it's a specific input by comparing this value with the values obtained with bindings.GetAllKeysForCommand() or detect what command is bound to it by passing it to bindings.GetBinding(e.KeyScan).

In addition, the value of KeyScan can be compared to special Doom input keys.

• int KeyChar

The real ASCII value of the pressed key. It can be used to detect the name of the pressed key, but checking e.KeyString is usually more convenient.

Converting KeyChar to a string is not guaranteed to be the same as KeyString. Note that, while a bit counter-intuitive (for people unfamiliar with the console bind system), mouse buttons are considered keys for this event. For example, a left mouse click is registered as KeyDown+InputEvent.Key_Mouse1.

• String KeyString

A single-character string that contains KeyScan provided for convenience.

• int MouseX
• int MouseY

Delta values (offsets from the last mouse position). These are internally used for player aiming.

Return values

• bool — false by default. If true is returned instead, this will completely block player's input. Can be used to manually override specific inputs.

Examples

Warning: While it may be obvious to more experienced developers, inputs must never be bound to keys explicitly. As such, this event must never be used to create behaviors like "pressing W produces this action" (with the exception of extremely niche cases, like perhaps requiring the player to input a password, although for that UiProcess would be arguably more suitable.) For the majority of cases the logical approach is to create a custom command that calls a network event which gets captured and processed in NetworkProcess, not to catch specific keys.

This example shows how the input for scrolling between weapons can be overridden in order to add custom behavior (for example, if you're creating another system where weapon scrolling gets different use).

class WeaponSwitchDetector : EventHandler
{
    override bool InputProcess(InputEvent e)
    {
        // only process the input when the key is pressed,
        // not when it's let go:
        if (e.Type != InputEvent.Type_KeyDown)
        {
            return false;
        }
        if (bindings.GetBinding(e.KeyScan) ~== "weapnext")
        {
            // Print a message and call a custom network event:
            Console.Printf("Pressed Next Weapon key");
            EventHandler.SendNetworkEvent("PlayerPressedWeapNext");
            return true;
        }
        if (bindings.GetBinding(e.KeyScan) ~== "weapprev")
        {
            // Print a message and call a custom network event:
            Console.Printf("Pressed Previous Weapon key");
            EventHandler.SendNetworkEvent("PlayerPressedWeapPrev");
            return true;
        }
        return false;
    }
}

Note: Since InputProcess is UI-scoped, to do something in the play scope, you'll need to use EventHandler.SendNetworkEvent, as shown in the example above.

See also

• Events and handlers