Weapon abilities: grant on equip, remove on unequip

Commits 7629966, 02ab227 + work in progress · GrantHeroWeaponAbilities, RemoveGrantedHeroWeaponAbilities, AWarriorHeroWeapon::GrantedAbilitySpecHandles · 9 min

The round trip

1. Equip (GA_Hero_EquipAxe): read HeroWeaponData.DefaultWeaponAbilities from the axe → GrantHeroWeaponAbilities → get back a list of handles → AssignGrantedAbilitySpecHandles stores them on the axe.
2. While equipped, pressing an attack button finds those abilities by input tag (ability input).
3. Unequip (GA_Hero_UnequipAxe): GetGrantAbilitySpecHandles from the axe → RemoveGrantedHeroWeaponAbilities clears each one and empties the list.

Granting, and getting handles back

UFUNCTION(BlueprintCallable, Category="Warrior|Ability", meta = (ApplyLevel = 1))
void GrantHeroWeaponAbilities(const TArray<FWarriorHeroAbilitySet>& InDefaultWeaponAbilities,
                              int32 ApplyLevel,
                              TArray<FGameplayAbilitySpecHandle>& OutgrantedAbilitySpecHandles);

// body: same spec-building loop as the startup data, plus:
OutgrantedAbilitySpecHandles.AddUnique(GiveAbility(AbilitySpec));

• GiveAbility returns a handle, the ID of that one grant. Startup abilities ignored it because they're never removed. Weapon abilities must be removed later, so this time you keep it.
• Why handles, not ability classes? "Remove the light attack class" is ambiguous if two things granted it. A handle identifies this exact grant.
• meta = (ApplyLevel = 1): a default value for the Blueprint pin. Blueprint reads metadata named after a parameter as that pin's default. (A C++ default, int32 ApplyLevel = 1, also works and helps C++ callers too.)

Out parameters and UPARAM(ref): how references become Blueprint pins

This is the references page in action. A UFUNCTION's reference parameters turn into different pins depending on const:

Without UPARAM(ref), Blueprint would treat the remove function's array as an output, and you couldn't plug the weapon's handles in. With it, InSpecHandlesToRemove.Empty() empties the array you actually passed in. Unreal's naming convention helps you read these: In prefix for inputs, Out for outputs.

Removing

void UWarriorAbilitySystemComponent::RemoveGrantedHeroWeaponAbilities(
        UPARAM(ref) TArray<FGameplayAbilitySpecHandle>& InSpecHandlesToRemove)
{
    if (InSpecHandlesToRemove.IsEmpty()) return;
    for (const FGameplayAbilitySpecHandle& SpecHandle : InSpecHandlesToRemove)
        if (SpecHandle.IsValid()) ClearAbility(SpecHandle);
    InSpecHandlesToRemove.Empty();
}

• ClearAbility(Handle): the same call the OnGiven policy uses to remove one-shot abilities (activation policy).
• Empty after the loop, not during. The loop only reads the array, so it's safe; changing an array while looping over it is the TArray trap.
• Emptying matters: stale handles left on the weapon would be "removed" again on the next unequip. That's harmless here thanks to the IsValid check, but untidy.

Does this hit the "list changes while looping" issue from the input lesson?

On the ability input page I flagged that OnAbilityInputPressed loops over the ability list while activating, and granting abilities changes that list. In your case it's fine: the equip ability grants the weapon abilities after the montage's gameplay event, a later frame, long after the input loop has finished. If a future ability granted something immediately on activation, that's when to collect handles first.

The T-pose fix (Blueprint, from your commit message)

Unequipping unlinks the axe anim layer. The main anim BP then falls back to its own default implementation of each layer. If that default is empty, there's no pose at all, and an empty pose is the skeleton's reference pose: T-pose. The fix: give ABP_HeroCharacter's default ArmedLocomotionState layer an unarmed pose so there's always something to fall back to. General rule: every layer slot needs a sensible default, because "no layer linked" is a real state.