DEV Community: Marko Petrić

Custom Gameplay Effect Context

Marko Petrić — Sun, 07 Jun 2026 17:29:45 +0000

Why would you make a custom gameplay effect context

If you followed my damage pipeline post, you passed in FGameplayEffectContext through your ExecCalc. This post covers how to extend it with your own data so you can carry exactly what your game needs.

The default context carries the basics, such as the instigator, causer, or hit result, but nothing specific to your game. Whether it's knowing if a hit was a headshot, which ability triggered the effect, or any other game-specific data you need to pass along, none of that lives on the default context.

How to make a custom gameplay effect context

For the file where you actually store the context, you can just create a regular .h and .cpp. In the header, you should first #pragma once, then #include "GameplayEffectTypes.h" and the .generated.h of your header.

The struct

The struct itself that's storing your custom gameplay effect context is the core body of your header. It's a regular BlueprintType struct inheriting from the base gameplay effect context.

When inheriting this struct, it's mandatory to override the GetScriptStruct function, which just returns the static UStruct.

The second function that must be overridden is the NetSerialize function, which we will use to determine how serialization will be done for the struct, for sending data across the network.

The last function we will override is Duplicate, making sure to return our own context instead of the base. This function allows us to create a copy of the gameplay effect context for any later modifications if needed. In the function, we check if there is a hit result and call AddHitResult if so. This is necessary because the hit result is stored as a shared pointer on the base context, which means a plain copy would leave both contexts pointing to the same hit result in memory, so we explicitly allocate a new one for the copy.

In the same struct body, we can add our custom variables that will be included in the context that can be passed along. In my example, I will utilize a bool for checking if a hit was through a shield and the damage multiplier for shooting through the shield (the same can be done with headshots for example), and also passing along a FGameplayAbilityTargetDataHandle, which I will show in more detail in a future post.

The final struct with all your variables and the overridden functions should look something like this:

USTRUCT(BlueprintType)
struct FComplyGameplayEffectContext : public FGameplayEffectContext
{
    GENERATED_BODY()

public:
    // Returns the actual struct used for serialization, subclasses must override this
    virtual UScriptStruct* GetScriptStruct() const override
    {
        return StaticStruct();
    }

    // Custom serialization, subclasses must override this
    virtual bool NetSerialize(FArchive& Ar, class UPackageMap* Map, bool& bOutSuccess) override;

    virtual FComplyGameplayEffectContext* Duplicate() const override
    {
        FComplyGameplayEffectContext* NewContext = new FComplyGameplayEffectContext();
        *NewContext = *this;
        if (GetHitResult())
        {
            NewContext->AddHitResult(*GetHitResult(), true);
        }
        return NewContext;
    }

public:
    UPROPERTY()
    bool bHitThroughShield = false;

    UPROPERTY()
    float ShieldDamageMultiplier = 1.f;

    // Used to send the shotgun's trace target data for cue effect purposes
    // *Note: this variable is not marked as UPROPERTY(), since it's not a UObject
    FGameplayAbilityTargetDataHandle ShotgunTracesTargetData;
};

StructOpsTypeTraits

StructOpsTypeTraits is a template struct which is required to be implemented for the custom gameplay ability context, where we set WithNetSerializer and WithCopy to true. WithNetSerializer tells the engine that this struct has a custom NetSerialize and to use it instead of the default property-based replication. WithCopy tells Unreal's type system that this struct is safely copyable via its copy constructor and assignment operator. Without it, Unreal's reflection system may treat the struct as non-copyable and refuse to copy it by value in certain contexts. You can add this struct in the same header, right below the struct definition.

template<>
struct TStructOpsTypeTraits<FComplyGameplayEffectContext> : TStructOpsTypeTraitsBase2<FComplyGameplayEffectContext>
{
    enum
    {
        WithNetSerializer = true,
        WithCopy = true
    };
};

NetSerialize

Note: NetSerialize handles serialization of all variables in the struct. The explanation gets technical, but the implementation is largely boilerplate. Feel free to skim to the code if you just need to get it working.

Parameters

NetSerialize is a function that handles serialization of variables in the struct.

