Cast bindings
Why a character's identity is separate from the row that declares it, and how to bind one member to another through a variable.
A cast row holds two different things. One is a character sheet: this name, this color, this blip, this avatar. The other is a slot the script writes into: this is who the masked figure turns out to be. A binding is what keeps those two apart.
What a binding does
Set the bind field on a member to a declared variable. At play time, if that variable holds another cast member's id, the bound member is that member everywhere: name, color, blip, portrait, avatar, and any interpolated token that reads their name. The bound member keeps its own id, so placements, speakers and stage direction targets still work through the row you wrote.
Any other value falls back silently. Unset variable, an id that names nobody, a number instead of a string, the member's own id: all of them leave the member as itself. There is no error at play time, by design.
The pick side is an ordinary set beat:
set trueIdentity = "<the other member's id>"That single beat is the entire unmasking. Character select, disguises, and a narrator who rotates between chapters are all the same primitive with different writing around it.
Why not just edit the character
Because the character is authoring data and the disguise is runtime state. If "who is behind the mask" were a field on the cast row, then two players on different branches could not disagree about it, the save file would have nothing to record, and the reveal would need its own beat type and its own runtime machinery.
Putting the identity behind a variable means the studio already has everything: a set beat writes it, a condition reads it, the HUD can show it, the save snapshot carries it, and history can rewind it. Nothing new was invented for character identity.
The trade is that a binding is one hop only, deliberately. If A is bound to B and B is bound to C, A wears B's configured face, not C. Chaining would make what a reader sees depend on resolution order, and two members bound to each other would loop.
Identity is sampled once per scene entry. A set beat that changes the binding variable mid-scene takes effect at the next scene, not on the line after it. The scene transition is what covers the avatar swap, which is why the sample happens there.
Set one up
Declare the variable
In the Variables panel, add a variable of type cast. That type exists exactly for this: it holds a cast member id. A text variable also works and stays legal, which is why older projects still compile.
Bind the member
In the Cast panel, open the bind select on the member whose identity should follow the variable. Cast-typed variables are listed first, text variables after. (itself) clears the binding.
Write the reveal
Add a set beat wherever the truth lands, assigning the target member's id. Cast-typed variables give you a picker rather than a raw id field.
What the compiler checks
| Error | Cause |
|---|---|
UNDECLARED_VARIABLE | The bind field names a variable that does not exist. Usually a rename or a delete in the Variables panel. |
CAST_BINDING_TYPE_MISMATCH | The variable exists but is neither cast nor text. A number or a boolean can never hold an id. |
What the variable actually contains at play time is not checked, because it is runtime state. If it holds garbage, the member is simply itself.
A binding whose variable has been renamed or deleted stays visible in the select, marked (missing), rather than resetting to (itself). You get to see the broken reference and decide.
The clickable pick reads through it
When a choice option targets a cast member, clicking that member's staged avatar takes the option. The routing uses the resolved identity, so if the reader is looking at a disguised character, clicking the body they can see picks the option that targets the identity they perceive. Related reading: Variables and Choice.