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

docs #137: record the portal-poly oracle greps (question stays open)

Browse source 
CCellStruct::UnPack loads physics polys + BSP verbatim (no portal
stripping); the CPolygon test chain is pure geometry; CCellPortal
carries portal_side/exact_match but nothing in the BSP tests consults
it. Retail's PortalSide passability is therefore not a load filter or
poly flag — remaining candidates are the transit/membership test
order or a stippling/sidedness interaction. Next: cdb-attach retail
at the 0x8A02016E corridor per the step -1 protocol.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-07-05 17:22:05 +02:00
parent 17ce23ce38
commit 59705cf647
1 changed files with 14 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/ISSUES.md
View file

@ -1196,10 +1196,20 @@ matching the door's open/closed state.)
planes to world ±X — the phantom mid-corridor wall. Retail must honor the
portal's SIDE (pass from one side / solid from the other, or pass when the
neighbor is loaded); we collide with the raw polygon unconditionally.
**Oracle next (MANDATORY before fixing):** grep named-retail for how
BSPTREE::find_collisions / CEnvCell treats portal-flagged physics polys
(portal_side semantics; the prep note "portal passability comes from BSP
structure" was true for ExactMatch portals only).
**Oracle findings so far (2026-07-05 evening — greps done, question
OPEN):** `CCellStruct::UnPack` (0x00533d00) loads physics_polygons +
physics_bsp verbatim — NO portal-poly stripping at load;
`CPolygon::pos_hits_sphere`/`hits_sphere`/`polygon_hits_sphere_slow_but_sure`
(0x005394f0/0x00539540/0x00538a10) are pure geometry — no portal check;
`CCellPortal` (0x0053bab0) carries portal→CPolygon ptr + portal_side +
exact_match but nothing in the BSP test chain consults it. So retail's
passability for a PortalSide physics poly is NOT a load filter and NOT a
poly-level flag — remaining candidates: the transit/membership order
makes the sphere test the NEIGHBOR cell first (never hitting the portal
poly from the passable side), or a sidedness interaction
(stippling=NoPos + approach direction). NEXT: cdb-attach retail at this
exact corridor (0x8A02016E→011E portals) per the CLAUDE.md step −1
protocol — the decomp alone hasn't settled it.
2. **The stale sliding normal then wedges all forward motion** (the #116
slide-response family): after the single seam hit, EVERY subsequent
forward resolve returns `ok=False hit=no` with zero advance — the