> 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/pipeline/templates.md). # Templates Configure something once, reuse it everywhere. The fifth time you set up the same **Remap Range** with the same numbers, the same **Format String** with your project's date format, or walk down to the same `localPosition.x`, the configuration is worth saving. A **template** is exactly that: something you already filled in, given a name, offered back to you where it fits. There are three kinds, and one window holds all of them. **Window ▸ Binding System ▸ Templates**, or **Project Settings ▸ Binding System ▸ Tools ▸ Templates**, which has a button per tab.

Tab	What it saves	Where it comes back
Modifiers	A modifier with its values filled in	Add Modifier ▸ From Template in the bind menu
Converters	A converter with its values filled in	From Template in the converter picker of the binding
Paths	A path, under a name of your own	Saved Paths in the bind path menu, leading either the type's group or the whole menu

The Templates window, on the Modifiers tab

## The window Whichever tab you are on, it works the same way.

Control	What it does
The tabs	Switch between the three kinds. Each carries a count, so you can see what the project has without opening it. The window reopens on the tab you used last.
+ Add	Adds an entry and opens it with its name selected, ready to be typed over. The label follows the tab: + Add Modifier, + Add Converter, + Add Path.
The search box	Filters the cards of the open tab by name, by description, and by what they are built on: the modifier or converter name, the types it works with, the path and its type.
The collapse button	Folds every card, or unfolds them.
The card header	Click anywhere on it to fold that one card. It shows the entry's icon, its name, and what it is based on.
The duplicate button	Copies the entry, values and all, right below the original. The copy is independent: editing it does not touch what it was copied from.
The remove button	Deletes the entry. Bindings already created from it are unaffected.
Show In Paths only	Whether the path leads its type's group or the whole menu. See Where it appears. A path set to the top of the menu is marked as such on its card.
The icon well	Optional. Drop a texture in and the entry carries it in the menus, which is worth doing for the handful you reach for daily.

{% hint style="info" %} A template is a **stamp, not a link**. Using one copies its values into the binding. Changing the template later does not change bindings already made from it, and editing the binding does not change the template. If you want a value that stays connected across many bindings, bind the modifier's parameter to a [bind variable](/binding-system-3/overview/bind-variables.md) instead. The two features compose: a template that ships with a variable-bound parameter gives you both a good starting point and a live link. {% endhint %} ## Modifiers A modifier with its values filled in. 1. **+ Add Modifier**, then pick the modifier the template is based on. The picker groups every registered modifier by the type it works on, so look under `float`, `Color`, `string` and so on. 2. Give it a name. 3. Fill in its values exactly as you would in a binding. The card header shows the types the modifier handles as badges, and a **Change** button swaps the underlying modifier type without losing the name, the description or the icon. ### Using one In the bind menu, under **Add Modifier**, a **From Template** heading follows the ordinary modifiers. Only the templates that fit are listed: the modifier has to work on the type the binding carries, and in a direction the binding can use.

### Worth templating

Template	Example
A remap for your project's canonical ranges	0 to 100 health into 0 to 1 fill, once.
Your number formats	Currency, percentages, timers. One template each, and the whole project is consistent.
A configured Value Smoother	The smoothing value that feels right for your game, applied everywhere.
A standard Value Logger	With your log prefix and format, so bindings log the way the rest of the project does.

## Converters A [converter](/binding-system-3/pipeline/converters.md) with its values filled in. A **Format String** carrying your date format, a **String to Color** with your fallback colour, a **Numeric to Bool** with the threshold your project treats as on. 1. **+ Add Converter**, then pick one. The picker is arranged by the conversion itself: the type it reads, then the type it produces, then the converter's name. You look for a converter by what it has to do, so that is the order. 2. Give it a name. 3. Fill in its values. The card header shows one badge per conversion the converter can perform, each reading `from → to`. A converter that handles several pairs shows several badges. Some converters have nothing to fill in, and the card says so: it is saved for its name alone, which is still useful when a binding offers a choice between several. ### Using one A binding shows a converter row whenever the value it reads is not already the type it needs. Click the converter name to open the picker: the implicit conversion comes first, then the converters the package knows for that pair, then your own under **From Template**. A saved converter is offered wherever it fits, which means wherever the binding's conversion is one that converter can perform. One saved template is enough to turn the converter row into a picker even where there would otherwise have been only one way to do the conversion. ## Paths A path, under a name of your own. This is the one that saves the most clicking: a path you reach for daily is otherwise three groups deep in a member tree, and no amount of searching makes it the first thing you see. 1. **+ Add Path**. 2. **Starts From**: the type the path is written against, `Transform` for example. Any type a path can start from is offered, not only the ones Unity can serialize: an abstract class such as `Renderer`, whose paths are then offered for every renderer, an input device, a plain C# class. The picker opens on the components paths are most often saved for, with the rest under **In This Project**, **In Unity** and **In .NET**. 3. **Path**: type it, or press **Browse…** to pick it out of that type's members. 4. **Show In**: where the bind menu offers it. See [Where it appears](#where-it-appears) below. 5. Give it a name. *Left Magnitude* says more at the point of use than `localPosition.x` does. Under the fields the window says what the path lands on and which directions it supports: *Lands on float, read and write*. If the path does not resolve against the type it says where it breaks instead, so a saved path is never quietly wrong. The card's header repeats the answer as an arrow and a type, so a list of folded cards still says what each one gives. Where the menu will offer the path is not obvious, for a type no GameObject carries, the window says that as well.

