The difference only shows up once the hierarchy has more than one level, which happens as soon as someone creates a Blueprint child of a subsystem written in C++.

I covered the lifecycle contract and where each collection starts in a separate post: Subsystem and manager actor lifecycles. Here, I’m focusing on one specific part: the loop that picks the classes.

A subclass does not replace its parent

The collection gathers derived classes in a single call and runs every one of them through the same procedure (Engine/Private/Subsystems/SubsystemCollection.cpp:209):

TArray<UClass*> SubsystemClasses;
GetDerivedClasses(BaseType, SubsystemClasses, true);

for (UClass* SubsystemClass : SubsystemClasses)
{
    AddAndInitializeSubsystem(SubsystemClass);
}

There is no selection of the most-derived class here, no collapsing of the hierarchy, no rule that the child wins over the parent. The question is asked separately of each entry’s own CDO (SubsystemCollection.cpp:331):

const USubsystem* CDO = SubsystemClass->GetDefaultObject<USubsystem>();
if (CDO->ShouldCreateSubsystem(Outer))
{
    USubsystem* Subsystem = NewObject<USubsystem>(Outer, SubsystemClass);
    SubsystemMap.Add(SubsystemClass, Subsystem);
    // ...
}

The consequence is straightforward and easy to miss: a Blueprint child of a C++ class joins the parent as a second, independent instance. The base implementation returns true (Subsystem.h:61), so if nobody has overridden the method, two instances live in the collection. One of the C++ class, one of the Blueprint class. Both have run Initialize, both carry their own state, and neither knows about the other.

Two filters run before that question is asked. The first rejects abstract classes (:318), the second rejects non-authoritative ones (:324):

// Do not create instances of classes that aren't authoritative.
if (SubsystemClass->GetAuthoritativeClass() != SubsystemClass)
{
    return nullptr;
}

The second one says something about intent. GetAuthoritativeClass filters out the intermediate classes produced when Blueprints are recompiled, which means Epic hardened this path for Blueprint classes. A Blueprint subsystem is a scenario the engine anticipates.

The switch: false in C++, true in Blueprint

The question is asked separately of every CDO, and Blueprint defaults live on the CDO of their class. The same flag can therefore hold a different value at each level of the hierarchy, which turns it into a switch between implementation layers:

UCLASS(Blueprintable)
class MYGAME_API UMySubsystem : public UGameInstanceSubsystem
{
    GENERATED_BODY()

protected:
    /** Read from the CDO only - set to true in the Blueprint child that implements this. */
    UPROPERTY(EditDefaultsOnly, Category = "Config")
    bool bShouldCreateSubsystem = false;

    virtual bool ShouldCreateSubsystem(UObject* Outer) const override
    {
        return Super::ShouldCreateSubsystem(Outer) && bShouldCreateSubsystem;
    }
};

With false on the C++ side and true in the Blueprint class defaults, exactly one instance ends up in the collection. The C++ class becomes a skeleton: it defines the interface, the BlueprintImplementableEvent declarations, and everything Blueprint cannot declare on its own, while the implementation lives one level below.

This works because ShouldCreateSubsystem runs on the CDO before an instance exists, which means it runs on the object that holds the default values stored in the Blueprint asset. That is also why the flag is marked EditDefaultsOnly. The value is read from the defaults and nowhere else, so per-instance editing changes nothing.

GetSubsystem<T>() finds the child anyway

Instances live in a TMap<UClass*, USubsystem*> keyed by the concrete class. The natural conclusion is that querying for the base class will not find an instance of a derived one, and that conclusion is wrong. GetSubsystemInternal has a fallback (SubsystemCollection.cpp:66):

USubsystem* SystemPtr = SubsystemMap.FindRef(SubsystemClass);

if (SystemPtr)
{
    return SystemPtr;
}
else
{
    const FSubsystemArray& SystemPtrs = FindAndPopulateSubsystemArrayInternal(SubsystemClass);
    if (SystemPtrs.Subsystems.Num() > 0)
    {
        return SystemPtrs.Subsystems[0];
    }
}

A miss in the map triggers an IsChildOf sweep and returns the first hit. So GetSubsystem<UMySubsystem>() with the base class as the parameter returns the Blueprint child instance, even though nothing is stored under the base class key.

Without that fallback the switch would make no sense. Every piece of C++ that queries the subsystem by its own base class would stop seeing it the moment the implementation moved into Blueprint.

Listing every instance at once takes a separate accessor. In 5.7 it is called GetSubsystemArrayCopy and returns by value, both on the collection itself (Public/Subsystems/SubsystemCollection.h:139) and on the UGameInstance wrapper (Classes/Engine/GameInstance.h:463).

The flagless variant: yielding to subclasses

The flag has one unpleasant property. When the Blueprint child is gone, whether it was deleted, moved, or simply never loaded in time, false on the C++ side means nothing is created. The subsystem disappears entirely, including the part that was written in C++ and had nothing to do with Blueprint.

The condition can be phrased differently: let the class step aside, provided there is someone to step aside for.

bool UMySubsystem::ShouldCreateSubsystem(UObject* Outer) const
{
    if (!Super::ShouldCreateSubsystem(Outer))
    {
        return false;
    }

    /// @Note: The collection instantiates every non-abstract subclass, so a Blueprint child
    ///        would live alongside this one. Yield so that only the most-derived class is created.
    TArray<UClass*> DerivedClasses;
    GetDerivedClasses(GetClass(), DerivedClasses, /*bRecursive*/ true);
    return DerivedClasses.Num() == 0;
}

In the normal case the outcome is the same, since a child exists and the parent steps aside. The failure looks different though: a missing child leaves a working C++ instance instead of an empty slot. There is also no flag to forget to set in a new Blueprint’s defaults.

