Motion Scripting
/ ErrorsBudgets
The hard limits a script runs inside, why they exist, and what happens the moment one is exceeded.
The evaluation runtime is fenced by hard, HOST-INDEPENDENT budgets - the same numbers in the editor, in unit stubs and on the render farm, so a script that fits on one machine fits on all of them. Tripping a budget is a typed, recoverable status on the script, never a crash.
| Budget | Value | What it fences |
|---|---|---|
script_polls | 200 | Interpreter polls one script may spend on one frame. A runaway loop, endless recursion or a catastrophic regex trips this and reports the typed interrupted - the editor presents it as a fixable budget issue. |
frame_polls | 2000 | Interpreter polls ALL scripts together may spend on one frame - the whole frame's ceiling, so a hundred well-behaved scripts cannot add up to a stall. |
memory_bytes | 67,108,864 bytes | The evaluation realm's memory ceiling. Exceeding it is the typed out_of_memory; the realm survives and the next frame evaluates afresh. |
state_bytes | 262,144 bytes | The serialised size cap for ONE state() store. A store that grows past it reports the typed state_too_large - keep stores to the working set, not a history of everything. |
stack_bytes | 262,144 bytes | The JavaScript call-stack guard. Runaway recursion reports the typed stack_overflow before the engine's own stack is at risk. |
The editor additionally runs a WALL-TIME watchdog around live previews so a runaway draft can never wedge the app while you type; the render truth is always the poll budgets above.