Quick Start

By the end of this page your pawn moves with WASD and fires one GAS ability - both routed by gameplay tag through a UCrimsonInputConfig. You will make the Enhanced Input assets, tag them in a config, bind them, and apply the mapping context.

Prerequisites
CrimsonCommon and CrimsonInput are installed, you have a Pawn / Character and a PlayerController you can edit, and (for the ability step) an ability system on your pawn or player state. New to Enhanced Input? Step 2 walks you through the raw assets.

1. Enable the plugin

Open Edit -> Plugins, type Crimson in the search box, tick CrimsonInput's checkbox (and CrimsonCommon, its dependency), and restart the editor when prompted. For a Blueprint project that is the entire install - you never hand-edit the .uproject or any .Build.cs.

Edit -> Plugins -> search 'Crimson' -> tick CrimsonInput's Enabled checkbox -> restart the editor.

C++ projects: after enabling the plugin, add its module to your build file so your game code can use its types:

csharp
// YourGame.Build.cs
PublicDependencyModuleNames.Add("CrimsonInput");
Verify
CrimsonInput shows as enabled in the Plugins window and the editor restarts without errors.

2. Create the Enhanced Input assets

CrimsonInput does not replace Enhanced Input - it sits on top of it. You still need the standard assets: an Input Action per action, and one Input Mapping Context (IMC) that binds keys to those actions. If you already have them, skip ahead.

  1. Content Browser -> right-click -> Input -> Input Action. Make IA_Move (set its Value Type to Axis2D (Vector2D)) and IA_Ability1 (leave it Digital (bool)).
  2. Right-click -> Input -> Input Mapping Context. Make IMC_Default.
  3. Open IMC_Default, add a mapping for IA_Move (bind WASD - use the standard 2D-vector modifiers) and a mapping for IA_Ability1 (bind e.g. the 1 key).
Create IA_Move and IA_Ability1 Input Actions, then an IMC_Default that maps keys (WASD, 1) to them. These are stock Enhanced Input assets - the config in step 4 references them by tag.
Config vs mapping context
Two different assets do two different jobs: the IMC maps keys -> actions (which you just made), and the CrimsonInputConfig (step 4) maps actions -> gameplay tags. The config holds no keys; the IMC holds no tags. You need both.
Verify
You have IA_Move, IA_Ability1, and an IMC_Default whose mappings light up the right keys when you preview them.

3. Use the Crimson input component

UCrimsonInputComponent is the Enhanced Input component with the tag-based binders. Point the project at it once in Config/DefaultInput.ini - this applies to every controller with no per-pawn code:

ini
[/Script/EnhancedInput.EnhancedInputDeveloperSettings]
DefaultInputComponentClass=/Script/CrimsonInput.CrimsonInputComponent
Per-pawn alternative (C++)
To use it on just one pawn, set InputComponentClass = UCrimsonInputComponent::StaticClass(); in that pawn's constructor instead. The project-wide DefaultInputComponentClass above is the recommended default and matches how CrimsonCore ships.
Verify
In C++, CastChecked<UCrimsonInputComponent>(PlayerInputComponent) in SetupPlayerInputComponent succeeds. In Blueprint, Get Component By Class -> Crimson Input Component on the pawn returns a valid component at runtime.

4. Create a UCrimsonInputConfig

Right-click in the Content Browser -> Miscellaneous -> Data Asset -> CrimsonInputConfig. Open it and tag the actions from step 2: put IA_Move in NativeInputActions with tag InputTag.Move, and IA_Ability1 in AbilityInputActions with tag InputTag.Ability.1. (The plugin ships no input tags - add these under an InputTag parent in your Project Settings -> GameplayTags, or use native tags.)

Create a CrimsonInputConfig; add IA_Move to NativeInputActions (tag InputTag.Move) and IA_Ability1 to AbilityInputActions (tag InputTag.Ability.1).
Verify
The asset shows your two entries, each an InputAction paired with an InputTag scoped to your InputTag hierarchy.

5. Bind the actions

Bind native input (move) and ability input (ability 1) from the config. Blueprint and C++ take different paths - the C++ binders are template helpers, so Blueprint drives input from the standard Enhanced Input Action event nodes instead. Both need a reference to your config: see How-To: Get the Building Blocks.

In the pawn/controller Event Graph: the IA_Move Enhanced Input Action event -> Add Movement Input. The IA_Ability1 event -> Get Ability System Component -> Ability Input Tag Pressed (Triggered) / Released (Completed + Canceled). Ability Input Tag Pressed/Released are CrimsonAbilitySystem nodes.
Why the Blueprint path differs
BindNativeAction / BindAbilityActions are C++-only templates. In Blueprint you place an Enhanced Input Action event per action (it references the UInputAction asset directly) and call your logic from it. For ability input, forward the tag to your ASC (this example uses CrimsonAbilitySystem's Ability Input Tag Pressed) - see How-To: Bind Ability Input for the full node chain.
Verify
The move key drives movement in PIE; the ability key reaches your ability-input handler with tag InputTag.Ability.1.

6. Apply the mapping context

Finally, apply IMC_Default through Add Mapping Context With Chord Triggers (not the vanilla Add Mapping Context). It applies the IMC and injects chord triggers on any rebindable mapping; with no chords authored yet it behaves exactly like the vanilla node. Do this once when the pawn is possessed (e.g. BeginPlay). Getting the subsystem is covered in How-To: Get the Building Blocks.

BeginPlay -> Get Controller -> Cast To PlayerController -> Get Enhanced Input Local Player Subsystem (from Player Controller) -> Add Mapping Context With Chord Triggers (Mapping Context = IMC_Default, Priority = 0).
Verify
Press Play: WASD moves the pawn and the ability key fires your ability. That is the full tag-driven loop.
What's next
Learn the getter chains once (How-To: Get the Building Blocks), then add modifier-key chords (How-To: Add Modifier-Key Chords), let players rebind them (How-To: Let Players Rebind Chords), and drive deadzone / sensitivity from player settings (How-To: Settings-Driven Modifiers).
On the full Crimson stack this is automatic
With CrimsonCore you do none of steps 3, 5, or 6 by hand. You make a Blueprint subclass of its ACrimsonCharacter and assign a Crimson Pawn Data asset whose InputConfig is your config; UCrimsonHeroComponent then binds all input (native + ability) from an init-state machine with zero wiring. See Concept: Full-Stack Integration & Multiplayer.