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-config	Per-user settings, recent projects, state/cache paths and explicit legacy env import. 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 Git dependency at the exact commit in BENILLA_REV. A sibling checkout is not required. The build verifies the manifest pin; updating it remains a separate change. The engine's development source-directory lookup is disabled in the editor.

Running

For content creators, see installation and updates. Start the installed benilla-editor.exe without arguments to create/open a project and configure this computer. Settings and Play state live in the user profile; shared content belongs in its own repository. Build the Windows distribution with powershell -File scripts/package.ps1.

# 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

# First-run project picker and local settings.
cargo run -p editor-app

# Optional explicit migration of an existing developer .env into the user profile.
cargo run -p editor-cli -- config-import /absolute/path/to/.env
cargo run -p editor-cli -- config-path

# 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

Quest/item authoring, terrain changes, DBC publishing and the rest of the roadmap after R1. The brush currently previews the patch-10 template.