UCLASS Specifiers & Data Ownership

Four specifiers control how a C++ class is exposed to Blueprints and the editor.

The four Blueprintable / BlueprintType combinations:

UCLASS(Abstract, Blueprintable, BlueprintType)
class UAbilityBase : public UObject
{
    GENERATED_BODY()
};

Everything in this chapter follows from one fact.

This single difference drives referencing, inheritance, mutation safety, and loading behavior, covered section by section below.

Data-Only Blueprints

A Blueprint normally has two parts: a graph (logic) and default values (Details panel). A data-only Blueprint is a Blueprint where the graph was never touched — just a child class with changed defaults. Unreal detects this automatically and shows a stripped-down editor window (Details panel only, with an "Open Full Blueprint Editor" link). It is not a distinct asset type or a checkbox — it's a normal Blueprint that happens to be empty of logic, and the check is re-evaluated every time the editor opens it.

What flips it out of data-only status:

• User-added components in the Components panel
• New variables declared on the Blueprint itself (overriding an inherited property is fine — declaring a new one is not)
• Nodes in the event graph
• Extra functions or macros beyond the default construction script
• Timelines
• Being an Interface Blueprint

Special case: an Actor Blueprint with only the automatic DefaultSceneRoot still counts as data-only — the engine ignores that node since it wasn't added by the user. The check is stateless and reversible in both directions — delete the component/node/variable and it becomes data-only again.

Where Default Values Actually Live: the CDO

Every class has a hidden singleton called the Class Default Object (CDO), auto-created at load (Chapter 6). Editing the Details panel of a data-only Blueprint edits its CDO. Reading a data-only Blueprint's values without spawning anything goes through the CDO:

const UMyWeapon* Defaults = GetDefault<UMyWeapon>(WeaponClass);
float Damage = Defaults->Damage;

A Data Asset has no such indirection — the object already exists:

float Damage = WeaponData->Damage;

This also shapes how the reference is stored:

TSubclassOf<AMyWeapon> WeaponClass;   // reference to a TYPE (Blueprint)
TObjectPtr<UWeaponData> WeaponData;   // reference to an OBJECT (Data Asset)

Blueprints inherit. Data Assets do not. Base weapon Blueprint: Damage = 10, Range = 1000. Children Pistol/Rifle/Shotgun. Rifle overrides Damage = 25, leaves Range alone. Change Range on the base to 2000 → all three children that never overrode it pick up the new value automatically. The editor shows a revert arrow next to any property that diverges from its parent.

Data Assets are flat and standalone. Fifty weapon Data Assets means fifty separate edits to change one shared value (or a script, or multi-select property matrix editing) — there is no parent to change. Composition can simulate inheritance: give the Data Asset a pointer to a shared "archetype" asset and fall back to it in code when a field is unset. This is hand-built and needs fallback logic wherever the value is read.

Runtime Mutation Safety

A Data Asset is one shared object in memory. If ten enemies reference DA_GoblinStats and one writes to it, all ten see the change — and in the editor, that write dirties the asset on disk, risking gameplay state leaking into source data. Treat Data Assets as read-only at runtime; copy values out into the actor/component for per-instance state.

Spawning from a Blueprint class is safe by construction — each spawned actor is its own object with its own copy of the values.

Where Logic Is Allowed to Live

Data-only Blueprints can silently grow logic — add one node and it's no longer data-only, with no warning or gate. Convenient for quick designer overrides, risky for "just data" assumptions elsewhere in the codebase. This is a team-discipline problem, not something the engine prevents.

Data Assets structurally cannot hold logic through the normal workflow (barring an unusual Blueprint subclass of a DataAsset class). This makes the data/logic split enforced by the tooling rather than by convention.

Data Assets are the lighter option. A Blueprint drags in a UBlueprintGeneratedClass, its CDO, its component hierarchy (if an Actor), and every hard reference in its defaults — so a data-only weapon Blueprint with an assigned mesh/sound pulls those into memory on class load (Chapter 7 covers why hard references pull their target in).

UPrimaryDataAsset is the intended hook into the Asset Manager (Chapter 9): override GetPrimaryAssetId, register the type in project settings, get asset registry scanning, asset bundles, async loading, and chunking for free. Blueprint classes can be registered as primary assets too, but carry the extra class/CDO overhead. Both support TSoftObjectPtr for deferred loading of heavy content — this part is a wash.

Choosing Between Them

Two questions, in order:

1. Does this get created, or just consumed? Spawned / instantiated / needs overridable functions → class (Blueprint). Configuration read by a system that already exists → Data Asset.
2. Is shared-value inheritance useful here? A real tuning hierarchy where the base ripples down to children → Blueprints win outright. Genuinely flat data (item definitions, stat blocks, tuning curves) → Data Assets are cleaner and lighter.

