Skip to content

modules: the served editor - #8489

Draft
keithharvey wants to merge 1 commit into
missionsfrom
mission-editor
Draft

modules: the served editor#8489
keithharvey wants to merge 1 commit into
missionsfrom
mission-editor

Conversation

@keithharvey

Copy link
Copy Markdown
Collaborator

The game publishes what only it knows into .editor; an external tool renders it and writes edits back, so authoring a mission does not mean restarting one.

It costs nothing when nobody is editing — both widgets return before GetInfo unless dev mode is on, so for an ordinary player the handler never registers them.

@github-actions

github-actions Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Integration Test Results

15 tests   7 ✅  4s ⏱️
 1 suites  8 💤
 1 files    0 ❌

Results for commit a70c9ac.

♻️ This comment has been updated with latest results.

@keithharvey
keithharvey force-pushed the mission-editor branch 2 times, most recently from efbe9f3 to 4783d09 Compare July 27, 2026 07:56
@keithharvey
keithharvey marked this pull request as draft July 27, 2026 10:23
@keithharvey keithharvey mentioned this pull request Jul 29, 2026
The game publishes what only it knows into modules/missions/.editor: the
unit vocabulary, the armed mission, and live values for whatever the
served view asks about. An external tool renders that and writes edit
intents back, so authoring a mission does not mean restarting one.

It costs nothing when nobody is editing. Both widgets return before
GetInfo unless dev mode is on, so for an ordinary player the handler
never registers them: no 100 KB vocabulary dump written on every game
start, no .editor tree in their data directory, no document parsed into
the RmlUi context, and no polling of a file that will never exist.

Two things the artifact contract has to survive. serve writes it
non-atomically, so a torn read must not consume the generation — it is
validated first and retried otherwise, and the panel renders the bytes
it validated rather than re-reading and catching the next tear. And the
hot-reload it triggers is synced and broadcast while the edited files
are local, so only a singleplayer session may drive it; dev mode alone
is not enough, since every client of a dev build passes that test.

Edit intents are named from a clock that keeps rising across widget
reloads, and zero-padded, so a reload cannot overwrite an intent the
tool has not consumed yet and a plain lexicographic drain is submission
order.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant