Skip to content

KubeJS Reload and Editor

hp-1e edited this page Oct 25, 2026 · 1 revision

English | 中文

Reload and Editor

The base file is still config/skill_atlas/atlas.json. Skill Atlas reads the base file first. The integration then applies the script overlay to a copy, validates it completely and hands it to the native revision, point tracking, refund and sync pipeline.

Reloading

  • After /reload replaces the KubeJS listeners, the atlas is rebuilt once on the next server tick.
  • /skillatlas reload rebuilds the atlas with the listeners that are already loaded. It does not re-evaluate the KubeJS scripts.
  • Every rebuild starts from the base file again, so repeated reloads never duplicate nodes.
  • An invalid overlay does not replace the previous valid atlas. The native loadFailed state and error message are synced as they are, so a failed reload is never reported as a success.
  • Removing a node from a script and reloading truncates levels and refunds actual payments by the native rules. Removing a pool does not wipe every player's historical data for a pool with that name.
  • A KubeJS script error still has to be fixed followed by /reload. Old Rhino objects cannot fully roll back the script context.

In-game editor

  • When scripts actually change the atlas, the whole in-game atlas editor becomes read-only so edits cannot conflict with the overlay. This is not a per-field lock. Edit the base JSON or server_scripts and reload instead.
  • Custom condition and reward declarations also lock the editor, even if they come from the base JSON, because the native editor does not know their structure.
  • Saving from Skill Atlas writes the base atlas. Script results are never baked into atlas.json. Player progress keeps the native save format.

Sidecar data

Integration declarations are stored in the atlas under the skill_atlas_kubejs field and survive toJson / fromJson / copy and full sync.

  • getNode(id).kubejs shows a node's declarations, and kubejs inside json(patch) replaces the declarations of a node or a single level.
  • Each declaration list on a node or level holds at most 32 entries. Each entry is at most 16 KiB, and all declarations together at most 256 KiB. Node and level references must be valid.
  • data accepts plain JSON only, with at most 32 nesting levels and a recursive validation budget of 8192 steps. Functions, cycles and non-finite numbers are rejected.
  • External acquisition bindings live in the same sidecar under $acquisitions, and getPool(id).kubejs returns the type, config, name, description and unit.
  • A bound pool keeps a legal playtime method underneath only to carry the native threshold and limit. Natural tracking skips custom pools, so they do not award points every second.

Choice groups are a native field (choice_group). Setting them in the base JSON or the in-game editor does not lock the editor.

Not available

Writing offline player progress, arbitrary client-side player writes and per-frame drawing are not available.

The integration does not change vanilla behaviour that already happened. It offers no normal learn that skips validation, does not expose a writable payment ledger, and does not promise to roll back commands, economy or item side effects of other mods.

Clone this wiki locally