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

docs: file #316 — player landing block omits the collision-shadow publish

Browse source 
Found while scoping the OnPosition collapse and confirmed by reading the
block: the player-guid LANDING TRANSITION hard-snap syncs body and render
entity but never calls LiveEntityShadowPublisher.TryPublishRemote, while the
NPC-guid copy's tail does. Contradicts the file's own #184 Slice 2b comments.

Filed with severity UNKNOWN deliberately: the per-tick remote commit may
republish the shadow on the next tick, which would make this a ~33 ms lag
rather than the #184 invisible-but-solid class. Measuring that is the first
step, not fixing it — and it is explicitly out of the behaviour-preserving
collapse's scope.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-04 17:03:18 +02:00
parent b260bcd12c
commit a89bcb39b2
1 changed files with 44 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

44
docs/ISSUES.md
View file

@ -13089,3 +13089,47 @@ meshes; scrolling cloud layers kept `GL_REPEAT`. The 5 dome walls were
sampling opposite-edge pixels via UV wrap + LINEAR filtering, producing
visible seam lines that formed a cube outline across the view.
-->
## #316 — The player arm's LANDING TRANSITION block never publishes the collision shadow
**Status:** OPEN
**Severity:** UNKNOWN pending one measurement (see "The open question") — either
a ~33 ms shadow lag (cosmetic, invisible in practice) or the #184
invisible-but-solid class (real). Do not act on it before measuring.
**Filed:** 2026-08-04
**Component:** physics / collision / remote presentation
**Found by** the OnPosition-collapse contract scoping
(`docs/research/2026-08-04-onposition-collapse-contract.md`), which neither
C4 route 4b-3 review round caught. Confirmed independently by reading the
block.
**Description:** `LiveEntityNetworkUpdateController.OnPosition`'s player-guid
LANDING TRANSITION block (the `!rmState.Body.InContact` hard-snap) does all of:
`Interp.Clear()`, the body position/orientation snap,
`TryArmConstraintAfterOperation`, the render-entity sync
(`entity.SetPosition` / `ParentCellId` / `Rotation`),
`EnsureRemoteMotionBindings`, and the landing probe — then returns. It never
calls `LiveEntityShadowPublisher.TryPublishRemote`. The three publish sites in
the file all sit outside this block, and the NPC-guid copy's equivalent
scenario DOES publish through its arm tail.
So a landing player-remote's body and render entity move to the authoritative
landing pose while its collision shadow stays at the pre-snap position.
This also contradicts the file's own #184 Slice 2b comments, which assert
"player shadows follow the resolved body exactly like NPCs". Those comments
are the stale-comment class the campaign has hit six slices running.
**The open question (measure before fixing):** the per-tick remote physics
commit syncs shadows on translation/orientation/cell change, so this may
self-heal on the next tick (~33 ms) rather than persisting. Whether it does
decides whether this is cosmetic or the #184 class. Resolve by landing a
remote player observer and sampling the shadow entry position against the body
across the landing frame and the following tick — `ACDREAM_PROBE_REMOTE_LANDING`
already instruments the packet side of exactly this edge.
**Why it is NOT fixed in the collapse:** the collapse is behaviour-preserving
by contract; adding a publish would be a behaviour change smuggled into a
refactor, and its severity is unmeasured. Split-on-discovery: own commit, with
a dual-guid test, after the measurement.