Program your ship in Lua
Doors, thrusters and screens can be driven by small Lua programs that run on a board inside your construct — within strict limits, so no program can stall the world around it. Sensors are coming.
Dated 19 October 2026. The scripting engine is in the current build. Writing and running programs from inside the game is still in development, and the full reference manual is not yet published.
An airlock in ten lines: close the inner door, wait until it reports closed, then open the outer one. An illustration, not a recording.
How a program meets the ship
A program lives on a board. Each element you link to the board gets a name, and the program reaches it by that name —
hangar.open(), inner.state(). Reading is allowed by default; commanding an element needs a permission the
program asks for. in development
How it works
There is no numbered slot to run out of. Starting a program gives it a fresh Lua 5.4 state; its main body runs as the first task, and it lives as long as it has tasks. On every tick each task runs until it waits, finishes or spends its budget.
Commanding an element — opening a door, firing a thruster — needs the writeelements permission, which is not
granted by default; a program asks for it with sys.require.
-- Airlock: link two doors to the board as 'inner' and 'outer'. sys.require('writeelements') local function shut(door) door.close() -- returns 'closing', 'closed' or 'held' while door.state() ~= 'closed' do task.wait(0.2) end end shut(inner) print('inner sealed - outer is now', outer.open())
From the manual's quick start, abridged.
A budget that pauses, never kills
Every program gets a fixed budget each tick, so one script can never stall the world. A program that reaches its budget is paused until the next tick and carries on where it stopped. in today's build
The limits
A long calculation simply takes more ticks.
| Limit | Value | What happens |
|---|---|---|
| Work per tick | 500,000 instructions or 8 ms | whichever comes first: the program is paused until the next tick |
| Memory | 8 MB per program | a catchable “not enough memory” error |
| Code that cannot pause | 250 ms | a sort comparator or similar callback running past it is stopped |
| Any single tick | 1 s | the last resort: the program is stopped, with the reason and the line |
A sealed sandbox
A program can touch its own board, its linked elements and the libraries it is given — nothing else on your computer or the server. in today's build
What is left out
Absent by design: file access (io, dofile, loadfile), operating-system calls
(os.execute, os.getenv, os.remove and the others that reach outside; the time functions stay), the debug library, module
loading (require, package) and string.dump.
What a program can use
Libraries for permissions, tasks and JSON, plus the Lua standard library; doors, adjusters, thrusters and screens are reachable as elements.
The full list
- sys: permissions, the program's own budget and version information.
- task: waiting, spawning and timing tasks.
- json: reading and writing JSON.
- The Lua standard library, minus the sealed parts above.
- Elements: doors, adjusters and thrusters, and screens through a separate render script. screens: in the build · being tested
- Coming: modules for sensors, a programmable HUD, flight control, input and data banks are in the code and will be documented in the manual. in development
The reference manual
A full reference, every function with arguments, return values and an example, will be published here. coming
Help it exist. Back the game on Patreon, or follow how it is made.