fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: REGN is excluded as the wave scheduler -- it is a navmesh

Browse Source 
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<NN>.tbl, keyframed per squadron per phase with
t in seconds, remains the only located part of the mechanism.
This commit is contained in:
Sylpheed RE agent
2026-08-26 08:11:36 +00:00
parent 6c47f8231c
commit 7a351e641d
2 changed files with 23 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/re/BACKLOG.md
View File

@@ -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

17
docs/re/structures/regn-map-grid.md
View File

@@ -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<NN>.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