Tag-driven Enhanced Input — bind GAS abilities, rebind chords per player, and drive CommonUI from one config.

Free · Input · Unreal Engine 5

Bind input by tag, not by pointer.

CrimsonInput layers a tag-driven binding model over Unreal's Enhanced Input. One UCrimsonInputConfig maps every action to a gameplay tag — native C++ callbacks, GAS ability input, and UE 5.8 CommonUI navigation all resolve from the same asset. Per-player chord rebinding, settings-driven modifiers, and aim-sensitivity presets are built in, and it talks to GAS through the engine's IAbilitySystemInterface, so it never depends on a specific ability system.

Video coming soon

Why CrimsonInput

Everything Enhanced Input was missing for ability games — tags as the API, rebindable chords, and CommonUI in one place.

Tags are the API

A single UCrimsonInputConfig data asset maps each UInputAction to an FGameplayTag across three lists — native, ability, and UI actions. Game code references actions by tag and never holds a raw UInputAction*, so one config is the indirection layer instead of a parallel DataTable.

GAS input, zero coupling

BindAbilityActions bulk-binds every ability action and forwards each FGameplayTag to your ASC's pressed/released handlers. It discovers the ASC through the engine's IAbilitySystemInterface — CrimsonInput has no dependency on CrimsonAbilitySystem or any specific GAS layer.

Per-player chord rebinding

UInputTriggerCrimsonDynamicChord adds Shift / Ctrl / Alt requirements with exact-match semantics, authored right on the IMC mapping. Player overrides persist through UCrimsonInputUserSettings (a SaveGame UEnhancedInputUserSettings), and FindChordConflict validates a rebind before you commit it.

Settings-driven modifiers

Four UInputModifiers — deadzone, gamepad sensitivity, aim inversion, and a reflection-based setting scalar — read their values from an ICrimsonInputSettingsProvider on the local player. Settings concerns stay out of the input system; no concrete settings class is ever imported.

CommonUI input, UE 5.8+

A UIInputActions category lets widgets bind via FBindUIActionArgs(UInputAction*, Delegate). CommonUI's action router resolves the live key from the player's IMC, so button glyphs auto-update on rebind — and the old UCommonUIInputData DataTable workflow is gone.

Aim sensitivity presets

Ten named presets (ECrimsonGamepadSensitivity, Slow → Insane) map to float scalars through a UCrimsonAimSensitivityData asset, separating the settings-UI concern from the actual input scaling. Normal and ADS targeting types each read their own preset.

A closer look

Bind your whole pawn in one place

Set InputComponentClass to UCrimsonInputComponent, then in SetupPlayerInputComponent call BindNativeAction to wire tagged actions to C++ functions and BindAbilityActions to bulk-bind every ability action to pressed/released GAS callbacks. The config is the single source of truth — add an action by dropping it in the asset, not by editing bind code.

Video coming soon

Rebindable chords without the boilerplate

UCrimsonInputHelpers::AddMappingContextWithChordTriggers auto-injects a chord trigger onto any mapping whose action uses UCrimsonPlayerMappableKeySettings, so you don't hand-edit every row. GetChordDisplayTextForAction returns a formatted label like "Shift+E" for tooltips and action bars, and UCrimsonPlayerMappableKeyProfile fires Blueprint events when the active key profile changes.

Video coming soon

Decoupled by design

Following the suite's Cardinal Rule, CrimsonInput depends only on CrimsonCommon — where the shared ECrimsonGamepadSensitivity and FCrimsonChordRequirement types live so CrimsonInput and your settings code share them without a cross-plugin dependency. GAS binding goes through an engine interface; settings come through an interface on the local player. Nothing reaches into a sibling plugin.

Video coming soon

Technical details

Engine
UE 5.8
Platforms
Windows, Mac, Linux
Blueprint-ready
Yes
C++ required
Yes
Network replicated
No
Dependencies
CrimsonCommon, EnhancedInput, GameplayAbilities, CommonInput, GameplayTags, DeveloperSettings
Last updated
June 2026

Frequently asked questions

Do I need C++ to use it?
For the core binding, yes. BindNativeAction and BindAbilityActions are C++ templates called from your character's SetupPlayerInputComponent, and the input component class is set in the constructor. Everything built around them — the config data asset, chord rebinding and conflict checks, key profiles, the UI action lookups, and the settings provider — is Blueprint-accessible.
Does it depend on other Crimson plugins?
Only CrimsonCommon, per the suite's Cardinal Rule. The shared ECrimsonGamepadSensitivity and FCrimsonChordRequirement types live there so CrimsonInput shares them without a sibling dependency. Notably, it does not depend on CrimsonAbilitySystem — GAS binding uses the engine's IAbilitySystemInterface.
Is it free?
Yes. CrimsonInput is free on Fab — enable it alongside CrimsonCommon and you're set.
Does it integrate with the Gameplay Ability System?
Yes. BindAbilityActions bulk-binds your ability input actions and hands each action's FGameplayTag to your ASC's AbilityInputTagPressed / AbilityInputTagReleased. Because it discovers the ASC through the engine interface, it works with any GAS setup and stays decoupled from CrimsonAbilitySystem.
Can players rebind keys and modifier chords?
Yes. Mark an action's key settings rebindable and per-player chord overrides persist through UCrimsonInputUserSettings (SaveGame). FindChordConflict warns before two actions share the same key+chord, and gamepad input bypasses chord checks automatically. Modifier chords use exact-match semantics — requiring no modifiers means any held modifier blocks the action.

Wire up tag-driven input in minutes

Enable CrimsonInput, set the input component class, build one config, and bind by tag. Per-player chords, settings-driven modifiers, and CommonUI navigation come along for the ride.