I use this variant in a production subsystem, and I have tested it in PIE. With the Blueprint child present, exactly one instance is alive; with the child removed, the C++ instance is. I have not tested it in a packaged build, so that behavior remains an inference from the mechanism rather than an observed result.

There are two limits, and both follow directly from this implementation.

Two children mean two instances. Each of them sees zero descendants and each concludes that it is the most-derived one. This case cannot be resolved inside the method, which leaves a convention: exactly one Blueprint child per class.

A single permanently loaded C++ subclass disables the base class for good. A test class in an Editor module is enough. It is compiled, so it sits in memory from startup, so the parent yields to it in every editor session. In practice this means a test module must not derive from such a subsystem, and the test double has to be built on a plain UObject acting as a listener. This trap is worse than two Blueprint children, because nothing about it is visible in the assets. It lives in test code that nobody associates with runtime.

Common mistakes

The last of those cannot be reproduced in the editor. It only surfaces in a packaged build.

Verification

The number and classes of live instances, in one console command:

obj list class=MySubsystem

A query for the base class covers derived classes, so it shows the parent and the children at once, broken down by class. Two rows instead of one reveal the duplication described in the table above; a row for a _C class means the switch worked and the Blueprint implementation is the one running.

Each CDO decision is in the log once the category’s log level is raised:

-LogCmds="LogSubsystemCollection VeryVerbose"

LogSubsystemCollection: VeryVerbose: Subsystem does not exist, but CDO choose to not create (MySubsystem)

That line means the class was on the list and refused. Its absence, together with a missing instance, means something entirely different: the class was not on the list, so nobody asked it. Telling those two states apart is the only way to distinguish a working switch from a class that never loaded. At the default log level both of them look like silence, which is why the category’s log level has to be raised first.

The symptom: nothing to look for

No compile errors. No warnings. No lines in the log. GetSubsystem<T>() does not return nullptr either, because as long as the parent C++ class does not refuse to be created, an instance is created normally. What gets created is the parent. The Blueprint implementation that was supposed to replace it never runs, and the pointer looks perfectly valid.

There is a harsher variant, and it happens when the parent refuses on purpose. That is the case in the pattern where the C++ class returns false to make room for a Blueprint implementation. Then nothing is created at all: the parent refused, and nobody asked the child.

Two runs that settle it

The test project uses UE 5.7. It contains UMyTestSubsystem : UGameInstanceSubsystem, marked UCLASS(Blueprintable), which logs a single line in Initialize. It also contains a Blueprint child, BP_MyTestSubsystem, with a PrintString in its graph. The build is packaged in the Development configuration.

First run, with nothing in the project referencing the Blueprint class:

LogSubsystemCollection: Verbose: Initializing subsystem collection for BP_GameInstance_Test_C_2147482547 with type GameInstanceSubsystem
LogSubsystemCollection: VeryVerbose: Subsystem does not exist, but CDO choose to not create (MyTestSubsystem)

The parent made it onto the list and refused. The child is not on that list at all. There is no second choose to not create line, and no line from Initialize either, which the child inherits from C++ and would have run had it been created. Counting objects confirms this independently:

Obj List: class=MyTestSubsystem
Objects:

0 Objects (Total: 0.000M / Max: 0.000M / Res: 0.000M | ...)

Second run, after adding a single variable of type MyTestSubsystem Class Reference to the GameInstance class, with its default value pointing at the Blueprint child. The variable is never used anywhere. It exists for one reason: so that the asset holds a reference.

                    Class    Count
     BP_MyTestSubsystem_C        1

1 Objects

LogTemp: UMyTestSubsystem initialized.
LogBlueprintUserMessages: [None] PostInitialize(): Test Subsystem (BP_MyTestSubsystem)

The instance exists, it is of the Blueprint class, and both the inherited C++ Initialize method and the Blueprint graph ran. The only difference between the two runs is an unused variable.

Where it disappears: the scan happens once

FSubsystemCollectionBase::Initialize builds the class list in a single call, at the moment the collection is created (Engine/Private/Subsystems/SubsystemCollection.cpp:209):

TArray<UClass*> SubsystemClasses;
GetDerivedClasses(BaseType, SubsystemClasses, true);

for (UClass* SubsystemClass : SubsystemClasses)
{
    AddAndInitializeSubsystem(SubsystemClass);
}

GetDerivedClasses sweeps the class hierarchy in memory. A class that nobody has loaded exists only as a file on disk: the asset registry knows about it, the type system does not. Since it never lands in SubsystemClasses, AddAndInitializeSubsystem never receives it, and ShouldCreateSubsystem has nothing to run on. A class missing from the scan produces no CDO decision entry. A class that is found but refuses creation produces the CDO choose to not create line at VeryVerbose verbosity.

That loop is in fact the else branch. The first branch handles a completely different case (SubsystemCollection.cpp:194):

if (BaseType->IsChildOf(UDynamicSubsystem::StaticClass()))
{
    for (const TPair<FName, TArray<TSubclassOf<UDynamicSubsystem>>>& SubsystemClasses : GlobalDynamicSystemModuleMap)
    // ...
}
else
{
    // GetDerivedClasses, once
}

UDynamicSubsystem gets incremental registration. FSubsystemModuleWatcher listens for module loads and calls AddAllInstances for classes that have just appeared (SubsystemCollection.cpp:524). UGameInstanceSubsystem does not belong to that branch. For it, the scan runs once and nothing repeats it, so a class loaded one second after the collection is initialized is too late for that collection.

Why the editor can hide this

In the editor, the Content Browser keeps the Blueprint class in memory. Opening the asset once is enough, and so is having it sit in a visible folder. By the time PIE starts, the class is already loaded, GetDerivedClasses sees it, and everything behaves exactly as designed.

