Concept: Full-Stack Integration & Multiplayer

Used standalone, you bind input yourself (Quick Start) and need nothing on this page. It is here for orientation only: CrimsonCore consumes CrimsonInput for you through an init-state machine, the game feature actions, and ability-self-binding. CrimsonCore is free to download, but compiles only with all Crimson plugins installed - apart from the two game feature actions, which ship in CrimsonInput, none of the types below live in CrimsonInput, and each has a standalone equivalent already documented on the How-To pages.

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

The two game feature actions themselves ship in CrimsonInput, so a standalone project has them: UCrimsonGameFeatureAction_AddInputContextMapping and UCrimsonGameFeatureAction_AddInputBinding. See How-To: Add Input with a Game Feature for the full recipe. What CrimsonCore adds is the receiver on the other end - UCrimsonHeroComponent implements ICrimsonInputConfigReceiver and sends UCrimsonInputComponent::NAME_BindInputsNow once the pawn's input is bound, so a feature that activated earlier re-applies with no pawn edit.

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