The function has 3 parameters. The first parameter is an FArchive, which is a base class for archives used for loading, saving, and garbage collecting in a byte order neutral way, which means it abstracts away endianness differences across platforms. It also overloads the << operator, which works both ways depending on context. If we are saving and we have a bool for example, that bool will be serialized and stored in the archive as a series of bits. If we are loading, that series of bits will be deserialized and stored back into the bool on the right side of the operator.

The second paramater is a UPackageMap, which is a UObject that maps object references to compact integer indices for network communication. Rather than sending full object paths, both client and server maintain this map so only a small index needs to be transmitted, which keeps bandwidth low.

The last parameter is a bool by reference called bOutSuccess, which just returns whether or not serialization was successful.

Function body

*Make sure to include your header in the .cpp file.

The function will first require an unsigned integer variable (bitmask), used for serialization and deserialization by keeping track of which variables on the context are being replicated, with one bit per field. We can give it the variable amount of bits we need, which depends on the amount of variables. In this example, we will use uint16 as there are 7 variables from the base context and 3 additional variables in this context, so we need 10 bits in total.

uint16 RepBits = 0;

Now, we should check on the Ar if we are saving, and if we are, checks are performed on variables in the struct to determine whether or not they should be serialized, and serializing the ones that should be serialized at the end.

if (Ar.IsSaving())
{
    if (bReplicateInstigator && Instigator.IsValid()) RepBits |= 1 << 0;
    if (bReplicateEffectCauser && EffectCauser.IsValid() ) RepBits |= 1 << 1;
    if (AbilityCDO.IsValid()) RepBits |= 1 << 2;
    if (bReplicateSourceObject && SourceObject.IsValid()) RepBits |= 1 << 3;
    if (Actors.Num() > 0) RepBits |= 1 << 4;
    if (HitResult.IsValid()) RepBits |= 1 << 5;
    if (bHasWorldOrigin) RepBits |= 1 << 6;
    if (bHitThroughShield) RepBits |= 1 << 7;
    if (ShieldDamageMultiplier != 1.f) RepBits |= 1 << 8;
    if (ShotgunTracesTargetData.IsValid(0)) RepBits |= 1 << 9;
}

Ar.SerializeBits(&RepBits, 10);

Inside the if check, we are setting RepBits equal to itself, (=), then using bitwise OR (|) which compares two integers (before and after shifting) by comparing each bit in each place, and wherever there's two 0s, the result for that spot is 0, and if there's any 1s, the result is 1 and the results for each comparison will be placed at that spot on the new integer. In this case, 1 is being added to RepBits, so it will be added at the rightmost digit (flipping the bit, 0th, if counting from right to left). The shift left (<<) operator decides how much to shift digits to the left, so in this case, the digits won't be shifted because it's shifting by 0, but if they were being shifted, every digit would have to be moved to the left by what's specified, and any digits on the left would be lost, and new 0s will be created on the right. So, at 1 << 1, a new 1 will be created on the right, and we are shifting the bits to the left, so when comparing the bits, we will have 1 on 0th and 1st bit, so there will be 1s on both places. In this function, this is essentially a cheaper way of storing the results of bools. So, inside the if check, each field is tested and either sets its corresponding bit in RepBits to 1 if the condition passes, or leaves it as 0 if it doesn't. The full bitmask at the end of all the checks is a complete picture, as every bit position represents one field, with 1 meaning this field has data and should be serialized, and 0 meaning to skip it.

After all the checks are performed, we call the SerializeBits function on the archive, pass in the bitmask, and the possible number of bits that can be serialized (in this case 10 checks, so 10 bits). On save this writes the bitmask to the archive, and on load it reads it back, so the receiving end knows exactly which variables were sent and need to be deserialized.

After serializing the bits, we are now checking if the 0th digit in RepBits is 1, using the bitwise AND (&). It will only return true if both RepBits and the number being checked have a 1 in that position (in this case the 0th digit, due to << 0, otherwise if it had << 1, we would be checking the 1st digit). If we make it into the if statement, the variable will be serialized or deserialized using the << operator. Object references, hit results, vectors, arrays, and booleans are all fully serialized this way. For fields that weren't sent, we reset them to their default values on load using an else if (Ar.IsLoading()) check, ensuring the receiving end is always in a clean state.