In a real project the packaged build usually works too, but for a different reason: the reference exists by accident. A Get Subsystem node with the Blueprint class selected embeds a hard reference in the Blueprint that calls it, and that Blueprint ships with the level or with the GameInstance class. A reference from a Blueprint hides the problem if that Blueprint loads the subsystem class before the collection is initialized.

That is the whole trap. The mechanism breaks in exactly the place nobody tests it: when the subsystem is called from C++ and nowhere else.

The fix

Anything that loads the class before the collection is initialized. The cheapest option, and the one that does not disappear when somebody rewires a graph, is a variable of type <Subsystem> Class Reference on an object that loads early, with its default value set to the Blueprint class. The GameInstance class is the natural place for the variable, because the GameInstance itself is created before its subsystem collection.

The variable does not have to be used for anything. What matters is that the GameInstance asset holds a hard reference to the Blueprint class, so loading one pulls in the other.

Getting the class loaded in time is the only real fix. How badly the failure hurts when nothing loads it is a separate question, and the answer depends on how the C++ class steps aside for the Blueprint. Overriding ShouldCreateSubsystem with a condition that checks for subclasses, rather than with a flag set in the Blueprint defaults, turns “zero instances” into “a C++ instance without the Blueprint logic”: a reduced system rather than a missing one. I wrote up the mechanism itself, and its limits, in ShouldCreateSubsystem and the subsystem class hierarchy.

Checking this in your own project

Check two things separately: whether the instance exists, and whether the log contains a CDO decision for that class. A missing instance together with a missing CDO decision points to loading as the source of the problem. Neither observation is enough on its own.

When this matters

As long as a Blueprint reference gets the class loaded in time, the trap stays asleep. The reference appears on its own and nobody finds out it was ever needed. I reproduced it in two setups: one where the subsystem serves C++ code only, and one where a Blueprint child was added to override a few default values and nothing called it afterwards.

A third setup follows from the mechanism, but I did not reproduce it. Removing the last Get Subsystem call from Blueprints during a refactor can remove the only reference to the class. If that happens, this is the worst of the three cases, because nothing obviously connects the regression to the commit that triggered it. A node disappears from one Blueprint, the subsystem stops existing in the packaged game, and everything still works in the editor.

What FTickableGameObject is

FTickableGameObject is a plain C++ class from Tickable.h that you inherit from alongside UObject. Its constructor adds this to a pending queue (Tickable.cpp:133-145), and the object only moves into the real array at the next tick pass (Tickable.cpp:67-95). The destructor removes it from that array (Tickable.cpp:147-152), and the engine walks the array once per frame (Tickable.cpp:167-208). This is a separate track running alongside the FTickFunction machinery that actors and components use. It is not part of it.

The upside is that the object does not have to be in a world, does not have to be spawned, and has no transform. The price is that it also gets none of what the other track gives actors: no tick groups, no AddTickPrerequisiteActor, no TickInterval. The entire class declaration (Tickable.h:134-210) does not contain a single one of them. You either give up all three or build them by hand.

For an object tied to a world, the call sits in UWorld::Tick (LevelTick.cpp:1792), after TG_PostPhysics (LevelTick.cpp:1749) but before TG_PostUpdateWork (LevelTick.cpp:1848). An actor ticking in TG_PostUpdateWork sees the state this tick has already produced. An object with no world lands somewhere else: it ticks only after the loop over all worlds. The engine says so outright in the comment on the method (Tickable.h:183), and the call itself sits in GameEngine.cpp:1947.

When to reach for this, and when not to

Does this have to be an actor? If the object needs a transform, collision, replication, placement in a level, or tick groups, the answer is “actor” and the rest of this post does not apply. None of those can be bolted onto FTickableGameObject.

Is the logic per-frame or event-driven? If it comes down to “in three seconds” or “every half second” and nothing in between, that is FTimerManager, not a tick. Polling state sixty times a second to respond once is a cost with no return.

Should the object live exactly as long as the world? If so, the right answer is almost always UTickableWorldSubsystem: a ready, tested lifecycle, without a single line of what I describe below. Your own base class earns its place when you need multiple instances (a subsystem is one instance per class per owner by definition), or when a designer is meant to create subclasses in Blueprint, which a subsystem cannot do.

Decision one: when you register

The default answer: in the constructor. Inheritance is enough. The base constructor runs on its own, the object lands in the registry, no extra code.

And that is exactly what you must not do. The constructor documentation says so outright:

If this is something like a UObject that could be created on a different thread (like for async loading), construct with a Never tick type and enable tick later.

— Tickable.h:147 (UE 5.7)

The base constructor in full:

// UE 5.7 — Tickable.cpp:133-145
FTickableGameObject::FTickableGameObject(ETickableTickType StartingTickType)
{
    if (StartingTickType != ETickableTickType::Never)
    {
        // It is only safe to create tickable game objects on the game thread, as otherwise there is a race condition between object initialize and the game thread tick
        // If you hit this ensure, change the constructor to use FTickableGameObject(ETickableTickType::Never) and call SetTickableTickType after initialization
        ensure(IsInGameThread());

        // Queue for creation, this can get called very early in startup
        FTickableStatics& Statics = GetStatics();
        Statics.QueueTickableObjectForAdd(this, StartingTickType);
    }
}

The base constructor runs before the body of the derived class constructor, before the archetype and Blueprint-class defaults are applied over the native ones, and before the owner has a chance to configure anything. Defaults are not applied until FObjectInitializer::PostConstructInit (UObjectGlobals.cpp:4239), the copy itself in UObjectGlobals.cpp:4350, and PostInitProperties runs later still (UObjectGlobals.cpp:4427) — all three after the C++ constructor chain. The next tick pass will call GetTickableTickType(), and then Tick(), on a half-configured object. On top of that, the CDO registers along with the instances, because the FTickableGameObject constructor does not check IsTemplate() or anything of the sort (Tickable.cpp:133-145).

The correct answer is to construct with an explicit “do not tick” and enable ticking later:

