Dev Log #005 / Farm Forge

MAP-MODDER: A Guarded Native Editor and MCP Toolbox

Reusable authoring work from 3–5 October: guarded JSON-lines editor control, native sculpt/paint/save demonstrations, MCP transport, clean scene rendering, geographic tool registration and preservation checks.

Madison — My gift to FS25: mountain valley sunset, dedicated to Peanut
Madison — the creative direction and proving ground for Farm Forge. Tribute artwork, not an in-game screenshot.

Why a reusable editor layer matters

The map sessions produced a reusable MAP-MODDER authoring toolbox rather than leaving every editor action as a one-off script. Its initial interface accepted JSON-lines requests and combined native window/document/foreground checks with calibrated client coordinates, bounded UI strokes, camera helpers, checkpoints and XML/log inspection.

The first implementation was a local control protocol, not an MCP server. A later adapter used the installed official MCP SDK 1.30.0. Keeping those stages distinct makes it clear which evidence demonstrates editor control and which demonstrates transport and discovery.

This work supports the Technologies goal of reducing repetitive authoring effort while retaining human direction. It does not establish that the editor can safely complete arbitrary map changes without review.

A real save failure changed the control design

Sculpt, Undo, texture painting, foliage and transform/save actions were demonstrated in an isolated cloned authoring map. Those sandbox changes were not transferred into the working Aurora map.

A console-focused Ctrl+S attempt did not persist a transform. The save operation was changed to use the inspected toolbar and require a new matching native save log line. The saved sign translation was checked independently.

A camera action timed out without native log confirmation. A fresh observation and explicit retry succeeded. The failed attempt remains part of the evidence: receiving a command is not the same thing as the editor completing it.

MCP initialization, actions and image transport

  • Protocol: JSON-lines local control; later MCP stdio adapter using SDK 1.30.0.
  • Controls: foreground/document guards, calibrated coordinates, bounded native strokes and verified save confirmation.
  • Render evidence: 1,920 × 1,080 native scene captures; screenshot/render transport with matching image hashes.
  • Preservation: candidate terrain/scene replacement refuses while GIANTS Editor is running.

Real stdio initialization, tool discovery, registry access and rejection of an unsupported action were recorded. A disabled Cline example was supplied without changing live Cline settings.

Editor screenshot/camera transport was subsequently demonstrated through MCP. Native renderer commands produced clean 1,920 × 1,080 pond and Home Farm scene images without desktop overlays, and the transport returned actual UI and scene PNGs with matching hashes.

The ledger records six passing toolbox tests at that stage. The later geographic tool work reached 14 passing guard/preservation tests. Those are dated suite results, not tests rerun for this publication.

Native overview rendering and geography tools

Three overview trials were retained. The accepted baseline used the native orthographic renderer, foliage enabled and a 256-tile assembly into a 4,096 × 4,096 overview. Individual tiles were inspected when a reduced preview appeared to omit objects.

Temporary editor-only placeable groups were used for inspection and kept out of saved release scenes. A native render can show runtime placeables for artwork without making that diagnostic group part of the playable map.

Candidate terrain/profile/scene operations were registered in the reusable toolbox. Water collision geometry, fixed building levels, road formations and bridge spans gained explicit checks. These operations were developed in candidate or cloned contexts before promotion into the main project.

Preserving real editor edits through regeneration

Saved-editor preservation work introduced sparse PNG pixel merges, named-transform merges with regenerated node IDs, all-file conflict preflight, scoped paths, idempotent reapplication and a guard for opaque GDM/GRLE compiled baselines. Named objects added or deleted and changed opaque baselines require explicit resolution rather than an automatic merge.

A native sandbox transform saved at X = 0.25 metres initially triggered a safe rejection because native Save renumbered node/material identifiers. A reproducing test narrowed comparison to supported transform values. The captured edit was applied after regeneration, the model reopened in GIANTS Editor and native getWorldTranslation confirmed (0.25, 0, 0).

That demonstrates a real preserved object transform, with 14 passing toolbox tests recorded at the stage. It does not prove unrestricted terrain or density-data merging; those limitations remain explicit, and the main model was not changed by the sandbox demonstration.

Preservation, limitations and the next engineering steps

  • Evidence: ge-toolbox-progress.md; ledger.md; mcp-live-editor-render.json; mcp-live-editor-transport.json.
  • Private checkpoints and raw desktop captures remain local; this article publishes the engineering findings.

The private 3 October checkpoint matched 5,168 source/copy SHA-256 records across 17,535,516,769 bytes. It preserved maps, tools, isolated test data, reports and plans as a recovery point; it was not a public evidence bundle.

Info/procedural paint, wider semantic UI coverage, persistence of every GUI edit through regeneration and complete toolbox acceptance remain outstanding in the recorded work. Non-idempotent generators and native compiled data need particular care because rerunning a builder can overwrite later authoring.

The next useful progress is measured by durable, inspectable results: the right document changed, the editor saved it, compiled data agrees with the intended source, and the runtime still behaves correctly.

An automation command needs evidence that the intended editor accepted it.