if (RepBits & (1 << 0)) Ar << Instigator;
if (RepBits & (1 << 1)) Ar << EffectCauser;
if (RepBits & (1 << 2)) Ar << AbilityCDO;
if (RepBits & (1 << 3)) Ar << SourceObject;
if (RepBits & (1 << 4)) SafeNetSerializeTArray_Default<31>(Ar, Actors);
if (RepBits & (1 << 5))
{
    if (Ar.IsLoading())
    {
        if (!HitResult.IsValid())
        {
            HitResult = TSharedPtr<FHitResult>(new FHitResult());
        }
    }
    HitResult->NetSerialize(Ar, Map, bOutSuccess);
}
if (RepBits & (1 << 6))
{
    Ar << WorldOrigin;
    bHasWorldOrigin = true;
}
else if (Ar.IsLoading())
{
    bHasWorldOrigin = false;
}
if (RepBits & (1 << 7))
{
    Ar << bHitThroughShield;
}
else if (Ar.IsLoading())
{
    bHitThroughShield = false;
}
if (RepBits & (1 << 8))
{
    Ar << ShieldDamageMultiplier;
}
else if (Ar.IsLoading())
{
    ShieldDamageMultiplier = 1.f;
}
if (RepBits & (1 << 9))
{
    ShotgunTracesTargetData.NetSerialize(Ar, Map, bOutSuccess);
}

After all the serialization is done, if we are loading, we call AddInstigator, passing in the Instigator and EffectCauser. The InstigatorAbilitySystemComponent isn't serialized directly over the network, so it needs to be re-derived from the Instigator and EffectCauser once they've been deserialized on the receiving end. We then set bOutSuccess to true and return true.

if (Ar.IsLoading())
{
    AddInstigator(Instigator.Get(), EffectCauser.Get());
}   

bOutSuccess = true;
return true;

Setting a custom gameplay effect context

There is a default AbilitySystemsGlobals class which specifies some defaults and options to use for the gameplay ability system. If we want to set our own options and defaults, including using our custom gameplay effect context, we need our own AbilitySystemsGlobals class where we set it.

After creating the class, we need to override AllocGameplayEffectContext, which is called whenever a new gameplay effect context is created. In that function, we can return our custom context as an object on the heap using the new keyword. We will also need to include our header where we created our custom context.

#include "AbilitySystem/ComplyAbilitySystemGlobals.h"
#include "AbilitySystem/ComplyAbilityTypes.h"

FGameplayEffectContext* UComplyAbilitySystemGlobals::AllocGameplayEffectContext() const
{
    return new FComplyGameplayEffectContext();
}

After this, the custom AbilitySystemGlobals function needs to be set in DefaultGame.ini, so that this overridden function gets called whenever an effect context is created instead of the default one. Add these lines to it, replacing it with your own game's name and class name.

[/Script/GameplayAbilities.AbilitySystemGlobals]
+AbilitySystemGlobalsClassName="/Script/Comply.ComplyAbilitySystemGlobals"

Using a custom gameplay effect context and examples

When using the custom gameplay effect context, static_cast is always used to access it. The cast is safe because AllocGameplayEffectContext guarantees every context allocation returns the custom context type.

The order of operations matters. Data should be packed into the custom context before applying the effect so it's accessible, not after.

Creating and packing a context

In this first code snippet, we are creating a fresh context by first making a regular effect context through the ASC via MakeEffectContext, then creating a variable for our custom type and using static_cast to cast to it. After that, we are creating a variable for target data to pass into the context, which will now be sent along with the context when applying a gameplay effect or just passing it into something else. Anything downstream using the context after we packed this data will be able to access it. In my case, it's being passed into gameplay cue parameters straight away.

FGameplayEffectContextHandle ContextHandle = GetAbilitySystemComponentFromActorInfo()->MakeEffectContext();
FComplyGameplayEffectContext* Context = static_cast<FComplyGameplayEffectContext*>(ContextHandle.Get());
if (Context)
{
    FGameplayAbilityTargetDataHandle ShieldTargetData;
    for (const FHitResult& Hit : ShieldHits)
    {
        ShieldTargetData.Add(new FGameplayAbilityTargetData_SingleTargetHit(Hit));
    }  
    Context->ShotgunTracesTargetData = ShieldTargetData;
}

