From 7a351e641dd883b73800122fd6fb9034a9f82862 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 08:11:36 +0000 Subject: [PATCH] re: REGN is excluded as the wave scheduler -- it is a navmesh The original reason for investigating REGN was that a mission's enemy count rises and falls, so a scheduler with parameters must exist somewhere, and a per-map uniform grid is what such a thing would be indexed by. Now that it is decoded that reasoning is answered: REGN is a tetrahedral navigation mesh -- vertices, faces carrying plane equations and adjacency, tetrahedra with portal costs between face pairs, and a grid indexing which tets fall in each cell. Every section is accounted for by that structure, and there is no time field, no unit reference and no trigger anywhere in it. So the wave-scheduler search should treat REGN as excluded rather than unread. The page's original hedge was right to keep the reading provisional, but the reasoning it hedged was a guess from shape, and the shape belonged to pathfinding -- which is what pointed the whole investigation here. The arrival timetable in Route_S.tbl, keyframed per squadron per phase with t in seconds, remains the only located part of the mechanism. --- docs/re/BACKLOG.md | 6 ++++++ docs/re/structures/regn-map-grid.md | 17 +++++++++++++++++ 2 files changed, 23 insertions(+) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index eabeccc..d3cd4e5 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -337,6 +337,12 @@ search cannot find a *schedule*. **Places searched so far:** +* ❌ **`REGN` is EXCLUDED as the wave scheduler (2026-08-26)** — it is a + tetrahedral navigation mesh (vertices, faces with planes and adjacency, + tetrahedra with portal costs, a grid indexing which tets fall in each cell). + Every section is accounted for; there is no time field, no unit reference and + no trigger anywhere in it. It was chased here because "a scheduler would be + indexed by a grid" — a guess from shape, and the shape was pathfinding. * ✅ **`hidden/MiscBin.pak` — new to the corpus.** 11 `REGN` + 11 `MCOL` objects, none name-resolved. `REGN`'s header is now decoded: a per-map **uniform spatial grid** (bbox, cell size, 5³ or 10³ cells), self-checked 11/11. Its four data diff --git a/docs/re/structures/regn-map-grid.md b/docs/re/structures/regn-map-grid.md index bfe0c7c..b7d2f49 100644 --- a/docs/re/structures/regn-map-grid.md +++ b/docs/re/structures/regn-map-grid.md @@ -131,6 +131,23 @@ thing is indexed *by*. partition and no more; the sections are unread. Treat this as the location of the world's spatial data, not as the wave table. +> ❌ **SETTLED 2026-08-26 — `REGN` is not the wave scheduler, and cannot be.** +> It is a **tetrahedral navigation mesh**: vertices, faces with plane equations +> and adjacency, tetrahedra with portal costs between their face pairs, and a +> grid that indexes which tetrahedra fall in each cell. Every section is +> accounted for by that structure. There is nowhere in it for "what spawns, when, +> on what trigger" to live — no time field, no unit reference, no trigger. +> +> The hedge above was right to keep the reading provisional, but the reasoning +> it hedged ("a grid is what a scheduler would be indexed by") was a **guess from +> shape**, and the shape belonged to pathfinding. Worth noting because that guess +> is what pointed this whole investigation at `REGN` in the first place. +> +> The wave-scheduler search should now treat `REGN` as **excluded**, not as +> unread. The arrival timetable already found in `Route_S.tbl` — keyframed +> `(time, quat, pos)` per squadron per phase, with `t` in seconds — remains the +> only located part of that mechanism. + ## ✅ Update: `REGN` is a stage's **MapPath** The per-stage definition record (see