Skip to content

Activate / Deactivate / Set Active / Is Active / Set Component Tick Enabled

At a glance

Lives in: Blueprint API / Components / Activation and Components / Tick - Target: Actor Component - Returns: Is Active and Is Component Tick Enabled return Booleans; the setters return no success value - Fails by: doing nothing, changing only generic component state, or changing state on this machine only - Official docs: Set Active, Set Component Tick Enabled, and UActorComponent

The one-minute version

  • Activate, Deactivate, and Set Active change an Actor Component's active state. Is Active reads that state.
  • The base Actor Component implementation also enables component tick when it activates and disables component tick when it deactivates. A component class can override those operations and add its own behavior.
  • Set Active(true) chooses Activate; Set Active(false) chooses Deactivate. It is one Boolean-driven node, not a different kind of state.
  • Reset means force the activation path even when the component's normal Should Activate test says no. It does not reconstruct the component, restore defaults, clear variables, or restart every system attached to it.
  • Generic active state is not a universal on/off switch. It does not promise to play audio, start Niagara, move an Actor, show a mesh, enable collision, simulate physics, or run your custom gameplay unless that component class implements those meanings.
  • Set Component Tick Enabled controls the component's tick separately. It cannot make a component tick if Can Ever Tick is false, and the engine documents that the runtime setter only has an effect while the component is registered.
  • Actor tick and component tick are separate. Set Actor Tick Enabled(false) does not automatically stop the Actor's components.
  • These calls happen on the machine that runs them. Do not use a local active flag or tick switch as the authoritative replicated state of an ability, door, hazard, or objective.

What they actually do

Every Actor Component owns a transient active flag. The base implementation wraps that flag in virtual functions so specialized component classes can attach real start/stop behavior.

pseudocode of the base behavior - not engine source

SetActive(NewActive, Reset):
    if NewActive:
        Activate(Reset)
    else:
        Deactivate()

Activate(Reset):
    if Reset OR this component's ShouldActivate test passes:
        enable this component's tick
        set active flag true
        broadcast On Component Activated(Component, Reset)

Deactivate():
    if this component accepts the inactive transition:
        disable this component's tick
        set active flag false
        broadcast On Component Deactivated(Component)

IsActive():
    return the current active flag

That is the generic contract. Activate and Deactivate are virtual: an Audio Component, Niagara Component, Movement Component, or project-specific component can extend or replace parts of the base behavior. This is why two components can both report active while "active" has a different practical meaning for each.

The activation delegates are events, not hidden success outputs. Code or Blueprint graphs that bind to On Component Activated and On Component Deactivated run when the component accepts those transitions. Repeating a normal activation on an already-active component normally does not create another transition. Reset = true deliberately forces the activation path and can rebroadcast activation.

What you get back

The mutation nodes have only execution output:

Node Result you can read
Activate No return value
Deactivate No return value
Set Active No return value
Is Active Current active flag as Boolean
Set Component Tick Enabled No return value
Is Component Tick Enabled Current primary component-tick enabled state as Boolean

A setter's execution pin means "the call returned," not "the component started the behavior I imagined." When the result matters, validate the component, call the setter, and query the exact state you care about:

Is Valid(ScannerComponent)
-> Set Active(true)
-> Is Active
-> true: continue
-> false: handle rejected/unavailable component

Even that confirms only generic active state. To confirm an Audio Component, query its playback state. To confirm collision, query collision settings. To confirm a custom ability, expose a project-owned state such as Is Running that means what the game actually needs.

What Reset really means

The Reset pin belongs to the activation request. With Reset = false, the component's virtual ShouldActivate test decides whether activation should run. With Reset = true, Activate takes its activation path even if that test says no.

Useful cases are component-specific: restarting an effect, reapplying a subclass's activation behavior, or deliberately rebroadcasting activation. The pin does not have one universal "reset the component" meaning.

It does not automatically:

  • restore Details-panel defaults;
  • clear timers, arrays, targets, or accumulated gameplay state;
  • recreate render or physics state;
  • rerun BeginPlay or Construction Script;
  • replace a destroyed component; or
  • guarantee that a subclass can safely restart at any moment.

If your custom component needs a real reset, give that operation a name such as Reset Charge, Clear Target, or Restart Scan. A generic Reset checkbox should not carry undocumented game rules.

The base activation path toggles component tick, but four settings still answer different questions:

Setting / node Question it answers
Auto Activate Should registration automatically request activation?
Can Ever Tick Is this component's primary tick function allowed to register at all?
Start with Tick Enabled When tick registers, should it begin enabled?
Set Component Tick Enabled Should the registered component tick be enabled now?
Tick Interval When enabled, how much time should normally pass between component ticks?

The combinations matter:

  • Can Ever Tick = false is the hard capability gate. The runtime setter cannot turn a nonexistent tick function into a working Tick event.
  • Start with Tick Enabled = false is only the initial tick preference. Registration with Auto Activate = true can then run generic activation, which enables tick again.
  • To start a generic tickable component dormant, set both Auto Activate and Start with Tick Enabled to false, then activate it deliberately.
  • A nonzero Tick Interval makes an enabled component run less often. Enabling it does not mean "once per rendered frame" when an interval, pause rule, tick prerequisite, or specialized tick policy says otherwise.
  • Disabling the owning Actor's tick does not disable component ticks. Use the component node for work implemented by the component.

Set Component Tick Enabled is documented to affect a registered component. Before registration, choose the construction/default settings instead. An unregistered component can still hold an active flag, but it has no normal registered world tick, render state, or physics state for that flag to drive.

When they fail (and what failure does)