UTickableObject::UTickableObject()
    : FTickableGameObject(ETickableTickType::Never)
{
    // Deliberately empty. Registering for tick here is exactly what Tickable.h forbids.
}

Decision two: when you unregister

The default answer: in the destructor. And again it is too late. A UObject destructor runs long after the object stopped being useful, and in the meantime the engine is free to tick it.

The right place is an explicit method called by the owner, plus a hard gate in BeginDestroy() as the last line of defense. The tick queries themselves are gates too, each in its own place:

ETickableTickType UTickableObject::GetTickableTickType() const
{
    // Never for the CDO and before Initialize: the object stays out of the tickable
    // array entirely instead of sitting in it and being polled every frame.
    return (IsTemplate() || !bInitialized) ? ETickableTickType::Never : ETickableTickType::Conditional;
}

bool UTickableObject::IsTickable() const
{
    return bInitialized && bTickEnabled && CachedWorld.IsValid() && IsValidChecked(this);
}

The split between these two methods is deliberate. IsTemplate() belongs in GetTickableTickType, not in IsTickable: that way the CDO never enters the array at all, instead of sitting in it and answering “no” every frame. IsTickable is left for the conditions that genuinely change over the object’s lifetime.

// UE 5.7 — Tickable.cpp:59-63, indentation reduced (branch for an object not yet in the array)
else
{
    // Add to the pending list (which could override previous request), this will apply it next frame
    NewTickableObjects.Add(InTickable, NewTickType);
}

Decision three: which world you belong to

The default answer: none. Left unoverridden, GetTickableGameObjectWorld() returns nullptr (Tickable.h:187-190), and the object ticks in the global pass that follows all the worlds — knowing nothing about pause, nothing about PIE, nothing about the moment its world stops existing.

Overriding that method is cheap and handles all three at once:

UWorld* UTickableObject::GetTickableGameObjectWorld() const
{
    return CachedWorld.Get();
}

I resolve the world once, in Initialize(), and hold it in a TWeakObjectPtr<UWorld>. Plain GetWorld() is enough: the default UObject::GetWorld() implementation walks the Outer chain (Obj.cpp:1145-1150), so an object created with a sensible Outer finds its world with no help at all.

Here is the trap I ran into. Once the world is gone, CachedWorld.Get() starts returning nullptr. You would expect that to be the end of the tick. The opposite is true. The gate in the engine reads GetTickableGameObjectWorld() == World (Tickable.cpp:189), and TickObjects is also called with World == nullptr, precisely for objects with no world (GameEngine.cpp:1947). The comparison nullptr == nullptr passes. The object does not stop ticking. It quietly migrates from its own world’s tick to the global engine pass and keeps going.

The whole condition in the engine loop:

// UE 5.7 — Tickable.cpp:186-189 (indentation reduced)
// If it is tickable and in this world
if (TickableObject->IsAllowedToTick()
    && ((TickableEntry.TickType == ETickableTickType::Always) || TickableObject->IsTickable())
    && (TickableObject->GetTickableGameObjectWorld() == World))

Closing this takes two things at once: the CachedWorld.IsValid() condition in IsTickable(), and a subscription to world cleanup, so that the object shuts itself down instead of just no longer being polled.

void UTickableObject::HandleWorldCleanup(UWorld* World, bool bSessionEnded, bool bCleanupResources)
{
    if (World == CachedWorld.Get())
    {
        Shutdown();
    }
}

The delegate is FWorldDelegates::OnWorldCleanup, hooked up in Initialize() and removed in Shutdown(). Unregistering from inside your own broadcast is safe: Unreal’s multicast delegates defer compacting the list until the call finishes (MulticastDelegateBase.h:380-390).

Decision four: who cleans up

The default answer: nobody. A UObject with no UPROPERTY reference is collected at the next GC, and that is the correct behavior. It just has to be handled deliberately, instead of discovered halfway through a session when the object is already gone.

The reflex is AddToRoot(). That is not lifetime management; it is turning GC off for this object, with a manual RemoveFromRoot() as the only way out. The object survives a map change and everything else.

A sensible contract is simpler and puts both obligations on the owner: the object lives in a UPROPERTY(TObjectPtr<>), and Shutdown() runs before that reference is dropped.

So BeginDestroy() does exactly as much as it has to and not an ounce more: it removes the delegate (a plain Remove, no dispatch into Blueprint), kills the tick, and reports that the owner never called Shutdown().

void UTickableObject::BeginDestroy()
{
    FWorldDelegates::OnWorldCleanup.Remove(WorldCleanupHandle);
    WorldCleanupHandle.Reset();

    SetTickableTickType(ETickableTickType::Never);
    bTickEnabled = false;

    ensureAlwaysMsgf(!bInitialized,
        TEXT("%s: destroyed while still initialized - the owner never called Shutdown()."), *GetName());

    Super::BeginDestroy();
}

ensureAlwaysMsgf, not ensureMsgf: a plain ensure fires once per callsite per process. The bEnsureHasExecuted flag is keyed by a hash of __FILE__ and __LINE__, and the Always variant skips that filter (AssertionMacros.h:440-448). The first leaked object would silence the diagnostic for every one after it.

Epic does the same in UTickableWorldSubsystem::BeginDestroy (WorldSubsystem.cpp:154-159): it does not call Deinitialize from there — and now the reason is clear. Two differences from the listing above are deliberate: Epic leaves a plain ensureMsgf there (WorldSubsystem.cpp:158) and calls Super::BeginDestroy() first (WorldSubsystem.cpp:156).

The whole class

The complete implementation ships in StillCooking_Tools as USCTickableObject — a free, MIT-licensed plugin distributed as C++ source (GitHub), module StillCookingCore, header Objects/SCTickableObject.h. It is the class from this post, developed further: on top of the four decisions above it adds an explicit tick intent that Initialize() applies, the bTickWhenPaused and bTickInEditor gates, and a protected engine-facing interface with IsTickable() marked final.

