Table of Contents

Server-side Lua scripting

This page documents the game-server Lua scripting system and how to bind scripts through ScriptComponent.

Related pages:

Where scripts live

Script execution model

The ScriptSystem runs once per server tick and drains queued ScriptEvent values.

Main execution paths:

The global Context userdata is set before each script run. The concrete fields depend on which ScriptContext variant triggered execution.

Using ScriptComponent

Add a [script] table to an entity resource (res/ents/*.toml):

[script]
on_init = "player-init.lua"
on_hit = "tutorial/training-dummy-tutorial-hit.lua"

on_init

on_hit

Inline vs resource scripts

Both on_init and on_hit support two forms:

  1. Resource reference (string ending in .lua):
    1. The server looks up the resource and executes it.
  2. Inline Lua source (any other string):
    1. The string itself is executed as Lua code.

For maintainability, prefer resource scripts over inline Lua.

Script module (include/) usage

Modules under res/scripts/include are preloaded and added to Lua package.preload at startup and script reload.

Example:

local common = require("common")
local tutorial = require("tutorial")
local DamageType = require("damage_type")

Useful built-in modules currently in the repo:

Resource validation

On resource load/reload, the server validates script references in entity and item resources.

For ScriptComponent, only values ending in .lua are validated as resource names. Missing resources are logged as validation errors.

Reload and iteration workflow

Recommended flow while developing scripts:

  1. Edit files in res/scripts or entity resources in res/ents.
  2. Use /reload_resources script (dev command) to reload ScriptDb.
  3. Scripts under include/ are reloaded and re-preloaded.
  4. Trigger the entity behavior in-game.

For quick one-off evaluation, developers can use /lua [code] which queues ad-hoc script execution with default context.