Visual Logger, EQS Debugger, and ShowDebug Boundaries¶
Print String proves a moment. The Gameplay Debugger shows a live actor. Visual
Logger records a timeline. EQS debug views explain a query. showdebug asks a
view target or engine system to draw its debug data. Use the smallest tool that
answers the question.
At a glance
Use this for: deciding between Print String, Gameplay Debugger, Visual
Logger, EQS Testing Pawn, and showdebug-style console overlays -
Main split: live overlay vs recorded timeline vs query preview vs
view-target debug - Beginner rule: record or visualize only the facts
that prove one suspicion - Official docs:
Visual Logger,
AI Debugging,
and Console Commands Reference
The one-minute version¶
- Use Print String / Output Log when you need a fast timestamped fact from one Blueprint path.
- Use the Gameplay / AI Debugger when you need the live selected AI pawn, controller, NavMesh, Behavior Tree, Blackboard, EQS, or Perception state.
- Use Visual Logger when the important part already happened and you need to scrub actor snapshots, messages, paths, or shapes over time.
- Use EQS debug views when the question is "why did this query choose or reject these candidate locations?"
- Use an EQS Testing Pawn to preview a query in the editor without running the full enemy behavior.
- Use showdebug / DisplayDebug-style overlays when a built-in system or current view target exposes useful debug data through the console.
- Do not turn every tool on at once. Each one has a different owner, audience, and cost.
The decision rule¶
Start with the question:
| Question | Tool |
|---|---|
| Did this Blueprint path run here? | Print String or Output Log. |
| What value is on this pin right now? | Blueprint breakpoint/watch value. |
| Which AI pawn/controller/tree/key is live? | Gameplay / AI Debugger. |
| Why did Move To or perception behave this way live? | Gameplay / AI Debugger plus targeted prints. |
| What happened two seconds before the AI made a bad choice? | Visual Logger. |
| Why did this EQS query choose that point? | AI Debugger EQS category or EQS Testing Pawn. |
| What does the current view target/system expose through debug drawing? | showdebug / console overlay. |
Do not choose the fanciest tool. Choose the one that answers the narrowest question with the least extra noise.
Visual Logger¶
Visual Logger records debug information and lets you inspect it later in an editor viewport. It is useful when the bug is:
- rare;
- timing-sensitive;
- visible only after the important frame has passed;
- easier to understand from a path/shape than a text print;
- reported from a clip or playtest where you need to reconstruct what the AI thought.
Open it from:
Window
-> Developer Tools
-> Visual Logger
The useful mental model:
Actor list:
which actors logged data
Timeline:
scrub to the moment of interest
Snapshot view:
selected actor state at that time
Text window:
log messages for that frame
Shapes:
paths, points, cones, boxes, or other logged spatial evidence
For Blueprint beginners, Visual Logger is mostly a review tool for engine/AI systems and any project code that already logs to it. Custom Visual Logger output is usually C++ work.
What to record¶
Record facts that explain a decision:
AIController:
target actor
last known location
current state/branch
requested move destination
path result
Pawn:
health/dead/stunned state
movement mode
attack cooldown
current montage
Perception:
sensed actor
stimulus location
successfully sensed / lost
EQS:
query name
context actor/location
winning item
failed/filtered candidate reason
Avoid recording everything because it exists. High-volume logs become another debugging problem.
What to ignore¶
Do not use Visual Logger for:
- every Tick value that can be watched more simply;
- UI widget ownership bugs where a local print is enough;
- one obvious Accessed None warning;
- per-frame inventory slot rebuilds;
- broad "something is wrong" sessions with no question;
- shipping telemetry or analytics;
- secrets, personal data, or player-report data you do not need.
The logger is strongest when you can say:
I need to inspect the five frames around the moment this AI switched from
Chase to Patrol even though the player was visible.
EQS debug views¶
EQS debugging is for query decisions. It is not a general AI requirement.
Use it when your AI asks the environment a scored question:
- best attack spot with line of sight;
- nearest reachable health pickup;
- cover point with distance and visibility tests;
- flee location away from the player;
- patrol point that satisfies project rules.
Runtime path:
AI runs EQS query
-> open AI Debugger with apostrophe
-> Numpad 3 toggles EQS category
-> inspect generated items, failed items, scores, and winner
Editor-preview path:
Create Blueprint based on EQSTestingPawn
-> place it in the level
-> assign Query Template
-> move pawn/context and inspect colored spheres/scores
Read blue/failed candidates as "this test filtered the item out," not "EQS is broken." Read green-to-red or score values as "this item passed and received a relative score," not "the AI must always choose the greenest-looking sphere from my camera angle."
EQS boundaries¶
EQS is past the first patrol/chase loop. Do not add it because the enemy is
stuck on a missing NavMesh or never sets TargetActor.
Use this order:
1. Pawn is possessed by AIController.
2. NavMesh exists.
3. Perception or target assignment works.
4. Blackboard keys are correct.
5. Behavior Tree branches switch correctly.
6. Move To works with normal actor/vector targets.
7. Now add EQS if position choice is the real problem.
If step 2 fails, EQS will produce clever-looking debug spheres around a broken movement setup. Fix the boring owner first.
ShowDebug and DisplayDebug¶
showdebug-style console overlays are different from the Gameplay Debugger.
They ask a view target or system to draw built-in debug information on the
screen.
Useful mental model:
Console command:
showdebug SomeCategory
Engine/system:
draws debug text/data for the current view target or category
Actor hook:
AActor::DisplayDebug can contribute actor-specific debug display
Use this when:
- the system you are testing documents a
showdebugcommand; - you need current view target information;
- a built-in plugin exposes its own debug category;
- you want a quick overlay without selecting an AI actor through Gameplay Debugger categories.
Do not assume every Blueprint variable appears in showdebug. Your project
has to expose useful data through the relevant system or code path.
Console command boundaries¶
Console commands are broad. Some draw, some dump to the log, some toggle runtime state, some simulate network conditions, and some are development-only.
For a beginner:
- use documented commands from the page or system you are debugging;
- write down the command you changed and how to turn it off;
- prefer editor UI/debugger controls when they answer the question;
- do not leave debug draw/state toggles enabled and then tune gameplay around them;
- avoid destructive or performance-heavy commands unless you understand the target.
If you are unsure whether a command changes state or only displays data, look it up before running it.
Tool combinations that work¶
Move To fails¶
AI Debugger:
Numpad 0 NavMesh
Numpad 1 path following / movement mode
Print:
Move To result, target actor, destination
Visual Logger:
only if the failure is intermittent and you need to scrub path history
Enemy loses target incorrectly¶
AI Debugger:
Numpad 4 Perception
Numpad 2 Blackboard TargetActor / LastKnownLocation / HasLineOfSight
Breakpoint:
On Target Perception Updated
Visual Logger:
record target changes and last-known-location around the lost sight moment
EQS cover point is bad¶
EQS Testing Pawn:
preview query and contexts in editor
AI Debugger:
Numpad 3 live query while behavior runs
Visual Logger:
scrub query results if the bad choice is intermittent
Multiplayer replication feels delayed¶
Print:
net mode, authority, local control, owner, value
Multiplayer PIE Debugger route:
pick correct server/client window and actor
Network Emulation:
repeat after clean no-emulation pass works
Visual Logger:
only if project/engine code logs the state you need over time
When it fails, and what failure looks like¶
| Symptom | Likely cause |
|---|---|
| Visual Logger has no actor data | Nothing logged for that actor, wrong actor selected, recording not active, or the system does not emit Visual Logger data. |
| Timeline is full of noise | You logged too much or did not filter by one actor/question. |
| EQS spheres appear but choice seems wrong | Context, generator, filter, scoring, or nav agent settings differ from your mental model. |
| EQS category shows nothing in AI Debugger | No active/running query, wrong selected AI, or query finished before you inspected it. |
| EQS Testing Pawn hangs the editor | Query/generator density is too expensive; clear the query while editing and add a time limit. |
showdebug displays the wrong thing |
The current view target/category is not the actor/system you meant to inspect. |
| Console command changed gameplay state | The command was not only a display toggle; turn it off or restart the test. |
| More tools made the bug less clear | You skipped the first precise question and collected unrelated debug data. |
The fix is usually to narrow the question, pick one actor, record one short window, and compare one expected value with one observed value.
What these tools do not do¶
- Visual Logger does not automatically capture every Blueprint variable.
- Visual Logger does not replace a live breakpoint when you need a pin value right now.
- EQS debug views do not explain non-EQS movement, possession, or perception setup bugs.
- EQS Testing Pawn does not prove the full Behavior Tree is wired correctly.
showdebugdoes not expose arbitrary project state unless a system or actor implements useful debug display.- Console commands do not all mean "display only."
- None of these tools fix authority, ownership, stale references, or invalid Blackboard keys by themselves.
Lookalikes - which one do I want?¶
| Tool | Use when | Not for |
|---|---|---|
| Print String | One Blueprint path/value needs quick proof. | Timeline review or spatial path history. |
| Output Log | You need persistent labeled text. | Seeing world-space candidate locations. |
| Breakpoint/watch value | You need to pause and inspect pins. | Reviewing what happened before you paused. |
| Gameplay / AI Debugger | Live selected AI stack and categories matter. | Recording a rare bug after the fact. |
| Visual Logger | Actor snapshots, messages, and shapes over time matter. | Beginner-only Blueprint values with no visual log output. |
| EQS Testing Pawn | Query candidate generation/scoring needs editor preview. | Full AI behavior, combat, or networking. |
| AI Debugger EQS category | A live AI is currently running an EQS query. | A query asset that has not been run. |
| showdebug | A view target/system exposes documented debug display. | AI-specific selected actor categories or arbitrary widgets. |
The quick path is to leave every debug overlay on and hope one of them explains the bug. The concrete cost is noise. Pick the tool that owns the evidence you need, then turn it off when the question is answered.
Going deeper¶
- Gameplay Debugger and AI Debugger for Blueprint Beginners - live AI category selection and reading order.
- Simple Patrol, Chase, Attack, and AI Debugging - the first AI loop and debug layers.
- Multiplayer PIE debugging basics - labeled prints and correct server/client debug worlds.
- Network Emulation for beginner replication checks - latency/loss tests after clean replication works.
- Print String and the Output Log - first-line text evidence.
- Breakpoints and watch values - pausing the live Blueprint instance.
- Official docs: Visual Logger, AI Debugging, Environment Query System, Environment Query Testing Pawn, Console Commands Reference, and AActor::DisplayDebug.
- Engine/editor source (requires engine access - we do not reproduce it
here): Visual Logger runtime declarations start in
Engine/Source/Runtime/Engine/Public/VisualLogger/VisualLogger.hwith implementation underEngine/Source/Runtime/Engine/Private/VisualLogger/; Visual Logger editor UI lives in LogVisualizer/VisualLogger editor modules; EQS runtime and testing support live underEngine/Source/Runtime/AIModule/Private/EnvironmentQuery/;showdebugactor output starts atAActor::DisplayDebuginEngine/Source/Runtime/Engine/Private/Actor.cppwith declarations inEngine/Source/Runtime/Engine/Classes/GameFramework/Actor.h.