Skip to content

Print String and the Output Log

At a glance

Lives in: Blueprint API / Development - Returns: no data; it passes execution through Out - Fails by: producing no visible message where you expected one - Main inputs: In String, Print to Screen, Print to Log, Text Color, Duration, and Key - Official docs: Print String

The one-minute version

  • Print String is a development debugging node. Use it to prove what ran and what value a pin had at runtime.
  • Print to Screen shows an on-screen debug message. Print to Log writes a visible Output Log line. They are separate switches.
  • The In String pin is a String. If you connect a number, object, vector, boolean, or name, Blueprint inserts or offers a conversion to string.
  • Duration only controls the on-screen message. It does not keep a log line alive or delay execution.
  • Key is the anti-spam pin. A non-empty key replaces the existing on-screen message with the same key instead of stacking a new line every frame.
  • Do not use Print String for player-facing UI or shipping diagnostics. It is marked as development-only engine debug output.

What it actually does

Print String takes the value on In String, then sends it to one or both debug destinations:

pseudocode of the engine behavior - not engine source

function PrintString(WorldContext, InString, Options):
    if PrintToScreen and on-screen debug messages are available:
        add or replace an on-screen debug message
            message = InString
            color = TextColor
            duration = Duration
            key = Key

    if PrintToLog:
        write InString as a visible log message
    else:
        write only lower-visibility verbose debug output

    continue execution through Out

The node does not pause the game. It does not return the string. It is just a debug side effect placed in the execution path.

That makes it ideal for answering narrow questions:

Did this overlap event run?
-> Print String "Door trigger begin overlap"

Which actor did my trace hit?
-> Hit Actor -> To String (Object) -> Print String

How fast is my AnimBP seeing the character?
-> GroundSpeed -> To String (Float) -> Print String

Once the question is answered, remove or gate the print. A graph full of old prints turns the Output Log into noise.

Screen vs Output Log

The two checkboxes answer different debugging needs:

Destination Use when Watch out
Print to Screen You need immediate feedback while playing. Fast to see, easy to miss, and cluttered by Tick spam.
Print to Log You need searchable history after the moment passed. The log can be noisy; include context in the message.

For a one-frame trace, screen output is usually enough:

Line Trace By Channel
-> Branch Return Value
-> Print String "Hit: " + HitActorName

For setup bugs, the Output Log is better:

BeginPlay
-> Print String
   In String = "BP_DoorButton BeginPlay: TargetDoor=" + ToString(TargetDoor)
   Print to Screen = false
   Print to Log = true

That line survives long enough to search, copy, and compare across attempts.

The Key pin

Without a key, repeated prints add repeated on-screen messages. That is awful on Tick:

Event Tick
-> Print String "Speed = 423.5"

A non-empty Key tells the on-screen debug system: "replace the message with this key instead of adding another one."

Event Blueprint Update Animation
-> Print String
   In String = "GroundSpeed = " + ToString(GroundSpeed)
   Print to Screen = true
   Print to Log = false
   Duration = 0.1
   Key = AnimGroundSpeed

Now the screen shows one updating line instead of a stack. Use stable keys for live values:

Debug value Good key
Player speed PlayerSpeed
Current interact target InteractTarget
Door trigger count DoorTriggerCount
AI state AIState

The key only helps if you reuse the same key for the same message slot. A different key is a different slot.

Duration and color

Duration controls how long the on-screen message remains visible. It does not delay the Blueprint and it does not affect Output Log history.

Good beginner defaults:

Situation Duration
One button press or one overlap 2.0 seconds
Tick or animation update with a Key 0.0 to 0.1 seconds
A setup print you only want in the log screen off; duration irrelevant

A negative duration uses the engine's configured default display time. That can be convenient, but an explicit value is clearer when you are teaching yourself what a graph is doing.

Text Color is screen presentation. Use it sparingly: for example, green for a success branch and red for a failure branch while debugging a specific graph. The Output Log line is not a styled UI label.

