Cue Notify Types¶

UE 5.7 ships six Gameplay Cue Notify classes. The overview page introduced four of them -- here we cover all six in full, including the two newer types (Burst and BurstLatent) that provide a much better workflow than the original Static and Actor classes.

Decision Matrix¶

Before diving into each type, here's the quick decision guide:

UGameplayCueNotify_Static¶

The lightest cue. A non-instanced UObject (not an Actor) that handles cue events through its CDO. No actor is ever spawned -- the engine calls methods directly on the class default object.

When to Use¶

• Triggering sounds or VFX from code that you don't need editor-exposed spawn configuration for
• Running pure logic in response to a cue (logging, analytics, UI notifications)
• Maximum performance -- zero actor spawn overhead

Lifecycle Events¶

Key Properties¶

Inheritance¶

UObject
  └── UGameplayCueNotify_Static
        ├── UGameplayCueNotify_Burst        (child)
        └── UGameplayCueNotify_HitImpact    (child, deprecated)

Practical Example¶

A simple static cue that plays a sound at the target's location:

UCLASS()
class UGC_HitConfirm : public UGameplayCueNotify_Static
{
    GENERATED_BODY()

    virtual bool OnExecute_Implementation(AActor* MyTarget,
        const FGameplayCueParameters& Parameters) const override
    {
        if (MyTarget && HitSound)
        {
            UGameplayStatics::PlaySoundAtLocation(
                MyTarget, HitSound, Parameters.Location);
        }
        return false; // false = also run parent handlers
    }

    UPROPERTY(EditDefaultsOnly, Category = "Sound")
    TObjectPtr<USoundBase> HitSound;
};

UGameplayCueNotify_Burst¶

The recommended one-shot cue. Inherits from UGameplayCueNotify_Static (so it's still non-instanced and cheap), but adds editor-configurable spawn conditions, placement rules, and burst effects (Niagara, sounds, camera shakes, force feedback, decals).

Display name in the editor: GCN Burst.

When to Use¶

• Hit impacts, damage numbers, ability cast effects
• Any one-shot VFX/SFX where you want designers to configure everything in the editor
• When you don't need Timelines, Delays, or any latent actions

Lifecycle¶

Burst cues only respond to OnExecute. When triggered, the system:

1. Checks DefaultSpawnCondition (locally controlled policy, chance to play, surface filter)
2. Determines placement from DefaultPlacementInfo (attach to socket, use hit location, offset)
3. Spawns all effects in BurstEffects (particles, sounds, camera shakes, decals, force feedback)
4. Calls OnBurst Blueprint event with spawn results

Key Properties¶

Blueprint Events¶

The SpawnResults struct contains references to spawned Niagara/audio/decal components, so you can modify them in the event graph if needed.

Practical Example¶

In Blueprint:

1. Create a new Blueprint, parent class GameplayCueNotify_Burst
2. Set GameplayCue Tag to GameplayCue.Hit.Physical
3. In BurstEffects, add a Niagara system for spark particles and a sound for the impact
4. Set DefaultPlacementInfo to use hit location from parameters
5. Done -- no code needed

AGameplayCueNotify_BurstLatent¶

A one-shot cue that supports latent actions. Unlike Burst (which is a UObject), BurstLatent is an Actor -- it gets spawned into the world. This means it can use Timelines, Delays, and other latent Blueprint nodes.

Display name in the editor: GCN Burst Latent.

When to Use¶

• One-shot effects that need to animate over time (fade out, scale up then down)
• Effects that need a Timeline node
• When Burst almost works but you need just a bit more control over timing

Lifecycle¶

Like Burst, this only responds to OnExecute. The difference is the actor persists until:

• It finishes its work and calls K2_EndGameplayCue() (or the auto-destroy delay fires)
• It's recycled back to the pool

Key Properties¶

Same as Burst (DefaultSpawnCondition, DefaultPlacementInfo, BurstEffects), plus the full AGameplayCueNotify_Actor properties it inherits (auto-destroy, recycle settings).

Blueprint Events¶

Inheritance¶

AActor
  └── AGameplayCueNotify_Actor
        ├── AGameplayCueNotify_BurstLatent    (child)
        └── AGameplayCueNotify_Looping        (child)

AGameplayCueNotify_Actor¶

The stateful base class. An actor that is spawned into the world and persists for the duration of a gameplay effect. It handles the full lifecycle (Active, WhileActive, Execute for periodic ticks, Remove) and supports actor recycling to avoid spawn/destroy overhead.

When to Use¶

• Any persistent visual that starts and stops (auras, shields, status overlays)
• When you need full actor functionality (components, tick, collision)
• When you need unique instances per instigator (beam effects)
• As a base class for fully custom cue actors

Lifecycle Events¶

Key Properties¶

Recycling¶

Actor cue notifies are recycled, not destroyed and re-created. When a cue finishes:

1. Recycle() is called -- the actor hides itself, disables tick, and resets state
2. The actor goes into the GameplayCueManager's recycle pool
3. Next time a cue of the same class is needed, ReuseAfterRecycle() is called instead of spawning a new actor

Override Recycle() to return false if your cue can't be recycled (rare).

Practical Example¶

A burning aura cue:

1. Create Blueprint, parent GameplayCueNotify_Actor
2. Add a Niagara component for fire particles as a child component
3. Set GameplayCue Tag to GameplayCue.Status.Burning
4. Set bAutoAttachToOwner = true
5. Set bAutoDestroyOnRemove = true, AutoDestroyDelay = 1.0 (let particles fade)
6. In On Become Relevant, activate the particle system
7. In On Cease Relevant, deactivate the particle system

AGameplayCueNotify_Looping¶

The recommended duration-based cue. Inherits from AGameplayCueNotify_Actor and adds the same spawn-configuration workflow that Burst brought to one-shots: editor-configurable effects for application, looping, recurring (periodic ticks), and removal.

Display name in the editor: GCN Looping.

When to Use¶

• Duration-based effects where you want designers to configure VFX/SFX in the editor
• Effects with distinct phases (start burst, looping particles, tick effects, removal burst)
• The standard recommendation for any persistent cue

Lifecycle¶

The Looping cue maps its four effect categories to the Actor lifecycle:

Blueprint Events¶

Each event receives Target, Parameters, and the SpawnResults for that phase.

Key Properties¶

Practical Example¶

A poison DoT cue:

1. Create Blueprint, parent GameplayCueNotify_Looping
2. Set GameplayCue Tag to GameplayCue.Status.Poison
3. Application Effects: A burst of green gas particles + poison apply sound
4. Looping Effects: Persistent dripping green particles attached to the target
5. Recurring Effects: A small green flash + tick sound (fires each DoT tick)
6. Removal Effects: A cleanse burst particle + sound
7. Set DefaultPlacementInfo to attach to the target's mesh

All of this is configurable in the editor with zero code.

UGameplayCueNotify_HitImpact (Deprecated)¶

A non-instanced cue (inherits from Static) with two hardcoded properties:

It only handles OnExecute and spawns the particle/sound at the hit location from the parameters. The Burst class does everything this does and more, with Niagara support and configurable spawn conditions.

Type Comparison Summary¶

Related Pages¶

• Cue Parameters -- what data your cue receives
• Cue Manager -- how cues are routed, loaded, and managed
• AnimNotify and Sequencer -- triggering cues from animations
• Add a Gameplay Cue -- step-by-step recipe
• Cue Batching -- performance optimization