• Reference: USCTickableObject — functions, properties, events and the messages it logs.
• Lifecycle — the ownership contract and what happens when the owner forgets Shutdown().

Checklist

Five things to check in your own class:

1. The constructor calls FTickableGameObject(ETickableTickType::Never) and does nothing else tick-related.
2. GetTickableTickType() returns Never for IsTemplate() and for the pre-initialization state, so the CDO never enters the array.
3. GetTickableGameObjectWorld() returns a real world, and IsTickable() checks whether that world is still alive.
4. There is an explicit shutdown method called by the owner, plus a world-cleanup subscription for the case where the world goes first.
5. BeginDestroy() kills the tick and reports the problem, but does not run subclass teardown.

The cause is not a race condition. A dispatcher broadcast is a synchronous loop over an array: one thread, one frame, the same result every time. The call order of the bindings is deterministic, and relying on it is legitimate, provided you know where that order comes from and what changes it. It comes from the lifecycle phase in which each Bind Event to… node ran.

The test setup

UE 5.7, pure Blueprint, two separate Blueprints. BP_GameInstance_Test owns both dispatchers and CustomEvent_1, which is bound in Init:

The actor BP_DispatcherTest binds to the same OnDelegate_1 in BeginPlay, and its handler is what creates the binding on OnDelegate_2:

A key press in the Level Blueprint fires the broadcast. After calling OnDelegate_1, the graph logs [END TEST]. That marker marks the end of the synchronous execution triggered by the key press, and it makes the log comparisons further down readable:

One key press, and the Output Log shows:

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [END TEST]

[3] never appears. A breakpoint on CustomEvent_3 is never hit. There is no compile error, no red node, and no warning. From the engine’s point of view nothing went wrong: the dispatcher called everything that was registered at the moment of the call, and CustomEvent_3 was not registered then.

This is not a race condition

The symptom suggests a race condition: the binding and the broadcast are competing, and the broadcast wins. That explanation is false and sends the diagnosis in the wrong direction.

Nothing here is racing anything. When CustomEvent_1 broadcasts OnDelegate_2, CustomEvent_2 has not started running yet. Not because it was too slow, but because it comes later in program order. Run the same project a hundred times and it behaves identically a hundred times.

The distinction has practical consequences. A race condition is something you look for in timing and try to fix with a delay added just in case. A delay does work here, but not for the reason that hypothesis suggests: it doesn’t give another thread time to catch up, it moves the OnDelegate_2 broadcast past the end of the entire OnDelegate_1 handler list. It is worth knowing which of the two you are buying.

Proving the order is deterministic

The setup above shows where the invisible order comes from, but it mixes two variables at once. One Blueprint is enough to isolate it: all three custom events on BP_GameInstance_Test, both bindings to OnDelegate_1 on a single exec wire in Init, no actor and no BeginPlay.

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [END TEST]

Now the only change in the entire project: the exec wire between the two Bind Event to OnDelegate_1 nodes is swapped. The nodes, the events, their contents, and the Level Blueprint stay untouched.

LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [3]
LogBlueprintUserMessages: [END TEST]

CustomEvent_2 ran first, bound CustomEvent_3 to OnDelegate_2, and only then did CustomEvent_1 broadcast that dispatcher. Reordering two nodes on an exec wire changed the result predictably and repeatably. The result follows directly from the order of execution: in one arrangement, registration happens after the broadcast; in the other, it happens before it.

Where the order comes from

A Blueprint dispatcher is an FMulticastScriptDelegate, and its broadcast lives in ScriptDelegates.h:917 (5.7):

if( InvocationList.Num() > 0 )
{
    // Create a copy of the invocation list, just in case the list is modified by one of the callbacks during the broadcast
    typedef TArray< UnicastDelegateType, TInlineAllocator< 4 > > FInlineInvocationList;
    FInlineInvocationList InvocationListCopy = FInlineInvocationList(InvocationList);

    // Invoke each bound function
    for( typename FInlineInvocationList::TConstIterator FunctionIt( InvocationListCopy ); FunctionIt; ++FunctionIt )
    {
        if( FunctionIt->IsBound() )
        {
            FunctionIt->template ProcessDelegate<UObjectTemplate>(Parameters);
        }
    }
}

TConstIterator runs front to back, and new bindings are appended to the end of the array. Hence the rule: in a Blueprint dispatcher, first bound is first called.

That leaves the question of why CustomEvent_1 runs first. Not the graph: neither of the two Blueprints contains a node that sets the call order. The lifecycle decides. UGameInstance::Init (Private/GameInstance.cpp:129) runs before the map is loaded, and therefore before BeginPlay on any actor in the world. The world startup timeline is laid out separately in Subsystem and manager actor lifecycles.

Same name, opposite order

The C++ equivalent iterates the other way, with a comment that says why (MulticastDelegateBase.h:292-293):

// call bound functions in reverse order, so we ignore any instances that may be added by callees
for (int32 InvocationListIndex = LocalInvocationList.Num() - 1; InvocationListIndex >= 0; --InvocationListIndex)

So one name, “multicast delegate,” covers two implementations with opposite iteration order. The order a graph relies on is a property of the specific implementation, not of the concept.

Same symptom, different cause

The comment above the copy, “just in case the list is modified by one of the callbacks during the broadcast,” describes a different case with an identical symptom. The copy means that a binding added to a dispatcher that is currently broadcasting will not be called in that broadcast. If CustomEvent_2 bound CustomEvent_3 to OnDelegate_1, the same dispatcher that is calling it right now, CustomEvent_3 would stay silent as well. The cause would be the frozen copy taken before the first handler, not the registration order.

What the order does not guarantee