There is no Failed execution pin. Common failure shapes are:

  1. Target is None. A member call on an invalid Blueprint reference is skipped and produces the usual Accessed None diagnostic. Nothing is activated or disabled.
  2. The component is being destroyed or is already invalid. Reset is not resurrection. Guard stored component references with Is Valid.
  3. The component is unregistered. Its active flag may change, but the runtime tick setter has no registered tick function to change and no world behavior is guaranteed.
  4. Can Ever Tick is false. Tick remains unavailable even if active state becomes true.
  5. It is already in the requested state. A normal repeated request can be a quiet no-op. Do not wait for another activation/deactivation event as an acknowledgement.
  6. The subclass gives activation a narrower meaning. A specialized component can reject, defer, or extend the generic transition.
  7. You changed the wrong switch. Active, tick, visibility, collision, simulation, audio playback, and gameplay-enabled state are separate.
  8. You changed only one network instance. A client-side call does not execute the same Blueprint graph on the server or other clients.

Failure does not roll back surrounding graph work. If you set your own IsAbilityRunning Boolean before an invalid component call, Unreal does not undo that variable. Validate first and change project-owned state in one authoritative path.

Generic active state is not a universal stop button

Use the operation that owns the behavior:

What you mean Prefer
Pause/resume a custom reusable behavior component Activate / Deactivate, with explicit activation event handling
Play or stop a sound Audio Component Play, Stop, or Fade Out
Start or stop a Niagara effect Niagara Component's activation/deactivation behavior, with its completion/pooling rules
Stop Character or Projectile movement The relevant Movement Component operation
Hide geometry Set Visibility or Set Hidden in Game
Disable blocking/overlap participation Collision Enabled / response nodes
Stop rigid-body simulation Set Simulate Physics(false)
Stop only repeated component work Set Component Tick Enabled(false)
Remove the component instance permanently Destroy Component

Some specialized components intentionally connect Activate to their normal start behavior. Others expose clearer Play, Stop, Start, or Deactivate Immediate operations because stopping has asset-specific timing and cleanup. Search for the specialized node first; generic activation cannot invent that contract.

The pattern everyone actually uses

For a reusable scanning component:

BP_ScannerComponent defaults
-> Auto Activate = false
-> Start with Tick Enabled = false

Owner starts scanning
-> Is Valid(ScannerComponent)
-> Activate

Scanner: On Component Activated
-> clear/rebuild scan target state if project rules require it
-> broadcast Scanner Started

Scanner: Tick
-> perform the frame-dependent scan

Owner stops scanning
-> Deactivate

Scanner: On Component Deactivated
-> clear any owned timer
-> clear current target
-> broadcast Scanner Stopped

The generic base activation already handles primary tick. The custom events own the gameplay state that "scanning" actually means.

For a looping machine sound, use the audio contract instead:

Machine starts -> AudioComponent.Play
Machine stops  -> AudioComponent.FadeOut(0.25, 0)

That preserves fade and playback semantics that a bare active flag cannot express.

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

void UScannerComponent::SetScanning(bool bScanning)
{
    SetActive(bScanning);
}

void UScannerComponent::Activate(bool bReset)
{
    const bool bWasActive = IsActive();
    Super::Activate(bReset);
    if (IsActive() && (!bWasActive || bReset))
    {
        OnScannerStarted.Broadcast();
    }
}

void UScannerComponent::Deactivate()
{
    const bool bWasActive = IsActive();
    Super::Deactivate();
    if (bWasActive && !IsActive())
    {
        CurrentTarget = nullptr;
        OnScannerStopped.Broadcast();
    }
}

Real custom components should make repeated activation/deactivation idempotent: calling the same request twice should not double-bind a dispatcher, start duplicate timers, or leak a previous effect.

Multiplayer: what actually replicates?

All five calls execute locally. The engine's Actor Component active flag has a replication path, but it participates only when the owning Actor and component are configured to replicate. That does not turn Activate into a remote procedure call (RPC), and it does not replicate arbitrary side effects from your activation event.

Tick configuration and local tick execution are implementation details, not a substitute for replicated gameplay state. A server disabling its component tick does not instruct a client's unrelated component instance to stop its Tick event.

For gameplay that affects rules:

owning client input
-> Server RPC requests ability
-> server validates and sets replicated AbilityState
-> server starts/stops authoritative component behavior
-> On Rep AbilityState updates client presentation

A local cosmetic component may activate only on a client. A damage volume, objective timer, or ability cooldown should be decided by the server and represented by explicit replicated state. That remains understandable even if the component class later changes how activation or tick works.

What these nodes do not do

They do not:

  • create, register, repair, or resurrect a component;
  • guarantee a specialized system started or stopped;
  • change Actor tick, timers, latent actions, or other components;
  • hide meshes, disable collision, stop physics, or clear velocity by default;
  • clear custom delegates, arrays, targets, or resources;
  • report success from a setter;
  • make per-frame work inexpensive; or
  • execute automatically on every network machine.

Lookalikes - which one do I want?

Node Changes Use when
Activate / Deactivate Virtual component active lifecycle You have a clear start/stop request.
Set Active The same lifecycle, selected by a Boolean Desired active state already exists as data.
Is Active Reads generic active state You need the component lifecycle flag.
Toggle Active Inverts current active state A true toggle is the product rule; avoid it when two callers can race.
Set Auto Activate Future automatic activation at registration Construction/default setup decides startup behavior.
Set Component Tick Enabled Component tick only You want to pause/resume repeated component work without changing the broader lifecycle.
Set Actor Tick Enabled Actor tick only The repeated work is implemented by the Actor.
Play / Stop / Fade / system-specific start-stop Specialized runtime behavior The component exposes a contract more precise than generic active state.
Destroy Component Component lifetime The instance should no longer exist, not merely pause.

Rule of thumb: use active state for a component-owned lifecycle, tick state for repeated work, and the specialized node for the thing the player actually sees or hears.

Going deeper