It's also possible to allocate the context directly with new instead of going through the ASC, pack data into it, and immediately pass it to another function as a parameter. In my example, I'm doing this when damage should be dealt (once target data is received). The bPassedThroughShield variable is set by a custom target data class and set in the effect context, and the multiplier float is taken from the CDO.

This calls CauseDamage, which immediately leads into the final part - reading from a custom context.

void URangedWeaponAbilityBase::OnTargetDataReceived(const FGameplayAbilityTargetDataHandle& DataHandle)
{
    const FGameplayAbilityActivationInfo ActivationInfo = GetCurrentActivationInfo();

    for (const TSharedPtr<FGameplayAbilityTargetData>& Data : DataHandle.Data)
    {
        if (!Data.IsValid()) continue;

        AActor* TargetActor = Data->GetHitResult()->GetActor();
        if (TargetActor && HasAuthority(&ActivationInfo))
        {
            // Context created and immediately packed with data
            FComplyGameplayEffectContext* Context = new FComplyGameplayEffectContext();
            Context->bHitThroughShield = HitscanTargetDataTask->bPassedThroughShield;
            Context->ShieldDamageMultiplier = ShieldShotDamageMultiplier;

            float FinalDamage = Damage.GetValueAtLevel(GetAbilityLevel());

            // ... damage scaling ...

            CauseDamage(TargetActor, FinalDamage, Context);
        }
    }
}

Whether or not you go through the ASC depends on what you need the context for. Using new means the context isn't tied to a handle, and that makes it convenient to pass around as a raw pointer between functions before it actually gets attached to a spec, as long as it's applied immediately after being passed in. Going through the ASC with MakeEffectContext gives a context handle which is a smart pointer wrapper, which is better when you need the context to stay alive and be managed for longer, like when passing it into gameplay cue parameters or other cases where it will be accessed later. So in short: use new when you're immediately handing off the effect to a function as a raw pointer, and use MakeEffectContext when you need to keep it alive.

Reading from the context

CauseDamage receives the context that was packed in the previous step. An effect spec handle for the damage gameplay effect is created, and we then create a variable for our custom context and cast to it. We then set the variables on that damage effect context to be the variables that were packed into the context we passed in when calling this function. From this point, anything downstream such as an ExecCalc or a gameplay cue can cast to the context and read those values.

You may be wondering why we are not just using the context we passed in directly, but we cannot do that because MakeOutgoingGameplayEffectSpec creates a new spec internally and allocates a fresh context with default values as part of that process. Since we can't just swap that context out, we copy the data from the context we passed in onto it manually, otherwise the spec would just use default values when applied.

void UDamageAbilityBase::CauseDamage(AActor* TargetActor, float ExplicitDamage, FComplyGameplayEffectContext* Context) const
{
    FGameplayEffectSpecHandle DamageSpecHandle = MakeOutgoingGameplayEffectSpec(DamageEffectClass, 1.f);
    UAbilitySystemBlueprintLibrary::AssignTagSetByCallerMagnitude(DamageSpecHandle, DamageType, ExplicitDamage);

    FComplyGameplayEffectContext* EffectContext = static_cast<FComplyGameplayEffectContext*>(
        DamageSpecHandle.Data->GetContext().Get());

    if (EffectContext && Context)
    {
        EffectContext->bHitThroughShield = Context->bHitThroughShield;
        EffectContext->ShieldDamageMultiplier = Context->ShieldDamageMultiplier;
    }

    GetAbilitySystemComponentFromActorInfo()->ApplyGameplayEffectSpecToTarget(
        *DamageSpecHandle.Data.Get(),
        UAbilitySystemBlueprintLibrary::GetAbilitySystemComponent(TargetActor));
}

Conclusion

Custom gameplay effect contexts are a powerful and scalable way to carry specific information that the default context doesn't support. Once it's set up, extending it with new fields is easy. You just add the variable, add a bit to the bitmask, and serialize it. For any GAS project beyond the basics, a custom context is worth having from the start.

If you have any questions or feedback, feel free to contact me on LinkedIn, or email me: petric.marko04@gmail.com

GAS Input Tags: Ability Activation Without Hardcoded Bindings

Marko Petrić — Sun, 24 May 2026 18:22:05 +0000

