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

docs(issues): reopen #145 — far-town teleport resolver runaway (residual of the source-drop fix)

Browse source 
Captured: teleport to far town (201,91) places correctly via the #145 verbatim path, then the per-frame resolve marches membership one landblock south/frame (un-rebased local position) until ACE rejects the inconsistent (cell, local) pair. #138 re-hydrate exonerated. Root cause under multi-agent research (acdream code + retail decomp oracle + capture).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik 2026-06-21 08:54:05 +02:00
parent b07825cd24
commit a4f0b51894
1 changed files with 29 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

32
docs/ISSUES.md
View file

@ -48,10 +48,36 @@ Copy this block when adding a new issue:
## #145 — Portals only work once per session (can't run in, run out, re-enter)
**Status:** CORE FIXED + user-verified 2026-06-20 (in→out→re-enter repeatedly works; no ACE errors; world renders). Remaining facets (server objects + own-avatar not rendering after a teleport-out) split to **#138** — they are entity render/lifecycle, a different subsystem from the cell-rooting bug this issue was.
**Severity:** HIGH (blocks repeated portal/dungeon travel — user, 2026-06-20)
**Status:** REOPENED 2026-06-21 — RESIDUAL: a teleport to a FAR town triggers a per-frame **resolver runaway** (the 2026-06-20 source-drop fix holds for Holtburg↔dungeon, but far-town destinations regress). #138 (objects come back) is confirmed SEPARATE + fixed. Root cause under research (retail-decomp oracle workflow).
**Severity:** HIGH (blocks far-town portal travel; breaks collision after the teleport — user, 2026-06-21)
**Filed:** 2026-06-20
**Component:** net/streaming — teleport (0xF751) + PortalSpace + arrival + cell rooting
**Component:** net/streaming/physics — teleport (0xF751) + PortalSpace + arrival + per-frame cell-resolve / coordinate-frame rebase
**⚠️ REOPENED 2026-06-21 — far-town teleport resolver runaway (capture in hand):**
Teleport dungeon (0,7) → far town **(201,91) = 0xC95B** (reached via the Town Network hub). The
client PLACES the player correctly via the #145 verbatim path
(`[snap] claim=0xC95B0001 pos=(14.8,0.3,12.005) branch=NO-LANDBLOCK -> verbatim`), then the
**very next per-frame physics resolve runs away**: cell membership marches one landblock SOUTH per
frame (`0xC95B → 0xC95A → … → 0xC900`, the landblock Y byte counting down) while the position
drifts (X +0.12/frame, Y −0.38/frame) and the player falls (Z 12 → −6.5) — i.e. the resolve never
REBASES the local position into the new landblock's frame, so it keeps "crossing" boundaries. It
settles "on ground" at cell `0xC900` local `(−6.1, −30.2, 12)`. ACE then sees a move from the true
spot `C95B0001 [14.8,0.3,12]` to `C9000008 [34.7, 17410, 24]` — landblock Y byte = 0 but local
Y = **17410 ≈ 91 landblocks of leaked offset** — an inconsistent (cell, local) pair → rejects every
move (`MOVEMENT SPEED` / `failed transition`) → no server-confirmed position → **collision gone**
(player falls through the world). `reason=resolver` (per-frame physics), NOT `teleport`.
Holtburg↔dungeon works because Holtburg is the startup center; the far town exposes the gap.
**Re-hydrate (#138) EXONERATED:** the re-hydrate fired only for Holtburg + the dungeon (log lines
412/498/710); it did NOT fire for the far town during the runaway (746+) — and it only adds RENDER
entities, never the physics `_landblocks` the resolver iterates.
**Apparatus:** `[cell-transit]` trail (`ACDREAM_PROBE_CELL=1`) + `desync-capture.jsonl` (72,401
`ResolveWithTransition` frames, `ACDREAM_CAPTURE_RESOLVE`). Suspected: the per-frame outdoor resolve
(`PhysicsEngine.Resolve` / `AdjustPosition` iterating `_landblocks`) does not normalize the local
position across a landblock crossing the way retail's `set_position`/`change_cell`/`AdjustPosition`
does — port that. Research workflow running (acdream resolver code + retail named-decomp/Ghidra
oracle + capture characterization → synthesis → adversarial verify).
**[ORIGINAL #145 — source-frame overlap, FIXED 2026-06-20; history below]**
**Description (user, 2026-06-20):** A portal can only be used ONCE per session. The first teleport works; a subsequent portal use (run out, or re-enter) does not. Goal: run in, run out, repeatedly.