Declaring a variable on a Blueprint always makes it a real Blueprint — this cannot be avoided directly. The fix is to reorganize the hierarchy so only leaf classes need to stay data-only.

Sandwich the Hierarchy

Only the variants at the bottom (the ones duplicated dozens of times for designers) need to be data-only. Classes in the middle that define structure are supposed to be real classes.

AWeapon (C++)              <- shared fields
  |- ARifle (C++)          <- rifle-only fields declared HERE
       |- BP_AK47          <- data only
       |- BP_M4            <- data only
       |- BP_ScoutRifle    <- data only

UCLASS(Blueprintable)
class ARifle : public AWeapon
{
    GENERATED_BODY()
public:
    UPROPERTY(EditDefaultsOnly, Category = "Rifle")
    int32 MagazineSize = 30;

    UPROPERTY(EditDefaultsOnly, Category = "Rifle")
    float ReloadTime = 2.0f;
};

Every data-only child inherits these fields with full revert-arrow support, and never declares anything itself. If C++ isn't available: same shape, one level lower. Make BP_Rifle_Base a regular Blueprint that declares the rifle variables; its children stay data-only. Pay the cost once instead of per-leaf.

Composition Instead of Subclassing

Put a pointer on the base class and let the pointed-at object carry type-specific data, so leaf Blueprints never need their own variables at all.

UCLASS(Blueprintable)
class AWeapon : public AActor
{
    UPROPERTY(EditDefaultsOnly, Category = "Config")
    TObjectPtr<UWeaponData> WeaponData;
};

URifleData : UWeaponData carries the rifle fields. Every weapon Blueprint stays data-only permanently — new weapon categories mean new Data Asset classes, not new Blueprint layers.

Subclassing vs. Composition Tradeoffs

• Subclassing gives inheritance on the type-specific fields too (change ReloadTime on ARifle, every non-overriding rifle updates). Composition is flat — no such propagation.
• Composition avoids hierarchy explosion (a "rifle that's also a launcher" just holds two configs instead of forcing a parent choice).
• Composition decouples data lifetime from the class — supports independent hot-reload / async load.

Anti-pattern: One Fat Base Class

Putting every field (rifle, shotgun, launcher) on a single base class works for small projects but grows badly — a shotgun's Details panel ends up showing HomingTurnRate doing nothing, and nobody can tell which fields are live. If unavoidable, gate visibility cosmetically:

UPROPERTY(EditDefaultsOnly, meta = (EditCondition = "bIsProjectile"))
float ProjectileSpeed = 3000.f;

These solve one problem: UObject properties are references by default; sometimes ownership is wanted instead.

The Default Behavior

UPROPERTY(EditDefaultsOnly)
TObjectPtr<UWeaponConfig> Config;

This gives an asset picker — a reference to an existing asset on disk. Two weapons pointing at the same asset share it.

EditInlineNew (on the class)

A permission flag: "this class may be created inline in a Details panel," instead of only picked from the Content Browser.

UCLASS(EditInlineNew, Blueprintable, Abstract)
class UWeaponConfig : public UObject
{
    GENERATED_BODY()
};

Without it, the editor never offers to create one inline. Default for UObject is effectively NotEditInlineNew.

Instanced (on the property)

Says "this pointer owns its object."

UPROPERTY(EditDefaultsOnly, Instanced)
TObjectPtr<UWeaponConfig> Config;

Two effects: the Details panel becomes a class picker + inline expandable editor instead of an asset picker, and the object is deep-copied on instantiation — each child Blueprint and each spawned actor gets its own copy rather than sharing the parent's object. (Implies ExportSubObject, which is what makes the sub-object save inside the owning asset.)

DefaultToInstanced (on the class)

Convenience: every property pointing at this class is automatically treated as Instanced, even without the property-level specifier.

UCLASS(EditInlineNew, DefaultToInstanced, Blueprintable, Abstract)
class UWeaponConfig : public UObject { ... };

This is what UActorComponent itself declares — the reason every component pointer on an actor automatically owns its component without ever writing Instanced explicitly.

Putting It Together

Both EditInlineNew (class) and Instanced (property) are needed together — one without the other gives either a class with nothing offering to create it, or a property still wanting an asset reference.

UCLASS(EditInlineNew, Blueprintable, Abstract)
class UWeaponConfig : public UObject
{
    GENERATED_BODY()
public:
    UPROPERTY(EditDefaultsOnly)
    float Damage = 10.f;
};

UCLASS()
class URifleConfig : public UWeaponConfig
{
    GENERATED_BODY()
public:
    UPROPERTY(EditDefaultsOnly)
    int32 MagazineSize = 30;
};

UPROPERTY(EditDefaultsOnly, Instanced, Category = "Config")
TObjectPtr<UWeaponConfig> Config;

Note: Instanced works on arrays too (TArray<TObjectPtr<UWeaponConfig>>) — a common pattern for a list of modifiers/effects where each entry is a different subclass.