What are input tags in GAS and why you should use them

Input tags are one way of activating gameplay abilities in GAS. They allow you to easily tie any gameplay ability's activation input to a specific gameplay tag, instead of hardcoding bindings. If you're new to gameplay tags, my earlier post covers them.

Input tags also let you rebind or assign abilities at runtime without touching input code.

How to add an input tag to an ability

The way input tags are added to abilities is by accessing that ability's spec, and adding your input tag to its dynamic spec source tags, which are just an FGameplayTagContainer . They are carried over with that ability's spec, and can always be accessed if you have that spec.

In my case, for adding input tags, I have an FAbilitySet struct which lets me choose to add an input tag to any abilities I give, and lets me access the relevant spec more easily. I give these abilities with their relevant input tags when the game starts, but you can choose to add them in many places and at runtime. The tag you give can be either an editor or native gameplay tag, and you are not required to use a struct.

// Maps abilities to input tags
USTRUCT()
struct FAbilitySet
{
    GENERATED_BODY()

    UPROPERTY(EditDefaultsOnly)
    TSubclassOf<UGameplayAbility> AbilityClass;

    UPROPERTY(EditDefaultsOnly)
    FGameplayTag InputTag;
};

for (const FAbilitySet& Set : StartupAbilities)
{
    FGameplayAbilitySpec AbilitySpec(Set.AbilityClass);
    AbilitySpec.GetDynamicSpecSourceTags().AddTag(Set.InputTag);
    GetAbilitySystemComponent()->GiveAbility(AbilitySpec);
}

How to activate an ability using an input tag

Now that your ability has an input tag given to its dynamic spec source tags, you can check for it when using input.

To check for it, in your input function, you can access the ability's spec, then use GetDynamicSpecSourceTags on that spec, and check if it has the specific tag(s) you choose to pass in. In my case, I'm checking for the input tag for primary actions.

void AComplyPlayerCharacter::PrimaryActionPressed()
{
    for (FGameplayAbilitySpec& Spec : GetAbilitySystemComponent()->GetActivatableAbilities())
    {

        if (Spec.GetDynamicSpecSourceTags().HasTagExact(
        ComplyTags::ComplyAbilities::InputTags::Input_Primary))
        {
            GetAbilitySystemComponent()->TryActivateAbility(Spec.Handle);
        }
    }
}

So in the above example, when pressing the primary input, we loop over all activatable abilities on the AbilitySystemComponent, and if an activatable ability has the Input_Primary input tag, it will be activated.

Conclusion

Input tags in GAS are a simple but highly useful and extendable system for handling input for activating abilities. What I've shown is just the basic template, but it's enough to set you up for creating your own advanced input system with things like holding input to activate abilities, or multi-tag checks.

If you have any questions or feedback, feel free to contact me on LinkedIn, or email me: petric.marko04@gmail.com

How to Deal Damage in Unreal's GAS: Meta Attribute and Execution Calculation Pattern

Marko Petrić — Mon, 11 May 2026 15:38:00 +0000

What are meta attributes and how to use them

Most commonly, and in this example, a meta attribute will be used for damage. Meta attributes are placeholder attributes that act as intermediaries on which we perform all the necessary calculations before damage is actually applied. For projects that have more complex damage handling in which certain calculations should be performed before damage is applied (armor, buffs, resistances etc.), a meta attribute is a good choice. Meta attributes are also useful because they separate concerns between the damage dealer and the target, as the damage dealer doesn't need to know how the target handles its damage. Meta attributes are typically not replicated.

Making a meta attribute

To make a damage meta attribute, you can make a regular attribute in your attribute set, which won't be replicated as damage should only be handled on the server, so there's no need for a GetLifetimeReplicatedProps entry or an OnRep.

UPROPERTY(BlueprintReadOnly, Category = "Meta Attributes")
FGameplayAttributeData IncomingDamage;

ATTRIBUTE_ACCESSORS(ThisClass, IncomingDamage)

Using a meta attribute

To use the meta attribute, in PostGameplayEffectExecute, we can store the value of this meta attribute in a local variable to use it later, and immediately zero out the attribute so that any new damage starts at 0 instead of adding to previous values. Now, we can have a check for if the damage is above 0, in which case we can subtract from our health attribute with it, and then set the health to the result of that subtraction while clamping. Optionally, you can now also check if health is at or below 0.

