> 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/getting-started/first-binding.md). # Your First Binding No code, three clicks, and a value that follows another value. This page is the whole flow, once, end to end. It takes about a minute and needs no code at all. {% hint style="info" %} There are [two ways to bind](/binding-system-3/overview/two-ways-to-bind.md). This page uses the one you should reach for first: **proxy bindings**, made entirely from the Inspector, on any field of any component or asset. The other way, declaring a `Bind` field in your own code, is at the [bottom of this page](#the-other-way-a-bind-field-in-code). {% endhint %} ## 1. Turn a field into a binding Pick any serialized field, on any component. It does not have to be yours: `Rigidbody.mass`, `Light.intensity`, a field on a component from a package, a shader property on a material. Right click the field's **label** and choose **Enable Binding**.

Enable Binding on a component you did not write

The field does not change yet. What appears is a small **hexagon toggle** beside the label. That is deliberate, and it is worth understanding on your very first binding. **Enable Binding** makes the field *bindable*. The hexagon says whether it is bound *right now*. Click the hexagon. The field is replaced by a binding row: a source slot, and a path button that reads **NOTHING SELECTED**.

The field, bound and waiting for a source

Nothing was written to disk in your project's code, and nothing was recompiled. {% hint style="success" %} This is the same hexagon a [`Bind` field](#the-other-way-a-bind-field-in-code) has. **Enable Binding** simply gives an ordinary field the toggle a bind field is born with, which is why everything after this point is identical for both. {% endhint %} ### The hexagon is a switch, not a commitment Click the hexagon off and the plain field comes back, with a value you can type. Click it on and the binding returns exactly as you left it: source, path, converters, modifiers, all of it. Nothing is discarded. So you can drop back to a hand-typed number to test something, and come back without rebuilding anything. **Disable Binding**, on the same right click menu, is the destructive one. It removes the setup and the hexagon goes with it. ## 2. Pick a source and a path Two ways, and they end in the same place. {% tabs %} {% tab title="Drag and drop" %} Drag any GameObject, component or asset from the Hierarchy or the Project window and drop it on the row. The drop sets the source and immediately opens the bind path menu, filtered to members that can feed this field's type. {% endtab %} {% tab title="Click the row" %} Click the path button. The menu opens on whatever is already available: the components of the current object, the [bind variables](/binding-system-3/overview/bind-variables.md) in the project, [pinned paths](/binding-system-3/overview/pinning.md), the sources you used most recently, and static types. {% endtab %} {% endtabs %} The menu is searchable. Type `angle`, `x`, `mass`, whatever you are after, and it filters as you go. Members that cannot produce the right type are not listed at all, so anything you can click is a valid choice.

The bind path menu, filtered to members compatible with the field

Pick something, for example a `Slider` and its `value`. ## 3. Check when it should update This step exists only for bindings made this way. The bound component does not know it is bound, so nothing in it will ever ask for the value. The engine has to move it, at a stage you choose. Open the bind menu and use **Update Points ▸ Update On**.

Pick	When to use it
UPDATE	The right answer for most things.
LATE UPDATE	When the value has to follow animation or layout.
FIXED UPDATE	Physics.
EDITOR	Also tick this to watch the binding work without entering play mode.

**UPDATE** is already ticked, along with **Optimized Update**, because that is the default for a new binding. So this step is usually a matter of confirming rather than choosing: press play and the field already follows the slider. Change it when the default is not what you want, and tick **EDITOR** when you want to watch the binding work without entering play mode. {% hint style="info" %} The default is configurable in **Project Settings ▸ Binding System**, so a project that has changed it will start somewhere else. {% endhint %} {% hint style="warning" %} Untick everything and the panel tells you so: *This bound field won't be updated automatically*. Nothing will move the value, so if a binding is ever mysteriously idle, this panel is worth a look. An empty panel can also be [entirely deliberate](/binding-system-3/overview/modes-and-updates.md#no-update-point-on-purpose): it is how you say that your own code, or a `UnityEvent`, decides when the binding runs. {% endhint %} ## 4. Shape the value on the way A slider gives 0 to 1 and your field probably wants something else. Rather than change either component, put a modifier in the binding. 1. Click the path button again to reopen the menu. 2. Under **Add Modifier**, pick **Remap Range**. 3. Set the input range to `0 → 1` and the output range to whatever you need.

A Remap Range modifier inside the binding

The slider still reports 0 to 1. The target still reads its own units. Neither one knows about the other, and the conversion lives in the connection where it belongs. There are around fifty modifiers in the box, listed in the [Modifier Catalogue](/binding-system-3/pipeline/modifier-catalogue.md), and writing your own takes a few lines. ## 5. See what is happening Reopen the menu and switch on **Live Debug**. The row now shows the value at every stage of the pipeline: what came out of the source, what the converter produced, what each modifier did to it, and what the target finally received. It updates as the game runs, and it reports while you author too.

Live Debug, showing every stage of one binding

{% hint style="info" %} Those fields are editable. Type into one and the stage reports your value instead of its own, and everything after it recomputes from there, which is how you check what the remap does at 0.95 without dragging a slider to 0.95. Nothing is written to the scene. {% endhint %} That is the loop: bind, shape, watch, poke. See [Live Debug](/binding-system-3/project-tools/diagnostics/live-debug.md) for the details. ## The other way: a bind field in code When the field is one you wrote, there is a second option. Change its type to `Bind`: {% code title="Spinner.cs" %} ```csharp using Postica.BindingSystem; using UnityEngine; public class Spinner : MonoBehaviour { public Bind speed = 90f.Bind(); // .Bind() sets the initial value private void Update() { transform.Rotate(0f, speed * Time.deltaTime, 0f); // ^^^^^ implicit conversion, no .Value needed to read } } ``` {% endcode %} `speed` still behaves like a `float`. In the Inspector it draws as a plain float with a small hexagon toggle to its left; click that instead of using the right-click menu, and steps 2, 4 and 5 above are identical.

An unbound `Bind<float>` draws as a plain float, plus the bind toggle

Step 3 does not apply, and that is the point of this mode: your `Update` reading `speed` **is** the update. Nothing is scheduled, and the value is exactly as fresh as the line that reads it. That control is what you trade the extra code for. [Two Ways to Bind](/binding-system-3/overview/two-ways-to-bind.md) compares the two properly, and says which to pick when. ## What to read next


Two Ways to Bind	Without code, or with it	Two Ways to Bind
Core Concepts	Why the pieces are shaped this way	Core Concepts
The Bind Field	Every control on the row	The Bind Field
Bind Modes and Update Points	When the value moves	Bind Modes and Update Points