This is the master distinction, and it explains most of the confusing errors in this area.
Latent — Delay, Retriggerable Delay
Pauses and resumes across frames. Needs an execution context that survives multiple frames.
Not latent — Set Timer
A normal call that returns instantly and schedules a callback with the timer manager.
2
Where Each Is Allowed
Context
Delay / latent
Set Timer
Event Graph
Yes
Yes
Function
No
Yes
Macro
Only if the macro is used in an Event Graph
Yes
Construction Script
No
Yes, though rarely useful
Functions must run and return within one frame, so no latent nodes at all.
Macros are graph substitution with no context of their own. A macro containing a Delay works in an Event Graph but throws a compile error the moment it's used inside a Function.
Timelines likewise can't live in Macros or Functions. They need a persistent UTimelineComponent on an owning Actor instance, so they're Event-Graph-only.
A classic footgun. Wrap a Delay in a macro for reuse, then break it the moment someone drops that macro into a function. The macro looks innocent; the error appears somewhere else entirely.
3
Timers in Depth
Set Timer by Event binds a custom event, which lives in the Event Graph.
Set Timer by Function Name takes a function name — useful when you need delayed behavior from inside a function, where a Delay is illegal. Add a looping flag if needed.
It returns a Timer Handle you can store, to pause, clear, query or invalidate the timer.
Timers can loop on a fixed interval, and are auto-cleared if the owning object is destroyed.
4
Delay Behavior
Plain Delay is non-retriggerable — calling it again while it's counting down is ignored.
Retriggerable Delay resets the countdown on each call, which is what you want for debounce.
Each Delay node tracks its own latent action per instance.
The debug-node duration convention
For Draw Debug nodes, Duration = 0 means one frame. For Print String, a 0 duration makes it disappear near-instantly. The intuition is inverted between the two — an easy one to trip on.
5
Choosing Between Tick, Timer and Delay
Tool
Use it for
Watch out for
Tick
Continuous per-frame work — smooth interpolation, following
Use sparingly; see Chapter 11
Timer
Something after a delay or on a repeating interval, decoupled from frame rate — cooldowns, periodic checks, spawning waves
More efficient than a tick-with-a-counter; returns a handle you can cancel
Delay
A simple inline sequence — do A, wait two seconds, do B
Blueprint-only; doesn't stack cleanly if re-triggered mid-run; wrong for precise or high-frequency timing
The rule. Per-frame goes to Tick. Recurring or scheduled goes to a Timer. A simple inline pause goes to Delay.
Interview drill
Answer out loud before re-reading the chapter.
Timers versus Tick versus latent nodes like Delay: when does each make sense?
6
Blueprint Threading & Async
Blueprint "async" and latent nodes still call back on the Game Thread. They don't give you true multithreading.
True off-thread work requires C++, with results marshaled back to the Game Thread.
The Blueprint-native "fire and forget with callback" pattern is async nodes plus delegates.
Mental model. Blueprints schedule work; C++ does the heavy lifting off-thread.
EQS and Behavior Tree ticks have some engine-level optimization, but their Blueprint-exposed nodes still run on the Game Thread. If perception or spatial queries get heavy, move them to C++ with async dispatch.