Skip to content

Breakpoints and watch values

Print String tells you that something happened. Breakpoints and watches let you stop at the exact node and inspect what the graph knew at that moment.

The one-minute version

  • A breakpoint is a marker on a Blueprint node. During Play In Editor or Simulate In Editor, execution pauses when that node is about to run.
  • A watch value tracks the most recent debug value for a pin or variable so you can inspect it while debugging.
  • Breakpoints work on the Blueprint instance that is actually executing. If the breakpoint never hits, first check the debug object / instance selector.
  • Watched pins only have meaningful values after the node that owns that pin has executed. "No debug data" usually means "this node has not run yet."
  • Stepping follows execution wires. It does not advance all gameplay forever; while paused, you are inspecting one stopped script context.
  • Debugger state is editor tooling. It does not fix the graph, replicate gameplay, or replace guards such as Is Valid.

What a breakpoint actually does

Blueprint execution normally runs too fast to inspect. A breakpoint tells the editor: "when this node is reached in a running play or simulate session, pause here before continuing."

pseudocode of the editor behavior - not engine source

Event Interact
-> Line Trace By Channel
-> Branch
-> Open Door

breakpoint on Branch:
    if this Blueprint instance reaches Branch during PIE:
        pause PIE
        focus the Blueprint editor near Branch
        allow stepping and value inspection

The breakpoint belongs to a node in a Blueprint asset, but the code that hits it belongs to a live instance. That distinction is the source of many "the breakpoint does nothing" moments:

flowchart LR
    Asset[BP_DoorButton asset] --> A[DoorButton_1 in level]
    Asset --> B[DoorButton_2 in level]
    B --> Event[Only DoorButton_2 receives Interact]

If you are watching DoorButton_1 while DoorButton_2 is the instance that receives the event, your breakpoint and values will feel wrong even though the graph is working.

Adding and using a breakpoint

Beginner workflow:

  1. Put a breakpoint on the first node you believe should run.
  2. Press Play.
  3. Trigger the gameplay moment.
  4. When execution pauses, inspect the node, pins, variables, and call stack.
  5. Step forward along the execution path.

For an overlap bug:

OnComponentBeginOverlap
-> Cast To BP_PlayerCharacter
-> Open Door

Put the first breakpoint on OnComponentBeginOverlap. If it never hits, the problem is not the cast or door function yet; the overlap event did not run for the instance you are debugging.

If it hits, step to the cast:

Other Actor = ?
Cast Success path or Cast Failed path?

Now you know whether the event fired and what actor it received.

Watch values

A watch value is a note to the debugger: "show me this pin's value when debug data exists."

Good things to watch:

Suspicion Watch
Cast keeps failing. The cast input object and the Cast Failed path.
Accessed None warning. The object reference immediately before the call.
Branch goes the wrong way. The Branch condition pin.
Trace hits the wrong thing. Return Value, Hit Actor, Impact Point.
Animation state is wrong. GroundSpeed, IsFalling, OwnerCharacter.

The most important rule: a pin value is not timeless. A watched pin shows the value from the most recent execution of the node that owns it. If the node has not executed yet in this play session, the debugger has no value to show.

That explains this common beginner trap:

Event Tick
-> Get Health
-> Branch Health <= 0

If you watch the Health output before anything has executed that Get Health node, the debugger cannot show the current health through that pin yet. Put a breakpoint earlier, let execution reach the node, then inspect.

Stepping and execution flow

Once paused, stepping answers "what runs next from here?" It is not the same as pressing Play and hoping the next frame tells you.

Use it to test mental models:

Breakpoint on Interact event
Step -> Line Trace By Channel
Step -> Branch
Inspect Return Value
Step -> Success path or failure path

This is especially useful for pure nodes. Pure nodes have no white execution wire, so beginners often think they "run in the background." They do not. The compiler evaluates them when an executing node needs their output.

Branch condition needs IsValid(TargetDoor)
-> pure IsValid is evaluated for that Branch

If you need to know whether a pure value was computed, watch the pin while stepping through the impure node that consumes it.

Why the breakpoint does not hit