Printing values that are not strings

The In String pin wants a String. Blueprint can convert many values:

Float -> To String (Float) -> Print String
Vector -> To String (Vector) -> Print String
Object -> To String (Object) -> Print String
Boolean -> To String (Boolean) -> Print String

Make the message include the variable name and context, not just the raw value:

"GroundSpeed=" + ToString(GroundSpeed)
"OtherActor=" + ToString(OtherActor)
"HasKey=" + ToString(bHasKey)

Bad debug print:

42

Useful debug print:

BP_DoorButton Interact: CurrentDoor=None

The second one tells you which Blueprint, which moment, and which variable. That matters when five Blueprints are printing at the same time.

When it fails (and what failure does)

Print String has no Failed pin. The usual failure is "I expected to see a message, but I did not."

Common causes:

  1. The execution wire never reached the node. Put the print earlier in the graph or use a breakpoint to find where execution stops.
  2. Print to Screen is off. The node can be logging only.
  3. Print to Log is off. The message may not appear as a normal Output Log line.
  4. The duration is too short. A screen message with a tiny duration can appear and vanish between glances.
  5. A Key is replacing it. Another print with the same key may overwrite the message immediately.
  6. You are in a Shipping-style build path. The node is marked development-only; do not depend on it for shipped behavior.
  7. You are watching the wrong instance. A different placed actor, widget, or Animation Blueprint instance may be running the graph.

Failure does not stop execution, repair your graph, throw a Blueprint error, or prove the value was empty. It only means the debug message was not visible in the place you checked.

What Print String does not do

  • It does not create UI. Use widgets for player-facing text.
  • It does not save telemetry or analytics.
  • It does not run in place of breakpoints, watches, or the debugger when you need exact execution state.
  • It does not fix Accessed None. It only helps you find where the reference becomes None.
  • It does not replicate. A print runs on whichever machine executed that graph.
  • It does not guarantee useful output in Shipping builds.

The pattern everyone actually uses

For an overlap that never fires:

OnComponentBeginOverlap
-> Print String "Trigger begin: OtherActor=" + ToString(OtherActor)
-> Cast To BP_PlayerCharacter
   Success:
       Print String "Player entered trigger"
   Failed:
       Print String "Non-player overlap: " + ToString(OtherActor)

For an Accessed None setup bug:

BeginPlay
-> Print String
   "Set TargetDoor from details: " + ToString(TargetDoor)
   Print to Log = true

Interact event
-> Is Valid (TargetDoor)
   Is Valid:
       Print String "Opening " + ToString(TargetDoor)
       TargetDoor.Open
   Is Not Valid:
       Print String "TargetDoor missing on " + ToString(self)

For C++, use real logging for code you intend to keep:

UE_LOG(LogTemp, Warning, TEXT("Current target: %s"),
    *GetNameSafe(CurrentTarget));

Use GEngine->AddOnScreenDebugMessage only for temporary on-screen debugging:

if (GEngine)
{
    GEngine->AddOnScreenDebugMessage(
        42,
        2.0f,
        FColor::Yellow,
        TEXT("Interact trace hit"));
}

Lookalikes - which one do I want?

Tool Use when Watch out
Print String Temporary Blueprint debug output from a string. Development-only; remove or gate noisy prints.
Print Text Your value is already Text or you are inspecting localized text data. Still debug output, not a UI widget.
Output Log You need history, search, warnings, or copied evidence. Include context in the message or it becomes noise.
Breakpoint You need execution to pause on a node. Requires the right debug instance during play.
Watch value You need pin or variable values while paused. A pin has a useful watched value only after its node has executed.
Draw Debug String / Line / Shape The debug information belongs at a world location. These are spatial debug helpers, not general logs.
Widget text The player should see it as part of the game. Do not ship Print String as UI.

Rule of thumb: Print String answers "did this run and what value did I have?" Use the Blueprint Debugger when you need to step, watches when you need state, and widgets/logging systems when the output is part of the product.

Going deeper