Moving a binding earlier in the lifecycle fixes the symptom, and it is a legitimate move. It is worth knowing what it assumes.

Epic does not promise this order. The multicast class documentation says so directly (DelegateSignatureImpl.inl:1024-1025):

Multicast delegates offer no guarantees for the calling order of bound functions. As bindings get added and removed over time, the calling order may change.

Removal from the list does not preserve order. RemoveInternal goes through RemoveAtSwap (ScriptDelegates.h:1069), so the last entry jumps into the freed index. The header warns about this on every removal method (ScriptDelegates.h:731, 771, 1045, 1056):

* Removes a function from this multi-cast delegate's invocation list (performance is O(N)).  Note that the
* order of the delegates may not be preserved!

The practical takeaway: the order is stable as long as nothing unbinds from the dispatcher. Unbinding from this dispatcher anywhere in the project can reorder its remaining listeners.

What to do about it

One pattern forces a decision: a dispatcher handler that broadcasts another dispatcher while it runs. It opens a window in which some listeners have not registered yet. Five ways out, each with its own condition. The first three change the graph and have results shown below. The last two are a project convention rather than a change in the nodes.

Defer the broadcast by one tick

Instead of broadcasting OnDelegate_2 straight from CustomEvent_1, route it through Set Timer for Next Tick by Event and a separate BroadcastDelegate2 event. The OnDelegate_1 broadcast then runs through every handler, each one gets to bind, and OnDelegate_2 starts with a complete list.

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [END TEST]
LogBlueprintUserMessages: [3]

[3] landing after the [END TEST] marker shows exactly what this solution does: the broadcast moved out of the synchronous execution triggered by the key press and into the next frame.

This applies when no OnDelegate_2 listener binds later than the next frame. An actor spawned two frames later, or a widget created on demand, still misses out. It widens the window; it does not remove the dependency.

Move the binding to a dispatcher that is guaranteed to fire later

CustomEvent_3 goes on OnDelegate_3, which is known to fire later. Here the same key press broadcasts it, right after OnDelegate_1.

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [3]
LogBlueprintUserMessages: [END TEST]

Cheap and effective, but it still depends on ordering: the order of separate broadcasts rather than the order of handlers within one broadcast. The condition is that nobody moves that call.

Turn the event into state

A dispatcher carries information only at the moment of the call. Whoever arrives late never gets it. A bDelegate2Broadcast bool on the sender side changes that rule: CustomEvent_1 sets it before the broadcast, and CustomEvent_2, once its binding is in place, checks it with a Branch and calls CustomEvent_3 directly if needed.

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [3]
LogBlueprintUserMessages: [END TEST]

[3] appears synchronously here, still within the same key press. The late listener does not wait for another broadcast. It reads the state and catches up immediately. This is the only option that survives a listener created after everything else, at the cost of maintaining extra state.

Declare the order instead of relying on it silently

If the order is meant to be a contract, write it down: a comment on both Bind Event to… nodes stating which one comes first and what depends on it, an event name that identifies the phase, and an explicit condition that nothing unbinds from this dispatcher. This option documents the existing ordering dependency without changing the graph.

Separate the phases: bindings in one, broadcasts in the next

If every Bind Event to… runs in a phase earlier than any call, the order within the list stops meaning anything. Here the dependency disappears instead of moving further out. The condition is that the phase boundary is clearly defined in the project and nobody binds after it.

When this matters

As long as every binding to a given dispatcher lives in one Blueprint, the problem barely exists. The order is visible at a glance, and nobody changes it by accident.

The risk shows up once listeners of the same dispatcher spread across different lifecycle phases: GameInstance, a subsystem, GameMode, an actor placed in the level, a spawned actor, a widget created on demand. Call order stops being a property of the graph and becomes a property of the whole project: it is set by the phases in which all the Bind Event to… nodes attached to that dispatcher run. Move one of them to a different phase and the rest shift position in the list.

A subsystem derives from one of five base classes. Each subsystem type is associated with a different owner and inherits that owner’s lifetime: UEngineSubsystem, UEditorSubsystem, UGameInstanceSubsystem, UWorldSubsystem (plus UTickableWorldSubsystem), or ULocalPlayerSubsystem (Runtime/Engine/Public/Subsystems/Subsystem.h:12-20). Everything below comes from reading the UE 5.8 source.

Choosing the base class is how you declare the subsystem’s lifetime. Everything else happens automatically.

All five follow the same contract: ShouldCreateSubsystem(UObject* Outer) → Initialize → Deinitialize. The first call is the exception. It runs on the CDO before an instance even exists, as the header states explicitly: “Note: This function is called on the CDO prior to instances being created!” (Subsystem.h:49-56).

Under the hood, the collection gathers every non-abstract derived class through GetDerivedClasses(BaseType, …, true) and asks each CDO whether that subsystem should be created (Private/Subsystems/SubsystemCollection.cpp:256,373-391). It stores the resulting instances in a TMap<UClass*, USubsystem*> (Public/Subsystems/SubsystemCollection.h:116-143). One instance per class per Outer isn’t a convention; it follows from the container type. The key is a concrete class, not a hierarchy. If another non-abstract class derives from that base class — a Blueprint child, for instance — its CDO gets asked the same question separately, and the collection ends up holding two independent instances. How this affects which class provides the implementation is covered separately in ShouldCreateSubsystem and the subsystem class hierarchy.

Where each collection starts

The first two rows are the easiest to get wrong. UEditorSubsystem and UEngineSubsystem derive from UDynamicSubsystem, which automatically populates the collection when a module loads and empties it when that module unloads. Your subsystem won’t exist until its module is explicitly loaded, and the engine won’t report an error if it isn’t.

The world startup timeline

By the time this timeline begins, the Engine and GameInstance collections have already been initialized. UEngine::Init runs during process startup, and UGameInstance::Init runs before the map load that creates the gameplay world.

