From a40c38e8bdc0b7050b7d51ddb73cde1b6e5f21ac Mon Sep 17 00:00:00 2001 From: Erik Date: Sat, 13 Jun 2026 19:36:04 +0200 Subject: [PATCH] =?UTF-8?q?milestone(G.3):=20dungeons=20RENDER=20=E2=80=94?= =?UTF-8?q?=20#95=20was=20a=20Bug-A=20symptom,=20not=20an=20unbounded=20fl?= =?UTF-8?q?ood?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- CLAUDE.md | 19 +++++++++++-------- docs/ISSUES.md | 41 ++++++++++++++++++++++++++++++----------- 2 files changed, 41 insertions(+), 19 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index e328ce51..d4c43ff5 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -108,14 +108,17 @@ movement queries. ## Current state -**Currently working toward: M1.5 — Indoor world feels right.** The -building/cellar demo is DONE + user-gated, but M1.5 was EXTENDED 2026-06-13 -to include **dungeon support (full Phase G.3)** — dungeons don't work at -all: terrain-less dungeon landblocks aren't supported by the streaming/ -load/render/physics pipeline (`LandblockLoader.Load` null with no -`LandBlock`; streamer needs a terrain mesh; teleport snaps before hydration -→ ocean — issue **#133**). M1.5 does NOT land until dungeons work; M2 -(CombatMath) deferred. Currently brainstorming the G.3 dungeon-support spec. +**Currently working toward: M1.5 — Indoor world feels right.** Building/cellar +demo DONE; **dungeons now RENDER** (2026-06-13, autonomous /loop): G.3a teleport +hold+place + **Bug A** (validated-claim keeps the dungeon landblock prefix, `2ce5e5c`) ++ **login-into-dungeon recenter** (`47ae237`) → live `0x0007` dungeon renders, navigable, +correct membership, WB-DIAG instances **9.1M→39K**. **#95 was a Bug-A symptom, NOT an +unbounded flood — DO NOT port `grab_visible_cells` stab_list bounding** (the flood is +already bounded; the "terrain-less landblock" framing was refuted — dungeons are +flat-terrain + EnvCells). REMAINING for M1.5: **A7 dungeon torch/point-lighting** (dungeon +gets retail's flat 0.2 indoor ambient but `Setup.Lights` torches aren't registered → dim, +"lighting off"); needs visual iteration. M2 (CombatMath) deferred. Detail in **#133/#95** +(ISSUES) + the render digest's top banner. Recent closes (2026-06-12/13): #119/#128, #112, #113, #124, #129/#130/#131/#132, UN-2, #108-residual, #127, #125; #116 partial (Ghidra threshold fix). Keep this paragraph ≤5 lines + pointers — detail in the diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 63e83b6a..9974b7be 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -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