feat(physics): C4 route 4a — remote steady-state Position through the seam
Routes the classifier's two NO-PLACEMENT remote branches — Interpolate (contact, PlayerDistance < 96 m) and NoPositionOperation (no contact) — through a Runtime-owned seam, and fixes the two divergences they carried. Teleport, far-snap and cell-less stay on the legacy App path; 4b owns them. Route 4 was split into 4a/4b after scoping put the whole route at 1,500-2,500 lines against a ~400 budget. 4a's branches perform no SetPosition, so this slice carries no deferred-cell park, no service-window guard and no allocation exposure — which is what made the split worth doing. Divergences fixed, both previously unfiled: * D1 — the NPC airborne branch hard-snapped Body.Position/Orientation and branched on the client-tracked rmState.Airborne, never consulting the wire IsGrounded bit. Retail's MoveOrTeleport @0x00516330 returns 0 at 0x0051636D and writes nothing. Player remotes were already correct; NPCs were not. * D2 — ConstrainTo was armed before the operation, unconditionally, so it fired on the airborne no-op retail skips and anchored to the PRE-move position. Retail arms it at 0x00454272, only when MoveOrTeleport returns nonzero, anchored to &arg2->m_position read live, i.e. post-move. AP-87 and TS-44 were carried deliberately, not delegated away. AP-87's three conditions — including firstUp, which one round silently dropped — are preserved as an explicit acdream policy layer applied AFTER the classifier commits to Interpolate; the two previously separate player/NPC copies are now one. TS-44 stays an NPC-only caller gate; extending sticky suppression to player remotes has no retail basis and no live evidence, so it was declined rather than absorbed. Landing is explicitly carved out of 4a's ownership on both arms. A landing packet classifies Interpolate, so an ordering slip would ENQUEUE a body that must PLANT and a creature knocked off a ledge would glide down over a packet interval. The carve-out is a named entry point returning AirborneSnap/SteadyStateInterpolate/ Legacy precisely so the PRECEDENCE is observable and testable rather than implied by statement order — that is how the slip happened once and was caught. The player/NPC asymmetry on landing is real and NOT resolved here: retail draws no such distinction, but converging them is a behaviour decision needing its own evidence. Filed into the 4b plan. Register: AP-135 filed for the two bookkeeping writes the airborne branch deliberately retains (rmState.CellId, LastServerPos/Time) — not retail's model, but load-bearing for our catch-up sweep and staleness timer, and verified not to be a canonical cell commit for ordinary remotes. AP-87 and TS-44 rewritten to describe the code. Honest remainder: App still owns branch selection, the airborne return, the cell write, the entity write and the shadow publish, and headless satisfies "both hosts drive the identical entry point" only vacuously since it returns early for remotes. That is written into the 4b bullet rather than left implicit. Cost: 364 non-comment production lines, 91% of the ~400 budget — the split did isolate the cheap half, but not by much. Do not carry "well under" into 4b's scoping. Gates: complete Release solution 10,938 passed / 4 skipped / 0 failed (pre-4a baseline 10,909). Four review rounds; the first three each introduced a new behavioural defect while fixing another, and each left a comment asserting behaviour that no longer matched — the final round's precedence matrix was traced cell-by-cell against HEAD with only the D1-intended difference. App tests call production entry points against a real WorldEntity and real classifier output, closing route 2's #292 gap rather than repeating it. Connected acceptance NOT run — needs a live second character. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik
parent
19d9509497
commit
44830a0eb3
12 changed files with 1854 additions and 150 deletions
|
|
@ -159,7 +159,7 @@ readiness/requeue adaptation. See
|
|||
|
||||
---
|
||||
|
||||
## 3. Documented approximation (AP) — 90 active rows (AP-130/AP-131/AP-132 filed 2026-08-02, continuation-executor slice; AP-1 narrowed 2026-07-31 by placement/streaming Slice 4A — the pure canonical retail `SetPosition` transaction exists, but production routes and lost-cell lifetime remain on the legacy resolver until Slice 4B; AP-5 retired 2026-07-31 at Campaign P Slice 2A — every successful `step_down` now performs retail's final `PLACEMENT_INSERT`; AP-3/AP-4 retired 2026-07-31 at Campaign P Slice 1B — `transitional_insert` and `edge_slide` now preserve retail's valid-contact early return and Branch-1-first order; AP-127 retired 2026-07-31 by #268 — the complete augmentation chain is shared by character UI and Runtime movement; AP-30 retired 2026-07-30 by the movement parity audit — retail Frame::is_equal genuinely uses the 0.0002 epsilon [byte-confirmed], so the row recorded a NON-divergence; acdream already matches; AP-129 narrowed 2026-07-30 at the P4 Opus review fix — `CanMoveInto`/`RestrictionDB::IsAllowedIn` are now ported and fed end-to-end (CreateObject HouseOwner/HouseRestrictions/Monarch tail fields + live `House_UpdateRestrictions 0x0248`, resolved through `PhysicsEngine.Objects`), retiring the original "CanMoveInto entirely unmodeled, unconditional fail-closed" gap the row described — the review was triggered by `RestrictionObjPrevalenceInspectionTests` showing 103,766 of 729,888 installed EnvCells (the whole housing estate) carry a baked `RestrictionObj`, so the unconditional fail-closed default would have locked every house for every player including its own owner; AP-10 retired 2026-07-30 at Campaign P Slice P4 — restored retail's 0.1 m dry-corner water sink-in, full suite green proving the sticky-bit no-regression argument; AP-71 retired same slice — `check_entry_restrictions` ported at the head of the indoor `FindEnvCollisions` branch, `CellPhysics.RestrictionObj` wired from the DAT-baked `EnvCell` field in both the dev and production caching paths; AP-128 filed 2026-07-30 at the P3 Opus review — PK-timer clock basis; AP-25 retired 2026-07-30 at Campaign P Slice P1 — the vitae/enchantment-aware run/jump skill chain; AP-7 retired 2026-07-30 at Campaign P Slice P2 — `calc_friction`'s threshold ported to retail's confirmed 0.25f; its still-open cos(10°)-vs-0.99999536f Sledding constant question moved to AD-55)
|
||||
## 3. Documented approximation (AP) — 93 active rows (AP-135 filed 2026-08-03, C4 route 4a — the airborne no-op's retained acdream bookkeeping; the stated total was 2 rows stale before that filing and is now a literal count of this section; AP-130/AP-131/AP-132 filed 2026-08-02, continuation-executor slice; AP-1 narrowed 2026-07-31 by placement/streaming Slice 4A — the pure canonical retail `SetPosition` transaction exists, but production routes and lost-cell lifetime remain on the legacy resolver until Slice 4B; AP-5 retired 2026-07-31 at Campaign P Slice 2A — every successful `step_down` now performs retail's final `PLACEMENT_INSERT`; AP-3/AP-4 retired 2026-07-31 at Campaign P Slice 1B — `transitional_insert` and `edge_slide` now preserve retail's valid-contact early return and Branch-1-first order; AP-127 retired 2026-07-31 by #268 — the complete augmentation chain is shared by character UI and Runtime movement; AP-30 retired 2026-07-30 by the movement parity audit — retail Frame::is_equal genuinely uses the 0.0002 epsilon [byte-confirmed], so the row recorded a NON-divergence; acdream already matches; AP-129 narrowed 2026-07-30 at the P4 Opus review fix — `CanMoveInto`/`RestrictionDB::IsAllowedIn` are now ported and fed end-to-end (CreateObject HouseOwner/HouseRestrictions/Monarch tail fields + live `House_UpdateRestrictions 0x0248`, resolved through `PhysicsEngine.Objects`), retiring the original "CanMoveInto entirely unmodeled, unconditional fail-closed" gap the row described — the review was triggered by `RestrictionObjPrevalenceInspectionTests` showing 103,766 of 729,888 installed EnvCells (the whole housing estate) carry a baked `RestrictionObj`, so the unconditional fail-closed default would have locked every house for every player including its own owner; AP-10 retired 2026-07-30 at Campaign P Slice P4 — restored retail's 0.1 m dry-corner water sink-in, full suite green proving the sticky-bit no-regression argument; AP-71 retired same slice — `check_entry_restrictions` ported at the head of the indoor `FindEnvCollisions` branch, `CellPhysics.RestrictionObj` wired from the DAT-baked `EnvCell` field in both the dev and production caching paths; AP-128 filed 2026-07-30 at the P3 Opus review — PK-timer clock basis; AP-25 retired 2026-07-30 at Campaign P Slice P1 — the vitae/enchantment-aware run/jump skill chain; AP-7 retired 2026-07-30 at Campaign P Slice P2 — `calc_friction`'s threshold ported to retail's confirmed 0.25f; its still-open cos(10°)-vs-0.99999536f Sledding constant question moved to AD-55)
|
||||
|
||||
Wave-0 UI ledger repair (2026-07-10) retired stale AP-38, resolved the AP-84
|
||||
collision, restored overwritten paperdoll rows as AP-92/AP-93, and registered
|
||||
|
|
@ -239,7 +239,7 @@ AP-94..AP-112 for the confirmed retail-UI completion gaps.
|
|||
| AP-83 | **CylCollideWithPoint PerfectClip TOI sub-branches decoded via ACE, not the binary**: the CCylSphere family port (2026-07-05, retires AP-6) reads `collide_with_point`'s PerfectClip time-of-impact math (0x0053adb6+) from ACE `CylSphere.CollideWithPoint` because the BN x87 mush is unreadable there; two ACE-verbatim quirks ported as-is (`movement.Z + radius` in the not-definite ascending case; `GlobalCurrCenter[0]` used even for head-sphere hits — the latter matches the raw decomp read). No current mover sets PerfectClip: players never do, and shipped ordinary missiles add PathClipped only. The non-PerfectClip path — SetCollisionNormal + Collided — is decomp-verified. Separately, the grounded head-sphere slide passes the HEAD disp per retail 0x0053b843 where ACE passes the foot disp — retail wins (ACE bug, not copied) | `src/AcDream.Core/Physics/TransitionTypes.cs` (`CylCollideWithPoint`; pseudocode doc `docs/research/2026-07-05-ccylsphere-collision-family-pseudocode.md` §7-8) | The load-bearing paths (non-PerfectClip Collided; the family's step-up/step-down/land) are decomp-verified; the TOI tail remains dormant unless a future mover explicitly enables PerfectClip | If a future mover explicitly enables PerfectClip, the two ACE quirks may diverge from retail — clip-through or wrong deflection on cylinder targets; re-decompile 0x0053acb0 in Ghidra before shipping that mover | `CCylSphere::collide_with_point` 0x0053acb0 (pc:324173, x87 mush from 0x0053adb6); ACE CylSphere.cs `CollideWithPoint` |
|
||||
| AP-91 | **CSphere `collide_with_point` PerfectClip TOI decoded via ACE, not the binary**: the CSphere family port reads the unreadable x87 tail from ACE `Sphere.CollideWithPoint`/`FindTimeOfCollision`; no current mover sets PerfectClip, and shipped ordinary missiles add PathClipped only | `src/AcDream.Core/Physics/TransitionTypes.cs` (`SphereCollideWithPoint`; `FindSphereTimeOfCollision`) | Load-bearing non-PerfectClip behavior is named-decomp verified; the adapted branch remains dormant unless a future mover explicitly enables PerfectClip | If a future mover explicitly enables PerfectClip, an ACE/retail TOI delta could cause clip-through or wrong sphere-target deflection | `CSphere::collide_with_point @ 0x00537230`; ACE `Sphere.CollideWithPoint` |
|
||||
| AP-86 | **Remote SHADOW-follows-resolved via a pose/cell-gated per-tick re-flood** (remote-creature de-overlap #184): every remote's collision shadow is rewritten at the resolved body position by the DR tick or authoritative UP tail, so collision remains where the creature renders and de-overlap persists. The effect matches retail, but acdream runs the full multipart cell flood whenever the body moved more than 1 cm, changed complete orientation, or crossed a cell instead of translating the existing shadow in place and relinking only when its crossed-cell set changes. Cross-cell motion now commits body/root/full-cell before the canonical rebucket callback; local and authoritative remote publishers prove exact-record spatial residency after that callback; pending projection suspends the retained shadow and cannot re-add it, including initial-pending and callback GUID-reuse cases. | `src/AcDream.App/Physics/RemotePhysicsUpdater.cs`; `src/AcDream.App/Physics/LiveEntityShadowPublisher.cs`; `src/AcDream.App/Rendering/GameWindow.cs` (local projection); `src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs` (authoritative UP tails); `src/AcDream.App/World/LiveEntityPresentationController.cs` (ordinary projection residency); `src/AcDream.Core/Physics/ShadowObjectRegistry.cs` (`UpdatePosition`) | The pose/cell gate is exact at de-overlap equilibrium, preserves offset/multipart shapes during in-place turns, and the resulting registered cell set matches retail; loaded/pending residency is symmetric and incarnation-scoped | A dense moving or turning crowd can still perform a full registration flood per creature per tick and create CPU/Gen0 pressure; a still crowd is gated out. Retire with an in-place move plus cell-relink-on-change implementation | `CPhysicsObj::SetPositionInternal(CTransition const*)` 0x00515330 → `change_cell`, then `remove_shadows_from_cells`/`add_shadows_to_cells` after the resolved frame/contact commit |
|
||||
| AP-87 | **NPC MoveOrTeleport placement adds a 4 m body-to-target snap + a no-Sequencer snap** beyond retail's <96 m-unconditional interpolate (remote-creature de-overlap #184, 2026-07-07): retail `CPhysicsObj::MoveOrTeleport` (0x00516330) hard-places only on the teleport-timestamp / cell==0 branch or the ≥96 m far-snap, and InterpolateTo-queues every near correction; acdream ADDS two snap conditions — `|Body.Position − worldPos| > 4 m` (a large correction / an unplaced first-UP body) and `!willBeDrTicked` (no Sequencer to consume the queue). Without them an unplaced body (origin / spawn seed) would enqueue, the InterpolationManager's 100 m far-blip would fire, and the per-tick sweep would run over a huge distance in a cell not containing the body → garbage resolved pos → the reverted attempt's INVISIBLE monster. `firstUp` (`LastServerPosTime<=0`) is a belt hint only — the 4 m guard is the load-bearing backstop | `src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs` (NPC MoveOrTeleport routing, `BodySnapThresholdNpc`/`willBeDrTickedNpc`) | acdream's catch-up+sweep needs the body already near the target (a valid nearby cell) for the per-frame sweep to be small; the 4 m snap keeps it there, and retail's own large-correction path (the 100 m far-blip) is upstream of it. The de-overlap sweep also uses the fixed human sphere (R 0.48 / H 1.835) for the mover regardless of creature size, so large packed creatures de-overlap at human radii — inherits **TS-46** | A grounded remote that legitimately lags >4 m from its server pos snaps (a small pop) where retail would slide; a no-Sequencer server-moved entity hard-snaps every UP (no DR smoothing). Both are rare | `CPhysicsObj::MoveOrTeleport` 0x00516330 (near-interpolate <96 m; teleport/cell-0 snap; far-snap ≥96 m); `InterpolationManager` 100 m `AutonomyBlipDistance` (the retail large-correction path) |
|
||||
| AP-87 | **Remote MoveOrTeleport placement adds a 4 m body-to-target snap + a no-Sequencer snap** beyond retail's <96 m-unconditional interpolate (remote-creature de-overlap #184, 2026-07-07; unified across player-remote and NPC-remote by C4 route 4a, 2026-08-03 — retail's disassembly makes no `this==player` distinction here either, so the two formerly-duplicated per-kind copies are now the SAME decision): retail `CPhysicsObj::MoveOrTeleport` (0x00516330) hard-places only on the teleport-timestamp / cell==0 branch or the ≥96 m far-snap, and InterpolateTo-queues every near correction; acdream ADDS two snap conditions — `|Body.Position − worldPos| > 4 m` (a large correction / an unplaced first-UP body) and `!willBeDrTicked` (no Sequencer to consume the queue). Without them an unplaced body (origin / spawn seed) would enqueue, the InterpolationManager's 100 m far-blip would fire, and the per-tick sweep would run over a huge distance in a cell not containing the body → garbage resolved pos → the reverted attempt's INVISIBLE monster. A third condition `firstUp` (`LastServerPosTime <= 0`) is RETAINED, not dropped, in the unified seam: it is a belt hint only — the 4 m guard is the load-bearing backstop — and it is structurally false for player remotes because the player-remote caller stamps `LastServerPosTime` in its diagnostic roll-forward block before it routes, so unifying the two copies on all three conditions leaves the player branch's own behaviour bit-identical | `src/AcDream.Runtime/Physics/RuntimeRemoteSteadyStatePosition.cs` (`ApplyInterpolate`, `BodySnapThreshold`); called from `src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs` for both the player-remote and NPC-remote near-Interpolate branches. The legacy far/cell-less/rejected fallbacks in that file still carry their own pre-existing copies of these constants until C4 route 4b deletes them | acdream's catch-up+sweep needs the body already near the target (a valid nearby cell) for the per-frame sweep to be small; the 4 m snap keeps it there, and retail's own large-correction path (the 100 m far-blip) is upstream of it. The de-overlap sweep also uses the fixed human sphere (R 0.48 / H 1.835) for the mover regardless of creature size, so large packed creatures de-overlap at human radii — inherits **TS-46** | A grounded remote that legitimately lags >4 m from its server pos snaps (a small pop) where retail would slide; a no-Sequencer server-moved entity hard-snaps every UP (no DR smoothing). Both are rare | `CPhysicsObj::MoveOrTeleport` 0x00516330 (near-interpolate <96 m; teleport/cell-0 snap; far-snap ≥96 m); `InterpolationManager` 100 m `AutonomyBlipDistance` (the retail large-correction path) |
|
||||
| AP-89 | **TransparentPartHook fade multiplies the SAMPLED TEXTURE alpha, not a separate material alpha channel** (#188, 2026-07-08 — the fading-wall secret-passage doors, e.g. "Pedestal Weak Spot"): retail's `CPhysicsPart::SetTranslucency` (0x0050e670) → `CMaterial::SetTranslucencySimple` (0x005396f0) REPLACES the D3D9 material's 4 alpha channels wholesale (`Ambient.a = Diffuse.a = Specular.a = Emissive.a = 1 − translucency`) — a per-material alpha that composes with, but is conceptually separate from, the surface's own sampled texture alpha. acdream's `mesh_modern.frag` has no material-alpha concept at all; the port multiplies the runtime fade's opacity multiplier directly against the already-sampled `color.a` (`FragColor = vec4(rgb, color.a * vOpacityMultiplier)`) | `src/AcDream.App/Rendering/Shaders/mesh_modern.frag` (final `FragColor` line); `src/AcDream.App/Rendering/Wb/WbDrawDispatcher.cs` (`ClassifyBatches` `opacityMultiplier` param, `InstanceGroup.Opacities`); `src/AcDream.Core/Rendering/TranslucencyFadeManager.cs` | Observably identical to retail for any surface whose base texture alpha is 1.0 everywhere — the Pedestal Weak Spot's stone-wall texture, and the overwhelming majority of AC surfaces, since `color.a * 1.0 == color.a` and the fade multiplier alone then drives the ramp exactly as `1 − translucency` would | A hypothetical object that is BOTH already alpha-keyed/blended from its own texture (stained glass, a flame surface) AND plays a TransparentPartHook fade simultaneously would compound the two alphas (texture-alpha × fade-multiplier) instead of the fade cleanly replacing/overriding the surface's own alpha as retail's material-replace does — such an object would fade darker / more-transparent than retail, not just at retail's rate | `CPhysicsPart::SetTranslucency` 0x0050e670; `CMaterial::SetTranslucencySimple` 0x005396f0 (`alpha = 1 − translucency`, applied to all 4 D3D9 material alpha channels) |
|
||||
| AP-90 | **Radar fellowship/allegiance relationship state is modeled but not yet delivered at runtime.** `RetailRadar.GetBlipShape` and `RadarBlipColors.For` implement retail's leader/member/allegiance precedence, and `RadarSnapshotProvider` exposes a `relationshipFor(guid)` seam, but acdream does not yet maintain live fellowship membership and its `AllegianceTree` is not wired into GameWindow. PK/PKLite relationship shapes do work from PWD flags. | `src/AcDream.App/UI/Layout/RadarSnapshotProvider.cs`; `src/AcDream.Core/Ui/RetailRadar.cs`; `src/AcDream.Core/Ui/RadarBlipColors.cs` | Preserve the exact model/seam now and avoid inventing membership from names or chat; connect it when the social game-event state is ported | Fellowship members render their ordinary player color/shape instead of bright-green leader/member triangles; allegiance members render an ordinary plus instead of a hollow box | `gmRadarUI::GetBlipColor` 0x004D76F0; `gmRadarUI::GetBlipShape` 0x004D7B60 |
|
||||
| AP-92 | Private creature viewports (paperdoll and examination) render through isolated `IGpuRenderTarget`s and blit into `UiViewport`; retail renders each `CreatureMode` directly and advances a cloned `CPhysicsObj`, while examination currently refreshes its clone from the live target's animated mesh pose. **V6l narrowing (2026-07-28), V11 update (2026-07-29):** the target is backend-neutral and the blit's V origin is not assumed — `IUiViewportRenderer.TextureIsBottomUp` derives it from the backend that made the texture. With GL deleted the only answer in the tree is Vulkan's top-left origin, but the seam is kept rather than folded flat, because it costs one property and it is what let the origin question be answered by data instead of by assumption. | `src/AcDream.App/Rendering/PrivateEntityViewportRenderer.cs`; `src/AcDream.App/Rendering/PaperdollFramePresenter.cs`; `src/AcDream.App/Rendering/CreatureAppraisalPresentation.cs`; `src/AcDream.App/UI/UiViewport.cs` | Vulkan render-to-texture is the modern backend equivalent; shared live pose data provides animation without registering a second gameplay entity or duplicating the world sequencer | Alpha, lighting, state isolation, or an assessment-time cloned motion diverging later from the live target can differ from direct retail CreatureMode presentation. The origin half of this risk is closed; a FUTURE backend would have to answer `TextureIsBottomUp` for itself | `CPhysicsObj::makeObject(CPhysicsObj const*) @ 0x005144B0`; `gmPaperDollUI::PostInit @ 0x004A5360`; `BasicCreatureExamineUI::Init @ 0x004AB9C0`; `UIElement_Viewport::SetCamera`; retail `CreatureMode::Render` |
|
||||
|
|
@ -281,6 +281,7 @@ AP-94..AP-112 for the confirmed retail-UI completion gaps.
|
|||
| AP-132 | **Filed 2026-08-02 (physics campaign, continuation-executor slice).** acdream gates queued parent relations on parent INCARNATION where retail's queue-by-GUID replay is pointer-only. Retail queues a missing-parent relation blob under the PARENT's GUID (`QueueBlobForObject` ~92326; GUID-keyed `CObjectMaint` placeholder bucket ~271082-271088) and replays it on GUID (re)creation with only an addressability check (~92312) - no PARENT INSTANCE_TS comparison anywhere on that path (retail's only instance check there is on the CHILD, ~92316-92317). acdream additionally compares the relation's `ParentInstanceSequence` at admission (pre-existing `TryApplyParent`/`Resolve` rules) and at executor replay (`ApplyReplayedParentRelation`): live-parent-newer discards, relation-newer stays queued for an exact match. The replay's child-missing arm also drops where retail would re-queue under the child's GUID; child-scoped bucket filtering (`RemoveObject`/`RemoveChild`) proactively covers the same ledger tradeoff. | `src/AcDream.Runtime/Entities/RuntimeInitialCreateContinuationExecutor.cs` (`ApplyReplayedParentRelation`); `RuntimeEntityObjectLifetime.cs` (`TryApplyParent` admission gate); `ParentAttachmentState.cs` (`Resolve` staleness rules) | The wire event names a SPECIFIC parent incarnation (`ParentEvent.Parsed.ParentInstanceSequence`) - the gate honors data the server explicitly sent. acdream's own established admission-time rules (`ParentAttachmentState.Resolve`, predating this slice) already fixed incarnation-gating as the project's parent-staleness posture; the replay path only extends that SAME posture for consistency. | Server GUID reuse between admission and replay: retail would attach the old queued relation to whatever NEW object now holds the GUID (retail's own recycling quirk); acdream discards it (parent newer) or leaves it queued (parent older) - silent loss of a relation retail would have applied, tied to server GUID-recycling cadence, not ordinary play. | Standalone parent handler 0x004535D0 (~92310-92326); `CObjectMaint::QueueBlobForObject` 0x005092D0 (~271082-271088); child instance check ~92316-92317 |
|
||||
| AP-133 | **Filed 2026-08-03 (#282).** A retail `CPhysicsObj` has exactly ONE `cell`; `ShouldDrawParticles` @0x0050fe60 reads that same field and calls `IsInView` on it, and `set_cell_id` @0x0050f4f0 / `change_cell` @0x00513390 are the only things that move it. acdream splits the concept into `WorldEntity.ParentCellId` (render parent, null for outdoor dat stabs and building shells) and `WorldEntity.EffectCellId` (authored landcell for those parentless stabs). Every consumer now resolves through the single `WorldEntity.VisibilityCellId` accessor (`ParentCellId ?? EffectCellId`); live entities carry `ParentCellId` only. | `src/AcDream.Core/World/WorldEntity.cs` (`VisibilityCellId`); writers `LandblockLoader.cs:80,97`, `LandblockBuildFactory.cs:408` | Outdoor dat stabs deliberately keep a null render parent so portal visibility does not filter them as interior geometry, yet retail still gives their physics object a landcell for particle gating. One accessor keeps the two fields from being read in conflicting orders, which is exactly how #282 arose - `EntityEffectPoseRegistry` preferred `EffectCellId` while `WbDrawDispatcher` and the remote spawn seed preferred `ParentCellId`. | A future writer that sets `EffectCellId` on a live entity re-creates #282: it wins `VisibilityCellId` while the 11 per-tick `ParentCellId` writers leave it frozen, stranding that entity's particles and lights on a stale cell so they fail `IsInView` after it crosses a boundary. | `CPhysicsObj::ShouldDrawParticles` 0x0050fe60; `CPhysicsObj::set_cell_id` 0x0050f4f0; `CPhysicsObj::change_cell` 0x00513390 |
|
||||
| AP-134 | **Filed 2026-08-03 (#297).** Retail keeps ONE `PublicWeenieDesc::_bitfield` per object and mutates it in place — `SetPlayerKillerStatus` @0x005AC7C0 rewrites bits 5/21/25 (PK `0x20` / Free `0x200000` / PKLite `0x2000000`, mutually exclusive), driven from `ACCWeenieObject::OnStatUpdated` @0x0058DF20 `case 0x86`, and `IsPK`/`IsImpenetrable`/`IsPKLite` @0x0058C8xx read that same field. acdream replicates the value into FIVE stores: `ClientObject.PublicWeenieBitfield` (the source, written only by `ClientObjectTable.UpdateIntProperty` on PropertyInt 134), `InboundPhysicsStateController._snapshots[guid].ObjectDescriptionFlags`, `RuntimeEntityRecord.Snapshot.ObjectDescriptionFlags`, the decoded `ShadowObjectRegistry` registration + per-cell `ShadowEntry.Flags`, and the local player's `RuntimeMovementSkillState` own-PWD bitfield. Coherence is maintained by two `ObjectUpdated` subscribers (`RuntimeEntityPvpBitfieldSnapshotSync` for the two snapshot stores, `LiveEntityPvpBitfieldSync` for the decoded shadow flags) plus the appearance-rebuild path re-deriving from the snapshot. The two shadow-flag writers are the SAME invalidation applied at the two edges that can invalidate it, not competing authorities. | `src/AcDream.Runtime/Entities/RuntimeEntityPvpBitfieldSnapshotSync.cs`; `src/AcDream.App/Physics/LiveEntityPvpBitfieldSync.cs`; source writer `src/AcDream.Core/Items/ClientObjectTable.cs` (`UpdateIntProperty`, PropertyInt 134); decode `EntityCollisionFlagsExt.FromPwdBitfield` | ACE never re-sends a `PublicWeenieDesc` after login (`EnqueueBroadcastUpdateObject` has zero live callers), so PropertyInt 134 over 0x02CE/0x02CD is the ONLY signal a PK status changed — a client cannot learn it from the bitfield itself. The replication exists because acdream separates wire snapshots, canonical records, and the collision shadow registry, which retail does not; each layer needs the decoded value at a different lifetime. Before #297 the snapshot stores were immutable wire captures; this commit is what converts them into write-through caches, and therefore what creates the invariant. | Any future write path that sets `ClientObject.PublicWeenieBitfield` outside `UpdateIntProperty`, or any NEW decoded cache of the PK bits, silently re-creates #297: the player walks through PKLite opponents and melee/missile admission refuses them, with no test failing. Note the same class already exists one field over — `Properties.Ints[134]` is written by `UpsertProperties` (PlayerDescription 0x0013) and `UpdateProperties` (IdentifyObjectResponse) WITHOUT mirroring into the bitfield (#300), and retail's `OnStatUpdated` also rewrites `_blipColor` (`case 0x5f`) and `_radar_enum` (`case 0x85`) which acdream ignores entirely (#301). | `PublicWeenieDesc::SetPlayerKillerStatus` 0x005AC7C0; `ACCWeenieObject::OnStatUpdated` 0x0058DF20 (`case 0x86`); `ACCWeenieObject::IsPK`/`IsImpenetrable`/`IsPKLite` 0x0058C8xx; retail `PKStatusEnum` `acclient.h:6412-6427` |
|
||||
| AP-135 | **Filed 2026-08-03 (C4 route 4a).** Retail `CPhysicsObj::MoveOrTeleport` 0x00516330 writes NOTHING on the airborne no-op (`arg4 == 0` -> `return 0` @0x0051636D), and `SmartBox::HandleReceivedPosition` 0x00453FD0 skips `ConstrainTo` with it (@0x00454272 sits inside `if (MoveOrTeleport(...) != 0)` @0x00454254). acdream honours that for every retail-modeled write — body pose, interpolation queue, leash, render entity, collision shadow, and the AP-80 velocity-derived animation cycle — but deliberately KEEPS two acdream-only per-packet bookkeeping writes on that branch: `RemoteMotion.CellId = wire landblock` and the `LastServerPos`/`LastServerPosTime` sample. This was pre-existing player-remote behaviour; route 4a extends it to NPC remotes so both arms are identical | `src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs` (`OnPosition`, both remote airborne-no-op returns) | The cell id is what acdream's OWN per-tick free-fall `ResolveWithTransition` sweep gates on (`rm.CellId != 0`); without it an airborne remote's sphere sweep is skipped and it falls through the floor (#42's neighbourhood). The server sample is what the first grounded packet after the arc synthesizes its velocity from; dropping it would make that velocity span the whole jump. Neither is a retail `CPhysicsObj` field being written | A remote's cell membership tracks the server's landblock during an arc where retail would keep the cell its own physics last resolved. Visible only if the server's mid-arc landblock disagrees with the client's swept cell — the wire cell is authoritative in every case acdream has observed. Retire together with the free-fall sweep gate, when the remote arc is resolved by the same transition machinery the local player uses | `CPhysicsObj::MoveOrTeleport` 0x00516330 (@0x0051636D `return 0`); `SmartBox::HandleReceivedPosition` 0x00453FD0 (@0x00454254/@0x00454272) |
|
||||
|
||||
## 4. Temporary stopgap (TS) — 36 active rows (TS-62/TS-63 filed 2026-08-02, continuation-executor slice; TS-4 and TS-8 retired 2026-07-31; Campaign P's goal-enumerated physics stopgaps are now zero. TS-4's graph/flat Path-6 branches match retail's foot SetCollide/Adjusted and head CollisionNormal/Collided split with no BSP-layer sliding-normal write; TS-8's live 0x02C2 carries its complete StatMod through the canonical enchantment record and updates effective stats immediately. Campaign P P7 2026-07-30: TS-25 retired — outbound stance has shipped via RawState.CurrentStyle since #219; TS-24 re-argued to AD-57; TS-40 re-argued to AD-58; TS-35 retired at P5; earlier same campaign: TS-1/TS-5/TS-23/TS-46 retired by ports; TS-23 retired 2026-07-30 at Campaign P Slice P3 — every mover-flags call site (local player world-entry ×2, remote DR sweep ×2, remote teleport, ordinary movers) now ORs in the mover's real PK/PKLite/Impenetrable `ObjectInfoState` bits via the new `ClientObjectTable`-backed `EntityCollisionFlagsExt.ResolveMoverPvpState` — **narrative corrected 2026-08-03 (#297): "real" only became true at #297. Until then the bits existed but the source `PublicWeenieBitfield` was frozen at CreateObject, so every one of those sites read a stale value for the whole session. The site enumeration is also incomplete: `RuntimeSetPositionMoverPreparation.cs:183-188` is a SEVENTH mover-flags site that decodes `record.Snapshot.ObjectDescriptionFlags` directly rather than calling `ResolveMoverPvpState`, and it also derives `ObjectInfoState.IsPlayer` from the PWD bit, contradicting `EntityCollisionFlags.cs:119-123`'s claim that every site uses a GUID-prefix heuristic. See AP-134.** — and `PlayerWeenie.JumpStaminaCost`'s `pk` parameter reads the real `PlayerKillerStatus`/`LastPkAttackTimestamp` pair against a 20-second window instead of a hardcoded `false`; the non-PK invariant (every ACE default-created character) is bit-identical to the pre-P3 value since `ResolveMoverPvpState` and the PK-timer predicate both resolve to a no-op for `PublicWeenieBitfield` absent/0; TS-46 retired 2026-07-30 at Campaign P Slice P3 — the Setup's verbatim ≤2-sphere list (`CPhysicsObj::transition` 0x00512dc0 → `SPHEREPATH::init_sphere` 0x0050c670) now seeds the sweep for the local player, remote dead-reckoning, and ordinary movers alike, replacing the two-scalar (radius, height) capsule reconstruction; remote/ordinary step-up/step-down are now Setup-derived (`CPartArray::GetStepUpHeight`/`GetStepDownHeight`, 0x005180d0/0x005180f0, ×ObjScale) instead of a hardcoded 0.4 m, closing both residuals the row named; TS-5 retired 2026-07-30 at Campaign P Slice P1 — real burden-gated CanJump + real JumpStaminaCost, both decomp-verbatim; TS-1 retired 2026-07-30 at Campaign P Slice P2 — the row was stale; the EdgeSlide → PrecipiceSlide/CliffSlide chain is already a real, tested port; TS-57..TS-61 filed 2026-07-29 during Campaign N — no outbound RejectRetransmit; TS-27 narrowed same slice to the inbound direction) + TS-37 historical note (TS-20 retired 2026-07-16 — the later named-retail audit disproved the proposed DrawingBSP polygon filter; TS-37 is a retired-row historical note, not an active count; TS-39 retired R5-V3 — sticky seams bound to the ported PositionManager/StickyManager, radii threaded; TS-45 retired 2026-07-07 — hand-rolled `SphereCollision` replaced by the faithful CSphere family port, fixing the player-vs-monster crowd wedge; TS-3 retired 2026-07-07 — `frames_stationary_fall` accounting ported in the #182 verbatim UpdateObjectInternal rebuild, fixing the airborne falling-animation wedge; TS-41 retired 2026-07-07 — SERVERVEL synth-velocity remote body-drive replaced by the retail interp catch-up + unconditional MovementManager::UseTime, the remote-creature de-overlap #184; TS-42 retired 2026-07-19 — semantic animation completion now precedes the ordered Target/Movement/PartArray/Position tail; TS-44 narrowed again 2026-07-19 — complete orientation joined interpolation, only during-stick enqueue suppression remains)
|
||||
|
||||
|
|
@ -309,7 +310,7 @@ AP-94..AP-112 for the confirmed retail-UI completion gaps.
|
|||
| TS-37 | RETIRED misattribution note (not a live divergence — kept here as the historical record R3-W3 closes): the S2a port had `contact_allows_move` (0x00528240) arm `StandingLongJump` as a side effect, explicitly flagged "PRE-EXISTING acdream side effect (not part of 0x00528240)". R3-W3 deletes that side effect; `ChargeJump` (0x005281c0) is now the ONLY arming site, matching retail exactly. No further action — recorded per the register's retire-in-same-commit rule | `src/AcDream.Core/Physics/MotionInterpreter.cs` (`contact_allows_move`, `ChargeJump`) | N/A — retired | N/A — retired | `CMotionInterp::charge_jump` 0x005281c0 @305448 |
|
||||
| TS-38 | `MotionInterpreter.Initted` defaults to `true` in both constructors, not retail's `false` — retail's `CMotionInterp` is never observed pre-`enter_default_state` (every real construction path calls it before exposing the interpreter); acdream's constructors are used directly by ~40 pre-existing tests and both App call sites as complete, immediately-usable objects with no separate "enter default state" step | `src/AcDream.Core/Physics/MotionInterpreter.cs` (`Initted` property + both constructors) | Defaulting `true` is the C# equivalent of "the constructor already did what `enter_default_state` would have done to this flag" — `EnterDefaultState()` remains available, verbatim, for the REST of retail's reset semantics (state defaults, sentinel enqueue, `LeaveGround` tail) when a caller wants them | None observed: no code path needs `apply_current_movement`/`ReportExhaustion` to no-op before an explicit `EnterDefaultState()` call, since nothing constructs a `MotionInterpreter` and defers initialization today. If a future caller DOES need staged construction (build now, `EnterDefaultState()` later), it must explicitly set `Initted = false` first | `CMotionInterp::enter_default_state` 0x00528c80 @306124 sets `initted = 1`; retire if/when construction is staged through `EnterDefaultState()` uniformly |
|
||||
| ~~TS-41~~ | **RETIRED 2026-07-07 (remote-creature de-overlap #184)** — the SERVERVEL synth-velocity body-drive (`Body.Velocity = ServerVelocity` / `get_state_velocity()` leg) is DELETED. Grounded NPC remotes now translate by the retail interp CATCH-UP (`RemoteMotionCombiner.ComputeOffset` → `InterpolationManager::adjust_offset` toward the MoveOrTeleport-queued server waypoint) and `MovementManager::UseTime` (`TickRemoteMoveTo`) runs UNCONDITIONALLY per tick — the retail `UpdateObjectInternal` shape (no wire-velocity leg-driver). The de-overlap sweep resolves the catch-up movement; the resolved position is written back into the SHADOW (AP-86) so it persists. Residual: the non-retail anim-cycle stale-stop heuristic (`ApplyServerControlledVelocityCycle(Zero)` on a >0.6 s velocity-staleness timer) is kept as ANIM-only and stays covered by **AP-80**; it no longer drives the body. | `src/AcDream.App/Physics/RemotePhysicsUpdater.cs` (grounded NPC branch) | — | — | `CPhysicsObj::UpdateObjectInternal` 0x005156b0 (`MovementManager::UseTime` @0x00515998, unconditional); `MoveOrTeleport` 0x00516330; `InterpolationManager::adjust_offset` 0x00555d30 |
|
||||
| TS-44 | NPC UpdatePosition **enqueue is suppressed while StickyManager is armed** (`PositionManager.GetStickyObjectId() != 0`). Position and complete orientation otherwise share the ported `InterpolateTo → Position::subtract2 → PositionManager::adjust_offset` Frame, so the former orientation hard-snap residual is retired. Retail would still enqueue the server Position and let Sticky overwrite that Frame each tick; acdream retains the gate so no queued waypoint survives the stick | `src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs` (NPC `snapSuppressedByStick` gate) | Avoids replaying an old ACE waypoint immediately after a stick lease ends; all live during-stick pose ownership is now otherwise retail-shaped | After unstick the body waits for the next UP instead of consuming the latest waypoint already in the queue; at low packet cadence this can pause correction for one update interval | `PositionManager::adjust_offset` 0x00555190; `CPhysicsObj::MoveOrTeleport` 0x00516330; retire by allowing enqueue while Sticky overwrites the shared complete Frame |
|
||||
| TS-44 | NPC UpdatePosition **enqueue is suppressed while StickyManager is armed** (`PositionManager.GetStickyObjectId() != 0`). Position and complete orientation otherwise share the ported `InterpolateTo → Position::subtract2 → PositionManager::adjust_offset` Frame, so the former orientation hard-snap residual is retired. Retail would still enqueue the server Position and let Sticky overwrite that Frame each tick; acdream retains the gate so no queued waypoint survives the stick. **Scope re-affirmed by C4 route 4a (2026-08-03):** the gate stays NPC-only and stays in the App caller. The shared Runtime seam route 4a introduced is deliberately indifferent to the sticky lease, because folding the check into it would have silently extended TS-44 to player remotes — which are stickable but have never had this suppression, and whose far branch would still not have it | NPC-only caller gate, `src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs` (`snapSuppressedByStick`) | Avoids replaying an old ACE waypoint immediately after a stick lease ends; all live during-stick pose ownership is now otherwise retail-shaped | After unstick the body waits for the next UP instead of consuming the latest waypoint already in the queue; at low packet cadence this can pause correction for one update interval | `PositionManager::adjust_offset` 0x00555190; `CPhysicsObj::MoveOrTeleport` 0x00516330; retire by allowing enqueue while Sticky overwrites the shared complete Frame |
|
||||
| ~~TS-45~~ | **RETIRED 2026-07-07** — the hand-rolled `SphereCollision` (forced `combinedR+1 cm` radial de-penetration + leaked `SetSlidingNormal` + always-Slid, head-sphere ignored) is REPLACED by the faithful `CSphere::intersects_sphere` family port (branch dispatcher 0x00537A80 + `step_sphere_up`/`slide_sphere`/`land_on_sphere`/`collide_with_point`/`step_sphere_down`), routing the grounded slide through the shared crease `SlideSphere` (0x00537440). Humanoid creatures collide via body Spheres, so this was the player-vs-monster crowd path; the radial de-penetration was the "can't wiggle free in a packed crowd" wedge. `SphereCollisionFamilyTests` (slide-around, block, ethereal) + `docs/research/2026-07-07-csphere-collision-family-pseudocode.md`. Residual `AP-91` (PerfectClip TOI dead in M1.5). | — | — | — | `CSphere::intersects_sphere` 0x00537A80 (pc:321678) |
|
||||
| TS-47 | **NARROWED 2026-07-13** — typed routing now ports the named-retail recall/house/PK travel, age/birth, local display/location, UI persistence, AFK/consent, emote, friends, squelch/filter, and fill-components families. Retail-owned verbs outside the researched family set still fall through to ACE until individually verified. | `src/AcDream.UI.Abstractions/Panels/Chat/RetailClientCommandCatalog.cs`; `src/AcDream.App/UI/ClientCommandController.cs`; `src/AcDream.Core.Net/Messages/ClientCommandRequests.cs` | The high-use researched families have decomp pseudocode, typed actions, and conformance tests; unresearched registry entries must follow the same evidence-first path | An unported retail-owned verb can still produce ACE unknown-command output or server-specific behavior instead of its client action | `ClientCommunicationSystem` command-table construction around `0x00581A40..0x005850A0`; `docs/research/2026-07-13-retail-client-command-routing-pseudocode.md`; `docs/research/2026-07-13-retail-client-command-families-pseudocode.md` |
|
||||
| TS-48 | Dragging an item onto another player honors the authoritative `DragItemOnPlayerOpensSecureTrade` option, but the option's default-true branch stops at the existing unavailable toast because the secure-trade transaction and UI are not ported. Direct player giving through `GiveObjectRequest 0x00CD` works when the option is disabled; NPC giving is complete. | `src/AcDream.App/UI/ItemInteractionController.cs` (`PlaceIn3D`, `PolicyActionMessage`); `src/AcDream.Core/Items/ItemInteractionPolicy.cs` | The player/NPC distinction and character preference are now faithful; inventing a direct gift while the option requests secure trade would be a worse behavioral divergence. Secure trade is a separate multi-party state machine beyond the starter-dungeon NPC-give slice. | With retail's default character options, an item dragged onto another player cannot be exchanged until the secure-trade subsystem lands. | `ItemHolder::AttemptPlaceIn3D @ 0x00588600`; `PlayerModule::DragItemOnPlayerOpensSecureTrade @ 0x005D31B0`; `ClientTradeSystem`; `docs/research/2026-07-13-retail-give-item-pseudocode.md` |
|
||||
|
|
|
|||
|
|
@ -270,6 +270,35 @@ same commit) → docs/handoff commit. No workarounds; no fused slices.
|
|||
Position-time service-window guard, #277's broken bound, N3 (headless never
|
||||
calls `RetryPending`), and the third divergence (`ConstrainTo` never armed
|
||||
on the remote teleport branch) all live.
|
||||
|
||||
**4b also inherits 4a's ownership remainder — scheduled here, not implied
|
||||
by code comments.** Two independent reviews flagged that 4a satisfies
|
||||
contract items 1 and 2 only partially, and the plan must carry that rather
|
||||
than leaving it in `// 4b deletes this fallback` comments:
|
||||
- Runtime owns the classification, the request construction (one shared
|
||||
builder, `RuntimeAcceptedPositionRouteRequests`), the near-InterpolateTo
|
||||
decision with AP-87, and the post-operation `ConstrainTo`. **App still
|
||||
owns** branch selection, the airborne early return, the
|
||||
`RemoteMotion.CellId` write, the `WorldEntity` pose write, and the
|
||||
collision-shadow publish — all in `LiveEntityNetworkUpdateController`.
|
||||
- Item 2 ("both hosts drive the identical Runtime entry point") is
|
||||
satisfied only VACUOUSLY: `RuntimeLiveEntitySessionController` returns
|
||||
early for remotes, so no no-window host exercises this path at all and
|
||||
nothing can diverge yet. That stops being true the moment a headless
|
||||
host needs remote motion.
|
||||
- Every legacy fallback 4a deliberately left in place is 4b's to delete:
|
||||
the pre-operation unconditional `ConstrainTo`, the player arm's
|
||||
`!update.IsGrounded` no-op, the player and NPC legacy near/far routing
|
||||
(each still carrying its own duplicate `96f` / `4f` constants), and the
|
||||
airborne-precedence carve-out
|
||||
(`LiveEntityNetworkUpdateController.ApplyRemoteContactRouting`) that
|
||||
keeps a landing body snapping. Retiring the last one is a real behaviour
|
||||
decision — retail makes no player/NPC distinction there — and needs its
|
||||
own live evidence, not a silent convergence.
|
||||
- Register row **AP-135** (the airborne no-op's retained acdream
|
||||
bookkeeping: the server cell id for the free-fall sweep gate, and the
|
||||
last-server-position sample) retires with 4b's transition machinery, not
|
||||
before.
|
||||
Note the route-4 Create half is ALREADY DONE (C3b/C3c); the remaining work is
|
||||
steady-state remote Position plus the deletions. AP-131 is NOT retired by
|
||||
either sub-slice — see the scoping doc for why route 4 alone cannot.
|
||||
|
|
|
|||
|
|
@ -81,11 +81,24 @@ a nonzero return, anchored post-move. No register row exists.
|
|||
|
||||
Only the parts reachable from the two 4a branches:
|
||||
|
||||
- The generic tail's remote writes (`entity.SetPosition` / `ParentCellId` /
|
||||
`Rotation` / `RebucketLiveEntity`) for a remote whose classification is
|
||||
`Interpolate` or `NoPositionOperation`. The committed result must reach the
|
||||
render entity through the existing placement-projection sink instead — the
|
||||
same substitution route 2 made.
|
||||
- The generic tail's remote RENDER-POSE writes (`entity.SetPosition` /
|
||||
`ParentCellId` / `Rotation`) for a remote whose classification is
|
||||
`Interpolate` or `NoPositionOperation`.
|
||||
|
||||
> **CORRECTED 2026-08-03 (review finding R1,
|
||||
> [`2026-08-03-c4-route-4a-review-findings.md`](2026-08-03-c4-route-4a-review-findings.md)).**
|
||||
> This bullet originally also listed `RebucketLiveEntity`, and said the
|
||||
> result "must reach the render entity through the existing
|
||||
> placement-projection sink instead — the same substitution route 2 made."
|
||||
> That instruction was copied from route 2 and does not transfer: route 2
|
||||
> performs a placement and therefore has a committed receipt to project,
|
||||
> while NEITHER 4a branch performs a placement, so nothing substitutes for
|
||||
> the bucket transaction. **The rebucket keeps running for both 4a
|
||||
> classifications.** It is the only site that moves an ordinary moving
|
||||
> remote's draw bucket, commits its canonical `FullCellId`, and recovers a
|
||||
> pending bucket promotion (`GpuWorldState`, the 2026-07-03 invisible-player
|
||||
> fix); deleting it produced the #184-class invisible-but-solid creature
|
||||
> through a different door.
|
||||
- The player-remote near/far routing at `:1653-1702` and the NPC copy at
|
||||
`:1826-1871` — **the near half only.** Each has its own duplicated copies of
|
||||
`MaxPhysicsDistance = 96f` and `BodySnapThreshold = 4f`; the far half stays
|
||||
|
|
@ -122,6 +135,19 @@ to the classifier is the failure mode.** Say which you chose.
|
|||
transfer.
|
||||
5. The airborne branch writes NOTHING (retail returns 0). Not the body, not the
|
||||
render entity, not the cell.
|
||||
|
||||
> **AMENDED 2026-08-03/04 (review finding R4).** As shipped, the branch
|
||||
> retains exactly two acdream bookkeeping writes — `rmState.CellId` and
|
||||
> `LastServerPos`/`LastServerPosTime` — on both arms. These are not part of
|
||||
> retail's model (retail's `MoveOrTeleport` has no catch-up sweep and no
|
||||
> staleness timer to keep alive), and dropping them would break the
|
||||
> per-tick free-fall sweep and the staleness timer respectively. Verified
|
||||
> NOT a canonical cell commit for ordinary remotes: `RemoteMotion.CellId`
|
||||
> only delegates to `RuntimePhysicsState` when `_canonicalCellWriter` is
|
||||
> bound, which is projectiles-only, and projectiles return earlier.
|
||||
> Recorded as register row **AP-135**. Everything else the branch used to
|
||||
> do — body pose, queue, leash, render entity, shadow publish, and the
|
||||
> velocity-derived animation cycle — is genuinely skipped.
|
||||
6. `ConstrainTo` moves to after the operation, anchored post-move, and does not
|
||||
run on the airborne branch.
|
||||
7. No behaviour change to the far, teleport, or cell-less branches.
|
||||
|
|
@ -145,6 +171,16 @@ to the classifier is the failure mode.** Say which you chose.
|
|||
AP-87 signature). Then pull a drudge, let it chase, melee it, let it die.
|
||||
- Divergence ledger: D1 and D2 retired by fix in the same commit. AP-131 stays.
|
||||
AP-87 / TS-44 either stay with justification or are retired with evidence.
|
||||
- **Added 2026-08-03 (review finding R15).** D1 makes ACE's wire `IsGrounded`
|
||||
newly load-bearing for NPC remotes: ACE emits it from
|
||||
`TransientState & OnWalkable` (`PositionPack.cs:73`), while acdream's NPC
|
||||
free-fall was gated on the client-tracked `rmState.Airborne` (set only by
|
||||
`0xF74E` VectorUpdate or `!Body.OnWalkable`, never from the wire bit). A
|
||||
creature ACE reports as not-in-contact while the client believes it grounded
|
||||
now receives NO correction where the legacy routing pulled it. **Push a
|
||||
monster off a ledge / pull one down a cliff**, and confirm it falls and
|
||||
lands without hovering, without a mid-air correction, and without an
|
||||
invisible-but-solid body.
|
||||
|
||||
## Budget
|
||||
|
||||
|
|
|
|||
269
docs/research/2026-08-03-c4-route-4a-review-findings.md
Normal file
269
docs/research/2026-08-03-c4-route-4a-review-findings.md
Normal file
|
|
@ -0,0 +1,269 @@
|
|||
# C4 route 4a — dual review findings, and a contract correction (2026-08-03)
|
||||
|
||||
Both mandated reviews returned **FAIL**. Nothing is committed. This supersedes
|
||||
the 4a contract where they disagree, and **corrects an error in that contract
|
||||
that caused one of the findings.**
|
||||
|
||||
Reviews: retail-conformance (Opus) and adversarial/architecture (Opus), run
|
||||
independently against the same uncommitted diff. Suite was green at 10,917/4/0,
|
||||
which again proves nothing.
|
||||
|
||||
## Verified correct — do not churn
|
||||
|
||||
- The Runtime seam `RuntimeRemoteSteadyStatePosition.cs` itself: pure,
|
||||
stateless, correctly decomp-anchored, genuinely well tested. Both reviewers
|
||||
passed it standalone.
|
||||
- Retail truth re-verified independently: `MoveOrTeleport` @0x00516330
|
||||
`arg4 == 0` -> `return 0` writing nothing; `player_distance < 96f` ->
|
||||
`InterpolateTo`; `ConstrainTo` @0x00454272 only inside
|
||||
`if (MoveOrTeleport(...) != 0)`, anchored post-move.
|
||||
- AP-87's two headline conditions survive with identical semantics and no
|
||||
bypass path.
|
||||
- `skipGenericPositionWrite` IS derived purely from classification (the staged-
|
||||
cutover discriminator condition is met).
|
||||
- Per-entity currency on the callee is sound; the caller re-validates
|
||||
`IsCurrentPositionAuthority` between classify and apply.
|
||||
- Budget respected: ~343 production lines against ~400.
|
||||
|
||||
---
|
||||
|
||||
## R0 — CRITICAL, and it is a defect in ALREADY-COMMITTED route 2
|
||||
|
||||
**`AcceptedPhysicsTimestamps.PreviousTeleport` is always 0 on the live Position
|
||||
path.** `InboundPhysicsStateController.cs:636` calls `Current(gate,
|
||||
teleportAdvanced: ...)` and omits the `previousTeleport` argument, which
|
||||
defaults to 0 (`:1119`). The ONLY site that populates it is `:926-941`, the
|
||||
deferred initial-create path — which is why the continuation executor is correct
|
||||
and every newer consumer is not. Verified first-hand.
|
||||
|
||||
Two live consequences:
|
||||
|
||||
**(a) Route 2, at HEAD, silently drops force corrections.**
|
||||
`LiveEntityNetworkUpdateController.cs:1199` and
|
||||
`RuntimeLiveEntitySessionController.cs:268` feed the always-zero value into the
|
||||
route-2 drive, where `ValidAcceptedAuthority` (classifier `:524-525`) requires
|
||||
`Previous == Accepted` for `ForcePosition`. For any local player whose
|
||||
TELEPORT_TS is nonzero — i.e. anyone who has portalled or recalled this session
|
||||
— the authority is rejected and the correction is dropped. The user's `@pklite`
|
||||
acceptance was genuine but narrow: that character had not teleported, so the
|
||||
stamp was still 0.
|
||||
|
||||
**(b) Route 4a misclassifies every previously-teleported remote.**
|
||||
`TeleportAdvanced` becomes `IsNewer(0, T)`, true for any `T` in `[1, 0x7FFF]`,
|
||||
so the classifier returns `SetPosition` — a disposition 4a does not own — and
|
||||
(per R3) the entity falls into the far-snap arm and hard-snaps on EVERY packet
|
||||
at 5-10 Hz. That is worse than the pre-4a behaviour it replaced, and it is
|
||||
exactly the per-packet stepping the connected gate screens for. Reachable the
|
||||
first time an observed character portals or recalls, permanently thereafter.
|
||||
|
||||
**Fix at the source**: capture `previousTeleport = gate.TeleportTimestamp`
|
||||
BEFORE `TryAcceptPositionEvent` mutates it, and pass it into `Current` — the
|
||||
shape `:926` already uses. Then audit every consumer.
|
||||
|
||||
**Commit this separately and first.** It is a shipped-code defect independent of
|
||||
4a, and it needs its own bisectable commit and its own issue.
|
||||
|
||||
---
|
||||
|
||||
## R1 — HIGH — my contract was wrong: the rebucket must NOT be deleted
|
||||
|
||||
The 4a contract listed `RebucketLiveEntity` among the generic-tail writes to
|
||||
delete, and said the result "must reach the render entity through the existing
|
||||
placement-projection sink instead." **That instruction was copied from route 2
|
||||
and does not transfer.** Route 2 performs a placement and therefore has a
|
||||
committed receipt to project. 4a's two branches perform NO placement, so there
|
||||
is no receipt and nothing substitutes for the bucket transaction. The
|
||||
implementer followed the contract precisely; the contract was wrong.
|
||||
|
||||
`skipGenericPositionWrite` currently also gates
|
||||
`_liveEntities.RebucketLiveEntity` (`:1400`), which is the ONLY site that moves
|
||||
an ordinary moving remote's spatial bucket (the nine other call sites are
|
||||
player, projectile, teleport, hydration, materialization, equipped-child and
|
||||
rescue paths; the per-tick DR writers deliberately do not rebucket — see
|
||||
`LiveEntityRuntime.cs:856-858`). So for every grounded remote inside 96 m none
|
||||
of these runs again: the GPU draw bucket, `IsSpatiallyVisible` +
|
||||
`RefreshPresentation`, `CommitRebucket` (the canonical `FullCellId`), the
|
||||
`prepare_to_enter_world` clock rebase, and `PublishProjectionVisibilityChanged`.
|
||||
|
||||
Failure: a creature chasing you across a landblock boundary keeps its body and
|
||||
collision shadow but leaves its draw bucket behind, is frustum-culled, and goes
|
||||
**invisible-but-solid** — the #184 class AP-87 exists to prevent, through a
|
||||
different door. Secondary: the stale `FullCellId` feeds back as the classifier's
|
||||
own `CommittedCellId` and as the `ConstraintDistance` cell key.
|
||||
|
||||
**Required: keep the rebucket running for both 4a classifications.** Delete only
|
||||
the three render-pose writes. Also note R12 below: the per-UP rebucket doubles
|
||||
as the pending-bucket promotion recovery (`GpuWorldState.cs:1113-1126`, the
|
||||
2026-07-03 invisible-player fix) — the cell-change-gated canonical commit does
|
||||
not cover it.
|
||||
|
||||
---
|
||||
|
||||
## R2 — HIGH — the App acceptance tests are tautologies
|
||||
|
||||
`LiveEntityNetworkRemoteSteadyStateIntegrationTests.cs:75-86` recomputes
|
||||
`skipGenericPositionWrite` in the test body, asserts it true, then places the
|
||||
mutation inside `if (!skipGenericPositionWrite)` — a branch the preceding assert
|
||||
proves unreachable. The second test writes the tail sync itself and then asserts
|
||||
its own arithmetic. **Both pass unchanged with the production file reverted to
|
||||
HEAD**, and the fixture supplies a correct `Previous/Accepted` teleport pair
|
||||
that production never produces, so the suite is structurally incapable of
|
||||
catching R0(b).
|
||||
|
||||
This is #292 again, in a WEAKER form than route 2's: a source-text pin at least
|
||||
fails when the source changes; this never observes production at all. The
|
||||
contract's acceptance bullet said "behavioural, not a source-text pin… do not
|
||||
repeat it."
|
||||
|
||||
**Required: a test that fails if the generic tail double-writes a remote.** If
|
||||
`LiveEntityNetworkUpdateController` genuinely cannot be constructed, then extract
|
||||
the decision+mutation into something that CAN be tested and have production call
|
||||
it — do not simulate production in the test body.
|
||||
|
||||
---
|
||||
|
||||
## R3 — HIGH — "not Interpolate" is treated as "far", mis-owning five dispositions
|
||||
|
||||
Player `:1723-1740`, NPC `:1867-1888` use `if (Interpolate) … else <far snap>`.
|
||||
The `else` also swallows `SetPosition` (cell-less half — `remotePlacementRequired`
|
||||
covers only the teleport half), `RejectedAuthority`, `RejectedData`, and `null`.
|
||||
So a wire quaternion failing validation, or a cell-less remote, now hard-snaps
|
||||
every packet where the legacy code did distance-based routing — a behaviour
|
||||
change to branches contract item 7 forbids touching. `ClassifyRemoteAcceptedPosition`'s
|
||||
own doc comment (`:47-50`) claims null leaves the legacy path "completely
|
||||
unchanged"; that is false.
|
||||
|
||||
**Required: test explicitly for the two dispositions 4a owns. Everything else
|
||||
falls through to untouched legacy routing.** One classification, one owner.
|
||||
|
||||
---
|
||||
|
||||
## R4 — HIGH — the NPC airborne branch still writes cell, render entity and shadow
|
||||
|
||||
Contract item 5 says the airborne branch writes NOTHING. The player arm complies
|
||||
(`:1624-1628` returns). The NPC arm only skips the snap and falls through to
|
||||
`rmState.CellId = p.LandblockId` (`:1931` — which commits the canonical cell via
|
||||
`RemoteMotion.cs:169-177` and can rebucket), `LastServerPos/Time`,
|
||||
`RemoteServerControlledVelocityCycle.Apply` (an animation decision from an
|
||||
airborne packet), the `entity.SetPosition`/`ParentCellId`/`Rotation` tail
|
||||
(`:1976-1978`), and `LiveEntityShadowPublisher.TryPublishRemote` (`:1979`).
|
||||
|
||||
Worse than before *because* the body no longer moves: previously body, cell,
|
||||
entity and shadow all agreed; now the body stays put while the cell jumps to the
|
||||
server's and the shadow publishes against a cell that need not contain it.
|
||||
|
||||
(Contract-precision note: `:1616` writes `rmState.CellId` before the PLAYER
|
||||
return too. That is pre-existing free-fall bookkeeping the contract's "not the
|
||||
cell" wording did not intend to forbid — decide deliberately and record it,
|
||||
rather than leaving the contract and the code silently disagreeing.)
|
||||
|
||||
---
|
||||
|
||||
## R5 — MEDIUM — `ConstrainTo` lost on the player-remote landing packet
|
||||
|
||||
The deleted unconditional arm sat before `if (IsPlayerGuid(...))`, so it ran for
|
||||
the landing transition. The new arm at `:1747-1752` is after the landing block's
|
||||
return at `:1710`. A landing UP is a grounded near correction where retail's
|
||||
`MoveOrTeleport` returns nonzero, so retail DOES arm the leash. Behaviour loss
|
||||
on a path 4a was to leave alone. Also: when the route is null or `Rejected*`,
|
||||
`ConstrainAfterRouting` is false so the leash never re-arms, yet the `else` arm
|
||||
still hard-snaps — a hard move with a stale anchor.
|
||||
|
||||
---
|
||||
|
||||
## R6 — MEDIUM — AP-87 and TS-44 changed silently; both register rows now misdescribe the code
|
||||
|
||||
**AP-87:** the NPC variant's third condition `firstUpNpc`
|
||||
(`LastServerPosTime <= 0`) was dropped with no replacement, and the updated row
|
||||
still describes it as a "belt hint". Low blast radius (a UP-created
|
||||
`RemoteMotion` is seeded so `bodyToTarget == 0`), but the contract demanded the
|
||||
choice be stated, and the original code carried an explicit comment about why
|
||||
`LastServerPosTime` is unreliable.
|
||||
|
||||
**TS-44:** the sticky check moved inside `ApplyInterpolate`, which BOTH kinds
|
||||
call, so it now suppresses player-remote near corrections that previously had no
|
||||
sticky check at all (the old `snapSuppressedByStick` gate was structurally
|
||||
unreachable for players). Player remotes are stickable
|
||||
(`LiveEntityMotionRuntimeController.cs:144-145`, `:342-352`). The updated row
|
||||
still says "NPC UpdatePosition enqueue is suppressed" and calls the App gate an
|
||||
"NPC-only caller gate" — both now false. The player arm is also internally
|
||||
inconsistent: near is suppressed, far is not.
|
||||
|
||||
**Required: decide each deliberately, and make the rows true.**
|
||||
|
||||
---
|
||||
|
||||
## R7 — MEDIUM — contract items 1 and 2 are not met; this is a helper extraction, not an ownership transfer
|
||||
|
||||
The Runtime "owner" is two stateless statics. App still owns request assembly
|
||||
(`ClassifyRemoteAcceptedPosition` is private to the App controller), branch
|
||||
selection, the airborne early return, the cell write, the entity write, and the
|
||||
shadow publish. No second host can reuse any of it. The headless claim is
|
||||
factually true (`RuntimeLiveEntitySessionController.cs:212-216` returns early
|
||||
for remotes, so nothing diverges) but it satisfies item 2 by redefinition.
|
||||
|
||||
Note Runtime ALREADY builds this exact request in
|
||||
`RuntimeInitialCreateContinuationExecutor.ApplyPositionAction:1907-1945`. The
|
||||
new App builder is a third copy of the same construction — which is precisely
|
||||
how R0 and R8 diverged from it. **Prefer sharing that builder over maintaining a
|
||||
third copy.**
|
||||
|
||||
---
|
||||
|
||||
## R8 — MEDIUM-LOW — the request builder fabricates `Vector3.Zero`, violating a documented invariant
|
||||
|
||||
`:75-77` uses `_playerController?.Position ?? Vector3.Zero`. `GameRuntime.cs:288-290`
|
||||
states the rule for this exact field: a null controller "must yield null, never a
|
||||
fabricated Vector3.Zero that would misclassify every remote entity as
|
||||
implausibly far." `RuntimeInitialCreateContinuationExecutor.ResolveInputs:510-521`
|
||||
honours it. The new builder does the opposite.
|
||||
|
||||
---
|
||||
|
||||
## R9 — LOW-MEDIUM — the new generation plumbing is decorative
|
||||
|
||||
`RuntimeEntityObjectLifetime.CurrentGeneration()` and `LiveEntityRuntime.Generation`
|
||||
return the lifetime's CURRENT generation, not the classified record's. The
|
||||
classifier only tests `Generation.Value != 0`, never compares it — so the token
|
||||
cannot detect a generation change, and the currency it claims to add is supplied
|
||||
entirely by the surrounding `IsCurrentPositionAuthority` checks. Two new public
|
||||
members for a non-zero placeholder. Also `_generation` is assigned in
|
||||
`BindEventContext` but never cleared in `Dispose`, unlike its siblings.
|
||||
|
||||
Either make it load-bearing or drop it.
|
||||
|
||||
---
|
||||
|
||||
## R10 — LOW — residue
|
||||
|
||||
- **R11:** `ApplyInterpolate`'s return value is discarded at both call sites, and
|
||||
the NPC caller still wraps it in its own `if (!snapSuppressedByStick)` —
|
||||
duplicating the check that moved into the seam.
|
||||
- **R12:** the deleted per-UP rebucket also lost the pending-bucket promotion
|
||||
recovery (`GpuWorldState.cs:1113-1126`, the 2026-07-03 invisible-player fix).
|
||||
Covered by fixing R1, but note it explicitly.
|
||||
- **R13:** HTML entity escapes leaked into plain `//` comments (`>=96 m`) at
|
||||
`:1718`, `:1735`, `:1864`, `:1883`.
|
||||
- **R14:** `preSnapPos` (`:1394`) assigned, never read, with a comment describing
|
||||
behaviour that no longer exists.
|
||||
|
||||
---
|
||||
|
||||
## R15 — live-gate addition, not a code defect
|
||||
|
||||
D1 makes ACE's wire `IsGrounded` newly load-bearing for NPC remotes. ACE emits it
|
||||
from `TransientState & OnWalkable` (`PositionPack.cs:73`), while acdream's NPC
|
||||
free-fall is gated on the client-tracked `rmState.Airborne`, set only by
|
||||
`0xF74E` VectorUpdate or `!Body.OnWalkable` — never from the wire bit. A creature
|
||||
ACE reports as not-in-contact while the client believes it grounded now receives
|
||||
NO correction where the legacy routing pulled it.
|
||||
|
||||
**Add to the connected gate: push a monster off a ledge / pull one down a
|
||||
cliff.**
|
||||
|
||||
---
|
||||
|
||||
## Gate
|
||||
|
||||
Complete Release suite, not a subset. Pre-4a baseline is 10,909/4/0. R2 means the
|
||||
current green number is not evidence for the thing it claims to test.
|
||||
Loading…
Add table
Add a link
Reference in a new issue