The relevant points in the timeline are all in Runtime/Engine/Private/World.cpp:

1. UWorld::InitWorld() calls InitializeSubsystems (:2447) and, near the end, PostInitializeSubsystems (:2610). World subsystems receive both Initialize and PostInitialize.
2. UWorld::InitializeActorsForPlay() runs (:5946). Only then does the engine start handling actors placed in the level.
3. UWorld::BeginPlay() calls OnWorldBeginPlay on every World subsystem and then calls AGameModeBase::StartPlay() (:6165-6179).

The third point gives us a guarantee that no actor can provide: a World subsystem has been initialized and has already run OnWorldBeginPlay before GameMode starts gameplay. An actor placed in the level receives its BeginPlay during InitializeActorsForPlay/StartPlay, which puts it after the subsystems. That last part is my interpretation of the call order, not a guarantee stated on any single line of engine code, but it follows directly from that order.

An actor spawned during play is a different case. Its BeginPlay fires immediately after it is spawned, so the startup-order question doesn’t apply.

A manager actor comes close to providing the same guarantee, but only when three conditions are met: it derives from AInfo (or explicitly sets bIsSpatiallyLoaded = false), lives in the persistent level, and has no dependency on a streamed sublevel. The AInfo constructor sets bIsSpatiallyLoaded = false and bReplicates = false (Private/Info.cpp:11-45), which is exactly the kind of role Epic designed this class for.

A plain AActor placed in a World Partition level is spatially streamed by default and can be unloaded during gameplay. A subsystem is structurally immune to this class of bug because it doesn’t belong to any ULevel.

Where the ordering guarantee stops

The guarantee from the previous section applies only to this ordering. Everything below falls outside it, and that is where the assumption that “the subsystem is always there” breaks down.

There is no declarative ordering between collections. FSubsystemCollectionBase::InitializeDependency enforces ordering within a single collection and nowhere else. The header states this plainly: “Dependencies only work within a collection” (Public/Subsystems/SubsystemCollection.h:31-45). A World subsystem that accesses a GameInstance subsystem from inside Initialize has no declarative safeguard. You must either enforce the order yourself or defer that access until OnWorldBeginPlay, when the world has already been assembled.

A dynamic subsystem whose module hasn’t loaded never appears. A UEditorSubsystem placed in a module with the wrong LoadingPhase simply never reaches the collection (Subsystem.h:72-83, EditorSubsystem.h:9-23). The symptom is misleading: GetEditorSubsystem<T>() returns null even though the class compiles, loads, and looks perfectly fine in the editor.

A class that hasn’t been loaded never even makes the list. This is the same mechanism as the point above, seen from the other side. Non-dynamic collections run their GetDerivedClasses scan once, when the collection is created, and they only see the classes that are in memory at that moment. A Blueprint child of a subsystem with no hard references to that child isn’t loaded yet in a packaged build, so its CDO is never asked — and at the default log level a refusal and an absence look identical: both are just a missing line. The editor never shows the problem, because the Content Browser keeps the class in memory. I covered the whole case in A Blueprint subsystem does not get created in a packaged build.

A conditional ShouldCreateSubsystem eliminates the non-null guarantee. Epic does this in its own code: UInputDeviceSubsystem returns false on a dedicated server, in a commandlet, and when Slate hasn’t been initialized (Private/GameFramework/InputDeviceSubsystem.cpp:240-252). The consequence is visible in the subsystem’s own accessor. UInputDeviceSubsystem::Get() returns nullptr (:194-197), so every call within the engine is wrapped in an if, three times in ForceFeedbackEffect.cpp alone (:122, :190, :214).

Overriding this hook gives up the very property that often makes a subsystem appealing in the first place. From that point on, every GetSubsystem<T>() requires a null check, and the call site has no way to know whether it is running on a path where the subsystem was created. Sometimes that tradeoff is intentional. The condition in this method doubles as a way of declaring which class in the hierarchy should be the subsystem, and the null check becomes the price of moving the implementation one level down, into a Blueprint.

DoesSupportWorldType includes editor worlds by default. A gameplay manager that doesn’t override this method gets an instance in every world opened in the editor, not just in PIE. This happens because UWorldSubsystem overrides ShouldCreateSubsystem through DoesSupportWorldType, whose default implementation allows game, PIE, and editor worlds (Public/Subsystems/WorldSubsystem.h:33-66, especially :64-66). If the subsystem also derives from UTickableWorldSubsystem, it ticks from Initialize to Deinitialize for as long as the map remains open in the editor (WorldSubsystem.h:72-106).

Confirming this in your own project

You can verify the entire timeline above in a single editor run. Log four points and include the world type on every line:

void UMyWorldSubsystem::Initialize(FSubsystemCollectionBase& Collection)
{
    Super::Initialize(Collection);
    UE_LOG(LogMyGame, Log, TEXT("[1] Subsystem::Initialize | World=%s Type=%d"),
        *GetWorld()->GetName(), (int32)GetWorld()->WorldType);
}

void UMyWorldSubsystem::OnWorldBeginPlay(UWorld& InWorld)
{
    Super::OnWorldBeginPlay(InWorld);
    UE_LOG(LogMyGame, Log, TEXT("[2] Subsystem::OnWorldBeginPlay"));
}

// AMyManagerActor::BeginPlay  → [3]
// AMyGameMode::StartPlay      → [4]

Seeing 1 → 2 → 3 → 4 in the log confirms the guarantee for one specific project and one specific streaming setup. If [3] appears before [2], the actor is being spawned rather than placed in the level. Its BeginPlay fires immediately after the spawn and has nothing to do with the world startup timeline.

The ordering guarantee is real, and the engine code enforces it, but it covers exactly one thing: a World subsystem exists before actors in that same world receive BeginPlay. It extends no further than that single axis. Everything above also covers startup only; the order in which a world and a session shut down is a separate question, and this note leaves it open.

