> For the complete documentation index, see [llms.txt](https://postica.gitbook.io/binding-system-3/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://postica.gitbook.io/binding-system-3/project-tools/diagnostics/live-debug.md). # Live Debug See the value at every stage of one binding, live. The value your field receives is the result of four stages. When it is wrong, the useful question is *which stage* made it wrong. Live Debug answers that directly by showing all of them. {% hint style="success" %} **Learn by doing:** [A Health Bar with No Driver Class](/binding-system-3/tutorials/health-bar.md) turns Live Debug on partway through building a binding, which is when it is most useful. {% endhint %} ## Turning it on Two ways: * The **debug icon** on the bind row. Its tooltip when off reads *Live Debug is Inactive. Click to enable it*. * The bind menu, under **Settings ▸ Live Debug**. It is per binding, and it is a serialized flag, so it survives a domain reload and it is visible to anybody who opens the scene.

## What it shows One row per stage, in pipeline order:

Row	What it shows
Path	What came out of the source at the end of the path, in the source's own type.
Converter	What the converter produced.
Modifier, one per modifier	What each modifier did, in order, so you can see exactly where the value stopped being what you expected.
Output	The value your field received.

A read/write binding shows two columns: the read chain, running down from the source, and the write chain, running back up to it. A stage that produced no value shows **Undefined** rather than a stale one, which distinguishes "nothing happened" from "the result happens to be zero". An exception anywhere in the chain is shown in place, with its message and source, plus the stack trace behind a developer detail. You do not have to go looking in the Console.

An exception reported inside the pipeline

## Overriding a stage The debug fields are real editor fields, not labels. Type a value into one and it is **pinned** onto that stage: the stage reports your value instead of the one it computed, and every stage after it carries on from there. That is how you test the second half of a chain without arranging for the first half to produce the value for real. A remap that only misbehaves above 0.9, a converter you want to see fed a negative number, a modifier chain whose source will not exist until three scenes later: pin the value and read off what comes out.

A pinned stage, and the pipeline recomputed from it

### An override never reaches the binding Only the debug chain reads it. The game keeps running on the real value, the scene is not modified, and nothing is written to the source. What you are looking at is what the rest of the pipeline *would* make of the value you pinned. ### Releasing it A pinned stage is drawn in violet and grows a revert button. Three ways back to the real value:

Action	What it does
The revert button on the stage	Releases that one stage.
Clear Debug Overrides in the bind menu	Releases every pinned stage of that binding. The entry appears only while there is something to release, and counts them.
Switching Live Debug off	Releases them too. A pinned value never outlives the panel that showed it.

Overrides are not serialized. They belong to a debugging session: they are never saved into the scene, and a script recompile drops them. ### What can be pinned Numbers, `bool`, `string`, `char`, enums, object references, `Color`, the vector and rect and bounds types, `Quaternion` and `LayerMask`. A stage carrying anything else, a custom struct or an interface, is shown as text and says so in its tooltip. It stays selectable, so the value can still be copied. `AnimationCurve` and `Gradient` are the deliberate exceptions. The editor has a field for both, but they are objects the source owns and their editors work on the instance they are given, so pinning one could quietly rewrite a curve on the bound object. An override must never change anything outside the debug chain, so those two stay read only. {% hint style="info" %} A rotation is pinned through its Euler angles, which is what the row shows. Expect the value to be normalised back into range. {% endhint %} {% hint style="warning" %} In the legacy IMGUI Inspector the debug row is a single line split between two columns, which leaves no room for a vector or a bounds field. There, pinning is offered for the types that fit one narrow field: numbers, `bool`, `string`, `char`, enums, object references and `Color`. A value pinned in the UI Toolkit Inspector is still honoured by both. {% endhint %} ## At edit time Live Debug reports while you author, not only while the game runs.

Column	What it means
Read	Works. The source is read through the very same accessors the binding uses, so the path, the converter and the read modifiers all report as they do in play mode.
Write	Reports Undefined until something writes to the binding, which outside play mode nothing does. Pin its input and the write modifiers and the write converter compute from there.

That second row is the pairing worth remembering: at edit time the write pipeline is exercised by pinning its input, not by running the game. Reading a path at edit time means calling into your own code on every Inspector tick, which is a thing a project may reasonably not want. It is therefore a setting: **Visualization ▸ Debug At Edit Time**, on by default. Turn it off and Live Debug goes back to reporting during play mode only. {% hint style="info" %} Because it reads through the real accessors, a path that ends in a **method** is called at edit time, on every tick, exactly as [Path Value Preview](/binding-system-3/project-tools/diagnostics/path-value-preview.md) does. If that method has side effects, leave Live Debug off on that binding while authoring. {% endhint %} ## Realtime Debug By default the debug values refresh when the Inspector repaints, which for a mouse that is not moving means not very often. Turn on **Visualization ▸ Realtime Debug** in the [settings](/binding-system-3/reference/settings.md#visualization) and they refresh at 60Hz instead. Values react instantly while the game runs, at the cost of a constant repaint. {% hint style="warning" %} Leave Realtime Debug off unless you are actively debugging. It repaints the Inspector continuously, which is noticeable on a large one. {% endhint %} Pinning a value does not wait for the next refresh either way. The stages after it recompute as soon as you commit the field. ## When to use something else

Situation	What to use
You only want to check what a path returns	Path Value Preview, which is lighter and does not open the debug rows.
You want a value in the Console, or in a file	The Value Logger modifier. See the catalogue.
You want to know what all bindings are doing	Bindings Monitor.
The field is red before you even run	Error Visualization already says why.
You want the binding to actually run while you author	The EDITOR update point, which drives a proxy binding for real. Live Debug only reports; it never writes.

## Cost Live Debug costs real work: every stage has to keep its intermediate value so it can be shown. It is on per binding, so the cost is scoped to the bindings you are looking at. Turn it off when you are done. At edit time the work is the Inspector's, and only while the debug rows are on screen. In play mode it is the game's. The flag is editor-only in effect. It has no meaning in a build.