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

docs: close #137 (dungeon collision, user re-gate) + file #187 (door animation dispatch gap)

Browse source 
#137 collision scope is done — user confirmed all dungeon door types can be clicked
and passed through with no phantom blocks (adds to the 2026-07-06 corridor +
window/opening gates). The same check surfaced a SEPARATE visual bug: sliding doors
and "fading wall" gates don't play their open animation, only literal-name "Door"
entities do (GameWindow.cs:3128 IsDoorSpawn gates the reactive-motion-table rescue on
an exact display-name match). Filed as #187 for investigation before any fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-07-08 17:14:11 +02:00
parent 4dea66b633
commit 0efa7ed2a1
1 changed files with 45 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

47
docs/ISSUES.md
View file

@ -46,6 +46,45 @@ Copy this block when adding a new issue:
---
## #187 — Non-hinged doors (sliding doors, "fading wall" gates) don't play their open animation
**Status:** OPEN — under investigation
**Severity:** MEDIUM (visual correctness; collision + interaction already work — #137)
**Filed:** 2026-07-08
**Component:** render — entity animation registration (`GameWindow.cs` live-spawn dispatch)
**Description (user):** door COLLISION is confirmed fixed (#137) — all doors can be clicked
and passed through correctly. But not all door TYPES play their open animation: normal
hinged doors swing open, but sliding doors and "fading wall" style dungeon gates do not
animate — the player passes through as if the door/wall just isn't there.
**Suspected root cause (pre-investigation read, NOT yet decomp-verified):**
`GameWindow.cs:3897` registers the door-swing sequencer only when
`IsDoorSpawn(spawn)` (`GameWindow.cs:3128`: `spawn.Name == "Door"`, an exact
display-name string match). The branch above it (`:3818`) already handles ANY entity
generically via its resolved idle cycle (multi-frame, framerate != 0) — no name check.
Doors need the special branch only because their REST pose is a static single frame
(fails the generic gate) while their MotionTable still carries reactive On/Off cycles
ACE drives via `UpdateMotion`. That "static rest + reactive motion-table cycle" shape
is not unique to hinged doors — any sliding/lever/gate prop with the same shape would
need the identical rescue, but only literal name `"Door"` gets it. Retail's own decomp
has ZERO `CDoor`-class or door-specific dispatch (only `ObjCollisionProfile::SetDoor`,
a collision-only concept) — suggesting retail's client-side animation dispatch is
entity-type-agnostic (MotionTable-driven), and the name-string gate is an acdream-only
divergence, not a port of anything retail does.
**Open question for the investigation:** are "fading wall" gates even MotionTable/
skeletal objects, or a structurally different mechanism (an ObjectDescription /
translucency-toggle triggered by a script, no motion involved)? Needs dat/weenie-data
survey before designing the fix — must not just add more name strings (same class of
bug, just deferred).
**Acceptance:** sliding doors + fading-wall gates play their open/close transition
matching the door's actual open/closed wire state, same as hinged doors today. Hinged
doors keep working (no regression). Suites green.
---
## #186 — [DONE 2026-07-08 · `8257b9ba`] Indoor→indoor GREY flap at a connecting room (top floor, new house type)
**Status:** CLOSED 2026-07-08 — live gate PASSED (no grey at any camera angle) + probe
@ -1891,9 +1930,13 @@ Both are the **entity-lifecycle/render path across a teleport**, NOT the streami
---
## #137 — Dungeon collision incorrect at doors and wall openings
## #137 — [DONE 2026-07-08] Dungeon collision incorrect at doors and wall openings
**Status:** OPEN
**Status:** CLOSED 2026-07-08 — user re-gate: "door collision is fixed" (clicked/passed
through multiple dungeon door types, no phantom blocks, no fall-through). Combined with
the 2026-07-06 corridor + window/opening gates already passed, all #137 COLLISION scope
is done. (The doors-open-but-don't-ANIMATE gap the same check surfaced is a SEPARATE
concern — filed as **#187**, since it's a visual/animation-dispatch issue, not collision.)
**Severity:** MEDIUM (movement/collision correctness in dungeons)
**Filed:** 2026-06-14
**Component:** physics — EnvCell collision (doors, portal openings, cell geometry)