From 8c37181a2cf35c0c5eec156c2f5d7643c31f3d1f Mon Sep 17 00:00:00 2001 From: Natalie Date: Sat, 25 Apr 2026 06:10:32 -0700 Subject: [PATCH] =?UTF-8?q?fix(@projects/@magic-civilization):=20?= =?UTF-8?q?=F0=9F=90=9B=20update=20stress-test=20objective=20with=20root?= =?UTF-8?q?=20cause=207=20details?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Lilith Autocommit --- .project/objectives/p0-22-ultimate-ai-stress-test.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/.project/objectives/p0-22-ultimate-ai-stress-test.md b/.project/objectives/p0-22-ultimate-ai-stress-test.md index b8da6b81..f906b0aa 100644 --- a/.project/objectives/p0-22-ultimate-ai-stress-test.md +++ b/.project/objectives/p0-22-ultimate-ai-stress-test.md @@ -109,7 +109,11 @@ a foregone conclusion; the grid is the precondition. **Root cause 6 (fix landed 2026-04-25, the actual `outcome:max_turns wi:-1` cause):** auto_play.gd's "done" state ran `_outcome = "victory" if _victory else "max_turns"` immediately when `_turn_count >= _max_turns`, but `vm.check_all` in `TurnManager.next_player()` had not yet fired the score-victory branch — `GameState.turn_number` lags `_turn_count` by 1-2 (depends on whether the round wrapped before the auto_play polling caught the limit). Fix: in auto_play.gd's "done" state, before quitting, bump `GameState.turn_number = max(turn_number, _max_turns)` and explicitly invoke `TurnManager._victory_manager.check_all(GameState.get_game_map())`. Verified `p0-22-vfb3-20260425_042503` (1-seed T50 5-player MCTS): debug print `turn_number 48→50, limit 50` confirms the lag bug existed; outcome wrote correctly as `victory wi=2 wp=goldvein` via score path. - Full huge-map-5clan re-run started 2026-04-25 with all 6 root-cause fixes in place. Awaiting verdict. + Full huge-map-5clan re-run started 2026-04-25 with all 6 root-cause fixes in place. + + **Root cause 7 (fix landed 2026-04-25, the actual blocker for huge-map gate):** apricot's `tools/autoplay-batch.sh` was an OLDER version that always computed `SAFETY_TIMEOUT = 2*TURN_LIMIT + 300`, ignoring the MCTS branch (`3× + 300` for `AI_USE_MCTS=true`). For T500 huge-map games, this meant 1300s instead of 1800s — 5-player MCTS games need ~5s/turn × 500 turns = 2500s minimum. With the EDIT host's autoplay-batch.sh now synced to apricot, safety_timeout correctly computes 1800s for T500 + AI_USE_MCTS. + + **Remaining performance gap (not a bug, calibration):** Even at 1800s, 5-player MCTS games on the standard 80×52 map don't reach T500 with PARALLEL=4 (CPU contention; each game gets ~25% of one core). Re-run `huge-map-5clan-20260425_051955` showed seeds finishing at T55-T392 via timeout, never the score-victory branch. Verified the pipeline works end-to-end at smaller scales: `p0-22-vfb3-20260425_042503` (T50, 1 seed, score-victory fired with `winner=2 wp=goldvein`). Single-seed T500 verification with `SAFETY_TIMEOUT_OVERRIDE=3600 PARALLEL=1` running to confirm. The ultimate_stress gate as currently scoped (10 seeds × T500 × 5 clans on standard map at PARALLEL=4) is fundamentally CPU-bound on apricot — it needs either smaller map, lower MCTS depth, or a much larger time budget. **Root cause 1 (fixed, confirmed):** Batch `000049` used a stale `.so` lacking `GdAiController` registration — 872 "not loaded" errors/game, tactical pass skipped, no capitals founded. Current `.so` (runs ≥035301) has 0 errors.