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 |
| Extension bases | UCrimsonPlayerInput, UCrimsonPlayerMappableKeyProfile | Optional subclass hooks for player-input processing and key-profile equip / unequip events |
Plugin dependencies
| Type | Name |
|---|---|
| Crimson | CrimsonCommon (logging + the shared ECrimsonGamepadSensitivity and FCrimsonChordRequirement types) |
| Engine plugins | EnhancedInput, GameplayAbilities, CommonUI |
| Engine modules | Core, CoreUObject, Engine, EnhancedInput, InputCore, GameplayTags, GameplayAbilities, DeveloperSettings, CommonInput |
Tags are the API - and there is no CrimsonAbilitySystem dependency
Game code references actions by
FGameplayTag, never by a raw UInputAction*. GAS input binding discovers the ability system through the engine's IAbilitySystemInterface::GetAbilitySystemComponent(), so CrimsonInput has zero knowledge of CrimsonAbilitySystem types. 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 C++: GAS ability input binding is easiest through CrimsonCore (standalone Blueprint forwards per-action with CrimsonAbilitySystem's
Ability Input Tag Pressed / Released nodes - see How-To: Bind Ability Input), and binding CommonUI actions is C++-only (Unreal has no Blueprint node for FBindUIActionArgs(UInputAction*, ...); CrimsonUI/CrimsonCore do it natively). 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.
- 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.