The Paths tab, picking the type a path starts from

{% hint style="info" %} Methods are not offered when browsing. A method needs its arguments before it can be called, and a saved path carries none. Fields and properties, including the ones nested inside structs, are all fair game. {% endhint %} ### Where it appears In the [bind path menu](/binding-system-3/overview/binding.md#the-bind-path-menu), under a **Saved Paths** heading. **Show In** decides where that heading goes.

Show In	Where the heading goes
Under its type the default	At the top of the group of the type the path reads from, above that type's own members, which follow under Members. A path saved against `Transform` leads the Transform group of every GameObject you bind from.
Top of the menu	In a section of its own at the top level of the menu, after the GameObject and before Components. One click from opening the menu, without opening a component first.

Under its type is the default because a path means little without the thing it starts from: *Left Magnitude* says what it is while it sits inside Transform. Move a path to the top of the menu when it is one of the handful you bind every day, and the name carries itself. At the top of the menu a row reads `Transform → float`: the type it is read from and the type it lands on, neither of which the row's own place in the menu can say. An entry saved before this choice existed sits under its type, which is where it already was.

Saved Paths, at the top of a component's group in the bind path menu

Which source a saved path is offered for, wherever the heading goes:

The binding's source	What is offered
An object of the saved type or of one derived from it, or a GameObject with such a component	The path, in that component's own group. A path saved against `Transform` reaches every GameObject in the project.
A source named by type rather than by object: a variable, or any of the modes that find the object while the game runs	The path, in that type's group, if the type matches.
A static source of the saved type	The path, through the type's own static accessor, if it has one. See below.

A saved path is offered in the group of its own type and nowhere else. It is not offered through a member of that type on another source: a `Transform` path does not turn up under your script just because the script holds a `Transform`, where it would read as one of the script's own paths. A saved path is offered only when the binding can actually use it: it has to resolve against the type, support the direction the binding reads or writes in, and produce a value the binding can take, directly or through a conversion. A path that fits only through a conversion carries the same converter mark the rest of the menu uses. ### Types reached through a static accessor Some types never sit on a GameObject. An input device is the usual case: nothing in a scene is a `Mouse`, so a path saved for one would have no source to be offered for. Such a type usually hands out its instance through a static member, and the menu uses it. A static field or property counts as that accessor when it is named `main`, `current`, `instance`, `singleton` or `shared` (in any case), and returns the type itself or one derived from it. That covers `Mouse.current`, `Camera.main` and the `Instance` of most singletons. Only classes qualify, since a struct handed out by a getter is a copy that no write would reach.

Show In	Where a path for such a type is offered
Top of the menu	In every bind path menu, read through the accessor. The row reads `Mouse.current → bool`. Picking it switches the binding to a static source of that type, with the accessor at the start of the path.
Under its type	Only where the source is of that type: a variable holding one, or a static source of the type, behind its accessor. The card suggests moving the path to the top of the menu to have it everywhere.

Where the source already is the type, or carries it, the source's own path is offered instead: a `Camera` path is read from the camera on this object when there is one, and from `Camera.main` only when there is not.

A path saved for Mouse, offered through Mouse.current on an object that has nothing to do with the mouse

These rows are not offered with several objects selected, because picking one changes the source mode of each object's own binding. ### Worth saving

Saved path	Why
`Transform` ▸ `localPosition.x`	One component of a position, several groups deep, every time.
`RectTransform` ▸ `anchoredPosition.y`	The same, for UI.
`Rigidbody` ▸ `linearVelocity.magnitude`	Speed, which nothing exposes directly.
`Camera` ▸ `fieldOfView`	Shallow, but used constantly.
Your own component ▸ the one field designers bind	Naming it in your own words is the point. The path is `state.health.current`; the name is Health.

## Where templates live In three assets, which the window creates on demand: `modifier-templates`, `converter-templates` and `path-templates`, in the [Bindings folder](/binding-system-3/reference/settings.md#bindings-path). You can also create them yourself with **Assets ▸ Create ▸ Binding System**. They are normal project assets, so they are under version control and shared with the team. That is the point: a template is a piece of project convention, like a naming rule. ## Related pages * [Modifiers](/binding-system-3/pipeline/modifiers.md): how the stack works. * [Modifier Catalogue](/binding-system-3/pipeline/modifier-catalogue.md): what there is to template. * [Converters](/binding-system-3/pipeline/converters.md): when a conversion happens at all, and which one. * [Paths and Parameters](/binding-system-3/overview/paths.md): what a path can contain. * [Pinned Paths](/binding-system-3/overview/pinning.md): the other way to shorten the bind path menu, by object rather than by type. * [Bind Variables](/binding-system-3/overview/bind-variables.md): the linked alternative to a copied value.