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

#119: the [up-null] lead is EXONERATED (dat-proven) - both GfxObjs are legitimately no-draw models

Browse source 
Issue119UpNullGfxObjDumpTests pins the dat truth: 0x010002B4 = 9 polys,
ALL NoPos, all surfaces Base1Solid; 0x010008A8 = 1 poly, NoPos,
Base1Solid|Translucent. Retail's skipNoTexture never draws either model
(the BR-1 build-time-skip <=> draw-time-skip equivalence), so
ObjectMeshManager's empty render-data cache is the CORRECT terminal state
- the only defect was the alarming "permanently invisible" log line,
reworded into an honest tripwire pointing at the dump test.

Second fact, same test (ShellModel_NoTexturedPolyIsDropped): on the
hall/tower shell 0x010014C3, ZERO textured polys are dropped by the
extraction gates (137/149 draw; the 12 dropped are the known #113
no-draw orphans) - the per-poly GfxObj extraction is exonerated for
building shells, kept green as a regression pin.

Net for #119: the missing tower-stair parts are NOT the up-null pair and
NOT a per-poly extraction drop. Remaining hypothesis space (interior
stair-cell flood admission, or a different model than assumed) needs the
re-gate to identify the exact tower; then the cell set + flood replay
headlessly like #118. ISSUES.md updated.

Suites: App 232, Core 1419+2skip (1416+3 new), UI 420, Net 294.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-06-11 16:55:45 +02:00
parent 5a80a2ee24
commit 8d93665053
3 changed files with 173 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

30
docs/ISSUES.md
View file

@ -4021,12 +4021,30 @@ in the render digest) and shows a water barrel that retail doesn't.
**Lead (from the T5 launch log):** exactly two
`[up-null] upload returned null for 0x00010002B4 / 0x00010008A8 — caching
EMPTY render data (permanently invisible)` lines at startup. Identify
which models those are (likely GfxObjs 0x010002B4 / 0x010008A8 — plausibly
the stair parts) and why `ObjectMeshManager`'s upload returned null; the
"permanently invisible" cache makes any transient failure sticky. The
barrel is a separate static-inclusion question (which cell owns it, and
is it admitted by a view it shouldn't be).
EMPTY render data (permanently invisible)` lines at startup.
**Narrowed 2026-06-11 (the [up-null] lead is EXONERATED, dat-proven):**
`Issue119UpNullGfxObjDumpTests` — both GfxObjs are legitimately no-draw
models: 0x010002B4 = 9 polys, ALL `NoPos`, all surfaces `Base1Solid`;
0x010008A8 = 1 poly, `NoPos`, `Base1Solid|Translucent`. Retail's
skipNoTexture never draws them either (the BR-1 equivalence) — the empty
cache is the CORRECT terminal state, and the alarming log line was the
only defect (reworded; it stays as a tripwire for the real-failure shape).
Second fact, same test: on the hall/tower shell 0x010014C3, ZERO textured
polys are dropped by the extraction gates (137/149 draw; the 12 dropped
are the known #113 no-draw orphans) — the per-poly extraction is
exonerated for building shells, pinned by
`ShellModel_NoTexturedPolyIsDropped`.
**Remaining hypothesis space (needs the re-gate to identify the exact
tower):** the missing stair parts draw from somewhere other than the
shell GfxObj's per-poly extraction — most plausibly interior stair-CELL
shells whose visibility depends on the flood admitting those cells from
the outside view, or a different building model than assumed. At the
re-gate: have the user point at the tower (one sentence / approx
location) — then the cell set + flood can be replayed headlessly like
#118. The extraneous water barrel remains a separate static-inclusion
question (which cell owns it; is it admitted by a view it shouldn't be).
---