Glossary
Status: Implemented. Terms for planned features are marked (planned).
| Term | Meaning |
|---|---|
| ABI | Application Binary Interface. CLight’s is the C ABI in clight.h: plain functions, plain structs and integer handles. |
| Attachment | Mod data attached to an entity, player, chunk or level, optionally typed with a default and copy-on-death (API 1.12, 1.20) (Persistence and data attachments). |
| Barrier | The point between ticks where all dimension ticks have finished and global work runs. |
| Behaviour table | The struct of callbacks a mod block or item carries (cl_block_behavior, cl_item_behavior). |
| Budget (planned) | A per-mod time allowance per tick and per frame. Today each callback has a time limit. |
| Capability | A sandbox permission declared in the manifest (net.http:<host>, …). |
clight.idl |
The CLight interface description; every binding and the generated API tables come from it. .clidl files for mod services are (planned). |
| CLight | Celestial’s mod loader and modding API. |
.clmod |
The mod package: a zip with clight.mod.json, code, assets and data. |
| Codec (planned) | A description of a value’s shape, used for JSON, network and save formats (Data components and codecs). |
| Compat layer | Celestial client code that translates the protocol of older servers to 26.3. |
| Context (thread context) | MAIN, TICK, RENDER or ANY (PARALLEL, NET, ASYNC reserved): where a callback runs and what it may touch. |
| Data component | A typed value on an item stack (26.x replaced most item NBT with components). |
| Data-pack registry | A data-driven registry synced to clients (enchantments, damage types, paintings…). |
| Fallback (vanilla fallback) | The base block or item of mod content: what it is in the world and what a vanilla client sees. |
| Frame graph | Celestial’s render-pass graph, which computes barriers and aliases transient memory. |
| Freeze | The moment static registries close and raw ids are assigned. |
| Holder | The cl_holder a registration returns; cl_holder_value gives the raw id after the freeze. |
| Integrated server | The in-process logical server used for singleplayer and LAN. |
| Job system | Celestial’s work-stealing scheduler. Jobs for mods are (planned). |
| Level | One dimension’s world (cl_level). |
| Logical side | Client logic versus server logic, independent of which executable runs it. |
| Mixin | A sandboxed callback attached to a named engine target (entity.living.hurt) at its head, return, a named point, value or call, or as a wrap or overwrite. Targets are compiled into the engine and kept across versions; no code is patched (Mixins). |
| Mixin target | A named, versioned piece of engine behaviour mixins attach to, declared in mixins.idl. |
| Override | A behaviour entry that handles a call instead of the base (CL_OVERRIDE_HANDLED). Overrides of vanilla content are (planned). |
| Owned value | A value you must release: cl_item_stack, cl_text, cl_buf. |
| Parity | Being exactly identical to vanilla 26.3 in visuals, physics, logic, timing and packets. |
| Payload | A mod’s custom network message, carried in vanilla custom_payload packets. |
.scw |
Celestial’s native world format. |
| Service (planned) | A named, versioned interface one mod provides to others. |
| Snapshot (planned) | An immutable view of chunk sections for background work. |
| Static registry | A registry filled by code before the freeze and fixed in vanilla clients (blocks, items…); mod entries are vanilla-backed. |
| Runtime | How a mod’s code runs: data (none), lua or wasm. Every runtime is sandboxed. |
| Trap | A sandboxed mod fault (WASM trap or uncaught Lua error), contained to one callback. |
| Value event (planned) | An event that publishes an engine computation; its mutable result starts as the vanilla value. |
| Vanilla-backed | How mod blocks and items exist in the world today: a vanilla base plus the mod’s id, model and properties. |
| WASM | WebAssembly, the portable sandboxed binary format used for C/C++ mods, run by Wasmtime. |