if (Data.EvaluatedData.Attribute == GetIncomingDamageAttribute())
{
    const float LocalIncomingDamage = GetIncomingDamage();
    SetIncomingDamage(0.f);
    if (LocalIncomingDamage > 0.f)
    {
        const float NewHealth = GetHealth() - LocalIncomingDamage;
        SetHealth(FMath::Clamp(NewHealth, 0.f, GetMaxHealth()));

        const bool bFatal = NewHealth <= 0.f;
    }
}

The meta attribute is now ready to be used in ExecCalcs. The value that the ExecCalc outputs will be used here.

What are execution calculations and how to use them

Execution calculations (commonly abbreviated as ExecCalc) are the most powerful and custom way to modify gameplay effects, such as the gameplay effect we will use to apply damage in this case. As opposed to magnitude calculation classes (MMC) which can only change one attribute, ExecCalcs are capable of changing multiple attributes.

There are some important caveats to using ExecCalcs:

They don't support prediction
They can only be used for instant and periodic gameplay effects (no infinite gameplay effects, but duration effects with periods can be used)
Capturing attributes doesn't run PreAttributeChange, so any clamping must be done again
They are only executed on the server from gameplay abilities with local predicted, server initiated, and server only net execution policies

Snapshotting is another feature of ExecCalcs, and it captures the attribute value when the gameplay effect spec is created. Otherwise, when not snapshotting, attribute values are captured when the gameplay effect is applied. From the target, the values are always captured on effect application only - snapshotting only applies to the source. In other words, should an ability's damage be locked when the ability is activated or read when it hits the target it should apply damage to? This difference matters when you have something like buffs that can expire in between.

Execution calculations are also capable of taking in set by caller magnitudes and using them in calculations, and they also supports calculation modifiers.

The execution calculation class is created by inheriting from the UGameplayEffectExecutionCalculation class, and is assigned in the Executions section of your gameplay effect.

Using an execution calculation class

The main function of ExecCalcs is the public Execute_Implementation.

virtual void Execute_Implementation(
const FGameplayEffectCustomExecutionParameters& ExecutionParams, 
FGameplayEffectCustomExecutionOutput& OutExecutionOutput) const override;

This function's first parameter is a const reference for execution parameters of the gameplay effect that's being applied, and the second parameter is a reference to the output of those same parameters, which is how this function modifies attributes (which will be seen later). The ExecutionParams can be used to access different kinds of information, for example:

const UAbilitySystemComponent* SourceASC = ExecutionParams.GetSourceAbilitySystemComponent();
const UAbilitySystemComponent* TargetASC = ExecutionParams.GetTargetAbilitySystemComponent();

AActor* SourceAvatar = SourceASC ? SourceASC->GetAvatarActor() : nullptr;
AActor* TargetAvatar = TargetASC ? TargetASC->GetAvatarActor() : nullptr;
const FGameplayEffectSpec& Spec = ExecutionParams.GetOwningSpec();

Note: In this post I won't cover capturing attributes or using their values in calculations. Instead I'll use a set by caller magnitude and feed its value directly into the damage meta attribute, just enough to show the ExecCalc → meta attribute pipeline clearly. I'll cover attribute capturing as a follow-up post.

Passing in a set by caller magnitude to the damage gameplay effect

The way you handle applying the damage effect with your set by caller magnitude will depend heavily on how your code is set up. In my case, I have a function that all gameplay abilities that deal damage will have due to inheritance, which simply just makes the effect spec, gets that ability's damage (based on level), then assigns the set by caller magnitude with a damage type tag, and applies the gameplay effect to the target actor.

// DamageEffectClass is a TSubclassOf of the damage gameplay effect
FGameplayEffectSpecHandle DamageSpecHandle = MakeOutgoingGameplayEffectSpec(
DamageEffectClass, 1.f);

// The magnitude in my case is an FScalableFloat damage based on that ability's level. 
// You can also just use regular floats here.
const float ScaledDamage = Damage.GetValueAtLevel(GetAbilityLevel());

