CrimsonInput
CrimsonInput is a tag-driven layer over Unreal's Enhanced Input. Instead of wiring UInputAction assets straight into your character code, you author one UCrimsonInputConfig data asset that pairs each action with an FGameplayTag. Game code then binds and looks up actions by tag - native C++ callbacks and GAS ability input both come from that same config. On top of the config it adds settings-driven input modifiers, a modifier-key chord system (inline or per-player rebindable), gamepad aim sensitivity, and UE 5.8 CommonUI action binding.
New here? Read in this order
Do Quick Start first (one working pawn), then How-To: Get the Building Blocks - it shows the exact Blueprint nodes and C++ for reaching the subsystem, your config, and the user settings that every other page assumes you already have. Use the Blueprint / C++ / Both switch at the top to see the path for your project type.
What's included
| System | Key Types | Purpose |
|---|---|---|
| Tag-based config | UCrimsonInputConfig, FCrimsonInputAction | One data asset maps UInputAction assets to gameplay tags across Native / Ability / UI lists |
| Binding component | UCrimsonInputComponent | Binds tagged actions to C++ callbacks (BindNativeAction) or GAS abilities (BindAbilityActions / BindAbilityActionsWithAction) |
| Settings-driven modifiers | UCrimsonInputModifierDeadZone, UCrimsonInputModifierGamepadSensitivity, UCrimsonInputModifierAimInversion, UCrimsonSettingBasedScalar | Input modifiers that read per-player values through ICrimsonInputSettingsProvider - no concrete settings class imported |
| Modifier-key chords | UInputTriggerCrimsonDynamicChord, FCrimsonChordRequirement | Require Shift / Ctrl / Alt on an action with exact-match semantics; authored inline or made per-player rebindable |
| Rebindable chords | UCrimsonInputUserSettings, UCrimsonPlayerMappableKeySettings, UCrimsonInputHelpers | Persist per-player chord overrides, detect conflicts, and format key + modifier display glyphs |
| Gamepad sensitivity | UCrimsonAimSensitivityData, ECrimsonGamepadSensitivity | Maps named sensitivity presets (Slow...Insane) to scalar multipliers, with a Normal / ADS split |
| Press-and-hold trigger | UInputTriggerCrimsonPressAndHold | Tap / Hold / Toggle-friendly trigger for multi-behavior ability inputs |
| CommonUI actions | UIInputActions (on the config), UCrimsonInputSettings | UE 5.8+ UI action binding via FBindUIActionArgs(UInputAction*, ...) - no UCommonUIInputData DataTable |
| Game feature input | UCrimsonGameFeatureAction_AddInputContextMapping, UCrimsonGameFeatureAction_AddInputBinding, ICrimsonInputConfigReceiver | Attach mapping contexts and input configs from a game feature and take them back when it deactivates |
| Extension bases | UCrimsonPlayerInput, UCrimsonPlayerMappableKeyProfile | Optional subclass hooks for player-input processing and key-profile equip / unequip events |
Plugin dependencies
| Type | Name |
|---|---|
| Crimson | None - fully standalone (ECrimsonGamepadSensitivity and FCrimsonChordRequirement are defined here) |
| Engine plugins | EnhancedInput, GameplayAbilities, CommonUI, GameFeatures, ModularGameplay |
| Engine modules | Core, CoreUObject, Engine, EnhancedInput, InputCore, GameplayTags, GameplayAbilities, DeveloperSettings, CommonInput, GameFeatures, ModularGameplay |
Tags are the API - and there is no ability-system dependency
Game code references actions by
FGameplayTag, never by a raw UInputAction*. Ability input binding hands your callback the tag and nothing else; you reach your ability system through the engine's IAbilitySystemInterface::GetAbilitySystemComponent(). CrimsonInput therefore has zero knowledge of any ability system type beyond Epic's UAbilitySystemComponent. It is a self-contained input layer you can drop into any GAS or non-GAS project.Blueprint reality check
Native input, chords, modifiers, and sensitivity are all Blueprint-friendly. Two things need care: GAS ability input is bulk-bound from C++ (
BindAbilityActions is a template), while Blueprint forwards one Enhanced Input Action event per ability action into GAS's own Try Activate Abilities By Tag node - see How-To: Bind Ability Input; and binding CommonUI actions is C++-only (Unreal ships no Blueprint node for FBindUIActionArgs(UInputAction*, ...)). Each page's Blueprint tab tells you which nodes to use.Where to go next
- Quick Start - one working pawn that moves and fires an ability, end to end.
- How-To: Get the Building Blocks - the exact nodes/code to reach the subsystem, your config, and the user settings (read this second).
- Task pages: create an input config, bind ability input, bind native input, add chords, let players rebind chords, settings-driven modifiers, gamepad sensitivity, CommonUI actions, and How-To: Add Input with a Game Feature.
- Mental model: Concept pages (tag-driven input, the chord system, the settings-provider bridge, full-stack integration & multiplayer).
- Looking up a signature? Jump to API Reference.
Using with other Crimson plugins
CrimsonInput works on its own. When you own other Crimson plugins, CrimsonCore (free to download, but compiles only with all Crimson plugins installed) contains the full-suite wiring for it:
UCrimsonHeroComponent binds a pawn's UCrimsonInputConfig (native and ability input) automatically, UCrimsonGameplayAbility_BindNativeInput lets an ability bind its own input, and Source/CrimsonCore/.../Integration/Input/ maps the player's saved gamepad sensitivity onto ECrimsonGamepadSensitivity. To wire it yourself, read CrimsonCommon -> Concept: Connecting Crimson Plugins; to see how CrimsonCore does it, read CrimsonCore -> Concept: The Integration Layer.