Skip to content
Back to wiki

Input Control Setup

Configure UGIPS_InputControlSetup, checkers, processors, and their order to control which tagged inputs pass under the current setup.

A

Author

Author

Created: Mar 24, 2025Updated: Oct 19, 2026

Table of contents

UGIPS_InputControlSetup is a data asset for input permission checks, the input-buffering switch, and the processor chain. A component can hold several setups; the last item in its array is current.

Switching setups by state

Call PushInputSetup(NewSetup) to push a setup onto the component stack and PopInputSetup() to restore the previous one. Pushing an asset that is already in the stack does not add a duplicate. PopInputSetup() does nothing when only one setup remains, so keep a default setup in the array. The StateTree GIPS Input Setup Scope task pushes on state entry and pops on exit.

Permission check order

  1. If InputCheckers is empty, the input passes validation.
  2. If the tag and trigger phase match an entry in AlwaysAllowedInputs, the input bypasses every checker. An empty trigger-phase list matches any phase.
  3. Other input is checked in order. Every non-null checker must allow it; one rejection blocks the input.
  4. A rejected input is attempted as buffered only when bEnableInputBuffer is enabled on the current setup and an active window allows that tag and phase. Otherwise it is recorded as blocked.

Tag relationship checker

UGIPS_InputChecker_TagRelationship reads Actor Gameplay Tags from a Pawn that implements IGameplayTagAssetInterface. It evaluates relationships whose non-empty ActorTagQuery matches those tags. If a relationship has AllowedInputs, the current tag and phase must appear there; a matching BlockedInputs entry rejects the input. Several matching relationships can constrain the same input.

If tags come from an Ability System Component and the Pawn does not expose them, derive a checker and override GetActorTags. A custom checker implements DoCheckInput and returns allow or reject; do not execute movement or combat behavior inside a checker.

Processor chain

After permission passes, GIPS filters InputProcessors in array order. An empty InputTags container matches every tag; otherwise matching is exact. TriggerEvents must contain the current phase and defaults to Started. Each matching processor also calls CheckCanHandleInput to decide whether it will handle the event.

  • MatchAll: execute every processor that passes CheckCanHandleInput, in array order.
  • FirstOnly: execute the first processor that passes CheckCanHandleInput, then stop.

A custom processor can implement CheckCanHandleInput and the event handler for each phase, such as HandleInputStarted, HandleInputTriggered, HandleInputOngoing, HandleInputCanceled, or HandleInputCompleted. Keep the checker responsible for whether input is allowed and the processor responsible for what happens afterward.

Debug settings

bEnableInputDebug enables permission-check logs. DebugInputTags and DebugTriggerEvents narrow the selection; an empty list does not filter on that field. See the Debugging Guide for log levels and input-record views.

  • Quick Start and Integration: create and assign configuration assets.
  • Input System Component: event dispatch, value access, and external processing.
  • Input Buffering System: window policies and release behavior.