// DamageType is a FGameplayTag variable for damage types set in the blueprints of my damage abilities, you can pass in any tag you want 
UAbilitySystemBlueprintLibrary::AssignTagSetByCallerMagnitude(
DamageSpecHandle, DamageType, ScaledDamage);

GetAbilitySystemComponentFromActorInfo()->ApplyGameplayEffectSpecToTarget(
*DamageSpecHandle.Data.Get(), 
UAbilitySystemBlueprintLibrary::GetAbilitySystemComponent(TargetActor));

Getting set by caller magnitude values in the execution calculation and modifying attributes

Now that we pass in a set by caller magnitude to the gameplay effect that has the execution calculation set, we can get that magnitude, and in this case, just add that magnitude to our IncomingDamage meta attribute.

To do this, we first need to get the gameplay effect's spec (the one that has the ExecCalc set). Then, we can store that damage by creating a local variable and getting the set by caller magnitude with our tag that we passed in when applying it. The last step is to create a const FGameplayModifierEvaluatedData struct, which when initializing requires the attribute you want to modify (our meta attribute in this case), in what way you want to modify it, and the variable to modify it with. After the struct is initialized, you can call AddOutputModifier on the OutExecutionOutput , and pass in our initialized struct.

void UExecCalc_Damage::Execute_Implementation(const FGameplayEffectCustomExecutionParameters& ExecutionParams,                                           FGameplayEffectCustomExecutionOutput& OutExecutionOutput) const
{
    const FGameplayEffectSpec& Spec = ExecutionParams.GetOwningSpec();

    // Here I check my custom damage type tag to see if it was used to apply the set by caller magnitude
    float Damage = Spec.GetSetByCallerMagnitude(ComplyTags::DamageTypes::Damage_Physical);

    const FGameplayModifierEvaluatedData EvaluatedData(
    UComplyAttributeSet::GetIncomingDamageAttribute(), 
    EGameplayModOp::Additive, Damage);
    OutExecutionOutput.AddOutputModifier(EvaluatedData);
}

After the ExecCalc modifies the attribute, PostGameplayEffectExecute will get called, and it will see our meta attribute was modified. It also handles clamping so we don't have to worry about caveat 3.

Conclusion

The meta attribute and execution pipeline is a great way to handle damage in games that require more complex setup. Now that the core system is in place, my follow-up posts will get into capturing attributes and using those values in the calculation.

If you have any questions or feedback, feel free to contact me on LinkedIn, or email me: petric.marko04@gmail.com

Native Gameplay Tags in GAS

Marko Petrić — Sat, 09 May 2026 12:09:26 +0000

What are gameplay tags and why should you use them

Gameplay tags are essentially FName wrappers, meaning they have a small upfront cost when first created but are very cheap to access and compare after that.

Gameplay tags are used as a clean way to handle things like character and actor state, input and ability activation, damage types and resistances, and communication between systems. GAS also has built-in tag requirements for gameplay abilities. Essentially, wherever you'd traditionally use booleans or enums, gameplay tags are generally the better choice when working with GAS.

What are native gameplay tags and why should you use them

Native gameplay tags are tags created in C++, rather than in the editor.

The main reasons for creating native gameplay tags rather than using editor ones is for type safety (autocomplete, no typo risk), which makes native ones safer, faster and easier to access through code.

Note: Any gameplay tag changes made in blueprint reflect to C++ code and vice versa. The Ability System Component does not care about the source of changes.

Storing tags

Before creating native tags, you need a place to store them. A simple way would be to manually create empty .h and .cpp files. For context, my project is called Comply, and I will be using that prefix for my tags, so my files will be named ComplyTags.

After creating these files, you need to use #pragma once at the top of the .h file, and to include CoreMinimal.h and NativeGameplayTags.h.

#pragma once

#include "CoreMinimal.h"
#include "NativeGameplayTags.h"

One way of storing tags, which lets you access specific tags cleanly, is to use namespaces. After creating a base namespace, each other namespace should be named based on the kind of tags it will store - so, for example, you could have a namespace called States for all state related gameplay tags, or Abilities for all ability asset tags. It's also possible to have namespace hierarchies.

This is just one way of storing them, but you can try any approach and see what you'd prefer. In this practical example, namespaces will be used.

Declaring tags

