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

docs(issues): #464 running reproduction (camera outside the stairwell at movement start); file #467 run-in-place at the corridor mouth

Browse source 
The held-forward route captured the owner's running symptom: the first frame
after the press has the chase camera above and outside the stairwell, the
next is clean. Same defect as the zoom-out. The runs also showed the
character running in place at one corridor spot for 5+ s (#467, movement,
outside the campaign).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-09-03 21:26:58 +02:00
parent 590fbb66c3
commit 36866ba663
2 changed files with 13 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/ISSUES.md
View file

@ -39,6 +39,16 @@ confirmed closed by the owner, 11 need a focused live gate, and 43 are safe to
remain closed. See
[`docs/research/2026-08-28-owner-closed-issue-validity-audit.md`](research/2026-08-28-owner-closed-issue-validity-audit.md).
## #467 — Running forward from the cathedral stairwell stops at the corridor mouth: the character runs in place
**Status:** OPEN — found 2026-09-03 21:19 by the lead's #464 running reproduction (Release `590fbb66c`, local ACE, GM character with run skill 15230). Not a Campaign OVERHAUL v2 item (movement/collision, not world solidity); tactical, own fix.
**Severity:** MEDIUM (a held forward key stops moving the character at a specific spot; unknown how common the spot class is)
**Component:** local movement/collision — the player mover's swept-sphere step (`PlayerMovementController`, the flat collision port) or the held-key motion state after a cell change
**Symptom:** holding MovementForward from `F4180113 [39.50 19.59 181.12]` (and from `[39.36 21.29 179.77]`), the character descends two flights, passes the central pointed arch into the narrow corridor, and then stays at the same corridor spot with the run animation cycling for the remaining 5.4 s of the hold (`logs/selfgate-20260903-211930-464-run/artifacts/screenshots/464-run-03..10.png`, frames 0.77 s apart, identical world and camera, changing run pose) and again at the same spot on the second run (`464-run-24..27-stopped.png`). The corridor floor is open for roughly ten metres ahead to the arched doorway. The client log carries no position, cell or collision line for the hold (no probe was on) and no server correction line.
**Unknowns:** whether this is a collision stop (a step the mover cannot climb, a portal polygon treated as solid, sliding into the corridor's side walls at this character's very high run speed), a motion-state fault (the held key no longer producing forward motion after the cell change, with the run animation still playing), or an ACE-side correction. **First checks, in order:** (1) repeat the run with the explicit collision diagnostics on (`ACDREAM_PROBE_*`, see `docs/launch-options.md`) and a position line per frame; (2) compare the MoveToState cadence before and after the arch; (3) the owner runs the same line in retail and in acdream by hand (a normal run skill) to see whether the spot stops them too.
## #466 — Ravenous Eater (`/create 35121`) renders with stretched stripes and flat, untextured patches over half its body
**Status:** OPEN — owner-reported 2026-09-03 night (Release at `ea76a3803`, local ACE, GM `/create 35121` in the cathedral). Not a Campaign OVERHAUL v2 item (creature appearance, not world solidity); tactical, own fix.
@ -78,6 +88,8 @@ remain closed. See
**Matrix:** row added to the campaign plan §10 ("Cathedral stairwell, camera zoomed out") with the invariant; a read-only investigation against the decomp is running (mechanism, differences from retail's sweep, root cause, retail-faithful fix). Not an S4 depth/alpha item; it is the camera-versus-cell rule, and it blocks G3.
**Moving reproduction (lead, 2026-09-03 21:19, Release `590fbb66c`, `logs/selfgate-20260903-211930-464-run/`, route `tools/overhaul-selfgate/route-464-run.txt`):** from the mid pose `F4180113 [39.36 21.29 179.77]` at rest the frame is the enclosed stairwell (`464-run-21.png`); 0.75 s after MovementForward is pressed, `464-run-22.png` shows the chase camera several metres above and behind the stairwell, outside the cell: a dark exterior slab fills the lower half of the frame, the balcony wall and the vaulted hall are drawn beyond it, and only the character's head shows above the slab; 0.78 s later (`464-run-23.png`) the camera is back inside and the frame is clean. So the owner's "running down the stairs" symptom is this defect: the chase camera transiently occupies a position outside the stairwell when it starts to follow, and the frame roots from there. From the top pose the moving frames (`464-run-01..03`) stay consistent. The frames are 0.77 s apart (the screenshot readback costs about 0.6 s), so the transient's true duration is unknown (at most about 1.5 s).
## #463 — Soak `turn` samples can report a 0.1 ms GPU p50 (the turn window catches non-world frames)
**Status:** OPEN — found 2026-09-03 by the Campaign OVERHAUL v2 S3 review's perf re-measure.