How-To: Get the Building Blocks

Goal: get the three CrimsonInput pieces every other page assumes you can reach - the Enhanced Input subsystem, your input config, and the Crimson user settings. Each is shown in Blueprint and C++. Bookmark this page; the task pages link back here instead of repeating these chains. Forwarding input to a GAS ability system is ability-system-specific and lives in How-To: Bind Ability Input - CrimsonInput itself has no ability-plugin dependency.

1. The Enhanced Input subsystem

UEnhancedInputLocalPlayerSubsystem is where you apply mapping contexts and reach the user settings. It lives on the local player, so you need a PlayerController first.

Right-click in the graph and search Enhanced Input Local Player Subsystem. Two forms come back. Inside a widget or a Player Controller graph, Get Enhanced Input Local Player Subsystem resolves from Self. From a Pawn, use the Player Controller form: Get Controller -> Cast To PlayerController -> Get Enhanced Input Local Player Subsystem (from Player Controller). Either one gives you the pin every other page calls the subsystem.

Verify
The subsystem node/pointer is non-null once the pawn has a PlayerController (i.e. after possession - BeginPlay on a possessed pawn is safe).

2. Your input config

There is no global getter for the config - you hold a reference to the asset. Add a variable and assign your UCrimsonInputConfig, then call the Find...InputActionForTag lookups on it.

In My Blueprint -> Variables, click +, and in the Details panel set the variable's Variable Type to Crimson Input Config (Object Reference) - search Crimson Input Config in the type picker. Tick Instance Editable if placed instances should each pick their own, then Compile and set Default Value to your config asset. Drag the variable into the graph and pull off it to reach Find Native Input Action For Tag, Find Ability Input Action For Tag, and Find UI Input Action For Tag.

Full stack: the pawn's active config is not Blueprint-reachable (CrimsonCore - requires all Crimson plugins)
On CrimsonCore the live config comes from PawnData->InputConfig, but GetPawnData is a C++ template and PawnData is not Blueprint-readable - there is no Blueprint node to fetch the pawn's active config at runtime. You do not need it: CrimsonCore binds everything for you. If you want the asset in Blueprint, reference the UCrimsonInputConfig asset directly (it is BlueprintType).

3. The Crimson user settings

UCrimsonInputUserSettings stores per-player chord overrides. You reach it through the subsystem - but two Project Settings must be on first, or Get Enhanced Input User Settings returns null.

Enable user settings first
Project Settings -> Engine -> Enhanced Input -> tick Enable User Settings, and set User Settings Class to CrimsonInputUserSettings (or set it in Config/DefaultInput.ini under [/Script/EnhancedInput.EnhancedInputUserSettings] UserSettingsClass=/Script/CrimsonInput.CrimsonInputUserSettings). Without both, GetUserSettings() is null and chord persistence silently does nothing.
Project Settings -> Engine -> Enhanced Input: Enable User Settings ticked, User Settings Class = CrimsonInputUserSettings.

From the subsystem pin you got in step 1: Get Enhanced Input User Settings -> Cast To CrimsonInputUserSettings. The cast's As Crimson Input User Settings output is what every chord call takes as its target - Set Chord Requirement, Get Chord Requirement With Defaults, Has Chord Requirement, Find Chord Conflict, Clear Chord Requirement, Clear All Chord Requirements. Wire the cast's Cast Failed pin somewhere visible while you set this up; a failure means the two Project Settings below are not both set.

Verify
The cast succeeds (non-null). If it is null, re-check the two Project Settings above - that is the number-one cause.

See also

  • How-To: Bind Ability Input - forward input to your ability system (GAS).
  • How-To: Let Players Rebind Chords - uses the user settings from step 3.
  • How-To: Create an Input Config - authoring the config from step 2.