Skip to content

Animation Notifies and Notify States

Animation Notifies are timed callbacks from animation playback. They are how footsteps, swing windows, sounds, particles, and montage callbacks line up with the frame where the animation actually reaches them.

The one-minute version

  • A Notify is a one-time marker on an animation timeline. When playback reaches it, Unreal can trigger an event or built-in effect.
  • A Notify State has a duration. It has begin, tick, and end behavior, so it is useful for windows such as "melee hitbox active from here to here."
  • Notifies live on animation assets such as sequences and montages. The Animation Blueprint or Play Montage callback path receives them while that animation plays.
  • Use notifies for animation-timed things: footsteps, landing dust, weapon trail windows, melee damage windows, sound cues, and one-shot particles.
  • Do not use Delay to guess animation timing when the animation itself can carry the marker.
  • Notifies can be filtered by blend weight, level of detail (LOD), dedicated server settings, montage notify type, and whether the animation actually reaches that time.

Notify vs Notify State

Use a Notify when one moment matters:

Run animation frame where foot hits ground
-> Footstep Notify
-> play footstep sound / spawn dust

Use a Notify State when a time range matters:

Sword attack montage
-> Notify State "MeleeWindow"
   Begin: enable weapon trace
   Tick: optional per-frame trace/sample
   End: disable weapon trace

The difference is not "simple vs advanced." It is instant vs duration.

Type Timeline shape Common uses
Notify One keyframe Footstep, sound, muzzle flash, landing dust, combo-open marker.
Notify State Start and end range Melee hit window, trail effect, temporary root-motion/input window, charged effect.

Where the event is received

There are several paths, depending on the notify type and how the animation is played.

For normal animation sequence/skeleton notifies:

Animation Sequence has Notify "Footstep"
-> Animation Blueprint Event Graph has AnimNotify_Footstep event
-> event runs when playback reaches marker

For Play Montage callback notifies:

Montage has Montage Notify "EnableHitbox"
-> Play Montage node On Notify Begin
-> Notify Name = "EnableHitbox"

For custom Notify Blueprint classes:

AnimNotify subclass
-> Received Notify

AnimNotifyState subclass
-> Received Notify Begin
-> Received Notify Tick
-> Received Notify End

Pick the path that matches who should react. Footstep audio may live in the AnimBP or a notify class. Attack hit windows often go back to the character or weapon so gameplay authority stays outside the AnimBP pose graph.

Why not Delay?

Delay guesses time from the Blueprint graph that started the action. A notify uses the animation timeline itself.

The notify is better when:

  • an animator moves the footstep frame;
  • play rate changes;
  • the montage starts from a section;
  • the animation blends out early;
  • the attack is interrupted;
  • the same animation is reused by several characters;
  • a hit window must line up with the weapon swing.

The quick path is:

Input Attack
-> Play Montage
-> Delay 0.22
-> Enable Hitbox
-> Delay 0.18
-> Disable Hitbox

The concrete cost is drift. The timing now lives outside the animation, so every edit to the asset, section, play rate, blend, or interruption can make the gameplay window wrong.

Better:

AttackMontage timeline
-> Notify State "MeleeWindow" covers the active swing frames

Common uses

Footsteps

Walk/run animation
-> Notify "Footstep_L" and "Footstep_R"
-> AnimBP event or notify class
-> trace downward for surface if needed
-> Play Sound at Location or Spawn Niagara dust

If footstep notifies come from a Blend Space, check the Blend Space's notify trigger settings and sample weights. Blending multiple locomotion samples can make notify timing feel different than a single sequence.

Melee hit windows

Attack montage
-> Notify State "MeleeWindow"
   Begin: clear hit actors, enable tracing
   Tick: trace weapon path, collect hits
   End: disable tracing

The notify state marks when the swing is allowed to hit. The character/weapon should still own damage rules, duplicate-hit prevention, teams, and server authority.

Sounds and particles

Built-in sound and particle notifies are good for repeatable animation-timed presentation. For gameplay-critical effects, trigger the gameplay state separately or call back into gameplay code intentionally.

Land animation
-> Notify "LandDust"
-> Spawn Niagara at foot/root location

When notifies fail or seem late

Failure What it looks like What to check
Animation never reaches marker Notify does not fire. Montage interrupted, state transitioned away, play rate/section, blend out.
Wrong notify type for callback Play Montage On Notify Begin never fires. Montage Notify vs ordinary notify when using Play Montage callbacks.
Blend weight too low Notify skipped in blends. Trigger weight / minimum trigger weight / Blend Space notify mode.
LOD filter blocks it Works near camera, not far away. Notify filter settings and skeletal mesh LOD.
Server expected it Dedicated server does not run presentation notify. Trigger on Dedicated Server and whether gameplay should be server-owned elsewhere.
Editor preview differs It fires in preview but not PIE, or opposite. Should Fire in Editor and live AnimBP instance.
Listener is in wrong Blueprint Event node never runs. AnimBP/event graph, Play Montage callback, or custom notify class path.

Notifies are timing signals. They do not guarantee that the receiver is valid, that damage is allowed, that a sound asset exists, or that every networked machine should perform the same side effect.

Multiplayer note

Be careful with gameplay authority. A melee notify on a client can be great for local animation timing, but damage should usually be decided by the server.

Safer pattern:

Server-approved attack starts
-> montage plays on relevant machines
-> notify opens local visual/sound window
-> server owns authoritative hit trace or validates hit event
-> replicated result updates health/state

For purely cosmetic footsteps, clients can usually play local sounds. For damage, inventory, score, doors, and pickups, use replicated gameplay state or server RPCs according to the normal networking rules.

The pattern everyone actually uses

Attack montage with hit window:

Character Attack
-> Play Montage AttackMontage
-> set IsAttacking true

Play Montage On Notify Begin
Notify Name == "MeleeWindow"
-> WeaponComponent BeginMeleeTrace

Play Montage On Notify End
Notify Name == "MeleeWindow"
-> WeaponComponent EndMeleeTrace

On Completed or On Interrupted
-> set IsAttacking false
-> ensure WeaponComponent EndMeleeTrace

Footstep:

AnimNotify_Footstep
-> get owning character / mesh location
-> optional Line Trace By Channel downward
-> choose sound by physical material or movement state
-> Play Sound at Location

The notify tells you "the foot hit now." Your gameplay/audio code still decides what to do with that fact.

Lookalikes - which one do I want?

Tool Use when Watch out
Notify One animation moment should trigger something. Can be skipped by blends/filters/interruption.
Notify State A duration/window matters. End cleanup must still be robust if montage is interrupted.
Montage Notify You want Play Montage callback pins. Ordinary notify events and montage callback notifies are easy to confuse.
AnimBP event node Animation Blueprint should react to a notify. Keep gameplay authority outside pure pose logic.
Delay A graph needs a simple unrelated wait. Bad for animation frame timing.
Timer Repeating or scheduled gameplay callback. Not tied to animation frames.
Timeline Blueprint-authored curve over time. Not tied to imported animation frames.

Rule of thumb: notify for animation-timed moments, notify state for animation-timed windows, timers/delays for non-animation scheduling.

Going deeper