benilla-editor

A content editor for 1.12.1 servers on top of benilla's world engine. Content is authored over the player's own install and exported as vMaNGOS migrations. Nothing from the install is ever committed or written to.

Where the work stands and what comes next: docs/STATUS.md. Working rules for agents: AGENTS.md.

Play opens a separate local game client with a reserved GM account and an optional arrival point selected in the world. Setup and the export/apply/restart cycle: docs/play.md.

Layout

Crate	What
editor-project	The project model: targets, reserved id ranges, spawns, the last-export baseline. No Bevy.
editor-vmangos	Pending changes to one vMaNGOS world migration, in the core's own template; the world database read back (world_db). No Bevy.
editor-release	The release manifest, schema 1: every artifact a release needs, where it lives, who consumes it (docs/release-manifest.md). No Bevy.
editor-cli	benilla-editor-cli new / check / export / manifest-check, for CI and the release pipeline.
editor-app	benilla-editor, the window: benilla's WorldPlugins, a free camera, placement, preview.

benilla is a sibling checkout (../benilla) at the commit in BENILLA_REV. The app's build fails against any other commit: benilla promises no stable API, so moving the pin is a change of its own (BENILLA_PIN_ANY=1 builds anyway, to try one).

Running

# A project with a guid range the server owner has reserved for it.
cargo run -p editor-cli -- new camp.json --vmangos-rev <core commit> \
    --guid-first 9000000 --guid-last 9000999

# Local settings: WOW_DATA (the install), and optionally EDITOR_WORLD_DB (the world database,
# read only) and EDITOR_EXPORT_DIR (the core's sql/content/migrations, for the window's Export).
# Both binaries read .env at the repository root; variables already set win.
cp .env.example .env

# The window. The catalog panel (left) searches creature_template by Russian or English name or
# entry and picks the brush; the inspector (right) edits the selected spawn, with undo; the changes
# panel saves, checks the server and exports. Without EDITOR_WORLD_DB there is no catalog: pass
# --entry <creature_template.entry> --display <CreatureDisplayInfo id>.
cargo run -p editor-app -- camp.json

# What would be exported, then write the migration into the server repository.
cargo run -p editor-cli -- check camp.json
cargo run -p editor-cli -- export camp.json --out <core>/sql/content/migrations

Guids are handed out from the top of the range down and never reused. The core gives .npc add and temporary creatures guids above MAX(creature.guid); once the range's last guid is that maximum, the server's own allocations land above the range instead of where the project places next.

With EDITOR_WORLD_DB set, check and export compare the server with the project first, and export refuses on a conflict: a row in the range the project never held, a guid it adds that is taken, a template missing at the spawn's patch_min, or (once every export is applied) a row that no longer matches the last export. The migration's own guards check the same at apply time.

An export writes only what changed since the last one, records the migration and its SHA-256 in the project, and refuses to overwrite a migration file. Re-exporting an unchanged project writes nothing.

The migration

The core's world tables are MyISAM, which cannot roll back. So every check runs before the migrations row and the first write, and a failed check SIGNALs out with nothing written: a new guid must be free; an updated or deleted row must still have the guid, entry and map the last export wrote; a deleted spawn must have no creature_addon, creature_movement, creature_linking, pool_creature or game_event_creature row.

R0 acceptance

The run that closes R0: a spawn appears on the server at the spot and facing the editor shows.

1. new, then in the editor place one spawn with a plain creature display (not a humanoid NPC) on terrain, one on a WMO floor (a bridge or an upper storey), turn each to a distinct facing, Ctrl+S.
2. export into the core's sql/content/migrations, apply it (deploy/local/apply-content.sh), restart mangosd.
3. In the client: .go xyz with the line the editor's status shows for each spawn. The creature stands at the editor's position and faces the editor's arrow. Record .gps next to the editor's numbers.
4. Apply the same file again: nothing changes (the migrations row).
5. Move one spawn, delete the other, export, apply: one row updated, one gone.

Not yet

Helm, shoulder and weapon models on humanoid NPCs, the server's existing spawns shown in the world, a project content patch (the brush previews the patch-10 template), animation, and everything after R1.