Skip to content

Delay, DoOnce, Gate, Sequence, and Latent Flow

At a glance

Lives in: Blueprint API / Utilities / Flow Control - Returns: no data values; these nodes route or resume execution - Can fail by: not firing an output, ignoring repeated latent calls, staying closed/used, or hiding state you forgot to reset - Official docs: Delay and Flow Control

The one-minute version

  • Delay pauses one execution path and resumes later. If the same latent action is called again while pending, repeat calls are ignored.
  • DoOnce lets the first execution pulse through, then blocks future pulses until Reset.
  • Gate lets pulses through only while open. It remembers open/closed state.
  • Sequence sends one incoming pulse through several outputs in order during the same execution chain.
  • These nodes are flow tools, not data ownership. If a gate or DoOnce "fixes" a bug, ask what state it is hiding.
  • Use timers when you need a reusable handle; use explicit variables/enums when the state matters beyond one local graph.

Delay

Delay is a latent node: it starts now and resumes the same execution path after a duration.

Interact
-> Play Sound
-> Delay 0.5
-> OpenDoor

The node does not block the whole game. Other actors, input, Tick, animation, and rendering continue while this execution path waits.

The important beginner behavior is re-entry. If the same Delay node is already waiting, calling it again while it is counting down is ignored. That makes Delay poor for "queue every press" logic:

Button pressed three times quickly
-> first pulse starts Delay
-> second and third pulses hit the same pending Delay and are ignored

Use a timer, queue array, or explicit state machine when repeat requests matter.

DoOnce

DoOnce is a tiny remembered gate:

Enter
-> if not used since reset:
       fire Completed
       remember used
   else:
       do nothing

It is useful for one-time pickups, tutorials, and setup paths:

BeginOverlap
-> DoOnce
-> Show tutorial prompt

Reset input
-> DoOnce Reset

The danger is that it hides the reason a second execution did not happen. If a door sometimes stops responding, check whether a DoOnce was never reset.

Gate

Gate has an Enter input plus Open, Close, and Toggle controls. The gate stores open/closed state.

OpenGate event -> Gate Open
CloseGate event -> Gate Close

Event Tick
-> Gate Enter
-> if open, run while-open logic

Use Gate for "let pulses through while a condition is active" when the active state is local to the graph and easy to reset.

For gameplay state other systems care about, prefer a named variable or enum:

Better for shared state:
    bIsAiming = true/false
    Event Tick -> Branch bIsAiming

The branch is less magical because the state has a name and can be inspected, replicated, saved, or printed.

Sequence

Sequence takes one incoming execution pulse and fires output pins in order: Then 0, Then 1, Then 2, and so on.

BeginPlay
-> Sequence
   Then 0: Create HUD
   Then 1: Bind health events
   Then 2: Start intro timer

It does not make those outputs parallel. They run in order in the same call chain. If Then 0 changes a variable, Then 1 sees the changed value.

Use Sequence sparingly. It can make setup readable. It can also turn one event graph into a hidden checklist of unrelated responsibilities. If the pins need labels to be understandable, split the work into named functions.

When these nodes fail

Flow-control nodes usually fail by not sending execution where you expected.

Node Failure shape What to inspect
Delay Completed never reaches when you expect, or repeat calls are ignored. Duration, world pause/time, destroyed owner, and whether the same latent action is pending.
DoOnce First pulse works; later pulses do nothing. Whether Reset ever runs on the same node instance.
Gate Enter pulses disappear. Open/Close/Toggle calls and Start Closed.
Sequence Later work sees changed state from earlier pins. Output order and side effects in each branch.
DoN / MultiGate It stops after a count or routes unexpectedly. Reset path, count, random/loop settings.

None of these nodes log a warning just because an output does not fire. Use breakpoints or Print String before and after the node while debugging.

What they do not do

  • They do not create gameplay state you can easily inspect elsewhere.
  • They do not replicate execution to other machines.
  • They do not protect object references from becoming None.
  • Delay does not create a timer handle you can clear later.
  • DoOnce and Gate do not explain themselves in logs; you must reset/open them deliberately.
  • Sequence does not run pins at the same time.

The pattern everyone actually uses

For a one-time pickup:

OnComponentBeginOverlap
-> Branch Other Actor is player
-> DoOnce
-> Add item to inventory
-> Play pickup sound
-> Destroy Actor

For a door with real state, use an enum instead of a hidden gate:

Interact
-> Switch on EDoorState
   Closed:
       Set DoorState = Opening
       Play open timeline
   Opening:
       do nothing
   Open:
       Set DoorState = Closing
       Play close timeline
   Closing:
       do nothing

For a short presentation pause:

Player died
-> Set View Target with Blend to death camera
-> Delay 1.5
-> Ask GameMode to Restart Player

If that respawn delay needs cancel/pause/replace behavior, use Set Timer by Event instead.

Lookalikes - which one do I want?

Node/tool Use when Watch out
Delay One local execution path should resume later. Repeat calls while pending are ignored.
Set Timer by Event You need a delayed/repeating callback with a handle. Store and clear the handle.
DoOnce First pulse should pass, then wait for reset. Missing reset looks like a dead graph.
Gate Pulses should pass only while locally open. A named boolean/enum is clearer for shared state.
Sequence One event has several ordered setup steps. It is ordered, not parallel.
Branch A boolean condition decides the path. The condition must be updated by real state.
Switch on Enum A named mode decides the path. Better than chains of contradictory booleans.

Rule of thumb: use flow nodes for local routing, and variables/enums for gameplay state you need to reason about later.

Going deeper