How-To: Bind Ability Input

Goal: make a key press activate a GAS ability by input tag - forwarding the config's AbilityInputActions to your ability system.

Prerequisites
A UCrimsonInputConfig with AbilityInputActions filled, and an ability system on your pawn/player state that exposes a tag-input entry point. This page uses CrimsonAbilitySystem as the example ability system; CrimsonInput does not depend on it.

1. Bind and forward to the ability system

CrimsonInput's binders hand your callback an FGameplayTag - the plugin does not know your ability system. Forward that tag to whatever ASC your project uses (discover it via the engine's IAbilitySystemInterface). The examples below use CrimsonAbilitySystem, whose AbilityInputTagPressed / AbilityInputTagReleased are BlueprintCallable; swap in your own ASC's tag-input call if you use a different one. Blueprint places one Enhanced Input Action event per ability action; C++ bulk-binds the whole AbilityInputActions list with one call.

For each ability action: its Enhanced Input Action event -> Triggered -> Get Ability System Component -> Ability Input Tag Pressed (InputTag.Ability.1). Wire BOTH Completed and Canceled -> Ability Input Tag Released. (Ability Input Tag Pressed/Released are CrimsonAbilitySystem's nodes.)
Get the ASC first
Get your ability system component with the engine node Get Ability System Component (from IAbilitySystemInterface). The Ability Input Tag Pressed / Released nodes shown here belong to CrimsonAbilitySystem - if you use a different ability system, call its equivalent tag-input node.
Why release binds Completed and Canceled
Enhanced Input fires Completed on a normal release, but Canceled when a trigger was still Ongoing (e.g. a UInputTriggerCrimsonPressAndHold released before its hold threshold). Both mean the player let go, so route both to your released handler. BindAbilityActions does this for you in C++; in Blueprint you must wire both pins.
Verify
Pressing an ability key activates the ability granted with that input tag; releasing it (immediately or after a hold) reaches your released handler exactly once.

2. Grant abilities with an input tag

For the ASC to match input to an ability, the ability's spec must carry the same input tag you used in the config.

cpp
const FGameplayTag Tag = FGameplayTag::RequestGameplayTag(FName("InputTag.Ability.1"));
FGameplayAbilitySpec Spec(AbilityClass, /*Level*/ 1, INDEX_NONE, /*SourceObject*/ this);
Spec.GetDynamicSpecSourceTags().AddTag(Tag);
ASC->GiveAbility(Spec); // server only
Grant on the server
GiveAbility is server-authoritative - call it where the ASC has authority (HasAuthority()), never on a client. Input events fire on the owning client and the ASC replicates activation with GAS prediction.

3. Combo-capable characters (advanced)

If a character routes input through a combo controller, use BindAbilityActionsWithAction instead - it binds press to Started and passes the UInputAction* and the tag, so the controller can identify inputs by action identity and fall through to the ASC when it does not consume the press. This is the binder CrimsonCore uses.

cpp
// Callback signature is void(UInputAction* Action, const FGameplayTag& Tag)
CIC->BindAbilityActionsWithAction(InputConfig, this,
    &AMyCharacter::Input_ComboPressed,
    &AMyCharacter::Input_ComboReleased,
    AbilityBindHandles);
On the full stack
CrimsonCore's UCrimsonHeroComponent calls BindAbilityActionsWithAction, offers the press to a UCrimsonComboController, and otherwise forwards to the ASC's AbilityInputTagPressed - all with zero wiring from you. See Concept: Full-Stack Integration & Multiplayer.

See also

  • How-To: Get the Building Blocks - getting the subsystem, config, and user settings.
  • How-To: Bind Native Input - the non-ability binder and the press-and-hold trigger.
  • Concept: Full-Stack Integration & Multiplayer - the combo router and prediction model.