Breakpoints fail by silence. The game keeps running and the editor never pauses.

Common causes:

  1. The graph path never executes. The event did not fire, the branch took the other path, or the function was never called.
  2. You are debugging the wrong instance. Pick the placed actor, widget, or Animation Blueprint instance that is actually running.
  3. The node is inside a class that is not in the play world. Editing the asset is not the same as having an instance executing in Play In Editor.
  4. The breakpoint is disabled. A disabled breakpoint is saved but ignored.
  5. The breakpoint is invalid. Compile the Blueprint and hover the warning icon to see why the editor cannot place it.
  6. The Blueprint is stale. Compile after changing nodes, function signatures, macros, or interface implementations.
  7. You expected another machine to pause. In multiplayer PIE, server and clients are separate worlds. Debug the world where the graph runs.

Use a cheap discriminating print only when you are unsure whether the graph is being reached at all:

Event Interact
-> Print String "Interact reached on " + ToString(self)
-> breakpoint on next node

If the print appears and the breakpoint does not, inspect breakpoint state and debug instance. If neither appears, the event path is not being called.

Picking the right debug instance

The debugger is most useful when you are explicit about the live object you are inspecting.

Examples:

Blueprint Instance to pick
BP_DoorButton The specific placed door button you walked up to.
BP_Enemy The enemy that is currently chasing or not chasing you.
WBP_HealthBar The widget instance currently on the viewport.
ABP_Manny The animation instance attached to the mesh that is animating.
Level Blueprint The current level's script instance during PIE.

Animation Blueprints deserve extra care. Preview, editor Persona views, and live Play In Editor instances can all exist. If your watched OwnerCharacter is None, make sure you are not inspecting a preview instance while expecting the live possessed pawn.

What breakpoints and watches do not do

  • They do not change gameplay state unless you manually edit something while paused.
  • They do not make a bad reference valid. They only show you that it is bad.
  • They do not prove code is correct on every instance. They prove what happened for the instance and path you exercised.
  • They do not replace Print String when you need a quick log over time.
  • They do not replace Output Log warnings such as Accessed None; use the warning to find the suspect node, then debug there.
  • They do not ship with your game as a feature. They are editor debugging tools.

The pattern everyone actually uses

For "my door does not open":

1. Breakpoint on input or interact event.
   If it does not hit, input/trace/interface call is the problem.

2. Breakpoint on the branch before OpenDoor.
   Watch the condition.

3. Step into or over OpenDoor.
   Watch bIsOpen and the timeline Play node.

4. If a reference is None, follow where that reference should be assigned.

For an Animation Blueprint:

1. Pick the live animation instance in the debug selector.
2. Breakpoint on Event Blueprint Update Animation.
3. Watch OwnerCharacter, GroundSpeed, IsFalling.
4. Step through the Is Valid branch.
5. If OwnerCharacter is None, debug Initialize Animation / Try Get Pawn Owner.

For a trace:

1. Breakpoint after Line Trace By Channel.
2. Watch Return Value.
3. Break Hit Result only on the true path.
4. Watch Hit Actor, Hit Component, Impact Point.

The C++ equivalent is not "a Blueprint breakpoint." In C++, use the debugger in your integrated development environment, log with UE_LOG, or break in the native function that the Blueprint eventually calls.

Lookalikes - which one do I want?

Tool Use when Watch out
Breakpoint You need execution to pause on a node. Wrong debug instance makes it look broken.
Watch value You need to inspect a pin or variable while debugging. A pin has useful data only after its node executes.
Hover tooltip while paused You need a quick value near the current node. It is contextual and temporary.
Execution Trace You need the recent node path. It shows what ran; it does not explain why by itself.
Call Stack You need to know which function/event led here. Macros are folded into the calling function.
Print String You need quick evidence over time without pausing. It is noisy and development-only.
Output Log You need warnings, history, and searchable text. It can be hard to connect a log line to the current instance.

Rule of thumb: print to find broad timing, break to inspect a moment, watch to understand values, and read the Output Log when Unreal already told you what went wrong.

Going deeper