Skip to content

Get All Actors with Interface / Get All Actors with Tag

At a glance

Lives in: Blueprint API / Actor; implemented by Gameplay Statics - Returns: an array of Actor references, possibly empty - Fails by: returning an empty array; no failure pin - Cost: world scan, slow if repeated over and over - Official docs: Get All Actors with Interface, Get All Actors with Tag, Gameplay Tags, and Blueprint Interfaces

The one-minute version

  • Both nodes scan the current world and return every actor that matches the requested condition.
  • Get All Actors with Interface finds actors whose class implements a Blueprint Interface.
  • Get All Actors with Tag finds actors with a matching plain Actor Tag in the actor's Tags array.
  • The returned array can be empty. Empty input also produces an empty result.
  • The returned elements are typed as Actor; cast, interface-message, or validate each element before using project-specific variables.
  • Do not put these on Tick. Use them for setup, debug, editor-like tools, or small worlds. For gameplay, prefer stored references, overlap events, dispatchers, or a manager registry.

What they actually do

The scan shape is simple:

pseudocode of the engine behavior - not engine source

function GetAllActorsWithInterface(InterfaceClass):
    Results = []
    if InterfaceClass is None:
        return Results

    for Actor in every actor in the current world:
        if Actor implements InterfaceClass:
            Results.add(Actor)

    return Results

function GetAllActorsWithTag(Tag):
    Results = []
    if Tag is None/empty:
        return Results

    for Actor in every actor in the current world:
        if Actor.Tags contains Tag:
            Results.add(Actor)

    return Results

That means the nodes answer "who exists right now in this world and matches?" They do not listen for future actors, cache the result, or prove the actor is still valid later.

When they fail (and what failure does)

Failure is an empty array.

Common causes:

  1. No actor currently matches. The actor is not spawned yet, is in an unloaded streamed level, or was destroyed.
  2. The input is empty. No interface class or no tag name means no useful search.
  3. The tag type is wrong. Actor Tags are plain Name entries on the Actor. Component Tags live on components. Gameplay Tags live in Gameplay Tag containers. These nodes do not search all three systems.
  4. The interface is on a component, not the actor. The node checks actors that implement the interface, not every component attached to those actors.
  5. The result order is not a design contract. Do not assume index 0 is the closest, newest, or most important actor.
  6. Multiplayer relevance hides actors. A client can only find actors that exist on that client. Server and client result arrays can differ.
  7. The scan is repeated too often. Searching every actor every frame gets expensive as the world grows.

The nodes do not log a warning for "no matches." Always branch on Length > 0 or loop safely over the array.

The pattern everyone actually uses

For setup-time discovery:

BeginPlay in ObjectiveManager
-> Get All Actors with Interface(BPI_ObjectiveParticipant)
-> ForEach
-> Interface Message: Register With Manager

For tag-based level setup:

BeginPlay
-> Get All Actors with Tag("Checkpoint")
-> ForEach Actor
-> Cast To BP_Checkpoint or Interface Message
-> store sorted/checkpoint data in manager

For moment-to-moment gameplay, move to event-based references:

Enemy spawned
-> registers self with WaveManager

Enemy dies / EndPlay
-> unregisters self

WaveManager
-> uses stored array instead of scanning the world every Tick

The C++ twin, for the curious (our own example code):

void AObjectiveManager::FindParticipants()
{
    TArray<AActor*> Participants;
    UGameplayStatics::GetAllActorsWithInterface(
        this, UObjectiveParticipant::StaticClass(), Participants);

    for (AActor* Actor : Participants)
    {
        if (IsValid(Actor))
        {
            IObjectiveParticipant::Execute_RegisterWithManager(Actor, this);
        }
    }
}

Tags are not behavior

Plain Actor Tags are labels. They are useful for small filters like:

  • "Checkpoint"
  • "LootSpawn"
  • "PuzzleLever"
  • "PatrolPoint"

They are not a substitute for a behavior contract. If the code needs to call OpenDoor, GetPromptText, or TakeObjectiveCredit, use a Blueprint Interface or a typed reference. If the code needs rich classification such as damage types, item categories, or status tags, use Gameplay Tags.

Lookalikes - which one do I want?

Node / pattern Returns / changes Use when
Get All Actors with Interface Array of actors implementing an interface Setup needs every actor that promises the same contract.
Get All Actors with Tag Array of actors with a plain Actor Tag Setup/debug needs every actor marked with a simple label.
Get Actor Of Class / Get All Actors Of Class First/all actors of a class You need concrete class instances, not a contract/tag.
Component Tags Tags on components You are filtering mesh/collision/component parts.
Gameplay Tags Hierarchical tag containers Gameplay state/classification needs structured tags.
Overlap / trace events Current nearby or looked-at actor Gameplay should react to local contact or aim.
Manager registry Stored live references Many actors need repeated coordination without repeated world scans.

Rule of thumb: Scan once to discover the world; store or receive references for gameplay that repeats.

Going deeper