5.7 GAS UpdateExplictTags Warning Behavior Changed

Development Programming & Scripting
, ,
1

UE 5.7 seems to have significantly changed the internals of FGameplayTagCountContainer::UpdateExplicitTags and one of the internal warning behaviors is different. I’m curious to know if that change is intentional or if it’s a bug.

In earlier versions of the engine, the warning snippet looked like this:

const bool bTagAlreadyExplicitlyExists = ExplicitTags.HasTagExact(Tag);

// Need special case handling to maintain the explicit tag list correctly, adding the tag to the list if it didn't previously exist and a
// positive delta comes in, and removing it from the list if it did exist and a negative delta comes in.
if (!bTagAlreadyExplicitlyExists)
{
    // Brand new tag with a positive delta needs to be explicitly added
    if (CountDelta > 0)
    {
       ExplicitTags.AddTag(Tag);
    }
    // Block attempted reduction of non-explicit tags, as they were never truly added to the container directly
    else
    {
       // only warn about tags that are in the container but will not be removed because they aren't explicitly in the container
       if (ExplicitTags.HasTag(Tag))
       {
          ABILITY_LOG(Warning, TEXT("Attempted to remove tag: %s from tag count container, but it is not explicitly in the container!"), *Tag.ToString());
       }
       return false;
    }
}

Notably, the warning only fires if the tag removal fails because the tag is in the container but not explicitly so.

In 5.7 it looks like this:

int32 TagCountIndex = Items.Find(Tag);

if (TagCountIndex != INDEX_NONE)
{
    ...
}
else if (CountDelta > 0)
{
    Items.Add(FGameplayTagCountItem(Tag, CountDelta, TagRepState));
    ExplicitTags.AddTag(Tag);
}
else
{
    ABILITY_LOG(Warning, TEXT("Attempted to remove tag: %s from tag count container, but it is not explicitly in the container!"), *Tag.ToString());
    return false;
}

In this case, the warning fires if the removal fails even for the case where the tag is not in either the items list or the ExplicitTags container.

I’d like to make sure my project is not firing superfluous warnings - should I be validating that the tag exists before attempting a no-op RemoveLooseGameplayTag call or should I just put back the original check that was wrapping the warning under the assumption that Epic will do so too?

2

Steps to Reproduce

  1. Call RemoveLooseGameplayTag on an ability system with a tag that has never been added to the ability system.
3

The log here was changed intentionally, but it’s probably a bit aggressive. Since the container now supports replication and replication state promotion we wanted to make sure that blanket removal wasn’t causing issues with state replication. There is a slight performance benefit by checking if the tag exists first, but it’s negligible unless you’re doing a lot of them per frame. The client side log is likely redundant and may be removed in the future, for now we’re changing this to a verbose log.

4

Perfect, thanks!