Skip to content

Add Component by Class / Child Actor Component

At a glance

Lives in: Blueprint API / Game - Target: an existing Actor - Returns: an Actor Component reference to the new component, or None if creation cannot happen - Creates: a component owned by the target actor, not a separate actor in the level - Official docs: Add Component by Class

The one-minute version

  • Add Component by Class creates a new component instance on an actor that already exists.
  • The Return Value is the component object that was just created. Its declared pin type is Actor Component, but the real object is the component subclass you selected, such as BP_HealthComponent or AudioComponent.
  • The new component is owned by the target actor. It is not a world actor, does not appear as a separate placed object, and does not have its own actor lifetime.
  • Actor Components have no transform. Scene/Primitive Components can have transforms and attachment, but still belong to the target actor.
  • A Child Actor Component is different: it is a component that owns/spawns a child actor as part of another actor's component hierarchy.
  • Design-time components in the Components window are usually better for stable parts. Runtime Add Component is for optional/temporary parts or composition that genuinely changes during play.

What it actually does

The node asks the target actor to construct a component of the chosen component class and finish adding it to that actor.

pseudocode of the engine behavior - not engine source

function AddComponentByClass(TargetActor, ComponentClass):
    if TargetActor is None or ComponentClass is not a valid ActorComponent class:
        return None

    Component = create new ComponentClass with TargetActor as its outer/owner
    add Component to TargetActor's component lists
    finish/register the component so it can participate in gameplay/scene work
    return Component

The exact finish path matters because a component that is not registered cannot tick, render, collide, or create scene/physics state in the normal way. The Blueprint node is the beginner-safe path because it goes through the actor's component-add machinery instead of constructing a raw object and hoping it behaves like a component.

If the selected component class has setup properties exposed to the add-node path, the Blueprint compiler can defer the finish step long enough to assign those values, then complete registration. That is the component version of the "Expose on Spawn" timing problem discussed on Spawn Actor from Class.

What you get back

The output pin is declared as an Actor Component Object Reference. The runtime object is the actual component class you asked for.

Add Component by Class
Class = BP_HealthComponent
Return Value declared as ActorComponent
Runtime object is a BP_HealthComponent instance

If you need functions or variables that only exist on your custom component, cast the return value or keep the variable typed to that component class after assignment:

Add Component by Class BP_HealthComponent
-> Cast To BP_HealthComponent
-> InitializeHealth(MaxHealth)
-> store HealthComponent reference

For engine component classes such as AudioComponent, StaticMeshComponent, or BoxComponent, use the correctly typed component reference before calling component-specific functions.

When it fails (and what failure does)

Failure has no special Failed execution pin. Execution continues and the Return Value can be None.

Common causes:

  1. Target actor is None. There is no actor to own the component.
  2. Class is empty or not an Actor Component class. You cannot add an Actor, Widget, Data Asset, or arbitrary object class with this node.
  3. Class is abstract or not allowed for Blueprint spawning. The picker filters many bad choices, but invalid runtime class values can still fail.
  4. You add the wrong component family. Adding a plain Actor Component when you expected a mesh, socket, camera, or collision shape creates a valid component that simply has no transform or geometry.
  5. You forget your own initialization. The component exists, but your game never told it which data, owner contract, or listeners to use.

The node does not attach a separate actor, choose a root for you in every design case, replicate the component's custom state by itself, or keep external references clean when the owning actor is destroyed.

Designed component vs runtime component

Use the Components window when the actor always has the part:

BP_Door
-> DoorMesh
-> TriggerBox
-> AudioComponent

That makes the part visible in the Blueprint editor, serializes it with the class/instance, and lets designers edit it in Details.

Use Add Component by Class when the part is truly dynamic:

Powerup applies shield
-> Add Component by Class BP_ShieldComponent
-> Initialize duration/strength
-> component removes itself or owner removes it later

Runtime component creation is more flexible, but it is harder to inspect and easier to leak references/listeners. If every copy of the actor should have the component, design it into the Blueprint.

Child Actor Component

A Child Actor Component is a Scene Component that creates and owns a child actor. That child actor is still an actor, but its lifetime is tied to the component.

Use it for authored composition:

BP_TurretBase
-> RotatingBase mesh
-> ChildActorComponent
   Child Actor Class = BP_TurretGun

This is different from Spawn Actor from Class:

  • the child actor is part of the owning actor's component setup;
  • the child follows the component transform;
  • unregistering/destroying the component destroys the child actor it created;
  • it is good for "this actor is built out of a designed sub-actor";
  • it is not the normal pattern for arbitrary pickups, projectiles, enemies, or one-off runtime world objects.

If the child needs fully independent placement, save/load identity, world searching, and lifetime, spawn an actor instead.

The pattern everyone actually uses

Optional health component at runtime:

Actor gains temporary destructible behavior
-> Add Component by Class BP_HealthComponent
-> Cast To BP_HealthComponent
-> InitializeHealth(50)
-> Bind OnDeath
-> Store HealthComponent reference

Optional audio loop:

Machine starts
-> Add Component by Class AudioComponent
-> Set Sound = LoopingHum
-> Attach/position if it is a Scene Component
-> Play
-> store AudioComponent

Machine stops
-> Fade Out or Stop
-> Destroy Component if it was temporary

Designed child actor:

BP_Spaceship
-> ChildActorComponent LeftTurret
   Child Actor Class = BP_Turret
-> ChildActorComponent RightTurret
   Child Actor Class = BP_Turret

The first two patterns add optional parts during play. The third makes the sub-actors part of the Blueprint's authored design.

Lookalikes - which one do I want?

Node or tool Creates Use when
Components window Designed component template/instance Every actor of this class normally has this part.
Add Component by Class Runtime component on an existing actor The actor gains optional behavior, audio, collision, mesh, or other part during play.
Child Actor Component A component-managed child actor A designed sub-actor should live as part of the parent actor.
Spawn Actor from Class Separate actor in the world The thing needs independent actor lifetime, placement, replication, or world identity.
Attach Actor To Component No new object; creates transform parent relationship You already have a separate actor and want it to follow a component/socket.
Get Component by Class Nothing; searches existing components on one actor You need to find a component that should already be there.

Rule of thumb: Add Component changes what one actor is made of. Spawn Actor creates another actor. Child Actor Component is authored composition with a managed sub-actor.

Going deeper