To declare tags, you use the UE_DECLARE_GAMEPLAY_TAG_EXTERN macro, and pass in the name of the tag you wish to use, as shown below:

namespace ComplyTags
{
    namespace ComplyAbilities
    {
        UE_DECLARE_GAMEPLAY_TAG_EXTERN(Primary_Ranger);
        UE_DECLARE_GAMEPLAY_TAG_EXTERN(Utility_Ranger);
    }
}

Defining tags

After declaration, tags need to be defined, and this is handled in the .cpp file for your tags. First, you need to include the .h file for the tags here, which in my case is ComplyTags.h.

#include "AbilitySystem/ComplyTags.h"

In the .cpp file, you need to make sure your namespace names and hierarchies match with the structure created in the .h file.

To define the tags, you use the UE_DEFINE_GAMEPLAY_TAG, and optionally UE_DEFINE_GAMEPLAY_TAG_COMMENT which unlocks a third parameter that lets you add a comment for your tag that can be seen in the editor. For this macro, the first parameter is the tag name (the same one you passed in when declaring the tag), then the tag hierarchy (which is how the tag can be accessed in the editor), and then, optionally, the comment.

namespace ComplyTags
{
    namespace ComplyAbilities
    {
        UE_DEFINE_GAMEPLAY_TAG_COMMENT(Primary_Ranger, "ComplyTags.Abilities.Ranger.Primary", "Primary ability asset tag for ranger")
        UE_DEFINE_GAMEPLAY_TAG_COMMENT(Utility_Ranger, "ComplyTags.Abilities.Ranger.Utility", "Utility ability asset tag for ranger")
    }
}

Accessing and using native tags

In the editor

Any tags created natively appear in the gameplay tag list found in Project Settings, even among any tags you may choose to create in the editor.

They can be assigned in the editor for all purposes.

In C++

Using native gameplay tags in C++ is where they really prove their worth over ones created in blueprint. When accessing gameplay tags created in the blueprint through C++, you would often have to use FGameplayTag::RequestGameplayTag(FName("Tag.Hierarchy")); which is prone to typos and has a slight overhead.

For accessing native ones in code, you just have to include the .h of where you store your native gameplay tags, which in my case is ComplyTags.h, wherever you need to access them. Then, you type in the name of the base namespace, and use double colons to navigate to different namespaces and to a specific tag.

Examples of using native gameplay tags in code:

// Checking if an actor has a certain tag
FGameplayTagContainer Tags;
Character->GetAbilitySystemComponent()->GetOwnedGameplayTags(Tags);

if (Tags.HasTagExact(ComplyTags::States::State_Aiming)
{
    PlayMontageAndBindDelegates(AbilityActivationMontageIronsights);
}

// Using a native gameplay tag to pass in a set by caller data tag
FGameplayEffectContextHandle ReserveAmmoContextHandle = GetAbilitySystemComponentFromActorInfo()->MakeEffectContext();

FGameplayEffectSpecHandle ReserveAmmoSpecHandle = GetAbilitySystemComponentFromActorInfo()->MakeOutgoingSpec(
ActiveWeapon->ReduceReserveAmmoEffectClass, 1.f, ReserveAmmoContextHandle);

UAbilitySystemBlueprintLibrary::AssignTagSetByCallerMagnitude(
ReserveAmmoSpecHandle, ComplyTags::SetByCaller::SBC_ReduceRifleReserveAmmo,-AmmoSpent);

GetAbilitySystemComponentFromActorInfo()->ApplyGameplayEffectSpecToSelf(
*ReserveAmmoSpecHandle.Data.Get());

// Registering a gameplay tag event by passing in a native tag
GetAbilitySystemComponent()->RegisterGameplayTagEvent(
ComplyTags::States::State_Aiming,EGameplayTagEventType::NewOrRemoved).AddUObject(
this, &AComplyPlayerCharacter::OnAimingTagChanged);

When you would prefer editor-created tags

Native gameplay tags make sense when you are accessing them frequently in code, but editor tags are fine for quick one-off logic, for designers, or for quick prototyping.

Conclusion

Although not required, native gameplay tags are a great alternative to editor-created tags for a multitude of reasons, and I would recommend everyone to try using them.

If you have any questions or feedback, feel free to contact me on LinkedIn, or email me: petric.marko04@gmail.com