erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

milestone(G.3): dungeons RENDER — #95 was a Bug-A symptom, not an unbounded flood

Browse source 
Autonomous /loop verification: a live launch into the 0x0007 dungeon renders with a
sane budget (WB-DIAG instances ~39,000, meshMissing=0; was 9.1M pre-Bug-A), correct
membership (no ACE failed-transition spam), navigable. The chain: G.3a teleport
hold+place + Bug A (2ce5e5c, validated-claim landblock prefix) + login-into-dungeon
recenter (47ae237). A headless diagnostic (Issue95DungeonFloodDiagnosticTests, 95d9dab)
proved the portal flood is already bounded (1-17 cells vs the stab_list's 120-204), so
#95's "port grab_visible_cells stab_list bounding" was the WRONG fix and is NOT pursued.
ISSUES #95 -> RESOLVED, #133 -> renders + login-into-dungeon fixed; CLAUDE.md current
state + render digest updated. Remaining for M1.5: A7 dungeon torch/point-lighting.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik 2026-06-13 19:36:04 +02:00
parent 47ae237e7b
commit a40c38e8bd
2 changed files with 41 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

41
docs/ISSUES.md
View file

@ -83,7 +83,23 @@ recenter streaming onto the spawn landblock when the login spawn first arrives
(mind the #107 auto-entry hold's `SampleTerrainZ(pe.Position)` frame after the
recenter). Pre-existing; only surfaces now that the test character can be saved in
a dungeon. Workaround to unblock testing: move `+Acdream` out of the dungeon
server-side (ACE) before logging in.
server-side (ACE) before logging in. **FIXED 2026-06-13 (`47ae237`)** — the login
player-spawn path now recenters `_liveCenterX/Y` onto the spawn landblock (mirrors
the teleport-arrival recenter; no-op for a same-landblock Holtburg login). Verified
live: `live: login spawn — recentering streaming from (169,180) to (0,7)` → dungeon
streams → `auto-entered player mode` in the dungeon.
**✅ DUNGEON RENDERS — M1.5 milestone (2026-06-13 PM, autonomous /loop, objectively
verified).** With Bug A (`2ce5e5c`) + login-into-dungeon (`47ae237`), a live launch
into the `0x0007` dungeon: player grounded on the dungeon floor (`[snap] claim=0x00070143
VALIDATED z=0.000`), correct membership (cell stays `0x0007…`, ZERO ACE `failed
transition` spam), and the render budget is sane — **WB-DIAG instances ~39,000
(meshMissing=0)** vs the 9.1M pre-Bug-A blowup (#95, now RESOLVED as a Bug-A symptom).
User-confirmed: "no errors from ACE this time." REMAINING (not a render bug): dungeon
**torch/point-lighting = Phase A7** — the dungeon correctly gets retail's flat 0.2 indoor
ambient (`GameWindow.UpdateSunFromSky`, `playerInsideCell` true via `playerRoot && !SeenOutside`),
but per-cell `Setup.Lights` point-lights (torches) aren't registered yet, so it looks dim
("lighting off"). That's the A7 indoor-lighting feature, needs visual iteration.
**Severity:** HIGH (any far/dungeon teleport is unusable)
**Filed:** 2026-06-13 (M1.5 dungeon-demo gate attempt — meeting-hall portal)
**Component:** physics/streaming — teleport-arrival snap vs async landblock hydration
@ -916,16 +932,19 @@ Retail oracle for cell-id hysteresis: `acclient_2013_pseudo_c.txt:308742-308783`
## #95 — Dungeon portal-graph visibility blowup (see-through-walls / other dungeons rendered)
**Status:** OPEN — **RE-CONFIRMED LIVE under the current Option-A pipeline (2026-06-13
G.3a gate).** A real `PlayerTeleport` into the `0x0007` dungeon blew WB-DIAG up to
entSeen=6.5M / instances=9.1M / drawsIssued=590K per frame (vs. 3345/4667 at Holtburg)
with a flood of `[mesh-miss] 0x000100xxxx` interior re-requests → dungeon renders as
"thin air." So the T1–T6 rewrite did NOT supersede this (the earlier "likely superseded"
read was wrong). This is now the **#133/G.3b** blocker; fix shape = port retail
`CEnvCell::grab_visible_cells` (:311878) stab_list bounding (seen_outside==0 → walk only
stab_list, never the whole resident cell set). Needs its own grounding/brainstorm in the
flap-sensitive `PortalVisibilityBuilder`. **Originally** also: **explains user-observed
"dungeons are broken"**
**Status:** RESOLVED 2026-06-13 — **the 9.1M-instance blowup was a SYMPTOM of Bug A
(wrong dungeon membership), NOT an unbounded portal flood.** Chain of evidence: (1) a
headless diagnostic on the real `0x0007` dungeon (`Issue95DungeonFloodDiagnosticTests`,
`95d9dab`) measured `PortalVisibilityBuilder` visiting only **1–17 cells** per root —
already tightly bounded and a strict *subset* of the stab_list (`VisibleCells`, which is
the BIG set: avg 120, max 204 of 205 cells). So porting `grab_visible_cells` stab_list
bounding would have made it WORSE — **DO NOT do that.** (2) The 9.1M blowup was captured at
the G.3a gate *before* Bug A's fix (`2ce5e5c`), when the player's membership wrongly
resolved to `0xA9B3` (Holtburg) → the render rooted at the wrong place. (3) With Bug A +
login-into-dungeon (`47ae237`) fixed, a live launch into `0x0007` measured
**instances=~39,000 (down from 9.1M, ~230×), meshMissing=0**, dungeon renders, no ACE
errors. The flood was never the bug. **Originally** also: explained user-observed
"dungeons are broken"
**Severity:** HIGH (blocks all dungeon navigation visually)
**Filed:** 2026-05-21
**Component:** rendering, visibility, EnvCell portal traversal