Skip to content
Logo_UE_XS
Yuewu
Back to wiki

Input Buffering System

Learn how GIPS buffer windows define allowed inputs, LastInput and Instant behavior, concurrency and close semantics, plus the current HighestPriority implementation limitation.

A

Author

Author

Created: Apr 08, 2025Updated: Oct 19, 2026

Table of contents

GIPS buffering saves a tag and trigger phase in an active window when the current permission setup rejects an input, then sends it to the current processor chain immediately or when the window closes. It does not define combo logic, action duration, or animation notifies for your game.

Define a window

In InputBufferDefinitions on UGIPS_InputConfig, configure a Tag, BufferType, and AllowedInputs for each window. An allowed entry can restrict the input tag and TriggerEvents; an empty phase list allows any phase for that tag. Window tags must be valid and unique.

Window policies

BufferType

Behavior

LastInput

Each active window keeps the latest matching input and releases it when that window closes.

Instant

Releases a matching input as soon as it arrives, then closes every active window.

HighestPriority

The declared intent is to prefer entries earlier in AllowedInputs. The current source implementation can overwrite an earlier saved entry with a later matching input, so do not rely on priority selection yet.

Window lifecycle and concurrency

Manage windows with OpenInputBufferWindow(WindowTag) and CloseInputBufferWindow(WindowTag). The tag must already be defined in InputConfig. The component supports several different windows at once; one rejected input can be recorded by each active window that allows it.

When a window closes with a buffered input, GIPS sends that input directly to the processor chain on the InputControlSetup that is current at release time. It does not run permission checkers again, and releasing the input closes every active window. Closing an empty window closes only the requested window. StateTree also provides GIPS Buffer Window Scope plus listen and wait tasks.

When input is buffered

Buffering only occurs on the internal processing path: the current setup must reject the input, bEnableInputBuffer must be enabled, and an active window must allow the input tag and phase. Inputs that pass permission go directly to processors. bProcessingInputExternally skips both checks and buffering.

A buffer window has no duration field, and GenericInputSystem does not provide an ANS_GCS_InputBufferWindow animation notify. Use project logic, Blueprint, animation flow, or StateTree to call the open and close APIs at the intended times.

Practical guidance

  • Use LastInput to release the latest pre-input at the end of a window and Instant for immediate response during a window.
  • Keep windows active only for the gameplay interval that needs them. Releasing a buffered input from any active window closes all active windows.
  • If strict priority semantics are required, validate or correct the current HighestPriority implementation first. Use LastInput or Instant for behavior that is verified today.

Related pages

  • Input Control Setup: enable buffering and configure permission rules.
  • Input System Component: window APIs, events, and value access.
  • Quick Start and Integration: create and assign configuration assets.
  • Debugging Guide: inspect active windows and buffered records.