The game code has to answer every other question for itself, and the engine won’t even signal that the question came up.

Here, zero means “clear the timer.”

The symptom: silence

No compile error. No red node. No runtime exception. Is Valid Timer Handle returns false for the returned handle — assuming you think to check it at all.

The only visible signal is a warning in the Output Log, generated from this format string in Engine/Private/KismetSystemLibrary.cpp:748 (UE 5.8):

FFrame::KismetExecutionMessage(*FString::Printf(
    TEXT("%s %s SetTimer passed a negative or zero time. The associated timer may fail to be created/fire! "
         "If using InitialStartDelayVariance, be sure it is smaller than (Time + InitialStartDelay)."),
    *ObjectName, *FunctionName), ELogVerbosity::Warning);

For the graph above, the output looks like this (the PIE path on the second line has been shortened):

LogScript: Warning: Script Msg: BP_TimerZero_C_UAID_74563C6B4F116DF302_1712491287 OnTimerFired SetTimer passed a negative or zero time. The associated timer may fail to be created/fire! If using InitialStartDelayVariance, be sure it is smaller than (Time + InitialStartDelay).
LogScript: Warning: Script Msg called by: BP_TimerZero_C /Memory/UEDPIE_0_…:PersistentLevel.BP_TimerZero_C_UAID_74563C6B4F116DF302_1712491287
LogBlueprintUserMessages: IsValidTimerHandle -> false

The first %s resolves to the actor instance name, and the second resolves to the function bound to the Event pin. The third line comes from the graph’s own Log String: the returned handle is invalid.

What the log does not contain is FIRED. The event never ran.

The phrase may fail to be created/fire is more cautious than the implementation warrants. There is no may here: when Time <= 0, the timer is not created.

Where it disappears: one condition in FTimerManager

The call path is short. K2_SetTimerDelegate checks the time only to emit the warning, then forwards the value unchanged (Engine/Private/KismetSystemLibrary.cpp:735):

InitialStartDelay += FMath::RandRange(-InitialStartDelayVariance, InitialStartDelayVariance);
if (Time <= 0.f || (Time + InitialStartDelay) < 0.f)
{
    // ... KismetExecutionMessage(..., ELogVerbosity::Warning);
}

FTimerManager& TimerManager = World->GetTimerManager();
Handle = TimerManager.K2_FindDynamicTimerHandle(Delegate);
TimerManager.SetTimer(Handle, Delegate, Time,
    FTimerManagerTimerParameters { .bLoop = bLooping, .bMaxOncePerFrame = bMaxOncePerFrame,
                                   .FirstDelay = Time + InitialStartDelay });

The actual decision happens one layer deeper, inside FTimerManager::InternalSetTimer (Engine/Private/TimerManager.cpp:653):

if (FindTimer(InOutHandle))
{
    // if the timer is already set, just clear it and we'll re-add it, since
    // there's no data to maintain.
    InternalClearTimer(InOutHandle);
}

if (InRate > 0.f)
{
    // ... the entire FTimerData setup, ExpireTime, heap push
}
else
{
    InOutHandle.Invalidate();
}

The entire timer initialization is guarded by InRate > 0.f. When that condition fails, the function does exactly one thing: it invalidates the handle, with no log and no ensure.

If a timer already existed on the same handle, InternalClearTimer has already run by this point. Setting Time to 0.0 therefore does more than prevent a new timer from being created: it also clears the timer that was already running.

That is easier to hit from Blueprint than the code suggests, because the node has no handle input. K2_FindDynamicTimerHandle resolves the handle from the delegate, so a second call bound to the same event — this time with Time = 0.0 — finds the existing timer and clears it.

The complete behavior matrix follows directly from that condition:

From C++, there is not even that one warning. A direct call to GetWorldTimerManager().SetTimer(...) reaches the same InternalSetTimer implementation but bypasses the Kismet layer entirely. Set Timer by Function Name is not a way out either: a different Kismet wrapper, the same condition underneath.

The condition itself is reasonable. A looping timer with a rate of zero could otherwise create an infinite loop within a single frame.

Epic documented it — just not where most users look

This behavior is explicitly documented in the function comment (Engine/Classes/Kismet/KismetSystemLibrary.h:723):

* @param Time    How long to wait before executing the delegate, in seconds.
*                Setting a timer to <= 0 seconds will clear it if it is set.

That line never appears in the node’s main tooltip. The editor stops the function description at the first @param and moves the remaining descriptions to the individual pin tooltips.

What to do instead

When Time comes from data — a Data Asset, a curve, a gameplay attribute, or a value produced by difficulty scaling — validate it before passing it to the node. A Branch is the simplest way to do that: feed the same value into both the condition and the Time pin. If zero and negative values should mean “run on the next tick,” route them to Set Timer for Next Tick by Event and positive values to the regular timer node.

That routing is a decision about the data contract, not a drop-in replacement. Set Timer for Next Tick by Event never loops, so it cannot stand in for a looping timer whose rate happened to arrive as zero. And if a timer is already running on the same handle, the two branches differ in effect: the regular node with a non-positive Time clears that timer, while the next-tick branch leaves it running and adds one extra call to the event. When neither outcome is the intended one, a non-positive value is simply bad data — log it and skip the call, or substitute a known default.

When this matters

This starts to matter once Time stops being a hard-coded literal and instead comes from a Data Asset, a gameplay attribute, a difficulty multiplier, a DPS-based interval, or a cooldown scaled by a character stat. In each of these cases, the value can end up being zero through an empty struct, an uninitialized field, a missing data value, or a division that happens to return zero under rare conditions.

And because Time = 0.0 also clears a timer already running on the same handle, there are two possible failure modes instead of one: “it never started” and “it was running, and then it stopped.”