Modding

Splintertree's content layer is the mod system. The Rust core stays content-neutral — every gameplay rule, balance tweak, custom NPC, new item, custom HUD, schema change, and DBC override ships as a self-contained .rcmod bundle.

Realms install bundles through the admin portal; the engine loads them on patch activation, runs their migrations, wires their hooks, and serves their client files through the launcher.

• Bundle layout — what goes inside an .rcmod.
• Tooling (stctl) — the umbrella CLI for authoring, building, and validating bundles.

For the script-side details (both Python and AC-compatible Smart AI), see Scripting.

Why a mod system?

Three forces drove the design:

1. Per-realm rulesets without forking. Realms want different XP curves, drop rates, custom bosses, and HUDs without cherry-picking patches from a fork.
2. Hot-loadable content. .script reload python swaps script logic in seconds; mod activation runs database migrations idempotently; addon files repack into the launcher's next sync.
3. Auditable, rollback-safe. Draft / published patch chains with one-click rollback. Every mod load writes to the audit log; activation can be reverted from the admin UI.

Reference mods

Source trees live under mods/ in the repository:

• mods/faction_tax/ — server scripts + HUD addon + tunables.
• mods/hide_death_knight/ — minimal opt-out class mod.

Use them as templates when you author your own bundle.

Distribution

Mod uploads push to an OCI registry (SPLINTERTREE_MOD_REGISTRY); the activator pulls and caches on activation, falling back to the on-disk blob if the registry is unreachable. stctl mods migrate-to-oci backfills legacy mods. The same content-addressable pipeline as game artefacts; cosign signing carries through.