docs(handoff): door collision session end — honest accounting
Replaces the puffed-up framing in the prior task7-shipped handoff. Honest summary: no user-visible bug fixed this session. Off-center and inside-out door walk-through still 100% reproducible. The 4 commits shipped real infrastructure (multi-part registration + the GetNearbyObjects dedup fix that would have silently broken any future multi-part feature) but no observed behavioral change. Also explicitly retracts the "step-up is the bug" hypothesis from the prior handoff doc — ACDREAM_DUMP_STEPUP=1 in the apparatus produced no stepup: ENTER lines, so DoStepUp wasn't even being called. That hypothesis was over-reach from an inference I should not have inflated to a conclusion. Recommends the apparatus-replay pattern (same one that closed issue #98 after 6+ speculation rounds): live capture via ACDREAM_CAPTURE_RESOLVE → harness replay test → first per-field divergence names the broken assumption. DO-NOT list for the next session: do not redo the multi-part work, do not speculate-and-fix, do not relaunch with more probes hoping for an obvious signal. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik
parent
163a1f0d35
commit
6a2c432e5a
1 changed files with 188 additions and 0 deletions
188
docs/research/2026-05-24-door-collision-session-end-handoff.md
Normal file
188
docs/research/2026-05-24-door-collision-session-end-handoff.md
Normal file
|
|
@ -0,0 +1,188 @@
|
||||||
|
# Door collision — end-of-session handoff (2026-05-24, late)
|
||||||
|
|
||||||
|
**Branch:** `claude/strange-albattani-3fc83c`
|
||||||
|
**Worktree:** `C:\Users\erikn\source\repos\acdream\.claude\worktrees\strange-albattani-3fc83c`
|
||||||
|
|
||||||
|
## TL;DR — what was actually accomplished
|
||||||
|
|
||||||
|
**No user-visible bug was fixed this session.** The door bug the user
|
||||||
|
reported at the start (center blocks, off-center walks through,
|
||||||
|
inside-out walks through) is **identically reproducible after the
|
||||||
|
4 commits** as it was before them.
|
||||||
|
|
||||||
|
What changed: infrastructure. Server-spawned doors now register
|
||||||
|
multi-part shadow shapes (cylinder + BSP slab) instead of one
|
||||||
|
cylinder approximation. The BSP slab is queried 135 times per door
|
||||||
|
near approach but produces **zero collision hits**, so observed
|
||||||
|
behavior is unchanged.
|
||||||
|
|
||||||
|
**Don't re-do the infrastructure.** It's correctly built and necessary
|
||||||
|
for any future fix. The remaining work is downstream of it.
|
||||||
|
|
||||||
|
## Commits landed (4)
|
||||||
|
|
||||||
|
```
|
||||||
|
163a1f0 diag(phys): [bsp-test] probe + grounded apparatus test + handoff
|
||||||
|
ca9341c feat(phys): A6.P4 Task 7 — RegisterLiveEntityCollision uses ShadowShapeBuilder + RegisterMultiPart
|
||||||
|
3b7dc46 fix(phys): GetNearbyObjects dedup-by-entityId silently drops multi-part shadows
|
||||||
|
e1d94d7 test(phys): door setup + GfxObj dat-inspection — Hypothesis A falsified
|
||||||
|
```
|
||||||
|
|
||||||
|
**Real-but-latent value from these:**
|
||||||
|
- The dedup-by-entityId issue (3b7dc46) was a latent footgun: any
|
||||||
|
future attempt at multi-part shadows (NPCs with hit-region capsules,
|
||||||
|
multi-part creatures, props with separated collision) would have
|
||||||
|
silently dropped all but the first shape. Now safe.
|
||||||
|
- The dat-inspection (e1d94d7) proved part 0 (`0x010044B5`) has a
|
||||||
|
real 1.9×0.26×2.5 m BSP slab in the dat. A future fix doesn't have
|
||||||
|
to question whether the data exists.
|
||||||
|
- The Task 7 wiring (ca9341c) puts the right architecture in place —
|
||||||
|
doors now register the shapes retail expects (cyl per CylSphere +
|
||||||
|
cyl per Sphere + BSP per Part-with-BSP).
|
||||||
|
- The `[bsp-test]` probe (163a1f0) fires before the cache lookup,
|
||||||
|
distinguishing "cache miss → silent skip" from "queried but no
|
||||||
|
hit" — neither of which `[resolve-bldg]` ever showed.
|
||||||
|
|
||||||
|
**Brutally clear: zero of these commits change observed door behavior.**
|
||||||
|
|
||||||
|
## What we now know vs. what we don't
|
||||||
|
|
||||||
|
### Known (from this session's probes)
|
||||||
|
|
||||||
|
- `0x010044B5` PhysicsBSP has 6 collision-bearing polygons forming a
|
||||||
|
1.925 × 0.261 × 2.490 m door slab. All `SidesType=Landblock`
|
||||||
|
(two-sided). Bounding sphere radius 1.975 m. Verified by direct
|
||||||
|
dat read.
|
||||||
|
- `0x010044B6` (the two leaf parts) have `HasPhysics=false`,
|
||||||
|
`PhysicsBSP=null`, `PhysicsPolygons.Count=0`. Visual-only by retail
|
||||||
|
design — our skip matches retail's
|
||||||
|
`CPhysicsPart::find_obj_collisions:275051`.
|
||||||
|
- Live Holtburg doors register with `shapes=cyl1+bsp1`. Cache is
|
||||||
|
populated. BSP entries are visited (135x for one door at player
|
||||||
|
approaches as close as 0.42 m).
|
||||||
|
- The BSP traversal produces ZERO attributed hits during live walking
|
||||||
|
(all 19 `[resolve-bldg]` lines show `gfxObj=0x00000000`, which is
|
||||||
|
the Cylinder shape). Whatever is happening inside
|
||||||
|
`SphereIntersectsPolyInternal` or the dispatch around it is
|
||||||
|
swallowing the hit silently.
|
||||||
|
|
||||||
|
### NOT known (don't speculate further)
|
||||||
|
|
||||||
|
- **Whether `DoStepUp` is involved.** The prior handoff doc
|
||||||
|
(`2026-05-24-door-collision-task7-shipped-but-bug-remains.md`)
|
||||||
|
asserted "step-up incorrectly succeeds" as the leading hypothesis.
|
||||||
|
That was over-reach. In the apparatus, `ACDREAM_DUMP_STEPUP=1`
|
||||||
|
produced no `stepup: ENTER` lines — `DoStepUp` was never called.
|
||||||
|
So the apparatus shows `hit=yes n=(0,0,1)` from some OTHER path
|
||||||
|
(terrain step-down? walkable poly preservation?). It does not
|
||||||
|
confirm step-up is the production bug.
|
||||||
|
- **Whether the production hit happens at the BSP polygon edge test,
|
||||||
|
the BSP node traversal, or some other layer.**
|
||||||
|
- **Whether the production code path is the same as the apparatus
|
||||||
|
path 5 in the first place.**
|
||||||
|
|
||||||
|
The earlier framing of "step-up is the bug" was a guess I inflated
|
||||||
|
into a conclusion. Treat it as a candidate, not a finding.
|
||||||
|
|
||||||
|
## Proper next move
|
||||||
|
|
||||||
|
**Same pattern that closed issue #98 after 6+ failed speculation rounds:
|
||||||
|
live capture + apparatus replay.**
|
||||||
|
|
||||||
|
The infrastructure for this already exists in the codebase:
|
||||||
|
|
||||||
|
1. `ACDREAM_CAPTURE_RESOLVE=<path>` env var (see
|
||||||
|
`src/AcDream.Core/Physics/PhysicsResolveCapture.cs`) captures every
|
||||||
|
player-side `PhysicsEngine.ResolveWithTransition` call as a JSON
|
||||||
|
Lines record with full `PhysicsBody` before-and-after snapshots.
|
||||||
|
2. `CellarUpTrajectoryReplayTests.LoadCapturedRecord` +
|
||||||
|
`AssertCallMatchesCapture` replay a captured record through a
|
||||||
|
harness engine and emit the first per-field divergence between
|
||||||
|
live and harness outputs.
|
||||||
|
|
||||||
|
The plan:
|
||||||
|
|
||||||
|
1. Launch with `ACDREAM_CAPTURE_RESOLVE=door-walkthrough.jsonl`
|
||||||
|
(no other probes — capture is independent).
|
||||||
|
2. Walk into a closed Holtburg cottage door 50 cm off-center.
|
||||||
|
3. Close gracefully. Save the JSONL.
|
||||||
|
4. Write a new test `LiveCompare_DoorOffCenterWalkthrough` that loads
|
||||||
|
the failing-tick record and replays it through a harness with the
|
||||||
|
real `0x010044B5` BSP hydrated + registered via
|
||||||
|
`RegisterMultiPart`. Compare per-field.
|
||||||
|
5. The first divergent field names the broken assumption. Fix that.
|
||||||
|
|
||||||
|
This is concrete, deterministic, and doesn't ask you to relaunch
|
||||||
|
multiple times for each fix attempt. The harness round-trip is <500
|
||||||
|
ms; a fix iteration is ~3 seconds.
|
||||||
|
|
||||||
|
## What NOT to do
|
||||||
|
|
||||||
|
1. **Do NOT re-do the multi-part registration.** It's correct. The
|
||||||
|
dedup fix is correct. Task 7 is correct. Verified by 53/53 tests
|
||||||
|
in the targeted scope.
|
||||||
|
2. **Do NOT speculate-and-fix.** This session burned cycles on a
|
||||||
|
"step-up is the bug" hypothesis that wasn't supported by the
|
||||||
|
evidence. The apparatus-first rule (`feedback_apparatus_for_physics_bugs.md`)
|
||||||
|
exists for exactly this. Build the apparatus before the fix.
|
||||||
|
3. **Do NOT re-investigate whether the door has BSP polygons.**
|
||||||
|
It does. 6 of them. Forming a full door slab. Cached. Visited.
|
||||||
|
4. **Do NOT relaunch with more probes hoping for an obvious signal.**
|
||||||
|
The probes we have already say "BSP visited 135 times, no hits."
|
||||||
|
More log lines won't tell us WHY it doesn't hit. The apparatus
|
||||||
|
replay will.
|
||||||
|
|
||||||
|
## Files to read first
|
||||||
|
|
||||||
|
- This doc (you're in it).
|
||||||
|
- `docs/research/2026-05-24-door-dat-inspection-findings.md` — the
|
||||||
|
dat data, polygon layout, bounding sphere center vs frame offset.
|
||||||
|
- `docs/research/2026-05-24-door-collision-task7-shipped-but-bug-remains.md`
|
||||||
|
— the prior end-of-session handoff. **Read with skepticism** — its
|
||||||
|
"leading hypothesis" section overstates confidence in the step-up
|
||||||
|
theory (corrected here).
|
||||||
|
- `tests/AcDream.Core.Tests/Physics/CellarUpTrajectoryReplayTests.cs`
|
||||||
|
— the capture+replay pattern to mirror for the door bug. See
|
||||||
|
`LiveCompare_*` tests.
|
||||||
|
|
||||||
|
## State of the M1.5 milestone
|
||||||
|
|
||||||
|
Doors at Holtburg cottages: center blocks, off-center walks through,
|
||||||
|
inside-out walks through. Same as it was 24 hours ago. The walking-
|
||||||
|
through case is the actual user pain point. Until the apparatus
|
||||||
|
replay names the divergence, treat M1.5 indoor-world as still
|
||||||
|
incomplete on the door front.
|
||||||
|
|
||||||
|
The infrastructure is in place for the eventual fix. The fix itself
|
||||||
|
remains future work.
|
||||||
|
|
||||||
|
## Pickup prompt for the next session
|
||||||
|
|
||||||
|
```
|
||||||
|
Door collision investigation. Previous session shipped infrastructure
|
||||||
|
(multi-part registration + GetNearbyObjects dedup fix) but did NOT fix
|
||||||
|
the user-visible bug: off-center / inside-out approaches still walk
|
||||||
|
through closed Holtburg cottage doors.
|
||||||
|
|
||||||
|
Read docs/research/2026-05-24-door-collision-session-end-handoff.md
|
||||||
|
|
||||||
|
State both altitudes:
|
||||||
|
Currently working toward: M1.5 — Indoor world feels right
|
||||||
|
Current phase: A6.P4 door bug — apparatus replay phase.
|
||||||
|
Multi-part registration shipped; need live capture
|
||||||
|
+ per-field divergence comparison to identify why
|
||||||
|
the door's BSP slab fires zero attributed hits
|
||||||
|
despite being visited 135x per approach.
|
||||||
|
|
||||||
|
First move: launch the client with ACDREAM_CAPTURE_RESOLVE=<path>,
|
||||||
|
walk into a closed Holtburg cottage door 50 cm off-center, close
|
||||||
|
gracefully. Then write a LiveCompare_* test in CellarUpTrajectoryReplayTests
|
||||||
|
that loads the captured failing tick + replays through a harness
|
||||||
|
with the door BSP hydrated via the existing 0x010044B5 dat read
|
||||||
|
pattern and registered via RegisterMultiPart.
|
||||||
|
|
||||||
|
DO NOT redo the multi-part registration. DO NOT speculate about
|
||||||
|
step-up without evidence — the apparatus tested DoStepUp and it
|
||||||
|
didn't fire. The bug is upstream of step-up. The replay will name
|
||||||
|
the actual divergence.
|
||||||
|
```
|
||||||
Loading…
Add table
Add a link
Reference in a new issue