Concept: Full-Stack Integration & Multiplayer

Used standalone, you bind input yourself (Quick Start). On the full Crimson stack, CrimsonCore consumes CrimsonInput for you through a Lyra-style init-state machine, GameFeature actions, and ability-self-binding. None of the types below live in CrimsonInput - they are how CrimsonCore drives it.

The Blueprint fast path

For a Blueprint project, the full stack is the simplest way to get everything (native + ability + chords) working: make a Blueprint subclass of ACrimsonCharacter, and assign a Crimson Pawn Data asset whose InputConfig is your config (and whose ability sets grant your abilities). No input nodes, no SetupPlayerInputComponent - UCrimsonHeroComponent binds it all on possession.

The init-state flow

UCrimsonHeroComponent::InitializePlayerInput runs from the GameFramework init-state machine. It takes the config from PawnData->InputConfig, applies each IMC via AddMappingContextWithChordTriggers, then binds ability input with BindAbilityActionsWithAction, and broadcasts that input is ready. (Note: AddInputMappings is called here too but is a reserved no-op in the current build - the IMC application is done entirely by the chord-trigger helper.)

cpp

// UCrimsonHeroComponent::InitializePlayerInput (abridged)
const UCrimsonInputConfig* InputConfig = PawnData->InputConfig;
for (const FCrimsonInputMappingContextAndPriority& M : DefaultInputMappings)
    if (UInputMappingContext* IMC = M.InputMapping.LoadSynchronous())
        UCrimsonInputHelpers::AddMappingContextWithChordTriggers(Subsystem, IMC, M.Priority);

CrimsonIC->BindAbilityActionsWithAction(InputConfig, this,
    &ThisClass::Input_ComboCapableActionPressed,
    &ThisClass::Input_ComboCapableActionReleased, BindHandles);
PawnExtComp->OnClientInputComponentReady.Broadcast(CrimsonIC);

GameFeature-driven mappings and bindings

Action	Does	Key type
`UGFA_AddInputContextMapping`	Registers IMCs with the user-settings subsystem and applies them (with chord triggers) on activation	`FCrimsonInputMappingContextAndPriority` (`InputMapping`, `Priority`, `bRegisterWithSettings`)
`UGFA_AddInputBinding`	Adds extra ability bindings to a pawn at runtime via `HeroComponent->AddAdditionalInputConfig`	another `UCrimsonInputConfig`

Both listen for the NAME_BindInputsNow ("BindInputsNow") extension event that the hero component sends once input is ready - the seam that lets features attach input without editing the pawn.

Native input lives inside abilities

CrimsonCore does not bind native input on the pawn. UCrimsonGameplayAbility_BindNativeInput activates once on spawn, subscribes to OnClientInputComponentReady, calls BindNativeAction, and re-checks the ability's tag requirements on every input event (so a look ability can be blocked by Status.LockedOn with no hard-coding). Move, look, sprint, and camera input are abilities of this family.

Only for always-on input

This pattern is for continuous / passive input (move, look, sprint modifier). Each press is a local callback with no per-press TryActivateAbility, so it cannot drive replicated montages or ability tasks. Discrete actions (jump, dash, attack) use a normal input-triggered UCrimsonGameplayAbility so GAS routes the tag to TryActivateAbility with prediction.

Multiplayer & authority

Input is a local concern. Bindings, chords, modifiers, and the input config are evaluated on the owning client only; nothing here is replicated gameplay state.

Concern	Where it runs	Networking
Key -> tag binding, modifiers, chords	Owning client	None - local only
Ability activation from input	Client predicts, server authorizes	GAS prediction + activation replication
Grant ability with input tag	Server (`HasAuthority`)	Ability spec replicates to the owner
Chord / sensitivity preferences	Local player settings	None - per-client preference

Never trust raw input on the server

The server validates through ability activation (and Server_ RPC _Validate functions on your own gameplay code), not by trusting a client's raw input events. Do not replicate input state or drive authoritative changes directly from an input callback - forward the intent to a predicted or server ability instead.