ReviewOS

stacks/the-settlers-iii-remake

Plan harvesting sites for usable neutral granite

#194
Closed chris opened this 8 days ago ·
8 days ago

The normal-start seed-2 match with two ordinary economic AIs reaches tick 200000 with both sides alive and clean conservation. Neither player's production changes from tick 100000 to 200000. This remains after the moving-settler construction correction in #193.

At tick 200000, player 1 has no owned granite object. Its view does show neutral granite, and the engine's normal public placement check permits a stonecutter at 11,54. The AI issues no command. Submitting just that ordinary build command completes the hut and increases actually produced stone from 72 to 80 within 8000 ticks. No stock, workers, land, map data or rules are injected. Conservation stays clean. The observed granite tile at 11,61 remains initially neutral.

The current AI resource anchors only include objects on owned tiles, although the existing harvesting router can legally reach a neutral blocking object from an adjacent owned tile. Pioneers can claim walkable ground around granite, but cannot stand on the granite itself. The policy can therefore keep expanding while overlooking a usable hut site. Do not change the simulation's established harvesting or territory rules to hide this planning gap.

Acceptance:

  • Use only explored resource information and legal public placement/movement behavior to plan a usable stonecutter when its granite object is neutral.
  • Reproduce the captured checkpoint's missing order and actual production recovery through ordinary AI commands, with no grants or terrain edits.
  • Cover both usable neutral resources and unreachable/enemy cases at the public AI/session seam.
  • Keep AI decisions deterministic across restore, and preserve rules/profile identity for this policy-only correction.
  • Repeat the normal two-economy match and report any remaining bottleneck; keep the broader economy/skirmish issues open until their full acceptance is met.

Related: #73, #74, #76, #193, #4. Original Gold executable behavior remains unobserved. This issue corrects planning against the engineering rules already implemented by the engine.

8 days ago

The source correction now uses the production worker's router to forecast harvesting from legal proposed sites. The query stays on explored owned walking tiles, blocks the future building footprint, and considers only known own or neutral harvest objects. It does not read hidden deposits or change stock, terrain, ownership, workers, rules or clocks.

The captured ordinary two-economy seed-2 checkpoint at tick 200000 now orders and completes a stonecutter, increases produced stone beyond 72 and continues identically after restore. Five focused cases cover that actual recovery, usable neutral granite, water isolation, enemy/unexplored resources and expansion toward known neutral forests.

The first revision regressed timber expansion: the existing fallback treated any resource anchor as already owned. Once neutral anchors were added, this prevented the tower that would open space for a timber workplace. A comparison with the committed policy isolated the first changed decision at tick 1120. The ownership-aware expansion correction passes the existing passive-rival match without changing its seed, clocks or bounds.

Final local game checks: 283 tests pass, zero failures, 22852 assertions; Pickier lint has zero errors/warnings; application, tool and stx type checks pass. A fresh normal-start match with both ordinary economic policies now completes at tick 45321: player 1 lost, player 2 won, checksum 26b13881, clean conservation and zero rejected enqueue submissions. Both start with 44 people and 30 planks. Player 2 actually produces 56 iron ore, 44 iron, 3 swords, 5 spears and 9 bows. Final checkpoint SHA256: 34f31c5eac9095af51658794c63a9a572e58efde7fdd9ea9ecb9972b5c7d89db.

The retained execution history also contains one refused move at tick 45120 because a garrison keeps its last soldier. That separate military-planning issue is not hidden by the clean enqueue result. Broader military, skirmish, human-input victory, all-seed and Gold fidelity acceptance remain open.

Publication is pending: the game changes are local while Stacks 0.75.311 completes its original package/native publication and verification for the related browser preparation fix (stacksjs/stacks#2994). Normal adoption, the full production browser suite, a normal main push and exact-head CI will precede closure of these specific fixes.

8 days ago

The policy now considers known neutral granite and trees when a worker can reach owned adjacent land. It asks the production router about a proposed workplace, excludes its future footprint, restricts the query to explored land, and preserves expansion when no owned workplace fits. No goods grants or unit relocation.

Implementation: https://github.com/stacksjs/the-settlers-iii-remake/commit/08d4eff3b50eb295e68324c2b453551cf829defb

The immutable tick-200000 stalled settlement resumes stone production through ordinary commands and matches a fresh-policy save/restore. Five focused regressions cover recovery, known neutral granite, water isolation, hidden/enemy resources and forest expansion. All 283 unit tests and 385 browser steps pass. Exact pushed-main CI: https://github.com/stacksjs/the-settlers-iii-remake/actions/runs/40225612811. Original diagnostic artifact SHA-256: 732cbccb239192709ac82a56aa0c393eadcc2f7e6f5319699f9bb9ca85c3ebf5.

A fresh two-computer seed-2 match repeats a player-2 win at tick 45321, checksum 26b13881, with clean conservation. The winner produces iron ore, iron, swords, spears and bows. See ai-neutral-harvest-2026-10-25.json and framework-0.75.311-browser-acceptance.json under docs/roadmap/receipts.

This scoped resource-planning correction is complete. Seeds 1, 3 and 5 remain unfinished at 80000 ticks and retain clean accounting; seeds 1 and 5 include scouting refusals. Those results are retained in random-seed-followups-2026-10-25.json. Broader military AI and random-map acceptance remain open in #74 and #76.

Sign in to comment on this issue.