Skip to main content

Gameplay Ability System

An item can grant gameplay effects, abilities and attribute sets while it sits somewhere, and take them back when it leaves. Equip a helmet and the armour bonus applies; drop it in a bag and it does not.

Setup​

GAS is a dependency of the plugin, so there is no module to enable. Your character needs the usual one-time setup:

AMyCharacter::AMyCharacter()
{
    AbilitySystem = CreateDefaultSubobject<UAbilitySystemComponent>(TEXT("AbilitySystem"));
    AbilitySystem->SetIsReplicated(true);
    AbilitySystem->SetReplicationMode(EGameplayEffectReplicationMode::Mixed);

    Attributes = CreateDefaultSubobject<UMyAttributeSet>(TEXT("Attributes"));
}

void AMyCharacter::BeginPlay()
{
    Super::BeginPlay();
    AbilitySystem->InitAbilityActorInfo(this, this);
}

Implement IAbilitySystemInterface so the inventory can find the component. Then add UEDGASLinkComponent to the actor — that is what watches containers and reconciles grants.

The Grants fragment​

FEDGrantsFragment holds three lists, each entry carrying its own conditions:

GrantGives
Effect GrantsA gameplay effect applied while the condition holds.
Ability GrantsAn ability granted while the condition holds.
Attribute Set GrantsAn attribute set added while the condition holds.

Every grant shares one FEDGrantCondition:

FieldMeaning
Container FilterWhich container the item must be in.
Slot FilterWhich slot, matched against the slot tag and the entry's dynamic tags.

Empty filters mean "wherever it is carried", which suits a passive charm. A helmet narrows the container filter to equipment.

The same vocabulary as visuals​

Grants and equipment visuals read the same tags: the container's type, the slot's tag, and the entry's DynamicTags. One item cannot be worn and stowed at once, so one answer serves both.

That is why drawing a sword can change its model and its buffs in one step:

Container->SetEntryDynamicTags(SwordHandle, FGameplayTagContainer(DrawnTag));

A visual state filtered on Drawn and an effect grant filtered on Drawn both react. Nothing wires them together.

Reconciliation, not events​

UEDGASLinkComponent does not apply grants on an "equipped" event. It reconciles: on any change it works out what should be granted now and makes reality match, adding what is missing and removing what no longer qualifies.

That matters because events can be missed, arrive out of order, or fire twice — on a client, on a respawn, on seamless travel. Reconciling from state cannot drift.

It also means teardown is free: the component undoes everything it granted on EndPlay, so a pawn being reused after a respawn does not keep the last life's effects.

Attribute-driven capacity​

A container's Slot Count Mode can be Attribute, reading a GAS attribute for its capacity:

Slot Count Mode:    Attribute
Capacity Attribute: MyAttributeSet.CarryingCapacity

A Strength perk then grows the bag with no inventory code at all. Editor validation refuses Attribute mode with no attribute set, since that failure is otherwise silent.

The same applies to FEDWeightLimitRule, which can read a weight cap from an attribute.

Attribute prerequisites​

FEDAttributePrerequisite gates an item on an attribute — "requires Strength 12". Like every prerequisite it is evaluated at the acceptance gate and reports player-readable text, so a UI can say why the item is refused rather than just refusing it.

Core stays GAS-free at the seams​

Core depends on GAS, but nothing in the item or container model does. Fragments describe grants; UEDGASLinkComponent applies them. An item with a Grants fragment on an actor with no ability system is inert rather than broken.

Where next​

Last updated on