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.
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.
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.
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.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.