> A Blueprint subsystem does not get created in a packaged build _

A Blueprint child of a subsystem can go an entire session in a packaged build without ever being created. Nothing is wrong with the code. It is the same code that worked in PIE a minute earlier. The problem lies earlier in the sequence: by the time the engine looks for subclasses, the Blueprint class is not in memory, so it never makes the list and its CDO is never queried.

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.