Forem: Marko Petrić

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