690 commits

Author	SHA1	Message	Date
Erik	3c9fc57adb	fix(vendor): Slice 6 review corrections — ownership-checked retire, live slider display, drag-proof shop rows, hardened buy reservation ... All nine findings from the buy-arc review, at root: F1 the materializer's retire pass re-checks ownership (guid->vendorId map; remove only while the live object's ContainerId still equals the recording vendor) — buying a player-sold UNIQUE no longer deletes the item you just purchased; the discriminating reparent-then-refresh test pins it. F2 the cost/name display subscribes to the live split state and shares ONE quantity computation with Buy (retail re-renders per slider tick: RecvNotice_StackSliderChanged 0x004C4500) — the sentence and the charge can no longer disagree. F3 shop rows never mint drag payloads (UiItemSlot.AllowDragSource gates both IsDragSource AND GetDragPayload — the second gate was caught by this pass's own test). F4 sendBuy reports whether anything was sent; a null-session buy cancels the reservation instead of leaking BusyCount forever. F5 the retire loop snapshots, isolates per-guid observer failures, and clears its tracking in finally and Dispose — teardown convergence can no longer wedge. F6 auto-select is retail's unconditional first-filtered-item shape (pc:201180-201184; the survival-check was our invention and the comment claiming otherwise is corrected). F7 non-stack buys clamp to quantity 1 locally (BuySingleItem pc:201669). F8 the Add button is hard-disabled until staging exists. F9 AP-161/162/163 rewritten to the post-fix reality. Clean-room complete solution: 11,378 passed / 4 skipped / 0 failed. The #350 render-ledger overflow observed this session is under separate investigation and is NOT addressed here. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 23:12:50 +02:00
Erik	97cf873870	feat(vendor): Slice 6 buy arc — shop items are real objects, vendor selection is THE selection, and Buy works (0x005F) ... Three ordered pieces in one landing (the shared controller/composition files carry all three; the internal order was 6.1 -> 6.2 -> 6.3): 6.1 VendorShopItemMaterializer diff-merges the shop list into the live ClientObjectTable on VendorState transitions (so client-local close and session teardown retire the entries too) and never claims a guid it did not add — ACE's UniqueItemsForSale can re-list a guid a player once held (AP-163 files the collision-skip; no retail counterpart traced). Right-click examine on shop items now routes through the ordinary appraisal path — the 5.4 F7c blocker dissolves with the table entries. 6.2 SelectionChangeSource.Vendor: row clicks, auto-select, and examine all flow through the canonical SelectionState; the status bar and the existing byte-faithful StackSplitQuantityState slider light up unmodified. VendorSplitPolicy is the single 0xDC41CB0 mask owner; the slider VALUE seeds to 1 for exempt items while maxSplitSize keeps the stack (the splitSize/maxSplitSize distinction, research §B.3). Selection clears at retail's actual site — VendorItemsUI::RemoveFromShop (pc:202848), not a CloseVendor-level clear that does not exist. 6.3 BuildBuy (0x005F): vendorGuid, count, (i32 amount, u32 guid) pairs, and the trailing alternateCurrencyId the REAL client sends (CM_Vendor::Event_Buy pc:689288) though ACE's reader ignores it. TryBuy rides the EXISTING J5.2 one-request-at-a-time reservation and completes on UseDone; the Buy button disables while a request is in flight. The reconciliation round-trip (money property update, inventory CreateObject, ApproachVendor refresh -> panel rebuild) is proven by a synthetic-inbound test against existing machinery — no new owner. Register: AP-161 narrowed (selection + examine residuals close; staging/Sell remain; double-click-to-buy confirmed ABSENT from retail with negative evidence cited — we match retail). AP-162 files the conscious no-client-side-affordability-precheck deferral. Clean-room complete solution: 11,368 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 20:28:26 +02:00
Erik	e602f84be2	fix(ui): Slice 5.4 review corrections — the dropdown renders from its authored popup, retail cost semantics, auto-select, icon overlays ... All nine review findings closed at root (one sub-item consciously deferred): F1 the category dropdown now draws: sprites/fonts wired and the popup geometry read from the vendor menu's own authored popup LayoutDesc 0x21000043 (root 0x1000034F — correcting the review's 0x1000014F transcription) per UIElement_Menu::MakePopup (pc:120705); chat's menu is untouched and its tests prove it. The new test drives selection through the REAL open/hit path the review flagged as bypassed. F2+F3 the selected-item cost display ports VendorItemsUI::UpdateItemsUI verbatim: quantity via the 0xDC41CB0 split-size mask (whole-stack for ammo, per-unit for groceries/components; mask lives at the toolbar SEEDING site pc:198784), plural names with retail's fall-back-to-singular (pc:409056 — correcting the review's "name+s" guess), full cost sentences with comma grouping and the player's coin total, and Buy/Add buttons that disable without a selection. F4 category switches auto-select the first filtered item (pc:201180). F5 icon underlay/overlay/effects + plural name forwarded from the already-parsed wire fields through VendorShopItem to the icon composer. F6 a DIFFERENT vendor opens on its own first category; same-vendor refresh preserves per the clamp. F7 scroll resets on rebuild and authored empty slots fill; the right-click examine route is consciously DEFERRED (shop items are not in ClientObjectTable and the appraisal panel hard-requires it — documented, not faked). F8 VendorState.Apply's fanout gets the same per-listener isolation as Close/Reset. F9 AP-110/AP-161 wording corrected ("quantity-correct pricing") and AP-161 rewritten to exactly the remaining conscious gaps. Clean-room complete solution with the #348 cursor fix in the same tree: 11,334 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 18:26:17 +02:00
Erik	c721830e71	feat(ui): Slice 5.4 — the authored vendor browse panel (LayoutDesc 0x21000012) ... The vendor window is retail's own: LayoutDesc 0x21000012, root 0x100000B7, found by enumerating all 101 layouts for the one containing both known tab controls and clinched by the root's Type 0x10000017 — the literal UIElement::RegisterElementClass id for gmVendorUI (pc:202075). Discovery evidence and the D0 read live in the research doc's new §B.4. D0 corrected two assumptions: retail's category "tabs" are a UiMenu DROPDOWN fed by a hardcoded 18-row ordered category table (ported bit-for-bit against our ItemType enum; list always scoped to exactly one category, first-present wins, selection preserved across refresh per retail's clamp), and the layout authors THREE tabs — Items (browse, this slice), Buying and Selling (staged-transaction review, Slice 6) — decision 4's "browse/Buy tab" names the Items tab retail's mode-2 OpenTab opens. The non-default tabs render and switch pages but stay inert, fenced in comments. VendorUiController mounts Items: category dropdown, icon-cell item row with the retained scrollbar, per-unit retail pricing via VendorPricing.SellPrice (the vendor-stock path VendorProfile:: VendorSellPrice feeds), name/cost on selection. The panel is a pure projection of VendorState — opens on populate, closes on clear; the close button's VendorState.Close() is its only permitted mutation. Nothing on the wire. AP-110 narrowed (vendor leaves the absent-panels list); AP-161 files the precise Slice-6 remainder (Buying/Selling unwired, Buy/Add buttons, InqAcceptability). Twelve controller tests on a real-dat fixture. Clean-room complete solution: 11,323 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 17:00:21 +02:00
Erik	6c6664a685	fix(app): #343 — a wounded render loop defers the native release instead of throwing over the real failure ... Root cause pinned by IL-decompiling Silk.NET.Windowing.Common: ViewImplementationBase._inRenderLoop is set at DoRender/DoUpdate entry and cleared ONLY on normal return, so a throwing frame callback leaves it armed forever and any later Dispose -> Reset throws "You cannot call Reset inside of the render loop", exit 82, replacing the original wounding exception in the report. The fix mirrors Silk's own bracket exactly: GameWindow._renderLoopArmed set at OnUpdate/OnRender entry, cleared only on their normal return — deliberately NOT in a finally, so it tracks the wound the same way Silk's private field does. ReleaseNativeWindow checks it before disposing: armed -> best-effort Close() (swallowed so it can never become the reported failure), no Dispose, and a new terminal status CompleteWithDeferredNativeRelease with Error kept null — the original exception stays the primary report. Healthy paths (OnClosing's in-loop completion, Run()'s tail release) are byte-unchanged, and the new PublishNativeWindow parameters default to null so every existing caller and test behaves identically. Sabotage: disabling the armed-check flipped the deferral test to Expected CompleteWithDeferredNativeRelease / Actual Complete — the guard is what the test exercises. Clean-room suite 11,262 / 6 / 1, the 1 being #340's documented load flake (passed standalone; second recorded firing noted in its entry). Queue: #344 done, #343 done; next #345's instrumented mechanism session, then #341's boundary hunt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 10:28:29 +02:00
Erik	52bdf4df71	fix(world): #344 — a mid-teleport world-frame disagreement defers the projection instead of crashing ... During a portal transit the two world-frame owners legitimately rebase on different edges (Runtime at TeleportAdvanced, streaming only after old-window retirement), and a spawn projection landing in that window hit the #283 invariant as an unhandled render-path throw — the crash the user hit entering a dungeon. The guard's check is unchanged; only the disagreement RESPONSE is discriminated on the canonical transit authority (RuntimeWorldTransitState.IsTeleportActive, the same field the App layer already reads for portal-in-flight): in transit -> the materializer's existing "not yet" return, parking the projection on its established retry rides (OnLandblockLoaded's re-attempt loop, whose ordering guarantees agreement on retry because the recenter coordinator adopts the new origin BEFORE unblocking new landblock loads — verified at source; plus OnPosition recovery and OnAppearance). Outside transit -> still throws: genuine corruption stays loud. The implementer explicitly ruled out riding the Runtime placement pump, which would have acknowledged-and-discarded the completion receipt and silently dropped the entity forever. Sabotage: removing the discriminator reddened the pre-existing #283 throw tests as well as the new not-in-transit test — the sabotage defeats the original contract, not merely the new coverage. Four new tests cover defer, defer-then-agree-then-succeed (projected exactly once), throw-outside-transit, and the agreeing pass-through. Clean-room suite: 11,261 passed / 6 skipped / 0 failed. #346 filed for a sixth, distinct load-sensitive allocation flake observed during the runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 10:07:45 +02:00
Erik	9671af0273	fix(physics): S2 — static publication emits authored Spheres as Spheres (AP-155 narrowed) ... Both static sites (LandblockPhysicsPublisher, the headless-only LandblockPhysicsContentBuilder) emitted an authored Setup Sphere as a base-anchored Cylinder of radius r and height 2r. The live path emits a Sphere for the same data, so the same object collided differently by arrival route, and the narrow phase met a flat cap where retail meets a curved surface. Both sites now mirror ShadowShapeBuilder.FromSetup's Sphere block exactly. Combined Opus review: PASS. Its numeric verification of the dispatch test's geometry (head-sphere clearance 0.201 m for the true sphere; the cylinder counterfactual inside by 0.10 m XY with the Z band overlapping) is what makes the discrimination claim more than a sabotage anecdote, and its F8 finding is applied: the test now carries a POSITIVE control — aiming straight through the boulder's centre must block — so a membership/seed regression can no longer masquerade as a curve-hit pass. F4 applied: CylHeight is asserted, not inferred (the C4 lesson). F3 applied: the deleted Quaternion.Inverse base composition is recorded as internally coherent for the old cylinder's world-Z axis — the defect was the shape TYPE, not that rotation math. The review also verified the deleted-cylinder blast radius: the F2 overlay's drawn span is IDENTICAL for both shapes (old [c-r, c+r], new [c-r, c+r]); the flood sphere's centre rises by exactly r, which cannot change outdoor membership (XY rectangle) and lands the indoor half on Session B's dungeon gate alongside S1B; and the sphere-branch flood is now pinned uncapped by a genuine eleventh-shape A/B test. PublishStaticCollision — the headless static path — gains its first test ever. AP-155 is NARROWED, not deleted (review F13): the has-BSP source split (entity.MeshRefs vs setup.Parts + AnimPartChanged) survives and keeps the row active. The shared-primitive-emitter refactor that would make route independence a compile-time property is the filed follow-up (review F20). Population: 3,506 of 5,935 installed Setups, structurally equal to AP-157's third-branch count (byte-identical classifier — three independent routes agree: 3,605 - 99 = 3,506). Clean-room suite at implementation: 11,253 passed / 6 skipped / 0 failed on landed S1B. Post-review-hardening: Publisher tests 25/25, Content tests 2/2, both green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 08:07:02 +02:00
Erik	55b07f6a62	refactor(physics): hoist the live-entity collision builder to Runtime (#330 groundwork) ... LiveEntityCollisionBuilder and LiveEntityDefaultPoseResolver move from AcDream.App.Physics to AcDream.Runtime.Physics with no behaviour change — diff-verified byte-identical shape math by both review lenses. The Build signature's App-record parameter is replaced by presentation-free primitives with identical guard semantics, INCLUDING the FinalPhysicsState read the contract had missed and the implementer surfaced rather than dropped. Visibility stays internal: Runtime's existing InternalsVisibleTo grants already cover every consumer, so the implementation's public widening is reverted per the architecture review's finding 11. The registration WIRING is deliberately WITHHELD. Both Opus lenses failed it, converging: a shadow registered at spawn freezes there (RuntimeRemotePhysicsUpdater is Runtime-homed but App-driven — nothing headless ticks it), so a walking NPC becomes a phantom obstacle at its spawn point while the real NPC still passes through the bot; three of five shadow-lifetime edges leaked (pickup leaves a permanent invisible collider, supersession orphans a duplicate, generation reset never unregisters and the K-ledger convergence oracle only checks retained shadows AFTER disposal clears them); and headless cannot resolve BSP collision assets at all, so doors and chests would still be walk-through. The frozen-shadow root was the SESSION LEAD's contract error (fact 3), not the implementer's. #330 stays OPEN, rewritten as the seven-point scope map the reviews produced — the honest overnight deliverable is that map, not a half-mechanism carrying new divergences. Suite 11,235 passed / 4 skipped / 0 failed (the withheld seam's two tests account for the delta from the implementation run's 11,237). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 01:49:13 +02:00
Erik	13fcf38138	fix(physics): port retail's find_bbox_cell_list outdoor extent walk (#334) ... acdream had never implemented retail's SECOND cell-membership algorithm. CPhysicsObj::calc_cross_cells @0x00515230 tests HAS_PHYSICS_BSP_PS at 0x00515285 and jumps (0x0051528f jne 0x515305) to find_bbox_cell_list @0x00510fc0 for a BSP-bearing object; everything below that jump is the OTHER algorithm, CObjCell::find_cell_list, and that is all we had. Every object, BSP-bearing or not, was routed through it. That path's outdoor expansion is a HARD CAP of one cell in each direction. CellTransit.AddAllOutsideCells computes minRad = radius, maxRad = 24 - radius and adds at most the eight neighbours of the sphere's own cell, so for any radius >= 12 m both boundary tests are unconditionally true and the result is exactly 3x3. Widening the radius or adding a second sphere is mechanically incapable of adding a tenth cell. The user's live probe measured the consequence directly: standing inside a Neftet formation, inCell=2 exempt=2 reached=0 -- the geometry was not a candidate at all. The port. AddAllOutsideCellsFromParts is CLandCell::add_all_outside_cells @0x00533360 plus add_cell_block @0x005331d0: base landcell from the FIRST part's own adjust_to_outside, baseX/baseY within-block, each part's authored CGfxObj::gfx_bound_box re-fit through all eight corners (BBox::LocalToGlobal @0x005b2120), floor(v / square_length) where square_length = 0x7c920c = 24.0f, four accumulators seeded to zero, ONE rectangle unioned across all parts, FILLED, in GLOBAL lcoords so it crosses landblocks freely, clamped only to [0, 0x7f8). BuildShadowCellSetFromParts is find_bbox_cell_list's worklist. RegisterMultiPart dispatches on the same flag retail does, and BuildFloodSpheres' BSP arm is deleted rather than left unreachable. Disassembled from the PDB-paired 2013-09-06 binary, not read from Binary Ninja: BN mis-renders four separate constructs inside add_all_outside_cells alone -- a dropped `and eax,0xffff` on baseX, a neg/sbb/and select shown as identically zero, a wrong get_landcell argument, and both x87 flag tests as `unimplemented {test ah}`. ShadowPartGeometry pairs the BSP root sphere with the authored box so no resolver can answer one and leave the other call site to synthesize a substitute -- the AP-156 invariant applied a second time, since that split is what produced AP-156 and then this. The box comes from FlatGfxObjVisualBounds, already computed by exactly CGfxObj::init_end's algorithm and already in the prepared package: no bake change, no DAT re-read. Cost, measured over the installed DATs before any code was written: 1,258 physics-BSP GfxObjs, cells/object p50 4, p90 4, p99 12, max 49. The port is CHEAPER than the old 3x3 = 9 for 98.97% of them. Row totals (shapes x cells) over all 1,031 landblocks with BSP owners fall 97,173 -> 15,607 (0.161x); dense Arwic 0xC6A9 falls 342 -> 43. One landblock more than doubles. Precondition confirmed before pinning any expected cell set: 0x010046D8's box is 96 m x 96 m about cell (2,2) = 0x87640013, which independently corroborates the 3x3-centred-there diagnosis, and its rectangle does contain 0x87640011 and 0x87640019 -- the two cells the probe measured empty. Register: AP-156's outdoor half CLOSED and its risk column CORRECTED (it read "extra broadphase candidates, never a missed one", which generalised the indoor direction to the whole row and is why #334 sat inside it unnoticed). AP-159 + issue #335 file the unported indoor arm; AD-49 records the seed-time rectangle. Issue #336 files a fourth load-sensitive test flake seen once during the gate. Ten tests, every one sabotage-verified in both directions across eight mutations (dispatch, 8-corner refit, floor-vs-truncation, union-vs-per-part, map clamp, adjust guard, landblock clamp, box-path-for-everything). The strongest is an installed-DAT replay of the user's own probe evidence. Suite 11,208 -> 11,218 passed / 4 skipped / 0 failed; the +10 is exactly the new tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 19:07:06 +02:00
Erik	e6457cc849	fix(physics): close the AP-156 fix review — real containment oracle, type-level invariant, AP-158 ... Both review lenses PASSED; this is the cleanup, not a rescue. Evidence: docs/research/2026-08-06-ap156-review-closure.md (the review itself is committed alongside it as the received artifact). R1 — the load-bearing containment test could not fail. Its truth and flood values were two hand-copies of the same expression over the same part set, so the shortfall was algebraically identically zero for any DAT input. The oracle is now PHYSICS-POLYGON VERTICES — a different DAT field from the bounding sphere the builder emits, so the two sides can genuinely disagree. Sabotage-verified three ways after full cleans: dropping the bounds centre in production reddens it (428 Setups, worst 35.869 m on 0x0200129A, matching an independent out-of-repo sweep exactly); dropping only the scale on the centre reddens it (326); and corrupting the TEST's own bounds oracle reddens it (467) where under the shipped oracle that same corruption was invisible by algebra. Renamed accordingly. A6's stale "cap control" comment corrected: that loop is the test's own uncapped re-implementation and cannot observe a cap regression — the cap is covered in Core. R2 — the population was understated. 172 is AP-152's DISPATCH population; AP-156's is 530 BSP-bearing Setups, of which 525 have a flood sphere move and 428 fail vertex containment before the fix (412 at a 1 cm tolerance — the review's figure; the gap is 16 Setups between 1.4 mm and 10 mm, real geometry). 0 fail after, at any tolerance down to zero. Corrected in the AP-156 row, the section-3 header, the C5c handoff and two test docstrings. Dated review artifacts are left as written — "170 of 172" was correct for what they measured, and rewriting evidence to match a later measurement loses provenance. A1 — BoundsCenter = default reopened at the type what the commit closed at the seam. Dropping the default alone would NOT have closed the review's own scenario (a copied Cylinder call site would write Vector3.Zero explicitly and stay green), so ShadowShape's constructor is now private and BSP shapes are built only through ShadowShape.Bsp(..., FlatCollisionSphere localBounds), which takes radius and centre as ONE value and scales them together. There is no expression a caller can write that carries one and drops the other. 22 construction sites converted; the same sabotage now reddens 5 Core tests where the review's sabotage A reached 4, because both BSP producers share one scaling path. A2 — #333 is real and bigger than filed, and its retail question is answered. I disassembled CObjCell::find_obj_collisions @0x0052b750 from the PDB-paired binary myself (check_exe_pdb.py MATCH) rather than inheriting the claim: its only early-out is sphere_path.insert_type == INITIAL_PLACEMENT_ INSERT, then it calls FindObjCollisions on every unparented non-self shadow object UNCONDITIONALLY. Retail has NO distance pre-filter, so acdream's "+ movement + 2f" reach filter is an invention with no register row — filed as AP-158, carrying the disassembly, the F_EPSILON = 0.0002 m contrast, and the measured blast radius (118 of 477 unique installed physics-BSP GfxObjs exceed its ~2.5 m budget, 46 exceed 5 m). Active AP rows 109 -> 110. Recorded prominently in three places a reader will hit: TALL PROPS MAY SHOW NO VISIBLE CHANGE UNTIL #333 LANDS, and a null result at the connected gate is EXPECTED, not evidence against AP-156. LOW items. R3: the comment claiming the cited evidence justified the whole cap line is corrected, but int.MaxValue on the sorting-sphere branch stays — capping at 1 would take Spheres[0], and retail's one sphere is CSetup::sorting_sphere, a different DAT field; capping keeps the wrong field AND flips the substitution under-inclusive (#98/#168 direction). AP-157 already owns it. R4: acdream scales the flood sphere where retail's find_transit_cells never reads gfxobj_scale — added as a second residual on AP-156. R5: retail's slack constant carried into AP-158 and #333. A3: the per-call delegate allocation is back to a cached field, still derived from the single bounds resolver. A5: noted; b52967de's message cannot be amended. Gates: all 44 bin/obj deleted before every verdict-deciding build, each test run gated on a verified "Build succeeded" in the same invocation. Release build 0 errors / 21 pre-existing warnings. Complete suite 11,208 passed / 4 skipped / 0 failed — reconciles exactly with the e2b2d04c baseline; one test renamed, none added, removed or skipped. Nothing conflated with the known load-sensitive flakes #302 / #308 / #321. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 16:44:48 +02:00
Erik	b52967def3	fix(physics): AP-156 — flood the BSP sphere where the geometry is, not at the part origin ... The AP-152 retail review (docs/research/2026-08-06-ap152-review-retail.md) FAILED `4abd1b5e` and is right. `ShadowObjectRegistry.BuildFloodSpheres` took each physics-BSP part's ROOT BOUNDING SPHERE RADIUS (FlatCollisionAssetBuilder.cs:393 -> LiveEntityCollisionBuilder.cs:137) and centred it on the PART ORIGIN (ShadowShapeBuilder.cs:194), discarding the root sphere's own Origin. Re-measured independently against the installed client_portal.dat, reproducing the reviewer's numbers exactly: 376 of 973 physics-BSP parts have |origin| > radius/2, worst 20.762 m on a 27.708 m sphere (gfx 0x010036DD, Setup 0x0200129A). Over the 172 Setups AP-152 moved onto that path the emitted flood FAILED TO CONTAIN the object's own BSP sphere for 170 of them (73 CylSphere-bearing, 97 Sphere-bearing), worst shortfall 9.911 m on Setup 0x02000255 — whose one part's sphere sits 9.911 m above the part origin — and for 43 the post-AP-152 flood was strictly SMALLER than the pre-AP-152 one. Indoor flooding is 3-D (CellTransit.cs:601 routes every id & 0xFFFF >= 0x0100 candidate through FindTransitCellsSphere), so a tall prop or door slab was absent from EnvCells it physically occupies and therefore never a broadphase candidate there (TransitionTypes.cs:3763 iterates only entries already in the cell). That is the #98 / #168 class AP-152 exists to remove. Retail, re-disassembled from the PDB-paired binary (check_exe_pdb.py MATCH, CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32), every address resolved back through named-retail/symbols.json: CGfxObj::physics_sphere is [gfxobj+0x74] (physics_bsp is [+0x78], as CPartArray::CacheHasPhysicsBSP @0x00518110 reads at 0x00518127), and acclient pseudo-C 0x00534b5b assigns it BSPTREE::GetSphere(physics_bsp). BSPTREE::GetSphere @0x005397e0 8b01 mov eax,[ecx] ; BSPTREE::root_node 83c004 add eax,4 ; past BSPNODE::vfptr -> CSphere sphere So retail's per-part flood sphere IS the BSP root bounding sphere, ORIGIN INCLUDED (acclient.h: BSPNODE { vfptr; CSphere sphere; ... }, CSphere { Vector3 center; float radius; } -> radius at +0xc). CPhysicsObj::find_bbox_cell_list @0x00510fc0 adds the object's own cell and then walks the PART ARRAY: 0x00511012 call 0x518160 (CPartArray::calc_cross_cells_static), which dispatches [edx+0x7c] with (num_parts, parts, cellarray). Its EnvCell body, CEnvCell::find_transit_cells @0x0052cae0: 0x0052cb31 mov edx,[eax+0x20] ; CPhysicsPart::gfxobj (CGfxObj**) 0x0052cb36 mov esi,[ecx+0x74] ; physics_sphere (else +0x90 drawing) 0x0052cb4c add eax,0x30 ; CPhysicsPart::pos 0x0052cb5a call Position::localtolocal ; transform the sphere CENTRE 0x0052cb65 fadd [esi+0xc] ; only NOW the radius Retail transforms the centre through the part's own Position before it ever touches the radius. Carrying the radius alone is not an approximation of that; it is a different sphere. Changes: * `ShadowShape` gains `BoundsCenter` — the bounding sphere's centre in the shape's own local frame, scaled like LocalPosition and Radius. Zero for Cylinder/Sphere shapes, whose LocalPosition already IS their centre. * `ShadowShapeBuilder.FromSetup` gains a `physicsBspBounds` resolver that supplies radius AND centre from ONE call, replacing the placeholder radius plus a downstream substitution. `LiveEntityCollisionBuilder` now holds a single `Func<uint, FlatCollisionSphere?>` and derives its dispatch predicate from it, so the gate and the geometry cannot disagree and the radius cannot be taken while the origin is dropped. That split is what produced this bug; it no longer exists. * `FromLandblockBspParts` carries the centre too. A landblock-baked part array is the same CPartArray walk, so stair runs, fences and rock clusters had the identical defect. Both storage forms (flat BSP and the graph fallback) are covered. * `BuildFloodSpheres` places each sphere at partWorldPos + rotate(BoundsCenter, partWorldRot), composed exactly as the ShadowEntry rows are. * The 10-sphere clamp now applies to the CYLSPHERE branch only. Retail's clamp is inside CObjCell::find_cell_list @0x0052b9f0 (0x0052ba21 cmp eax,0xa / 0x0052ba28 mov ebp,0xa); the BSP walk has none and the sorting-sphere overload @0x0052b990 takes one sphere. 7 installed Setups carry more than 10 physics-BSP parts (max 49, Setup 0x02001A91) and their tail parts were dropped from the flood entirely. Without this the new containment assertion would have covered shapes production never floods from. Register. AP-155 was two divergences with different code paths, populations and gates under one id; it is NARROWED to its static-publication half and its flood half is split out as AP-156 WITH ITS DIRECTION CORRECTED. AP-155(b) recorded the approximation as over-inclusive — "floods MORE cells rather than fewer, the safe direction for membership" — and that false direction was the stated reason the residual was safe to defer. It was under-inclusive for 170 of 172. AP-156 records the correction, this fix, and the one genuine residual: acdream's sphere-vs-portal traversal where retail walks each part's sphere against the cell's own portal planes. AP-155(b)'s "acdream approximates retail's bounding BOX" was wrong too — find_bbox_cell_list forms no box. AP-157 filed for the review's F4: retail's third branch floods from ONE CPartArray::GetSortingSphere @0x00518b00 ([partArray+0x54]+0x70 = CSetup::sorting_sphere; 4,154 of 5,935 installed Setups carry a non-zero one) where acdream floods from every Sphere shape, and acdream's cylinder flood ignores CylHeight. Deliberately NOT bundled here: different branch, disjoint population, different live gate. Active AP rows 107 -> 109, literal count. Tests. Both flood tests the review named substituted a CONCENTRIC Radius = 14f at LocalPosition = Zero — the one configuration in which the defect cannot appear. Every fixture is now off-centre by default, and `FromSetup_CylSphereAndBspSetup_FloodsTheBspFootprint` drives the production `physicsBspBounds` seam instead of hand-substituting. Five new facts: the flood centres on BoundsCenter not the part origin; it rotates BoundsCenter by the part rotation; it caps cylspheres at ten but never the BSP parts; the landblock path carries the scaled centre in both storage forms; and an installed-DAT containment sweep asserting every emitted BSP flood sphere contains that part's real bounding sphere at entity scale 1.75, behind four external controls — 973 parts, 376 off-centre, 172 affected, and 170 would-fail-if-the-origin-were-discarded, the last of which fails if the population ever stops exercising the field. Nine sabotages, each reverted and re-verified: A drop BoundsCenter from the flood -> 3 Core B rotate by entity rot, not part rot -> 1 Core (the rotation fact only) C FromSetup discards the origin -> 1 Core + 2 App + 1 Content (the shipped defect, now caught in three projects) D drop entScale on BoundsCenter -> 2 App + 1 Content E landblock flat branch drops the centre -> 1 Core F landblock graph branch drops it -> 1 Core G drop partScale on the landblock centre -> 1 Core H re-apply the 10-cap to every branch -> 1 Core I remove the cylsphere cap -> 1 Core AP-152's own two sabotages re-run against this tree: the step-0 gate disabled still reddens exactly its five facts with Headless 89/89 green, and cylinder-first flooding still reddens exactly one. Clean Release build after deleting all 44 bin/obj: 0 errors, 21 pre-existing warnings. Complete suite 11,208 passed / 4 skipped / 0 failed, +5 on the 11,203 baseline at 4abd1b5e — Core 4264 -> 4268, Content 126 -> 127, App unchanged (one rename, not an addition). No new skips. NOT yet gated live. This moves shadow-cell membership for real objects, in both directions, and the connected session must look for both: props and doors that START blocking from a neighbouring cell (the 73 CylSphere+BSP Setups), AND ones that STOP blocking (the 99 Sphere+BSP Setups can shrink; 43 shrink below their pre-4abd1b5e size, which is the regression this fixes). Tall indoor props and door slabs — the ones whose sphere sits metres above the part origin — are where the change is largest. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 15:52:04 +02:00
Erik	4abd1b5eb7	fix(physics): AP-152 — dispatch collision shapes BSP-first, at emission and at the cell flood ... The register row predicted "catching or stopping on a doorway sill". That symptom could not have been occurring. `Transition.BspOnlyDispatch` (TransitionTypes.cs:1348, landed 2026-05-25 as A6.P7) already skipped both primitive branches (:3911, :3954) whenever the target's wire PhysicsState carries HAS_PHYSICS_BSP_PS, and ACE sets that bit from CSetup.HasPhysicsBSP for every affected Setup. The extra primitive was never tested for collision. The live defect was CELL MEMBERSHIP. The same shape list feeds `ShadowObjectRegistry.BuildFloodSpheres`, which had no such guard and preferred Cylinders over everything whenever any Cylinder existed — retail's SECOND priority applied ahead of its first. For the 73 CylSphere+BSP Setups acdream therefore flooded shadow cells from the cylinder and never from the slab: an object absent from cells it physically occupies, which is the #98 / #168 symptom class, not the door-collision class the row named. Retail, re-disassembled from the PDB-paired binary (v11.4186, CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32, check_exe_pdb.py MATCH) rather than taken from Binary Ninja, which drops flag tests: CPhysicsObj::FindObjCollisions @0x0050f050 0x0050f165 test dword [esi+0xa8], 0x10000 0x0050f16f je 0x50f1a2 ; clear -> primitive dispatch 0x0050f18d call 0x518180 ; CPartArray::FindObjCollisions 0x0050f19d jmp 0x50f2b0 ; UNCONDITIONAL, past BOTH primitive loops ; (CylSphere 0x50f1a2, Sphere 0x50f21d) 0x0050f1d6 jae 0x50f317 ; CylSphere loop exhausted -> RETURN 0x0050f22f je 0x50f31b ; zero Spheres -> RETURN seeded OK_TS CPhysicsObj::calc_cross_cells @0x00515230 0x00515285 test dword [esi+0xa8], 0x10000 0x0051528f jne 0x515305 -> CPhysicsObj::find_bbox_cell_list @0x00510fc0 0x005152d1 call 0x52b9f0 ; cylsphere branch, below the jump 0x005152fb call 0x52b990 ; sorting-sphere branch, below the jump Priority at both consumers: BSP -> CylSphere -> Sphere -> nothing. BSP wins. Every address above was resolved back to its symbol by exact lookup in named-retail/symbols.json. Changes: * `ShadowShapeBuilder.FromSetup` gains a step-0 dispatch gate. Steps 1 and 2 are skipped entirely when any part's EFFECTIVE GfxObj carries a physics BSP. The gate and step 3 now share one `EffectivePartGfxObjId` helper, so they cannot read different identities — a gate on `setup.Parts` would, after an ObjDesc swap, suppress the primitives while step 3 emitted nothing and `Build` returned null, deleting the entity's collision. Emission order is unchanged. This also removes acdream's undeclared reliance on the server sending the flag: the gate is derived from the parts, exactly as CPartArray::CacheHasPhysicsBSP @0x00518110 derives it. * `ShadowObjectRegistry.BuildFloodSpheres` now applies calc_cross_cells' own order: BSP, else Cylinder, else everything. Given the gate above this is a no-op for every shape list acdream produces (FromSetup is now exclusive; both landblock-static publishers already emit homogeneous lists), so the measured membership delta remains attributable to the gate alone. It is kept for the same reason BspOnlyDispatch is kept: retail genuinely dispatches here, and it guards a future additive producer. `Transition.BspOnlyDispatch` is deliberately untouched. Register: AP-152 RETIRED with its four false statements corrected — the risk statement (the symptom was already inert); "small and centred at the part origin" (max primitive is 6.714 m, and 0x0200086E's sphere origin is (0.759, 0.165, 5.842)); the cottage door's "~14 cm base Sphere" (it is 0.100 m; 0.141 is Setup.Radius, which AP-22 proved is never collision geometry); and naming one pinning test where two existed. AP-153/154/155 filed: retail's dispatch flag is cached once at InitPartArrayObject+0x7e where acdream's gate is live; the query-time guard takes a client-derived flag off the wire; and the static publishers emit Setup Spheres as height-capped Cylinders while BuildFloodSpheres approximates retail's bounding box with bounding spheres. Tests. Both pinning tests corrected, neither deleted: `FromSetup_DoorSetup_ProducesFourShapes` -> `..._EmitsBspPartsOnly`; `FromSetup_DoorSetup_SphereAtExpectedLocalOffset` re-hosted on `_ => false`, the DAT-real configuration for the 3,605 Sphere-only Setups. `FromSetup_ScaleFactor_MultipliesAllRadiiAndOffsets` was the campaign's eighth green test covering nothing — its assertions sat inside `if (CollisionType == Cylinder)` on a fixture with zero CylSpheres, so only `Scale == 2.0f` ever ran. Proved empirically: with the sphere radius scale deleted, the old body passes and the corrected body fails. Three new facts: the effective-identity gate, the App-layer CylSphere+BSP registration (no App fixture combined the two before), and the flood-set dispatch. One new installed-DAT sweep pins 172 affected Setups (73 CylSphere+BSP, 99 Sphere+BSP) behind external bucket controls, re-measured independently and agreeing exactly with the filing commit's separate sweep. All eight sabotages run and reported; every discriminating fact reddens in the intended direction and only there. Clean Release build after deleting every bin/obj: 0 errors. Complete suite 11,203 passed / 4 skipped / 0 failed, +5 on the 11,198 baseline at ec29a732 — exactly the five added facts, no new skips. Blast radius, corrected: the FromSetup half is graphical-only (its sole production caller is LiveEntityCollisionBuilder in AcDream.App, which AcDream.Headless cannot reference — Headless -> Runtime -> Core/Content). The BuildFloodSpheres half lives in AcDream.Core and DOES execute in Headless via LandblockPhysicsContentBuilder, but is behaviour-neutral there because both of that builder's registrations pass homogeneous lists. Headless suite green at 89/89. NOT yet gated live: this changes shadow-cell membership for 22 Setups used by 151 Door weenies and 38 stationary props. Needs a connected session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 14:51:36 +02:00
Erik	bc4679cda5	fix(physics): delete the invented Setup-radius collision cylinder (AP-22) ... Retail synthesizes NO shape for a shapeless object, so the fix is deletion, not a corrected height formula. CPhysicsObj::FindObjCollisions @0x0050f050 dispatches exclusively -- BSP xor CylSphere xor Sphere xor nothing. The BSP branch leaves via an unconditional `jmp 0x50f2b0` at 0x0050f19d and cannot reach the primitive branches; a CylSphere-bearing object that survives its loop returns rather than falling through to the Sphere loop; and with zero cylspheres, zero spheres and no physics BSP, `0x0050f22f je 0x50f31b` branches straight to the epilogue, returning the OK_TS seeded at `0x0050f13b mov edi,1`. CPartArray::GetRadius (0x005180a0) and GetHeight (0x005180b0) are absent from the function's entire call set -- Setup.Radius/Height serve attack cones, cylinder_distance and MoveTo, never collision geometry. Disassembled directly from the PDB-paired binary (GUID 9e847e2f-777c-4bd9-886c-22256bb87f32) rather than read from the Binary Ninja text, whose ebp_1 aliasing in this function is visibly corrupt. THREE copies were deleted, not one. The AP-22 register row cited LiveEntityCollisionBuilder.cs and ShadowShapeBuilder.cs; the latter never reads Setup.Radius at all, and the row omitted both LandblockPhysicsPublisher.PublishStaticEntity and LandblockPhysicsContentBuilder.PublishStaticCollision -- the second being the only copy the headless host executes. Fixing just the cited site would have left headless statics on the invented footprint. The branch was unreachable dead code, not a live approximation. A sweep of all 5,935 Setups in the installed client_portal.dat -- validated by byte accounting (5,935/5,935 records consumed with an exact 20 + 48*numLights residual tail, zero unexplained bytes) and independently reproduced by the production FlatCollisionAssetBuilder.FlattenSetup path -- finds 0 Setups satisfying the guard: every Setup with Radius > 0.0001 carries at least one CylSphere or Sphere, and all 1,294 genuinely shapeless Setups have Radius exactly 0. Buckets: 678 cylsphere, 3,605 sphere-only, 358 BSP-only, 1,294 shapeless, 4,282 with Radius > 0.0001. Nothing loses collision because nothing gained it, so no visual gate is required. Tests, all sabotage-verified in both directions: - InstalledSetupCollisionReachabilityTests (new, Content) -- the negative claim plus five EXTERNAL positive controls, so a broken enumeration cannot satisfy it vacuously. Inverting the claim reddens it; emptying the enumeration fails on the controls at 0 != 5935 rather than passing. - ShapelessSetupWithRadius_ProducesNoRegistration (new, App) -- restoring the deleted block reddens exactly this fact and nothing else. - Build_PropagatesExactStateFlagsScaleAndFullSeedCell -- re-hosts the state / PWD-flag / seed-cell coverage that rode on the deleted fallback test, whose fixture (a Setup with a radius and no primitives) cannot exist in the DAT. Flipping a FromPwdBitfield bit reddens it; so does swapping SeedCellId for the landblock id. Also corrects ShadowShapeBuilder's retail-anchor comment, which claimed each part's find_obj_collisions tests "CylSpheres + GfxObj BSP". CPhysicsPart::find_obj_collisions @0x0050d8d0 tests ONLY the GfxObj physics BSP; CylSpheres are a Setup-level array reached via CPartArray::GetCylsphere. That comment was the written justification for the additive emission now filed as AP-152, so it is corrected here even though AP-152 is not fixed here. AP-22 retired with evidence; AP-152 filed (live path emits primitives AND BSP parts additively where retail is exclusive -- 172 of 5,935 Setups including BSP doors; deliberately not folded in, it needs its own visual gate). Issue #330 filed: the headless host registers no live-entity collision at all, a pre-existing gap this survey established and nothing tracked. Gates: Release build 0 errors / 0 warnings. Complete solution suite 11,195 passed / 4 skipped / 0 failed (baseline 11,193/4/0 at bcb66ccd; +1 App for the added fact, +1 Content for the reachability test; the replaced test is net zero). No new skips. Headless.Tests 89/89 exercises the site-3 copy. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 08:27:26 +02:00
Erik	bcb66ccdf3	fix(test): cover the atlas-tier seam the D-1 fix depends on; correct AP-150's citation ... Both items come from the D-1 fix review (both lenses PASS, D-1 genuinely closed). No production behaviour changes. L1 — THE SEAM HAD NO COVERAGE. The D-1 fix's "empty by construction" claim rests on LandblockSpawnAdapter's atlas-tier filter (`if (entity.ServerGuid != 0) continue;`) skipping the live server projections DetachNearLayer deliberately RETAINS across a demote. The reviewer removed that filter and all 4,170 App tests passed — only two Core unit tests caught it, none through a demote. So the invariant the re-assert depends on could have been deleted silently, re-opening D-1 by another route: a non-empty re-assert whose mesh reference is never satisfied leaves IsRenderReady false, which is the portal hang again. NearToFarDemote_WithALiveServerEntity_StaysRenderReady now demotes a landblock that CARRIES a live server-spawned entity through the real GpuWorldState + LandblockSpawnAdapter + LandblockPresentationPipeline, and asserts the retained entity never enters the desired set. Sabotage-verified: with the filter removed, exactly one test fails — this one — and the other 25 pass, including all four D-1 regression tests. That is the finding restated as a measurement: the D-1 tests genuinely do not cover this seam, and now something does. AP-150 citation corrected: the row cited 0x004D7064 as the ECM_UI::SendNotice_DisplayStringInfo call site. That address is the PStringBase construction of the "In Portal Space - Please Wait..." literal (:219516); the actual call is 0x004D70A1 (-> 0x006925B0). Same class of slip the #280 commit had just corrected for #326 — worth noting that a row filed WITH a byte-level disassembly still mis-cited a neighbouring address. Also refactored the existing pipeline demote test to keep its doc comment attached to its own method (an earlier insertion had orphaned its [Fact]). App.Tests 4,170 -> 4,171 passed / 3 skipped, net +1 for the new test. No new skips; none of #302/#308/#321 surfaced. src/ is byte-unchanged (the sabotage was reverted and verified). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 07:54:03 +02:00
Erik	73cdb95c7b	fix(streaming): make a demoted landblock render-ready like a published one (#280 D-1) ... Both #280 review lenses returned FAIL on the same defect, and both were right. IsRenderNeighborhoodResident's widened outer arm requires IsRenderReady out to FarRadius, justified by "a Far-tier landblock registers with an empty mesh set and is therefore render-ready." That held only for a landblock that ARRIVED as Far. The second, equally first-class way to be Far tier is a Near->Far DEMOTE: DemoteLandblock -> EnqueueNearLayerRetirement -> LandblockRetirementStage.MeshReferences -> GpuWorldState.ReleaseLandblockMeshReferences -> LandblockSpawnAdapter.OnLandblockUnloaded => WantsLoaded = false while DetachNearLayer deliberately keeps the landblock loaded, terrain-mesh resident, terrain-collision resident and DRAWN. Nothing re-publishes an already-loaded landblock, so the demoted member satisfied NEITHER arm of the gate, permanently: wormhole tunnel plus centered "In Portal Space - Please Wait..." forever, no recovery short of relog. Reachable by ordinary play. Two consecutive recalls to the same landblock with walking in between makes ChangesStreamingCenter false, so there is no origin recenter and the region recentres through the ordinary demote diff. Also reachable via a mid-hold quality-preset drop -- ironically the exact scenario ReconcileDestinationReservationRadius was added to support. The pre-#280 radius-1 gate never touched that band, because nothing inside the Near ring can demote. FIX SHAPE. Make the two routes genuinely equivalent rather than teaching the predicate to tolerate the difference. ReleaseLandblockMeshReferences becomes "reconcile the registration to the post-retirement tier": after the release converges, if the landblock is still loaded AND still Far tier, re-assert the empty registration -- the identical OnLandblockLoaded(lb, empty) a PublicationKind.Far activation makes. It is empty by construction: DetachNearLayer retains only live server projections, which the adapter's atlas-tier filter skips. A full retirement is unaffected (DetachLandblock clears both _loaded and _tierByLandblock), and a throwing release still retries because the re-assert is only reached after the adapter converged. The alternative -- "|| (IsFarTier && IsLoaded)" at the gate -- was rejected: it fixes one caller while leaving IsRenderReady meaning two different things, which is precisely how this defect arose. After this change the predicate reads "drawable at its current tier" for every caller, with no knowledge of how the landblock got there. WHY THE TESTS MISSED IT, fixed here too: - Proof obligation P2 was discharged against RESIDENCY (the FarRadius+2 eviction threshold) rather than against IsRenderReady, the gate's actual atom. The contract now carries the correction and the restated obligation: no transition may REVOKE IsRenderReady from a landblock that stays inside FarRadius. - WorldRevealDerivedWindowIntegrationTests advertised itself as end-to-end against the real GpuWorldState but constructed it with no spawn adapter, so its IsRenderReady degenerated to IsLoaded via the "?? true". The single most load-bearing predicate in the change was stubbed out by a null in the test named after it -- the same shape as C5b's D3 and #276's three settler tests. Every fixture in that file now owns a real LandblockSpawnAdapter. - The P1 test's comment described its subject as "a Near-shaped completion the streaming window has since DEMOTED to Far". It is not; it is a fresh PublishAsFar, the case that does hold. Corrected, since a future reader would have taken it as demote coverage. Four new regression tests, all driving the real GpuWorldState + LandblockSpawnAdapter + LandblockPresentationPipeline through an actual demote, and all sabotage-verified in both directions (fail with the production change reverted, pass with it): NearToFarDemote_LeavesTheLandblockRenderReadyThroughTheRealPipeline NearToFarDemote_LeavesTheLandblockRenderReadyUnderBudgetedRetirement TieredWindow_StaysResidentAfterAnOuterRingDemote OutdoorReveal_SurvivesAnOuterRingDemoteDuringTheHold The budgeted variant exists because production composes LandblockRetirementCoordinator.CreateBudgeted, whose MeshReferences stage is a separate call site from the legacy pipeline's. SECONDARY, same commit: - R-1: ACDREAM_PROBE_REVEAL_RADIUS=0 was parser-accepted and Runtime-rejected -- it yields far = 0 for an outdoor destination, which fails invalid-readiness-shape on every acknowledgement, hanging the very A/B route the probe exists to measure. Parser floor raised to 1, with a 7-case table test. - R-2: the composite-warmup TRIGGER had silently moved onto the far window's critical path. Pre-#280 the gate and the composite domain were the same radius-1 square; #280 widened the gate without widening the domain, so every composite upload serialised behind the last outer-ring landblock for no readiness benefit. Warmup now starts once the NEAR sub-window is published -- trigger scope == domain scope, as before. The reveal gate is untouched: Evaluate still requires the full window AND composite readiness. - AP-150 filed: acdream's RetailWaitCueDelay = 5 s arming is NOT retail's trigger, and #280's commit message got this wrong on both clauses. Retail emits the notice unconditionally per tunnel rotation segment, in the else arm of the segment-expiry test at 0x004D6FCD; segment duration is RandDouble(0.6, 1.8) s, byte-decoded at 0x004D6FE6. The 5.0 constant at VA 0x007991B0 is CellManager::CheckPrefetchStatus's prefetch RETRY cadence and has nothing to do with the cue. acdream's own 0.6/1.8 segment constants already match retail exactly; only the arming is wrong. Adopting retail's unconditional emit is filed as #329 rather than folded in here -- it is a user-visible presentation change and wants the user's eyes. - AP-151 filed: the gate is materially STRICTER than retail on the mesh-build/GPU-upload axis. Retail's LScape::PreFetchCells blocks on DAT RESIDENCY only -- no geometry construction, no upload; that work is lazy at draw. acdream requires a DAT read, terrain mesh build, render-thread upload, spatial commit, collision admission and spawn-adapter activation per member of a 625-member window, metered at MaxCompletionsPerFrame. Nothing bounds the hold. This is the OPPOSITE asymmetry from AP-149; both are live at once, on different axes. - AD-2's amendment stated the false Far-tier readiness assumption verbatim; corrected, along with the same error in claude-memory/reference_two_tier_streaming.md, which now carries an explicit DO-NOT-RETRY on the special-case-the-predicate shape. - AP-115 scope-noted (it covers the cue's presentation, not its arming). - #326's SmartBox::set_mid_radius citation corrected: the entry is 0x00453180; 0x004531D0 is the mid-function re-arm branch. Blast radius: GpuWorldState, LandblockSpawnAdapter, WorldRevealReadinessBarrier and StreamingDiagnostics are all App-internal; AcDream.Headless and AcDream.Runtime reference none of them outside comments. Headless tests run green as part of the gate below, per C5b's lesson about surveys that skip the no-window host. Gates: Release build 0 errors, 18 pre-existing xUnit analyzer warnings. Complete suite "dotnet test AcDream.slnx -c Release -m:1" with ACDREAM_PAK_PATH set: 11,192 passed / 4 skipped / 0 failed, from a clean rebuild (a prior session's deleted probe file had been compiled into a stale test DLL). Baseline at fafc0b65 was 11,179 / 4 / 0; the +13 delta reconciles exactly to this commit's additions -- 3 readiness tests, 1 integration test, 7 parser table cases, 2 warmup-trigger tests. None of the known flakes #302/#308/#321 surfaced, and none is conflated with the finding above. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 07:27:28 +02:00
Erik	3aab05b0cc	fix(streaming): derive the portal reveal window from the live streaming radii (#280) ... The user watched far terrain visibly assemble after portal space exits. The reveal gate was NOT missing a hold — Slice E's hold mechanism is correct and already in place. The hold was measuring the wrong domain: it opened at a hardcoded 3x3 landblock neighbourhood (~192 m) while the visible world extends to the fog end (~2,189 m at the shipped High preset, inside a 2,304 m Far window). An 11.4:1 ratio. Retail's equivalent ratio is 1:1 BY CONSTRUCTION. `LScape` owns one `mid_width x mid_width` array of `CLandBlock*` (`LScape::SetMidRadius` @0x00504C00, `LScape::update_block` @0x005063A0), `mid_radius` is assigned directly from the user's `Render.LandscapeDrawDistance` preference (`SmartBox::SetRegion` @0x004531F0; values `Render_LandscapeDrawDistance_Values` @0x007CA988 = {3,5,8,11,15,25}, default 8 — both byte-verified against the PDB-paired 2013 binary), and that same square is simultaneously the prefetched set (`LScape::PreFetchCells` @0x00505660), the drawn set (`block_draw_list` over the same array), and the set the simulation blocks on (`CellManager::blocking_for_cells`). There is no retail configuration in which the client streams farther than it gates, because there is only one number. So the fix derives rather than duplicates. Four coupled parts, which is why this is one commit and not four — D1 without D2 hangs the client and D2 without D1 is dead code: D1 `WorldRevealReadinessBarrier` takes a live `Func<StreamingRevealWindow>` and stops being static: outdoor requires `FarRadius`, indoor still 0 (retail's `CEnvCell::PreFetchCells` @0x0052D1E0 arm). Read per evaluation, never captured — the radii are runtime mutable through Settings, and retail's answer to a mid-hold radius change is to reset, re-radius, and re-arm the blocking prefetch at the NEW value (`SmartBox::set_mid_radius` @0x00453180). `OutdoorNeighborhoodRadius` is deleted; there is no constant left to drift. D2 `StreamingController.IsRenderNeighborhoodResident` becomes tiered, because acdream's loaded landscape is: inside `NearRadius`, `IsNearTier && IsRenderReady`; out to `FarRadius`, `IsRenderReady` only. Without this the fix cannot work at all — nothing outside the Near ring is ever promoted, so any radius above `NearRadius` was unsatisfiable and would have held the reveal forever. Proof obligation P1 (a Far-tier landblock genuinely satisfies `IsRenderReady`) is now a test driven through the real `PublicationKind.Far` pipeline against a real `LandblockSpawnAdapter`, not an inference. D7 `RuntimeWorldTransitState.AcknowledgeDestinationReadiness` re-derived `indoor ? 0 : 1` and failed `invalid-readiness-shape` on any other value, so changing the radius alone would have looked like "the fix hangs the client". It is now a SHAPE invariant (`indoor => 0`, `outdoor => >= 1`). Runtime does not own the graphical host's streaming configuration and must not learn it; plumbing App radii into Runtime to preserve the strict equality is exactly the assert-a-mechanism-that-does- not-exist failure C5b was built to stop. Both non-graphical producers keep emitting their centre-ring token and stay legal, annotated in place. D6 `PhysicsEngine.IsNeighborhoodTerrainResident` rebuilt a full-map `HashSet` on every call, every frame of every hold. At radius 1 that was invisible; at radius 12 (625 ring members) it violates Slice I1's 0 B/resolve standard. Now an engine-owned scratch set, cleared in place; measured at 0 bytes over 1,000 warmed radius-12 queries. Also: the destination reservation opens at exactly the gate's radius and reopens on the same generation when the radius changes mid-hold (retail has one square for both, and no concept of prioritising an inner ring differently). Composite warmup deliberately stays `NearRadius`-scoped — the composite domain is entity-scoped and Far builds carry no entities, so widening it would walk the outer window to warm nothing. `ACDREAM_PROBE_REVEAL_RADIUS` is a measurement probe in a diagnostic owner (CLAUDE.md rule 5) so the connected route can be run A/B on one binary; it is NOT a user-facing prefetch knob, since a low setting would reintroduce the decoupling this slice exists to close. Register: AD-2 amended with the derived window, the two-tier split, and the four new retail anchors. AP-149 FILED for the residual this does not close — the outer ring accepts terrain-only publication where retail requires LandBlockInfo and every building EnvCell, so a distant building can still pop in at Far-ring distances. Do not let a later closeout claim parity. Docs: `ACDREAM_STREAM_RADIUS`'s CLAUDE.md description was wrong on every clause (the default is unset, not 2; it forces `NearRadius`; it is silently discarded by any Settings save) — corrected, since that is the file every session reads. `reference_two_tier_streaming.md` corrected in four ways, including "Far tier = terrain only": Far also publishes terrain COLLISION, which is precisely what makes this fix viable. #280's issue text had the right conclusion from a wrong premise (it names a view-distance setting acdream does not have) — corrected, and the missing Viewing Distance option filed separately as #326, with #327 (DDD progress readout) and #328 (hardcoded 5000 f far plane vs retail's byte-verified 4000) filed alongside. Expect LONGER holds and the "In Portal Space - Please Wait..." cue on recalls MORE often. That is convergence toward retail, not away from it: retail emits the byte-identical string for the whole duration of a blocked prefetch and polls at 5 s intervals. The failure condition is non-convergence, not duration. Gates: Release build 0 errors. Complete suite 11,178 passed / 4 skipped / 0 failed, against a re-measured 11,142 / 4 / 0 baseline at 9ee9c1a1 — +36, reconciled exactly as 36 new tests (App +23, Runtime +10, Core +3), zero deleted, zero newly skipped. Nine discriminating tests sabotage-verified in both directions. The connected/visual gate is batched into C5's matrix; its recipe, its three positive artifacts, and its required recall leg are written into the campaign plan. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 23:54:59 +02:00
Erik	23aa62f292	fix(review): close the C5b architecture-review findings (D2/D3/D4, L1-L5, S1) ... Follow-up to C5b (735f0a72). The retail-conformance review passed, so no production behaviour line moved: the flag truth table and the refreshPosition:false withhold are untouched. This is blast radius, test discrimination and documentation fidelity - plus two findings I could not confirm and am rebutting rather than complying with. D3 - THE PUBLISH-CONSERVATION TEST DID NOT DISCRIMINATE. The reviewer was right and it was the worst finding here: proof obligation 3's test passed identically with C5b reverted. Its only delta assertion FILTERED (Assert.Single(deltas, Rebucketed && parentGuid)), so the pre-C5b stream [Rebucketed] and the post-C5b stream [Updated, Rebucketed] both satisfied it, and childSpatialBefore+1 held in both worlds because whichever site did not move the cell propagated idempotently. It now asserts the complete ordered parent stream plus each element's CellId and Position.ObjCellId. Sabotage: restoring refreshPosition:acceptedPosition turns it red (it was green before), together with the withhold test and the new L5 test. That cardinality change was itself unfiled and is now AP-147: a cell-changing accepted Position publishes TWO entity deltas where it published one, and the intermediate Updated pairs the OLD CellId with the NEW wire Position - a torn pair that did not exist pre-C5b, since both halves used to move inside one publish. No production consumer reads a delta's paired fields, but a recorder/plugin/bot event log would capture it. The row states why suppressing the Updated is not available at that layer (the merge cannot know whether its caller reaches W2). D4 - THE PROJECTILE DOC COMMENT WAS FALSE AND ITS RETAIL ARGUMENT WAS INVERTED. SyncPresentationFromResolvedBody claimed record.FullCellId is "the WIRE cell ... stamped by the merge's RefreshDerivedState/SetFullCell, before classification ever runs" and argued from retail's store_position @0x00515CE2 that the destination cell is the right one. C5b falsified the premise; the missile arm also returns before W2, so nothing stamps the wire cell for a projectile at all. Rewritten. The honest conclusion, which the old text would have called wrong: on a stored outcome presentation now pairs the DESTINATION world position with the SOURCE cell. That is not a choice this method can make differently - StoreAcceptedDestinationPose writes only Position/Orientation, so record.FullCellId and body.CellPosition.ObjCellId now hold the same source cell and reading either yields the same value. The divergence is AP-138 item (1)'s store-writes-pose-but-not-cell residual, retiring via #309, not a field choice here. Projecting the wire cell instead would invent a residency the placement declined - the AP-1 shape C5b closed. L3/L4/L5 - PINNING GAPS, ALL THREE CONFIRMED AND CLOSED. L3: the matrix's oracle passed HasAnimations as a literal, so the merge's old.MotionTableId ?? old.Physics?.MotionTableId and RuntimeAcceptedPositionRouteRequests.Build's canonical-snapshot twin were textually identical and pinned by nothing. The oracle is now BUILT by the production constructor. L4: every fixture set both MotionTableId halves to the same value, so deleting either operand of the ?? was undetectable while the production comment said the mixed case is the real-world one. Six mixed rows added, including the explicit-zero row (a present-but-zero top half is not null, so ?? never reaches the physics half). L5: the retained Rebucketed ternary had zero coverage through TryApplyPosition - every restoreCancelledPark test called Forget directly. Now driven through the real merge, with the wire cell deliberately the SOURCE while the park's committed body cell is the DESTINATION, so the restored residency can only have come from the rollback. Sabotage (each red, each restored): merge ?? -> top half only, 1 red; -> physics half only, 2 red; Build's ?? -> physics half only, 2 red; ternary -> constant Updated, exactly the L5 test red. L1/L2 - THE MISSING TEST IS ADDED; THE DEFECT IS NOT THERE. The reviewer was right that C5b's "no fixture covers pickup at that layer" was inaccurate - LiveEntityNetworkOnPositionCollapseMatrixTests drives the real OnPosition at ~26 sites - and the end-to-end test is added: withdraw -> accepted Position -> IsSpatiallyProjected && FullCellId == wireCell, both guid classes. But ChildUnparentDisposition.Pending is NOT a live defect, because it is production-unreachable. The sole production _withdrawProjection binding (LivePresentationComposition.cs:599) is LiveEntityProjectionWithdrawalController.WithdrawExact, whose only Pending mint is inside its catch block and therefore always carries a non-null Failure - and AdvanceUnparentTransition rethrows at EquippedChildRenderController.cs:1307 BEFORE the return Pending at :1309. The named drop scenario does not reach it anyway (BeginDetachedRemoval has already emptied the capture list) and would be correct if it did: a previously-equipped child is LegacyImmediate, so the FullCellId != 0u gate at DatLiveEntityProjectionMaterializer.cs:767 is never consulted and re-projection uses the wire cell at LiveEntityRuntime.cs:824. Measured while building that test, and NOT what C5b assumed: W2 and W3 are REDUNDANT on the remote tail. Sabotaging W2 alone - adopting the committed cell instead of the wire cell, OR skipping the rebucket outright - leaves the whole file green, because W3's RemoteMotion.CellId write reads through to canonical FullCellId via CommitCanonicalCell, whose CellCommitted recovery re-installs the bucket. Only removing BOTH goes red, and then the new test is the only red in the file. So it is named for what it pins, and AD-60 is amended with the measurement: neither channel is individually load-bearing, so a future retirement of one is caught by nothing else. D2 - REBUTTED, WITH THE REAL GAP FILED INSTEAD. The reviewer's hypothesis was that TryApplyInitialCreateCompletionPresentation's staleness guard lost its ability to detect an intervening steady-state Position when C5b stopped the merge stamping the wire cell, and asked for a PositionAuthorityVersion term. I do not think that is right and did not add it. The receipt's facts are the canonical BODY's pose and cell at publish (PublishExecutorCompletion builds both from the record). Exactly two owners can move them: a Runtime SetPosition commit/withdrawal, every one of which calls AdvancePlacementCommit - the only caller family is RuntimeSetPositionState - and a rebucket, which moves FullCellId. Both are already covered by the two existing terms. An accepted steady-state Position is neither, and C5b did not make it one: the merge refreshes the snapshot and advances PositionAuthorityVersion but never wrote the body, and the App generic tail writes the RENDER entity. The wire-cell half stays covered because W2/W3 commit it in the same call; the paths that return before them leave the record at the last committed cell, which IS the receipt's own cell - correctly not a supersession. Adding the term would decline receipts whose facts are still true, on the entity's FIRST world-visible moment: the pose write and RebucketLiveEntityPresentationOnly would be skipped while TryPublishPlace still publishes, so a packet returning before the render write would leave the sidecar visible at its materialized pose in a wrong bucket. That is the handoff's own "removed the invariant failure while leaving the bug" shape. There IS one supersession neither term covers, and it predates C5b: RuntimeRemotePlacementDriveController.StoreAcceptedDestinationPose writes body.Position/Orientation on the far-snap Refused/Contention arm with no placement commit and no cell move. Filed as #323 with the FIFO-blocking argument for why a receipt can still be pending when it lands, an explicit "not established as reachable", and an explicit "do not fix it with PositionAuthorityVersion". The guard's comment now carries the whole argument instead of one sentence. S1 - DANGLING POINTER CLOSED. InboundPhysicsStateController.cs:610 still said the two-callers-one-rule debt was "tracked for the eventual cutover unification ... See docs/ISSUES.md", which pointed at nothing after C5b closed #275 without a successor. Filed #322, cited from both the comment and #275's closure, including why widening TryApplyPosition's signature to take a route would be the wrong unification. AP-138 amended: C5b staled its round-3 measurement that "both accepted-Position callers commit the accepted wire cell to record.FullCellId before submitting". Route 2 submits from TryExecuteAcceptedLocalPosition ahead of W2, so on a first submit PlacementTouchesPrefix's CurrentCellId arm now names the SOURCE landblock, not the destination. Confined to which prefix the quiescence pre-flight matches, which that row already established is not the correctness mechanism. GATES. Release build 0 errors. Complete suite 11,134 passed / 4 skipped / 0 failed, from the 11,125 / 4 baseline at ed806997: net +9, all new tests, no test deleted or weakened, no new skip. Runtime.Tests 1195 -> 1202 (+6 mixed-motion-table rows, +1 park-rollback fact); App.Tests 4132 -> 4134 (+2 guid rows). None of #302/#308/#321 appeared. Not connected-gated - nothing here changes runtime behaviour. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 22:08:46 +02:00
Erik	735f0a72af	fix(physics): classify before merge on every steady-state Position (C5b, #275, AP-131/AD-60) ... The steady-state accepted-Position merge did two things retail never does, on every single Position packet: it installed the wire placement frame and unparented unconditionally, and it derived the record's FullCellId from bare wire acceptance. Both are now correct, and they land together - a half-flipped intermediate (classified flags with the wire stamp, or vice versa) is exactly the mixed-residency state this campaign keeps paying for. WHY the flags need no route. SmartBox::HandleReceivedPosition @0x00453FD0 decides both pre-placement writes BEFORE MoveOrTeleport is consulted: Gate A @0x0045400C returns @0x0045409D ahead of unset_parent @0x00454129 and ahead of the HasAnims SetPlacementFrame gate @0x00454137. Neither gate reads the near/far/teleport classification. So the two flags are a pure function of (disposition, hasAnimations) and are computable inside the merge, pre-merge, with no signature change, no route construction and no playerDistance - the scoping's ~150-400-line route-plumbing estimate over-counted because it did not see this. That truth table IS RuntimeAuthoritativePositionRouteClassifier.ClassifyAcceptedPosition's own ApplyPlacementFrameBeforeRouting/UnparentBeforeRouting rows; the classifier stays the oracle and the equality is pinned by test, not by a shared path, so each computation remains separately sabotage-verifiable. WHY the cell is withheld. HandleReceivedPosition reads the wire objcell_id into a LOCAL @0x00453FE3 and hands it only to BlipPlayer / TeleportPlayer / MoveOrTeleport / ConstrainTo; it never assigns the object's cell. The object's cell moves inside the placement family (SetPositionInternal @0x00515BD0 to set_cell, enter_world) or per-frame transit, and nowhere else. The continuation executor has encoded that rule since the executor slice; this caller now matches it verbatim. WHAT DELIBERATELY SURVIVES. Two steady-state wire-cell writers stay, downstream of the merge and outside the classification window: the OnPosition prologue rebucket (W2, into CommitRebucket), which is also the local player's own cell-freshness path, and the post-routing wire-cell adopt for non-placing arms (W3, AP-135). Gating W2 "for symmetry" would freeze the player's canonical cell between teleports and #319's child-cell equality would inherit the freeze. AD-60's rewrite names both so the retirement cannot be misread as "wire acceptance never changes residency anywhere". REGISTER. AP-131 RETIRED - the unconditional literals no longer exist; the caller was corrected, not deleted, so the row's own "deleted at the production cutover" framing is overtaken. AD-60's legacy half RETIRED and the row REWRITTEN rather than deleted, naming W2/W3 (route 4b-3's D8 precedent: a silent whole-row deletion would hide surviving channels). AP-130 amended - the merge consumes the same static HasAnimations proxy, deliberately not escalated to a live animation-queue read. AP-146 and #320 amended - their "accepted inbound Position (RefreshSnapshot into RuntimeEntityRecord.cs:234)" local-player cell writer is now the generic tail's CommitRebucket, and a ForcePosition (which returns before that tail) is placement-receipt-authoritative. #275 closed. HEADLINE BEHAVIOURAL DELTA, stated once: a refused or contended local ForcePosition now leaves FullCellId at the last committed cell where the merge used to stamp the refused packet's wire cell. Retail cannot refuse (AD-62) and its body keeps its last placed cell, so the new shape is the retail-reachable one. THREE CONSUMER SITES THE CONTRACT'S BLAST-RADIUS SURVEY MISSED, all D2-caused, all found by the suite rather than by reading, all intended semantics rather than regressions (recorded in the contract's new section 14): (1) DatLiveEntityProjectionMaterializer's self-projection branch reads FullCellId inside OnPosition's prologue recovery, ahead of W2. It now correctly declines to project from an unplaced wire claim; production installs the bucket at W2 in the same call (verified: no return between the recovery call and W2 is conditioned on IsSpatiallyProjected or FullCellId). Two hydration tests asserted the bucket at the recovery boundary and now drive the production W2 step - the same shape as trap T2, one layer up. (2) ProjectileController.SyncPresentationFromResolvedBody writes ParentCellId = record.FullCellId. On a refused missile placement that is now the committed source cell. The MAJOR-1 invariant is unchanged and is now asserted as the identity it always meant rather than as a wire-cell constant. (3) The merge's Rebucketed ternary does NOT become always-Updated as the contract predicted, and is deliberately kept: the Forget(restoreCancelledPark: true) above it can roll a wakeable lost-cell park back, and RestoreParkWithdrawal restores canonical residency. That is a real cell edge produced inside this method by a placement owner. TEST-COUNT RECONCILIATION. Baseline measured at this HEAD by stashing the change: Runtime.Tests 1176, App.Tests 4135 (4132 passed / 3 skipped), solution 11,106 passed / 4 skipped - matching the recorded figure at 6921a027 exactly. Post-change: Runtime.Tests 1195, App.Tests 4135 unchanged, solution 11,125 passed / 4 skipped / 0 failed. Net +19, entirely new Runtime tests: 3 facts plus a 12-row matrix theory in InboundPhysicsStateControllerTests, 1 fact plus a 2-row theory in the new RuntimeSteadyStatePositionMergeTests, and 1 fact in RuntimeAcceptedPositionDriveControllerTests. No test was deleted; five existing tests were rewritten in place, never delete-only. No new skip; none of #302/#308/#321 appeared. SABOTAGE VERIFICATIONS (each new discriminating test, both directions; production line broken, suite run, line restored): installPlacementFrame (!force && !hasAnimations) to (!force) 5 fail: ApplyOnAnimatedEntity_NeverInstallsTheWirePlacementFrame plus the 4 animated non-force matrix rows. installPlacementFrame to false 6 fail: ApplyOnNonAnimatedEntity_InstallsTheWirePlacementFrame, PositionPlacementAbsentAndPresentZeroBothApplyRetailZero plus the 4 non-animated non-force matrix rows. clearParent (!force) to true 3 fail: ForcePositionOnParentedLocalPlayer_RetainsTheParentAttachment plus the 2 force+parented matrix rows. clearParent (!force) to false 4 fail: the 4 Apply+parented matrix rows. refreshPosition false to acceptedPosition 4 fail: AcceptedPosition_WithholdsTheWireCellAtTheMergeBoundary, ContendedForcePosition_WritesNoResidencyAnywhere, ReentrantNewerPositionDuringPickupDiscardSuppressesStalePickupDelta, MissileFarRefused_...ParentCellIdAgreesWithCommittedCell. Confirmed a second time by the baseline measurement above, where the withhold test was the sole red. CommitRebucket publishes Updated instead of Rebucketed 2 fail: both parent classes of CellChangingAcceptedPosition_ConservesOneRebucketAndOneChildPropagation. RuntimeEntityDirectory.SetFullCell drops PropagateFullCellToChildren 2 fail: the same two rows. T4 respected: the ForcePosition placement-frame half is inert (appliedPlacement keeps old.PlacementId under either flag value), so the force row's discriminating assertion is parent retention, never the frame. NOT DONE, deliberately: the executor is still not wired into the steady-state path (#275's alternative branch); W2/W3 are untouched; no probe added or stripped; AP-130's proxy not escalated; no while-here unification of the two merge callsites. No automated OnPosition-level test drives the full pickup / drop / reproject sequence (no fixture covers pickup at that layer); the contract's connected gate recipe item 1 is the positive evidence for it and has NOT been run - this commit is not connected-gated. Contract: docs/research/2026-08-05-c5b-contract.md (committed here, with its section 14 implementation outcome appended). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 21:17:44 +02:00
Erik	6921a02744	refactor(physics): delete legacy PhysicsEngine.Resolve/ResolvePlacement/HasCellSurface (C5a, AP-1/AD-1) ... Member-wise deletion of the three legacy resolver members named in docs/research/2026-08-05-c5a-contract.md: PhysicsEngine.Resolve, PhysicsEngine.HasCellSurface, and PhysicsEngine.ResolvePlacement. An exhaustive receiver census over src/ found zero production callers of any of the three — every production placement writer already reaches the canonical PhysicsEngine.SetPosition transaction exclusively through RuntimeSetPositionState (three call sites total). The deletion is purely member-wise: IsSpawnCellReady and AdjustPosition, which shared the same source region as the deleted members, are preserved byte-identical — every remaining production caller of either (including PhysicsCameraCollisionProbe, AdjustPosition's sole surviving production caller) is unaffected. Companion changes: - PlayerMovementController's 3-argument SetPosition test overload is renamed to SeedPlacementForTest (internal) and CommitPreparedPosition is deleted; 83 call sites across 19 test files were mechanically renamed to match. - Seven pinned test dispositions from the contract are executed: 3.1 (PhysicsEngineTests.cs: 11 legacy-resolver tests deleted, 6 ResolveWithTransition tests kept), 3.2/3.3/3.4 (re-point to canonical SetPosition, with TransitionScratchDifferentialTests.cs additionally gaining positive IsCommitted assertions after each bitwise comparison so the differential proves a placement actually committed, not just that two possibly-uncommitted results match), 3.5 (Runtime rename), and 3.6 (PlayerMovementPlacementTransactionTests.cs rewritten — its xmldoc now states plainly that the render-root publish moved to RuntimeSetPositionState.cs, but the sticky-release relocation claim was false and is retracted; this disposition's coverage loss is the sticky release path, not silently absorbed elsewhere). - Stale `PhysicsEngine.Resolve`/`Resolve` doc citations in CellTransit.cs, PlayerMovementController.cs, and HeadlessSessionWorldProjection.cs are corrected to name the surviving canonical entry points by symbol (SetPosition, AdjustSetPosition/AdjustPosition, ResolveWithTransition) rather than fragile line numbers. Retires AP-1 and AD-1 in docs/architecture/retail-divergence-register.md: both rows described production zero-delta placement routing remaining on the legacy resolver pending the Slice 4B2/4B route cutover; that resolver no longer exists, so the condition each row tracked is now structurally false rather than merely narrowed. AP-145 (routed through the prior commit) and this commit's AP-1/AD-1 together bring the section counts to 101 AP / 47 AD active rows. Builds on the AP-145 fix (previous commit) — this commit's staged tree was independently rebuilt and its four suites independently rerun on top of that commit before this commit was created, in addition to the combined rebuild/rerun below. Full-solution build: 0 errors (21 pre-existing warnings, all unrelated). Suite results (combined tree): Core 4270/4271 passed (1 skip; the single DatSoundCacheTests concurrent-decode-dedup failure is a known load-sensitive race, confirmed passing standalone and unrelated to this change), Runtime 1176/1176, Headless 86/86, App 4132/4135 (3 skips). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 14:11:31 +02:00
Erik	f8e55ba5e4	fix(physics): route local-player shadow presentation through SyncPose (#318, AP-145) ... RuntimePlacementPresentationSink.TryPublishPlace previously published the local player's collision-shadow pose with a direct LocalPlayerShadowState.Set call — a plain cache write that never touched PhysicsEngine.ShadowObjects. Because LocalPlayerShadowSynchronizer.SyncPose's own dedup check compares against that same cache, the direct write could pre-seed the cache with the destination pose and cause the next real SyncPose call to see "nothing changed" and skip its own ShadowObjects publish — leaving the real collision shadow at the pre-teleport position until an unrelated movement tick forced a real publish. Fix: TryPublishPlace now calls _localPlayerShadowSync.SyncPose(..., force: true), the same publisher ordinary per-tick movement uses, so Place always drives a real ShadowObjects write before the cache updates. TryPublishWithdrawal carried the exact mirror asymmetry (a bare LocalPlayerShadowState.Clear with no ShadowObjects.Suspend, leaving a live phantom shadow row at the park's source cell for the whole park window — the #184 shape) and is fixed in the same commit, same one-call shape: _localPlayerShadowSync.Suspend(entity). The sink no longer holds a direct LocalPlayerShadowState reference; both halves route exclusively through the one synchronizer, which owns the cache internally. The single LocalPlayerShadowSynchronizer instance is now constructed in LivePresentationComposition (before the sink) and threaded through LivePresentationResult to SessionPlayerComposition, which no longer builds its own — this guarantees the sink's Place/Withdraw edge and ordinary per-tick movement publish through the exact same publisher and cache rather than two independent instances that could drift out of sync with each other. TryPublishPlace's xmldoc now states the behavioural nuance directly: routing through SyncPose means Place inherits SyncPose's own admission guard (IsHidden, cellId == 0, not-current-visible-projection), which the old direct .Set() call never consulted. Under those conditions SyncPose now calls Suspend instead of publishing — correct and symmetric, but new behaviour worth flagging at the call site, not just in a test comment. RuntimePlacementShadowCompositionTests.cs (#318) proves four facts against the real ShadowObjects registry, not the cache: a bare Place publishes a real row at the destination cell with the source cell's row gone; a subsequent ordinary per-tick Sync is then a correct no-op; a Place for a registered non-local-player entity leaves its row at the source cell untouched and never touches the player's cache (route 7 P4 — the fix lives entirely inside the pre-existing player-only gate); and Withdraw suspends the real registry row, not just the cache, with the retained (suspendable) registration surviving for a later restore. All four were sabotage-verified in both directions. RuntimeForcePositionRenderCommitTests.cs (B2) drives a real end-to-end accepted ForcePosition through RuntimeEntityObjectLifetime.TryApplyPosition and RuntimeAcceptedPositionDriveController.TryExecuteAcceptedLocalPosition against a live HostFixture, asserting both the committed render position AND a cell change that deliberately crosses out of the spawn's outdoor grid cell, so the cell assertion is independently falsifiable rather than riding along with the position assertion. Retires AP-145 (this fix) in docs/architecture/retail-divergence-register.md. AP-1 and AD-1 are untouched by this commit — they retire separately in the deletion-sweep commit that follows. Evidence chain: docs/research/2026-08-05-c5a-contract.md (the governing C5a slice contract), docs/research/2026-08-05-c5a-architecture-review.md (round 1, FAIL — three MAJORs: vacuous route-7 P4 test, unfixed Withdraw-side mirror asymmetry, non-driving B2 test), docs/research/2026-08-05-c5a-architecture-review-round2.md (round 2, PASS with two MINORs — an unfalsifiable B2 cell assertion and the undocumented SyncPose guard nuance, both fixed here). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 14:09:11 +02:00
Erik	392c1e22c1	fix(physics): bind a parented child to the parent's live incarnation (#319) ... A player-parented child never received a canonical cell. Its FullCellId stayed 0 for its whole attached lifetime, so it could not follow the player across a boundary. Scope was wider than the local player: every REMOTE player's equipment too. ROOT CAUSE. EquippedChildRenderController hardcoded ParentInstanceSequence: 0 for a parented CreateObject. Correct for creatures and statics, which really are sequence 0; wrong for players, whose ObjectInstance is Character.TotalLogins (ACE Player_Networking.cs:37). The relation filed under (playerGuid, 0) while the record carried TotalLogins, so both route-7 write sites — D1's attach re-cell and D2's propagation lookup — keyed on an incarnation that never matched. TryCommitParent did not validate the sequence, so the attach succeeded and printed normally. Silent. A ROUTE 7 REGRESSION (cd3129e9) that un-masked a latent bug: the TickChild call route 7 deleted was keyed on the child guid alone and was structurally immune to a wrong parent key. THE FIX IS TO STOP TREATING PLAYERS DIFFERENTLY, not to special-case them. Retail's attach path is guid-only end to end — PhysicsDesc::get_parent_id @0x00558a18 -> CObjectMaint::GetObjectA @0x00558a2d -> set_parent @0x00558a3e, with SetChildren @0x00509370 hash-walking by guid — and neither set_parent overload (@0x00515A90, @0x00515B50) nor enter_cell @0x00510ED0 contains any player test or instance-sequence read. Our player/non-player split was purely an artifact of keying relations by (guid, incarnation) against a wire message that carries no parent incarnation. Late-binding to whoever currently holds the guid is retail's own semantics. Fixed at BOTH producers: OnSpawn and OnCreateParentAccepted, the second carrying the byte-identical defect and not named in the contract's scope line. THE INVARIANT IS EQUALITY, NOT FRESHNESS. The contract rejected both framings I offered: every one of the 45 FullCellId liveness predicates excludes a committed child on a NON-cell clause first, so the child inherits only the parent record's existing staleness, which is already present today with no symptom. The key fix alone restores child-equals-parent for every parent class. TWO SITES GATED, inert only because the cell was zero and would have woken wrongly: the hydration candidate loop (a nonzero-cell child would take the legacy RebucketLiveEntity -> CommitRebucket, a second canonical writer — route 7's exact defect class) and RestoreShadow (would install a broadphase row for the weapon, the #184 shape, contradicting route 7's P4). Retail anchor: update_object's parent != 0 early-out @0x00515D40 — children are never independently re-placed. THREE MAJORS WERE FIXED BY DELETION. The first pass added a deferral queue for an unaddressable parent, carrying a missing child-freshness gate (A2), a sentinel-0 collision with the generation filters (A3), and unbounded accumulation (A5). Both reviewers then proved the deferred branch unreachable for BOTH producers — RegisterEntityCore defers the entire CreateObject one layer above, reading the same ?? chain, and CreateParentUpdate is produced only inside AcceptCreateCore, after that gate passes. The machinery was deleted rather than repaired, and the diff SHRANK to 76 added / 13 removed from 91/24 while gaining the A1 fix. Retail confirmed the deletion does not diverge: acdream's real port of retail's per-guid replay (QueueBlobForObject) is a different, untouched layer, and the deleted queue was a third redundant one downstream of it. THE GUARD MUST NOT TEAR WHAT IT PROTECTS. The first pass threw InvalidOperationException AFTER the canonical half had committed, so the one time it fired it left the child parented with no committed relation and a staged one blocking Resolve — a torn transaction, the exact outcome the contract pinned against. Now a pure CanCommitIncarnation precondition checked BEFORE the commit at both sites, with a logged refusal instead of a throw. Route 3's N3 principle (do not make a transient fatal on a host that must survive 30 sessions x 2 hours) reinforces it, but the tearing argument stands alone. TEST QUALITY, the recurring lesson in its most refined form. The A1 test initially passed sabotage FOR THE WRONG REASON: a mismatched ChildPositionSequence meant TryCommitParent's own gate refused in either ordering, so the three assertions carrying A1's meaning passed both ways and only an incidental staging assertion failed. It failed on stranding, not tearing. Corrected, the sabotage now names line 925 — Assert.Null(snapshot.ParentGuid), with the parent's guid in it — proving the canonical mutation happened before the catch. "Fails under sabotage" is necessary, not sufficient; WHICH assertion fails is the real question. The dual parent-class matrix (player 0x5… incarnation > 1 vs creature 0x8… incarnation 0, identical outcomes, sabotage-verified in both directions) is the structural fix for how this survived a full dual review and two connected sessions: every prior test and both captured gate logs used sequence-0 parents. Register: AP-142 clause (f); AP-132 amended to distinguish the two producers; new row AP-146 for the local player's coarse canonical cell (retail writes it per tick at SetPositionInternal @0x00515330 — which, per the retail review, ALSO walks this->children writing each child's objcell_id @0x005153AE-@0x005153D8, so retail's per-tick child propagation lives in the same function). That divergence had no row at all, a standing rule-1 violation now corrected. Follow-up #320 filed for making the player's cell track ordinary movement — deliberately excluded here: it touches the landblock-preserve contract, the Rebucketed cadence, route-2/4b-3 classification inputs AP-136/AP-138 spent four review rounds pinning, and the portal-space frozen-source-cell race. Two dual review rounds; 6 architecture MAJORs and 2 retail MAJORs closed. Diagnostic refusals are latched per child guid and the latch clears on Clear()/RemoveChild, so a recycled guid's next incarnation still logs rather than being silently suppressed. Complete Release suite MEASURED at 11,112 passed / 4 skipped / 0 failed (baseline 11,090 at 52175aa1, +22). Neither known flake fired. STILL OWED: the connected gate, with the CORRECTED positive criterion — assert the equipped child's FullCellId EQUALS the parent's after a crossing (a zero is a failure, not a silence), run with BOTH a player and a creature parent, plus the new step carrying an armed creature across a landblock unload/reload. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 11:56:31 +02:00
Erik	e0f96a55bf	fix(physics): C4 route 3 — portal placement authority (local player) ... Removes a duplicate placement authority for local-player portal arrival. Portalling worked before this change and works after it — this is not a bug fix, EXCEPT that it found and fixed one dead-code production bug. THE PRODUCTION BUG: TryExecuteCanonicalPortalPlacement re-read the accepted destination at Place time, but TryBeginPortalReveal already consumes that slot at Aim time — so the arm was 100% dead code and every real portal Place refused with host-token-unavailable. Found only because we refused to accept 7 skipped tests instead of chasing the count to zero. RETAIL IS THE GENERIC PATH FOR THE THIRD ROUTE RUNNING: SmartBox::TeleportPlayer @0x00453910 = SetPositionSimple(dest, 1) with flags 0x1012, followed by PlayerPositionUpdated. BOTH INVERSIONS, WITH THEIR ANCHORS: unlike route 2, the leash IS armed here (ConstrainTo @0x0045418A) and velocity is zeroed (set_velocity @0x004541B4); unlike route 4b-3, the local teleport_hook runs AFTER placement (@0x004538AE). THE THREE-ROUND DEFECT CHAIN, HONESTLY: - Round 1 released the player at the pre-teleport position while the anim stream marched on — the contract wrongly assumed Place re-fires (process rule 1's third occurrence this campaign). - Round 2's fix inferred commit from a global PendingCount, which three non-committing paths also clear — making the SAME bug complete cleanly and silently. Strictly worse than round 1: round 1 at least tripped portal-complete-before-materialized. - Round 3 latches the commit where it actually happens (ReconcileAndAcknowledgePortal), keyed on reveal generation and teleport sequence, via TryConsumePortalCommit. Two of the three required regression tests landed and are sabotage-verified on both hosts (ParkedPlace_ForgottenByOrdinaryMergeDoesNotLatchAsCommitted / HeadlessPortalPrepareDestinationForgottenByOrdinaryMergeDoesNotLatchAsCommitted). The third (force-arm-takes-the-slot) was judged unnecessary on review: with the inference gone, PendingCount is only a "don't ask yet" guard at both gates, so a force operation occupying or vacating the slot no longer changes an input the commit decision reads — the case collapses into what the landed test already discriminates. THE B2/P3 RESOLUTION: both round-2 reviews were right about different branches of the same synchronous call. RuntimePlacementProjectionSubscription .OnPlacement acknowledges the FIFO head only when TryApply returns true; a Place whose portal authority went stale (transit ended/superseded while parked) used to return false, wedging every later entity's placement receipt behind it forever. Both sinks (RuntimePlacementPresentationSink, HeadlessRuntimePlacementProjectionSink) now acknowledge-and-ignore a stale-authority Place instead of refusing it. The regression test (RuntimePlacementPresentationSinkTests .PortalPlace_StaleTransitHostOrSequenceIsAcknowledgedAndIgnored) had been asserting the old, wrong `false` behaviour; it now asserts and sabotage-verifies the fix. Also lands: AP-144 (register discipline — the portal movement-event send reuses the stricter UsePositionFromServer gate where retail's SendMovementEvent is the looser autonomy_level != 0 test, diverging only at level 1, currently unreachable), AP-145 + issue #318 (the local-player collision-shadow presentation write bypasses its own publisher's ShadowObjects write via a direct cache .Set(), self-healing only once dedup diverges — filed, not fixed, pending a composition test), AD-42 deleted (its last citation retired by the canonical portal arm), AD-2 updated (the wait-cue's trigger predicate now covers a second cause), and two documentation corrections: the enter_world misattribution (both call sites are in SmartBox::HandleCreateObject, only one in the player branch — portal arrival is TeleportPlayer, not enter_world) and the stale "local player never reaches this path" comment on the generic-remote-render-pose write. Suite: 11,090 passed / 4 skipped / 0 failed. No new skips, nothing weakened. STILL OWED: the connected two-client gate, with ACDREAM_PROBE_LOCAL_TELEPORT=1, scored only if [local-tp] lines actually appear in the capture — and explicitly NOT scored as covering issue #318 (no composition test yet asserts PhysicsEngine.ShadowObjects directly). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 03:57:37 +02:00
Erik	cd3129e9d6	fix(physics): C4 route 7 — child cell propagation moves from a render tick into Runtime ... Retail re-cells children when their parent crosses a cell, recursively, to unbounded depth. acdream did it from a RENDER tick, so headless parented children were cell-less forever and the canonical cell had two writers. This slice makes Runtime the sole authority and demotes App's tick to presentation-only. Contract: docs/research/2026-08-04-c4-route-7-contract.md; the research that unblocked it is docs/research/2026-08-04-retail-parent-cell-propagation.md (ca96ea5e). Retail: SetPositionInternal @0x00515330 branches on `this->cell == curr_cell` @0x0051536d; the changed branch reaches change_cell @0x00513390, whose delegates leave_cell @0x00510f50 and enter_cell @0x00510ed0 self-recurse over children and write the FULL identity (add_object @0x00510ee2, objcell_id @0x00510f1e, part-array cell id @0x00510f2b, cell pointer @0x00510f35). change_cell itself has no child loop. THE TRAP, recorded because it nearly shipped: the depth-1 loop @0x0051539c-0x005153d8 is the SAME-CELL fast path (objcell_id and part-array id only, deliberately not the cell pointer), NOT the propagation. An implementer who finds it first concludes "depth-1, id-only" and strands every equipped item at a landblock boundary — the #184 class. The clincher against that reading: update_object @0x00515d10 early-returns on `parent != 0` @0x00515d40, so a child never runs its own physics tick and parent propagation is the ONLY mechanism maintaining its cell. Route 7 performs NO placement (DoPickupEvent @0x00452240 = unset_parent + leave_world; DoParentEvent @0x00452290 = set_parent + SetPlacementFrame), so it arms ConstrainTo nowhere — the leash rule INVERTS relative to routes 2/4/5, and both reviewers confirmed nothing arms. Propagation is an ITERATIVE WORKLIST, not recursion. The first implementation recursed with a depth-64 cap; both reviews independently found the cap left a truncated tail at a stale NON-ZERO cell — permanently unrecoverable, logged only under a probe flag, and on the withdraw path exactly the #184 shape AP-142 clause (a) exists to reject. Shipping a fresh #184 instance inside the slice that fixes stranded children was not acceptable, so the cap was removed rather than tuned. The worklist retires the cap, the constant, its register clause, and the failure mode together. Termination: every record on the stack is already at the target pair, so nothing can be pushed twice and a hostile A->B->A cycle collapses without a visited set. The child write deliberately bypasses the public RuntimeEntityDirectory .SetFullCell and calls the record method directly. This is LOAD-BEARING: the public method re-enters PropagateFullCellToChildren, which opens with _propagationWorklist.Clear() — routing children through it mid-drain would wipe the shared stack and silently drop every unprocessed sibling. Any future side effect added to the public SetFullCell must be mirrored by hand at that call site. Deliberate divergence, recorded not disguised: retail's removal path leaves children with a null cell pointer but a STALE nonzero objcell_id @0x005133c1. acdream does not reproduce it, because FullCellId != 0 is the liveness predicate at 45+ sites — faithful porting would mark dead children live. AP-142 records this; clause (d) records that acdream cannot gate propagation on HasPartArray the way enter_cell gates on part_array @0x00510ed8, because the flag's only writers are graphical and headless never sets it — the reason is Slice J LAYERING, not a semantic difference (retail's part_array is itself a mesh-construction product, single assignment site makeAnimObject @0x0050e930 -> CPartArray::CreateSetup @0x0050e93e). D7 adopts retail's unset_parent-before-leave_world order @0x0045227f -> @0x00452286, applied to BOTH pickup paths including the dormant executor replay. Its inertness was verified by reverting it and finding all 12 propagation tests still green — reported honestly rather than papered over with a manufactured test, and independently confirmed by both reviewers. ClassifyLeaveWorld and its request/cause types are DELETED: retail has no classification here, and method-per-cause IS the retail dispatch shape. Wiring it would have forced a vacuous teleport-sequence predicate with the #307 shape. Two review rounds plus a coordinator-required third pass; 5 MAJORs. One was a handoff failure worth recording: enter_cell's part_array guard was correctly identified as load-bearing by the research, dropped by the contract when it enumerated the writes, and inherited as an omission by the code — a right finding that evaporated across two handoffs with nobody re-reading the source. Another was a test that survived deleting the entire behaviour it claimed to pin, because its assertion read a field written unconditionally one line earlier. NoProjection is structurally unreachable from TickChild (TryResolveExactAttachment performs a strictly stronger form of the same guard one call earlier). Kept as a fail-safe, unit-tested directly, and documented in two places rather than wrapped in a fabricated end-to-end test. Headless regression test — the direct gate for this defect, which FAILED before this work because no code path existed: RuntimeLiveEntitySessionControllerTests .DirectSink_D5_StandaloneParentEventCommitsChildToParentsExactCell. Probe: ACDREAM_PROBE_CHILD_CELL=1 emits [child-cell] lines at all four write sites (attach / headless-attach / propagate / withdraw / delete). TEMPORARY. Complete Release suite MEASURED at 11,079 passed / 4 skipped / 0 failed (baseline 11,063 at cff52c44, +16). An allocation flake appeared once under load and was proven NOT this slice by reachability — RuntimeCollisionReportingState contains zero SetFullCell and zero ParentAttachments references. STILL OWED: the two-client connected gate (equip/unequip, carry across landblock boundaries, pickup, loot, reconnect) with ACDREAM_PROBE_CHILD_CELL=1, and a session counts only if [child-cell] cause=propagate lines appear. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 23:53:05 +02:00
Erik	36255af0f6	fix(physics): C4 route 5 — projectile authoritative placement (#276 partial) ... Ports retail's missile Position handling into the canonical Runtime placement owner instead of the deleted ApplyAuthoritativePosition short-circuit. The Create/residence-window halves of the projectile pipeline (RuntimeProjectile binding, TryBind's adopted-body branch, the collision/shadow registration) were already canonical from prior slices; this closes the remaining gap — how an ACCEPTED Position for an in-flight missile is classified, placed, and presented. Byte-decode (Step 1 hard gate, before any code was written): CPhysicsObj::MoveOrTeleport @0x00516330-0x00516438 disassembled from the PDB-paired binary (Capstone, x86 32-bit thiscall). `ret 0x10` establishes four stack args; [esp+0x7c] (arg5, the velocity pointer) is never referenced in any of the three branches (teleport/near/far). The retail reviewer independently reproduced this by searching the whole function body for the `24 7c` mod/rm+disp8 encoding a `[esp+0x7c]` read would require and found zero occurrences. This retired a fabricated `?? Vector3.Zero` fallback in the deleted method — retail's PositionPack::UnPack initializes an absent velocity to zero and MoveOrTeleport never installs it; the projectile's Vector channel (RuntimeProjectilePhysicsUpdater.ApplyAuthoritativeVector) remains the sole velocity authority for a missile. D-P5 in the contract; the Runtime seam commits no velocity from the Position packet at all. The unbound-missile fix: RuntimeEntityObjectLifetime's ClassifyRemoteAcceptedPosition now derives ProjectileAuthoritative from a CONJUNCTIVE predicate — the Missile bit AND a bound RuntimeProjectile whose Body is the canonical PhysicsBody — never the bit alone. Retail places every non-player CPhysicsObj unconditionally (there is no missile-specific placement gate in MoveOrTeleport or its callers), so an unbindable or not-yet-bound missile taking the ordinary remote tail is retail-faithful, not a fallback: the earlier bit-only discriminator would have silently frozen it instead. AP-141 records this as a deliberate, recorded divergence, not fidelity. Retail mechanically WOULD arm a missile's ConstrainTo leash on any nonzero MoveOrTeleport return: HandleReceivedPosition @0x00453FD0's only kind test is player-vs-not, ConstrainTo @0x00454272 has no kind test of its own, and CPhysicsObj::ConstrainTo @0x00510520 creates a PositionManager on demand via MakePositionManager @0x00510523 if one doesn't exist. acdream deliberately does not construct that EntityPhysicsHost/ PositionManager/InterpolationManager chain for a ballistic body — the route-5b split the C4 route 5 contract rejected — so a live missile never shows an armed leash and never catches up via the near/ UnroutedCatchUp policy. This divergence is safe specifically because ACE never sends UpdatePosition for a missile (references/ACE/Source/ACE.Server/WorldObjects/WorldObject_Tick.cs: 333-334, SendUpdatePosition() commented out inside the PhysicsState.Missile branch at :265) — every half of this row is deterministic-test-gated only, never exercised against a real server. AP-141 also records the surviving ConstrainTo re-anchor divergence under clause (b): for the adopted-body case (TryBind's shared-body branch — an ordinary remote whose Missile bit is set by a later State packet, so it still carries a live RemoteMotion), acdream now ports retail's teleport-branch and far-branch StopInterpolating action (Interp.Clear()), but never re-arms or re-anchors the inherited ConstrainTo leash the way retail's HandleReceivedPosition @0x00454254/@0x00454272 does on every nonzero return. The risk column's earlier wording — that a stale leash "would drag the body toward a stale anchor" — was wrong and is retracted in this same commit: ConstraintManager.ConstraintPos is write-only in both retail and the port (never read by AdjustOffset), and ConstraintManager::adjust_offset @0x00556180 only tapers or zeroes an already-composed per-tick offset while InContact — a leash brakes motion the interp/sticky chain already produced, it cannot pull anything toward the anchor. The real residual is one tick of un-reset brake accumulator, contact-gated, and it cannot move an airborne far-snapped missile at all (the clamp branch does not run while airborne). NO CONNECTED GATE EXISTS for this route, by design: ACE never sends a missile UpdatePosition (see above), so retail's own server never exercises this code path in play. Every proof obligation here is test-gated only — Runtime and App-level fixtures constructing the packet directly — never a live client/server capture. Three review rounds closed 8 MAJOR findings before this landed: round 1 (A1 App discarded the seam's status; A2/R1 silent swallow on an unbound missile; A3/R2 the adopted-body teleport_hook never wired; A4/A5 zero Runtime/App test coverage); round 2 (a ParentCellId regression introduced by round 1's own R6 finding, which the retail reviewer retracted the following round as factually wrong — the fix here is the REVERT to record.FullCellId, not the relocation round 1 shipped; B2 the far-branch StopInterpolating skip never extended to the adopted-body case; residual App/Runtime store- path coverage; a per-packet closure contradicting the file's own #315 cached-delegate pattern). Round 3 closed on coverage alone (no defect): the Advance() retry arm's projectile branch — added at round 2, semantically reordered at round 2's B5 fix (skip prediction invalidation on a re-parked Contention, since it writes nothing) — had never been executed by any test; two new tests drive it directly and are sabotage-verified against both the reordering and the retry-arm's own SyncProjectilePresentation call site. The one recorded defect this campaign produced (the ParentCellId regression) was caused by complying with a review finding that its own author later retracted — the standing lesson recorded for future rounds is that review findings are evidence to re-verify against the code, not commands to obey unconditionally. Complete Release suite: 11,063 passed / 4 skipped / 0 failed (baseline 11,036 at 30d3d114, +27 new tests across this campaign). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 21:03:41 +02:00
Erik	edc911b042	refactor(physics): collapse OnPosition's dual player/NPC remote tail into one ... C4 route 4b-3 collapse (docs/research/2026-08-04-onposition-collapse-contract.md). Behaviour-preserving: the ~640-line duplicated player-guid and NPC-guid copies of the remote routing tail in LiveEntityNetworkUpdateController.OnPosition become one guid-blind tail, reached by every remote guid through the single ApplyRemoteContactRouting/RunRemoteArmTail seam. Two guid-conditionals survive, both named and justified: - Row 8 (TS-44 sticky suppression, creature-only): retail's sticky is independent of this acdream-only steady-state gate; the register row already describes it as NPC-only and this collapse does not widen it. - The AirborneSnap arm's interp-clear + shadow-publish (rows 2a/2b, player-only preserve): unifying either way would be an unauthorized behaviour change. #316 (shadow publish) is a real, unmeasured pre-existing defect, deliberately preserved not fixed. The interp-clear's equivalence could not be proven for the steep-non-walkable-landing edge case (AdjustOffset's CONTACT-keyed gate vs. AP-139's WALKABLE-keyed per-tick clear) — preserved per contract stop condition 2 rather than shipped on an incomplete proof. Category-(c) resolutions (contract §2.1-2.5), each with its evidence: - Row 2a (interp clear): PRESERVED — AdjustOffset's `if (!inContact) return` proves inertness on flat landings, but not on the steep-contact edge case. - Row 2b (shadow publish / #316): PRESERVED — no design note ever sanctioned the player-guid skip; the file's own #184 Slice 2b comments contradict it. - Row 2c (EnsureRemoteMotionBindings): UNIFIED — the method is idempotent (`if (rm.Host is not null) return rm.Sink;`), so "always ensure" is safe. - Row 3 (wire-cell adopt ordering): UNIFIED — RebucketLiveEntity already commits the wire cell before either guid branch runs, so the deleted player-guid pre-write was a proven no-op. - Row 4 (LastServerPos/Time sample timing): UNIFIED — on a genuine first UP, InterpolationManager.Enqueue's already-close branch and the Snapped branch both converge on the same body pose/orientation for a zero-distance target. - Row 12 (wall-clock capture): UNIFIED — one shared `nowSec`, a microsecond-scale skew in acdream-only bookkeeping/diagnostics. Sabotage check (contract §5, performed and reverted, not committed): deleting the one remaining TryArmConstraintAfterOperation call failed 10/16 dual-guid matrix tests, spanning BOTH guid halves of every arming-dependent scenario (teleport, landing, near, far, sticky) — proof the matrix discriminates a defect regardless of which guid range exercises it, closing the class of bug that let 4b-3's A1/A2/R3 findings survive review when only one copy's tests were green. New tests/AcDream.App.Tests/Physics/LiveEntityNetworkOnPositionCollapseMatrixTests.cs drives 8 scenarios x 2 guid ranges (0x50xxxxxx player, 0x8xxxxxxx creature) through the complete production OnPosition entry point. Doc comments on ApplyRemoteContactRouting, RunRemoteArmTail, ApplyWireAirborneLeftoverBookkeeping, TryAdoptWireCellAfterRouting, and the AirborneNoOperation throw guard updated to describe the collapsed one-path world (the "two callers stay one decision" claim was true before this commit and false after — fixed in the same commit that makes it false). One branch-routing source-text pin (LiveEntityNetworkBranchRoutingTests.cs) updated to follow the AP-140 CONTACT gate to its new address inside ApplyRemoteContactRouting. #316 stays OPEN, deliberately not fixed here — see its updated ISSUES.md entry. dotnet build AcDream.slnx -c Release: 0 errors. Verified independently bisectable at this exact commit: AcDream.App.Tests 4104/4107 (3 pre-existing skips), AcDream.Runtime.Tests 1125/1125. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 18:07:54 +02:00
Erik	daef7c9835	fix(inventory): reset a split result's movement timestamps so recovery cannot throw (#314) ... Found by C4 route 6's integration tests (1b484937) and split out of that zero-production closure per the standing split-on-discovery rule. PendingSplitToWorldProjection.BuildSpawn zeroes the top-level MovementSequence/ServerControlSequence, but its Physics.Timestamps `with` block overrode only Position/Teleport/ForcePosition/Instance — leaving Timestamps.Movement and .ServerControlledMove at the SOURCE item's values. RuntimeEntityObjectLifetime.HasConsistentCreateIdentityAndParent requires the PhysicsDesc timestamps and their flattened projections to agree, so the synthetic spawn failed the predicate and TryRecoverUnknownPosition threw `CreateObject 0x… has inconsistent instance or parent projections` instead of completing the canonical create-placement transaction. Reachable in ordinary play: retail's per-object update_times channels are monotonic and do not reset when an item re-enters a container, so any item that ever had world presence — dropped once, picked back up, then split — carries nonzero values in exactly those two fields. The split pile then never appears. Fix is the honest value, not a placation of the predicate: a fresh split GUID has no movement history by construction, so both channels are zero in both projections. Deliberately NOT fixed by loosening HasConsistentCreateIdentityAndParent — the predicate was right and the producer was wrong. The route-6 test that documented the throw (SplitSourceWithRetainedMovementTimestamps_ThrowsInsteadOfRecovering) is renamed to …_StillRecovers and now pins the fix. It asserts more than "no throw": the result's movement channels must be ZERO in both projections, so the test cannot pass against a lenient-predicate workaround. Sabotage-verified in both directions — restoring the old BuildSpawn reproduces the exact original InvalidOperationException. Notable for the campaign record: this is a crash in the precise mechanism route 6's scoping cited as EVIDENCE that drops already converge on the canonical transaction. Reading the code said the path converges; driving it said it throws. The zero-production route was still correct — and building its tests anyway is what found this. Complete Release suite 11,020 passed / 4 skipped / 0 failed, unchanged from 1b484937 (the test flipped its assertion rather than being added). Neither known flake fired. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 16:48:41 +02:00
Erik	1b484937b6	test(physics): C4 route 6 — drops/split-recovery closure, zero production lines ... Route 6 needs no production change and this commit contains none: C3c (529e0e9d) already flipped both hosts' Create paths onto the residence lease, so a dropped item is byte-for-byte route 1's create classification (RuntimePositionEntityKind.Remote, RuntimeCreateResidenceKind.TopLevel, ClassifyCreate -> SetPosition with InitialCreateFlags = Placement | Slide). Route 6 is a SOURCE of route-1 traffic, not a route of its own. Both drop flavours converge on LiveEntityHydrationController.OnCreate -> RegisterEntityWithInitialResidence — the whole-item drop through ItemInteractionController's DropToWorld (no physics, no position; the server decides), and split-to-world through TryRecoverUnknownPosition's call to the identical entry point. Contract: docs/research/2026-08-04-c4-route-6-contract.md. Retires a FALSE PREMISE from the campaign plan (:97-100), which claimed split-recovery creates "need an effect-replay suppression signal". Verified against the decomp instead of assumed: play_default_script @0x005132B0 / @0x00513300 has exactly three call sites in the entire pseudo-C dump — DefaultScriptPartHook::Execute @0x00526c08, DefaultScriptHook::Execute @0x00526c14, and ACCWeenieObject::DoCollision @0x0058c3b4 — and NONE from set_description or CreateObject. Neither client plays a default script at create, so there is nothing to suppress. acdream's only create-time replay is the F754/F755 queue drain keyed by server GUID, which is retail's own HandleCreateObject @0x00454C80 behaviour. The plan's other two clauses were closed at C0 (TryCommitParent/CommitWithdrawal cancellation symmetry; host-visible cancellation receipts); the list now states what actually remains — route 7's child-cell two-writer split and the headless parent-realize gap. Retail split marking recorded for the record: UIAttemptSplitTo3D @0x0058D850 stores only splitStackSize/splitClassID/splitTime and performs no placement; DeclareValid @0x0058E340's recovery action is SetSelectedObject @0x0058E481 — a SELECTION transfer with a 10-second expiry, not effect suppression and not placement. UIAttemptPutIn3D @0x0058D700 records no marker at all. Seven tests over the now-flipped path (whole item, split stack, new-GUID recovery, second drop, unavailable destination, newer Position after the pending identity is consumed, plus the #314 repro), each sabotage-verified: the production path was broken on purpose, the test was confirmed to fail, and the sabotage reverted. R6-c is now settled by assertion rather than argument — BuildSpawn's wholesale clone of Children/Movement/AnimationFrame/ SetupTableId is measured, not reasoned about. FOUND WHILE TESTING — #314, filed not fixed (this route is zero-production by contract). BuildSpawn resets top-level MovementSequence/ServerControlSequence to 0 but its Timestamps `with` block overrides only Position/Teleport/ ForcePosition/Instance, leaving Physics.Timestamps.Movement and .ServerControlledMove at the SOURCE item's values. HasConsistentCreateIdentityAndParent requires the two projections to agree, so a split whose source carries nonzero Movement timestamps — plausible for any item dropped once, picked up, and split again — fails the predicate and throws instead of completing the canonical transaction. Verified in source, not taken on report. Note this is a crash in the exact mechanism the scoping cited as EVIDENCE that drops already converge: code reading said the path converges, driving it said it throws. Fixed in the immediately following commit. Also filed: #313 (DeclareValid's SetSelectedObject port is missing and the container-split flavour records no marker — selection UX, deliberately not implemented inside a placement closure) and #315 (route 4b-3's per-packet runTeleportHook Func<bool> closure at three RunRemoteArmTail call sites; the network packet path, not Slice I's per-frame resolve path — filed now because route 5 adds a fourth site). AP-124 stays open and registered. Test lines are 410 against a 150-250 guidance, accepted: the excess is a real ItemInteractionController harness plus the #314 repro, which is what found the defect. A mock that proved nothing would have been shorter and worthless. Complete Release suite MEASURED at 11,020 passed / 4 skipped / 0 failed (baseline 11,013/4/0 at 6dc7ba51; +7 new). Neither known flake fired. Connected gate (user-run) still owed: drop a whole item, split a stack to the ground, drop a second within ~1 m, repeat indoors and after a portal recall, then walk two landblocks away and back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 16:45:57 +02:00
Erik	6dc7ba51ee	feat(physics): C4 route 4b-3 — remote teleport + cell-less through the canonical placement ... Flips the last remote classification (SetPosition: teleport-advanced and cell-less) onto 4b-1's RuntimeRemotePlacementDriveController, runs retail's teleport_hook before the placement, and deletes the legacy remote-teleport machinery. Contract: docs/research/2026-08-04-c4-route-4b-3-contract.md. Retail: MoveOrTeleport @0x00516330's branch @0x00516386 -> teleport_hook @0x005163EF -> SetFlags(0x1012) @0x00516414 -> SetPosition @0x00516420 -> return 1 @0x00516438. The hook @0x00514ED0 runs BEFORE the placement and regardless of its outcome. Retail places this branch unconditionally, at any distance and any contact state (arg4 is read only @0x0051638E, after the branch) — which is what retires AP-137's cell-less enqueue-vs-place delta. D1 — the classifier's cell-less input is now the PRE-merge committed cell. Retail's predicate is `this_1->cell == 0`, the BODY's own cell at MoveOrTeleport entry (this_1 is assigned from this @0x00516334). acdream fed the POST-merge canonical.FullCellId, which RefreshSnapshot -> RefreshDerivedState -> SetFullCell has already stamped with the accepted wire cell; a zero wire cell fails validation into RejectedData first. The shipped remote cell-less predicate was therefore dead code, not merely different from remotePlacementRequired. Threaded via a builder overload; route 1's overload is untouched. The graphical !IsSpatiallyVisible arm of projectionRequiresTeleportHook is deleted — a presentation predicate with no retail analogue that fired the teleport machinery on a routine hot path. Deleted: RemoteTeleportController (605), RemoteTeleportPlacement (85), RemoteShadowPlacementSynchronizer (49), their 1,709 lines of tests, the remotePlacementRequired predicate, the TeleportHookRequired plumbing, the legacy pre-operation ConstrainTo fallback, and the player arm's legacy !IsGrounded fallback. Net -2,030 lines. Structural fix (two independent Opus reviews, round 1 FAIL/FAIL): three of the four MAJORs were one defect — OnPosition carried two parallel inline copies of the routing tail (player-guid, NPC-guid) that had drifted. Extracted RunRemoteArmTail (3 call sites) and ApplyWireAirborneLeftoverBookkeeping (2), both branches now share one implementation. A1 ToConstraintArm mapped AirborneSnap -> AirborneNoOperation, so the NPC arm armed ConstrainTo ZERO times for an out-of-contact wire-grounded creature — a regression this slice introduced while closing a structurally identical hole. Now maps to NearInterpolate; switch made total with a throwing default proven unreachable. R1 D2's write-nothing shape existed on the player arm only; NPC packets fell through and wrote the body. Retail makes no player/NPC distinction. R2 report_collision_end(this,1) @0x00514F31 was bound to ShadowObjects.Suspend, a port of a DIFFERENT retail function (remove_shadows_from_cells) that teleport_hook never calls. Now routes to RuntimeCollisionReportingState.LeaveWorld, which wraps the private ForceEnd in an admission-blocking transaction so a DoCollisionEnd callback cannot recreate the contact table. R3/A2 A teleported NPC synthesized ServerVelocity from the teleport distance (~1,000+ m/s) and planned a run cycle from it. Both the install and RemoteServerControlledVelocityCycle.Apply now gate on !isTeleportRoute. BISECT HAZARD — A1's fix is correct only BECAUSE R1 landed. AirborneSnap is reachable wire-airborne on the NPC arm only while D2's shape is missing there. Reverting R1 alone silently inverts A1 into the opposite divergence: arming where retail returns 0. Revert both or neither. Also in the velocity hunk: the NPC block's two !IsPlayerGuid(update.Guid) guards were dropped when it was wrapped in `if (!isTeleportRoute)`. Safe — all five exit paths of the enclosing IsPlayerGuid block return, so the predicate is unconditionally false below it — but it was unremarked by both reviews. Register: AP-137 REWRITTEN (not deleted) to the surviving acdream-only divergences — null classification during the login window and Rejected* through UnroutedCatchUp keep a row. AD-42's RemoteTeleportController citation retired; AP-136/AP-138 writer lists corrected to the two surviving non-Position rebucket writers; AP-138 gains the teleport arm as a second producer of the visible-without-collision residual (retirement path remains #309). AP-135 is untouched and its two airborne bookkeeping writes are preserved on both arms. AP-131 does not retire; #276 does not close. Proof obligation 1: ParkCollisionResidents' overlap throw stays unreachable — the teleport arm adds packets to the same TryBeginExclusiveAuthoredPlacement one-operation-per-key machinery the far arm uses, opens no new operation shape, and every DeferredCell outcome cancels synchronously with restoreCancelledPark: true. The guarded property remains HasOldPrefixPlacementDebt's stall, not a throw (4b-1's B2 caveat stands). Correction to an earlier claim: LiveEntityPresentationController's _activePlacementOwners was NOT write-never at HEAD — remotePlacementRequired -> BeginPlacement -> Begin -> BeginAuthoritativePlacement was a live writer chain. It becomes write-never BECAUSE this slice deletes that chain, which is why deleting the dead half is behaviour-preserving. Probe: ACDREAM_PROBE_REMOTE_TELEPORT=1 emits one [remote-teleport] line per routed arm (guid, cause, hook-ran, placement status). TEMPORARY, strip with the probe family. Carried, disclosed not fixed: no dedicated bidirectional collision-partner test for R2 (the wiring, not LeaveWorld itself, is what lacks coverage); the stress test's teleport step drives hand-written field assignments rather than the canonical arm; the per-packet runTeleportHook closure allocation (network path, not the resolve path Slice I's 0 B discipline governs — file before route 5 adds a fourth call site). B2: IRuntimeCollisionReportObserver has zero production implementations, so retail's bidirectional DoCollisionEnd half still reaches no gameplay consumer — this fix closes the wrong-function binding, not that nobody listens. Complete Release suite MEASURED at 11,013 passed / 4 skipped / 0 failed (baseline 11,027/4/0; net -14 = ~33 deleted test cases against ~19 added). Neither known flake fired (#302 PortalProjectionTests GC-allocation, #308 NakEmissionTests wall-clock). STILL OWED: the two-client connected gate, which MUST use an NPC/creature teleport target. Both round-1 MAJORs lived on the NPC arm and the velocity cycle early-returns for 0x50xxxxxx guids, so a player target structurally cannot observe A1, A2, or R3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 16:00:10 +02:00
Erik	2eb39a0250	fix(physics): route remote Positions on contact, not walkability (AP-140) ... The two gates that decide whether an accepted remote Position is interpolated or hard-snapped read `Airborne`, which is `!Body.OnWalkable` — WALKABILITY. Retail reads CONTACT: InterpolationManager::adjust_offset @0x00555D30 gates its entire body on `transient_state & 1` @0x00555D52, so a retail body in contact with a non-walkable face still interpolates. The two predicates disagree in exactly one state — in contact, not on walkable ground — which 204d0ae0 turned from unreachable into ordinary. Before it, the per-tick forge made every non-airborne remote walkable by construction, so the disagreement could not occur. Both gates now read `!Body.InContact`: ApplyRemoteContactRouting's flight carve-out and OnPosition's player-remote arm. `Airborne` is deliberately NOT re-derived from CONTACT. That would perturb all five of its writers and contradict a pinned assertion in RemoteTeleportPlacementTests.Apply_PendingGroundToSteepContact_ (InContact: true, OnWalkable: false -> Assert.True(remote.Airborne)); a previous implementer attempted it and correctly backed out rather than editing the assertion. This narrower shape touches no existing test. AP-140's register row is retired in this commit, as the row itself specified. Honest scope: this is a faithfulness fix, not a visible one. ACE derives its IsGrounded flag with the same floor_z test, so during a slide it almost certainly reports not-grounded, the classifier returns NoPositionOperation, and neither arm is taken. Expect no observable change against ACE. Suite 11,027 passed / 4 skipped / 0 failed (baseline 11,023). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 11:53:48 +02:00
Erik	b1f914d508	fix(physics): restore presentation when a park is cancelled (#312) ... Regression from 7f1c1f5a (C4 route 4b-2). A remote player who recalled in, arrived, and stood still was permanently absent from the world render AND the radar while remaining fully simulated — 71 healthy physics ticks with contact and walkable, interpolation enqueues, equipment attached, chat visible. Route 4b-2 is the first commit that lets an ordinary remote UpdatePosition open a canonical SetPosition. A park publishes a synchronous Withdraw that tears down presentation registrations; only TryPublishPlace restores them. RestoreParkWithdrawal — added in the same slice — restores InWorld, the object clock, and canonical residency, i.e. the Runtime half only. Eight Opus reviews verified those three fields and the tests asserted exactly them, so the suite stayed green while the entity was invisible. Why it is intermittent: the presentation half IS restored incidentally by the per-packet prologue rebucket for a MOVING remote. It only sticks when the entity parks on its FINAL accepted Position and then goes idle, because ACE stops broadcasting for a stationary entity, so no later packet arrives to re-publish it and nothing else re-drives. The fix publishes a RuntimePlacementProjectionKind.WithdrawalRestored receipt on the one ordered placement stream, acknowledge-only in Runtime (the parked operation is already retired by CancelCoreDeferred), which the App sink maps to the exact inverse of its own TryPublishWithdrawal: the projection half (bucket, IsSpatiallyProjected, IsSpatiallyVisible, spatial indexes, RefreshPresentation) plus the publish half (_worldState, _worldEvents, _effectPoses, _localPlayerShadow, visibility sinks). Applied with commitPose: false, because the withdrawal never moved the sidecar; a test feeds a deliberately wrong position to pin that. Two alternatives were refuted on measurement, not preference. Routing the restore's SetFullCell through CommitCanonicalCell cannot fire on the shipped remote path at all — the prologue rebucket has already recommitted a non-zero FullCellId before the merge cancels the park, so no cell edge remains — and it never touches the publish half regardless. Extending RestoreParkWithdrawal directly reduces to the same receipt, since Runtime must not reach behind the host sink. Gated on the entity ending the rollback canonically whole (FullCellId != 0 && InWorld) rather than on residencyRestored, which is false on the shipped remote path and would have made the fix a no-op. AP-136's quiescing-prefix refusal arm is preserved: no receipt, entity stays withdrawn. Corrects my own framing of the defect: _worldState/_worldEvents/_effectPoses are lost but are NOT what kills render and radar (_worldState is the plugin IGameState; _effectPoses is the pose registry, not entity.MeshRefs). The load-bearing casualties are the visibility sinks and the IsSpatiallyProjected/IsSpatiallyVisible + bucket removal that gates the radar. Register: AD-63 filed (selection deliberately not restored — user intent), AP-136 amended (its "restored visible" claim covered only the canonical half; the gap was a defect, not a divergence). ShadowObjectRegistry.Suspend stays out of scope per AP-136. Seven-revert discrimination table including one that proves the test is not merely re-checking the bucket. Suite 11,023 passed / 4 skipped / 0 failed. Live gate is user-run and folds into #309: two clients, ACDREAM_PROBE_PARK=1, recall a remote in and let it stand still; acceptance is [park-restore] ... presentation=True for that guid plus a visible model and a radar blip. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 11:21:45 +02:00
Erik	7f1c1f5aa6	feat(physics): C4 route 4b-2 — remote far snap through the canonical placement ... Flips the SetPositionSimple classification (contact, PlayerDistance >= 96 m) for remotes onto 4b-1's drive controller and deletes both legacy far blocks, both duplicated 96f/4f constant pairs, and both `?? Vector3.Zero` fabrications. The 4 m constant now exists exactly once. Teleport and cell-less stay legacy for 4b-3. Retail: MoveOrTeleport @0x00516330's far branch runs StopInterpolating @0x005163CB before SetPositionSimple @0x005163D9 and returns 1 @0x005163E8 regardless — the SetPositionError is discarded — so HandleReceivedPosition arms ConstrainTo @0x00454272 post-move on commit AND on failure. The x87 parity decode at @0x00516393-@0x0051639E puts exactly 96.0 on the far branch. SetPositionSimple @0x005162B0 builds flags 0x1012 at @0x005162C4. Non-commit outcomes still advance the body, because retail's SetPositionInternal @0x00515BD0 commits the destination via store_position @0x00515CE2 when no cell resolves. The partition is by STAGE, not heuristic, enforced by an exhaustive switch: Refused/Contention/NotApplicable/RejectedPreparation store (the placement never executed); Committed/Deferred/RejectedByPlacement do not (the engine ran and refused, matching retail's non-storing returns @0x00515CB2 and @0x00515CD5). Without this a refused far snap froze the remote with an emptied queue. Also fixes a shipped defect this route made live: ParkDeferred's quiescence parks withdrew the entity (InWorld=false, clock suspended, residency removed) and were never restorable, while Forget(restoreCancelledPark: true) runs for every accepted Position on every entity. The restorable decision now lives inside ParkDeferred AFTER SnapToCell, reading body.CellPosition.ObjCellId — the value RestoreParkWithdrawal actually restores at — against every live quiescence rather than one minimum-OperationId token. The three pre-snap fields are hoisted into locals because SnapToCell ends with InWorld = true. ParkCollisionResidents passes restorableOnCancel: false explicitly; the plain unplaceable park is provably unchanged. RestoreParkWithdrawal re-tests the prefix at restore time so a retained route-2 park cannot re-admit into a prefix that began quiescing during the park. CanAttemptDestination is retained as an OPTIMISATION only, with the two Core predicates it cannot reproduce written down at the pre-flight, plus the two properties that depend on it staying there. Four fix rounds and eight Opus reviews. The slice was fully green at 10,990, 10,997 and 11,004 while containing real defects — a frozen remote pinned as correct by its own test, a fallback that over-wrote on the exact retail paths that decline to store, and a park guard incomplete on two independent axes. Register: AP-137 (leftover classifications take AP-87's catch-up; states the cell-less enqueue-vs-place delta deferred to 4b-3, that RejectedData is applied anyway, and the headless divergence), AP-138 (the refusable far placement), AP-136 narrowed to match the relocation. #309's acceptance steps rewritten — step 5 previously asserted a recovery the code does not perform — and gated on a new ACDREAM_PROBE_PARK=1 signal so the check cannot pass while broken. Suite 11,009 passed / 4 skipped / 0 failed against a measured 10,968 baseline. The 10,973 figure recorded earlier was wrong and is corrected here. Connected gate outstanding: the two-client far-snap walk and #309. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 07:55:56 +02:00
Erik	2e8e09acd0	feat(physics): C4 route 4b-1 — remote placement infrastructure (dormant) ... Builds the machinery route 4b-2 and 4b-3 will flip on, and changes no remote behaviour: it has no production caller, so RemotePlacementDrivePendingCount is provably 0 and IsConverged is unchanged. Five pieces: a per-entity remote placement owner (RuntimeRemotePlacementDriveController), a Position-time service-window guard with a Runtime interface plus BOTH host implementations, N3's headless RetryPending pump, parked-count observability in the ownership ledger, and the service-window optimisation that avoids parks we can cheaply predict. Landed alone because it is where the park-withdraws-the-entity failure was decided; that decision is fixed at the source in the preceding commit and must not share a review signal with a behaviour flip. Two parts of route 2's controller are deliberately NOT ported, both verified against retail rather than assumed. There is no ack: SendPositionEvent is called only inside HandleReceivedPosition's local-player FORCE_POSITION gate @0x0045400C-@0x00454091, and the remote arm @0x0045414D has no equivalent. There is no re-issue funnel: retail never re-attempts a position it could not apply — stale timestamps merely bump error_count @0x004542AC — and re-issuing packet N after N+1 has merged would apply a pose the newer packet already superseded, which is correct for a one-shot ForcePosition and wrong for a 5-10 Hz stream. The service-window guard is an OPTIMISATION, not the correctness mechanism. The original contract had it the other way round, justified by a claim that retail cannot represent "arrived but not placeable" — false, and corrected in the review findings: retail's GotoLostCell/reenter_visibility path represents it exactly. A pre-flight guard also cannot be complete, because Core defers on the entity's CURRENT cell, on the swept QueriedCellIds footprint spanning neighbouring landblocks, and on residency evaluated after AdjustToOutside — conditions only Core can see. Review found and this commit fixes: DetachRoute cleared two maps of LIVE Core operations without cancelling them (route 2's AbandonPending is the correct mirror, not the first-entry controller) and its test asserted that blindness as convergence; the headless predicate answered "can ever publish" rather than "is published", and after the first fix still matched only 1 of the 9 landblocks this host publishes; OwnsPlacement admitted remote top-level Creates until gated on the Teleport flag as well as the disposition; Advance re-submitted without re-checking the window; and four comments cited a report that did not exist. Contract item 6 is met by the structural proof, not the earlier test: HasOldPrefixPlacementDebt refuses collision-prefix mutation permission before ParkCollisionResidents is ever entered, so its overlap throw is unreachable. That same mechanism is the unbounded stall filed as #310, which 4b-1 does not bound — it only avoids widening it. #311 files the remaining per-tick allocation in RetryPendingProjections; the early-out for the empty-FIFO case landed via a new HasPendingReceipts accessor so hosts still never touch .Placements. directly. Gates: complete Release solution 10,973 passed / 4 skipped / 0 failed (baseline 10,938). Four review rounds; every fix discrimination-verified by revert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 04:08:19 +02:00
Erik	44830a0eb3	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>	2026-08-04 00:19:05 +02:00
Erik	bc0077a55f	fix(combat): #298 — admit player targets to melee/missile attack and the camera ... Selecting a PKLite player and attacking did nothing: with auto-target on it retargeted to the nearest monster, with auto-target off it logged "combat: attack ignored; no creature target found". Spells on the same target worked, which was the clue. Root cause: CombatTargetPolicy.IsHostileMonster:31-33 rejects any candidate carrying BfPlayer BEFORE reaching ObjectIsAttackable, so the both-PKLite pool match at SelectedObjectHealthPolicy.cs:70-71 was unreachable for players. Melee and missile targeting never supported player targets at all — the gate is named IsHostileMonster and does exactly what it says. Nobody could hit it until 69ba9486 made PK Lite reachable. Retail uses ONE predicate for monsters and players, with no player exclusion: ClientCombatSystem::ExecuteAttack @0x0056BB70 gates unconditionally on ObjectIsAttackable @0x0056A600 (creature type, Free-PK short-circuit on either side, then IsPlayer -> bothPK || bothPKLite, else BF_ATTACKABLE with pets excluded). acdream already ported that predicate verbatim; it was simply unreachable. The fix SPLITS the two concerns rather than relaxing the shared predicate: explicit-target admission routes through ObjectIsAttackable, while auto-target ACQUISITION keeps the monster-only gate. That is required by register row IA-19 — explicit product direction that Auto Target must never select NPCs, players or pets. IA-19 is not overridden here; its own justification promises "manual player-selection commands remain available", and that promise was never implemented, so this makes the row true. Review confirmed no path lets auto-acquisition select a player: every automatic Select is fed by a FindClosest* filtered through IsHostileMonster. Review also found a second site with the same bug, which the first pass froze in place on my instruction: retail gates combat-camera tracking on the SAME predicate as the attack. ClientCombatSystem::UpdateTargetTracking @0x0056A950 reads GetAttackTarget() then gates CameraSet::TrackTarget on ObjectIsAttackable. Ours used the monster-only gate, so with ViewCombatTarget on by default the attack would land while the camera refused to track the opponent — user-visible in exactly the duel this fix enables. GetCombatCameraTargetPoint now uses the wide predicate. IA-19 does not reach the camera: it performs no acquisition, only presentation on an already-chosen target. The first pass had added a source comment asserting IA-19 covered it; that comment and the matching text in docs/ISSUES.md are corrected, since a wrong citation is how a real divergence becomes invisible. Depends on 9b1e6fc6 (#297): the both-PKLite arm needs the LOCAL player's own bit to be live. Review confirmed both admission sites read ClientObjectTable on every call, so this is not inert in production. Newly reachable and now pinned: ObjectIsAttackable's pet-exclusion arm, which CombatTargetPolicy rejected before it could ever run. Follow-ups filed: #304 (SelectionInteractionController.GetSelectedOrClosestCombatTarget has no production caller — one of the two widened call sites is dead code), #305 (HeadlessGameplayOperations has the identical pre-existing bug, so the graphical/headless hosts now diverge). Gates: complete Release solution 10,904 passed / 4 skipped / 0 failed (baseline 10,900). Adversarial + retail-conformance review PASS after one FAIL round; the predicate was re-verified branch-for-branch against 0x0056A600 since it goes live here for the first time. Camera fix discrimination-verified by revert. Connected acceptance NOT run — needs a live two-client PKLite session. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 21:29:15 +02:00
Erik	9b1e6fc637	fix(physics): #297 — keep the PWD bitfield live so PK status reaches the client ... The user typed @pklite and then walked straight through other PKLite players. Root cause: ClientObject.PublicWeenieBitfield was written exactly once, from the 0xF745 CreateObject parse, and never refreshed. ACE's only PK-change message is PropertyInt.PlayerKillerStatus (134) over 0x02CE/0x02CD, which we parsed and stored into Properties.Ints[134] but never translated back into the bitfield — and ACE never re-sends a PublicWeenieDesc at all (EnqueueBroadcastUpdateObject has zero live callers), so that property is the ONLY signal a client can learn from. Both sides of the collision test read the frozen value, so CollisionExemption's "4c. both PKLite -> collide" rule could never fire. Retail's missing port: PublicWeenieDesc::SetPlayerKillerStatus @0x005AC7C0 rewrites _bitfield in place — PK(4) -> (b & 0xfddfffff) | 0x20; PKLite(0x40) -> (b & 0xffdfffdf) | 0x2000000; Free(0x20) -> (b & 0xfdffffdf) | 0x200000; else b &= 0xfddfffdf. Mutually exclusive, verified byte-for-byte, with input values confirmed against retail's own PKStatusEnum (acclient.h:6412-6427), not just ACE's. Driven from ACCWeenieObject::OnStatUpdated @0x0058DF20 case 0x86. The fix rewrites the value at its source rather than patching consumers. Two review rounds were needed because the first pass missed that there are TWO snapshot stores: InboundPhysicsStateController keeps its own private _snapshots dictionary, and every untimestamped-field merge (ApplyAcceptedObjDesc and friends) reads `old` from THAT store, not from RuntimeEntityRecord.Snapshot. Refreshing only the active record left the target-side shadow flags correct until the remote's next equip or unequip — ACE broadcasts an ObjDesc on every one — at which point the appearance path rebuilt the registration from the frozen spawn and dropped the bit permanently. The regression test demanded by review is what surfaced that; it is verified discriminating (reverting gives Actual: 8 instead of 33554440). Five stores now hold this value, kept coherent from one source by two ObjectUpdated subscribers plus the appearance-rebuild path. The two shadow-flag writers are the same invalidation applied at the two edges that can invalidate it, not competing authorities — review enumerated every drift path and closed each. That coherence invariant is new as of this commit and is recorded as register row AP-134, with AP-133 as the precedent for filing a row when the danger is a future writer rather than current behaviour. Also corrects TS-23's retirement narrative, which claimed every mover-flags call site read the mover's "real" PK bits from 2026-07-30. The bits existed but their source was frozen, so that only became true here; the site enumeration also missed RuntimeSetPositionMoverPreparation, a seventh site that decodes the snapshot directly. Unblocks #298 (melee/missile admission needs the local player's own PKLite bit). Follow-ups filed: #300 (Properties.Ints[134] vs bitfield mirror gap), #301 (same defect class for radar blip colour and radar behaviour), #302 (a pre-existing PortalProjection allocation-assertion flake, 1 in 6, found while verifying this gate), #303 (LiveEntityPvpBitfieldSync is App-resident but Runtime-owned-state). Gates: complete Release solution 10,895 passed / 4 skipped / 0 failed (baseline 10,887 including #299). Adversarial + retail-conformance review PASS after one FAIL round. Every new test discrimination-verified by reverting the fix. Connected acceptance NOT run — needs a live two-client PKLite session. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 20:59:01 +02:00
Erik	69ba9486b6	feat(chat): port retail's @pklite client command (EnterPkLite 0x028F) ... acdream never implemented @pklite. It is a CLIENT command in retail, not a server one — ACE has no pklite text-command handler — so typing it forwarded as inert chat text that the server ignored. Retail: ClientCommunicationSystem::DoPKLite @0x0057A490 rejects with WeenieError 0x507 when ACCWeenieObject::IsPlayerKiller @0x0058C910 is true (that returns true when EITHER the PK bit 0x20 OR the PKLite bit 0x2000000 is set), prints "Please see @help pklite for more..." and sends nothing if given any argument text, and otherwise calls CM_Character::Event_EnterPKLite @0x006A13F0 — a bare 12-byte parameterless game action, opcode 0x28F, the same shape as Event_LoginCompleteNotification beside it. Verb string at 0x007E16B0, help text at 0x007DF0C8, failure string at 0x007D31E8; one verb, no alias. HasPlayerFlag is a tri-state (null = the local PublicWeenieDesc has not arrived). The existing arena gates compare `== false` because they reject on a known-FALSE flag; retail's DoPKLite gates the other way, rejecting on known-TRUE. So this case compares `== true` on either bit: an indeterminate description sends rather than blocks, which matches retail trusting the server instead of inventing a client-side suppression rule. Landed as its own commit because it is retail-faithful on its own merits, but the motivation is C4 route 2: ACE advances SequenceType.ObjectForcePosition in exactly two places, and the only reachable one is Player.HandleActionEnterPkLite's entry-collision bump (allow_pkl_bump, default on). Every admin teleport advances ObjectTeleport instead, so @teleto-style displacement exercises route 3, not route 2. Without this command route 2 has no connected acceptance gate at all. Gates: complete Release solution 10,867 passed / 4 skipped / 0 failed (9966b531 baseline 10,858/4/0; +9 = the 9 tests added). Coverage includes both known-true rejections, the known-false success case, the tri-state unknown case, the 12-byte wire envelope, and @pklite resolving as ClientHandled rather than falling through to the server-text path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 18:57:17 +02:00
Erik	9966b53174	feat(physics): C4 route 2 — ForcePosition through the canonical placement ... A local-player ForcePosition had TWO independent writers for one accepted packet: LocalForcePositionTransaction snapped the physics body (PlayerMovementController.BlipPosition, a raw SnapToCell with no collision resolve), while LiveEntityNetworkUpdateController's generic tail separately wrote position/cell/rotation to the render WorldEntity from the raw wire and rebucketed it. Two stores, one packet — the divergence class 670f307c fixed on the remote path. The outbound AutonomousPosition ack also fired BEFORE any canonical commit existed: we told ACE "got it, I'm here" before deciding where "here" was, and the trailing isCurrent() could only suppress the continuation, never recall the packet. RuntimeAcceptedPositionDriveController is now the one Runtime-owned seam. Both hosts call the identical TryExecuteAcceptedLocalPosition; App and headless project the committed result through the existing placement projection sink (LiveEntityRuntime.TryApplyRuntimePlacementPlace already performed the same four writes, from committed state rather than a wire guess). Retail: SmartBox::HandleReceivedPosition @0x00453FD0's FORCE_POSITION branch is get_heading -> Frame::set_heading -> SmartBox::BlipPlayer @0x00453940 -> stamp POSITION_TS -> SendPositionEvent @0x00454091 -> return @0x0045409D. BlipPlayer is CPhysicsObj::SetPositionSimple @0x005162B0 with flags 0x1012 (Teleport|Slide|SendPositionEvent) — a real collision-resolving SetPosition, not a snap. The pinned classifier already encoded this exactly. Named behaviour changes: * The ack is now an OUTPUT of the committed route, fired strictly after the canonical commit and exactly once per accepted force packet. * The ForcePosition route no longer re-arms the constraint leash. The force branch returns at 0x0045409D, ahead of all three ConstrainTo sites (0x00454272, 0x0045418A, 0x004541EC); the old re-arm cited retail's "Player, normal" branch, which BlipPlayer is not on. The teleport, CommitPreparedPosition and first-entry callers legitimately still constrain and are untouched. * A force correction that terminates WITHOUT committing still sends its position event and is not retried — retail's BlipPlayer discards SetPositionSimple's SetPositionError return and acks unconditionally. A single _pending funnel owns the in-flight placement, deciding on the token's PositionAuthorityVersion against the record's: equal -> clear; advanced with the newest accepted event still a force -> re-issue, re-classified; advanced to an ordinary Apply -> clear, since newer server truth owns that pose. This closes a double-apply/double-ack and a silently-dropped correction that two earlier iterations of this slice each introduced. AD-62 records the residual: a ForcePosition our async collision publication cannot carry to a committed placement is not re-applied. Retail has no park — its world is fully resident and its placement synchronous — so the state is unreachable there. AP-131 is NOT retired; its legacy Position caller is route 4. Deleted: LocalForcePositionTransaction, PlayerMovementController.BlipPosition, HeadlessSessionWorldProjection.BlipLocalPlayer. Gates: complete Release solution 10,858 passed / 4 skipped / 0 failed (baseline 10,844/4/0). Two independent Opus reviews (retail-conformance and architecture/adversarial) PASS on the final diff after three FAIL rounds; every intermediate state was fully green, so the suite caught none of the four real defects. Connected acceptance is NOT run: nothing a user can do makes ACE emit a ForcePosition without retail's @pklite, which acdream does not implement — see docs/research/2026-08-03-c4-route-2-visual-gate.md. Known gap, recorded not claimed: the plan's acceptance item 2 is unmet. The App double-write check is a source pin, and "the committed projection moves the render entity" is uncovered at any layer (#292). Filed alongside: #286-#291, #293-#296. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 18:46:36 +02:00
Erik	89cf1e66d0	fix(physics): guard the world-frame agreement proven unreachable by measurement ... Closes #283 (plan S3) - as UNREACHABLE, not by restructuring ownership. acdream has two owners that convert a landblock-local network origin into the streamed world frame: LiveWorldOriginState for presentation/streaming, and RuntimePhysicsState.TryGetWorldFrameOffset for placement. They rebase on different edges - Runtime the instant an accepted Position carries TeleportAdvanced, App only once StreamingOriginRecenterCoordinator observes old-window retirement completion, many frames later. A one-landblock disagreement places an entity 192 m from the geometry around it: the same failure family as the zero-offset bug 670f307c fixed, with a wrong origin instead of a missing one. The plan's first step was to prove or disprove reachability BEFORE moving ownership, because a restructure on a hypothesis is churn. The probe added in 898ff18b answered it: a connected Release session recorded ZERO disagreements across 11 completed reveals and six destination landblocks (0x0904, 0x1134, 0x3032, 0x8763, 0xA9B4, 0xF682) spanning roughly 45 km. A gap of even one frame would have printed an offset in the tens of thousands of metres. Cause of the safety: BeginOriginRecenter detaches EVERY resident landblock before the new origin is adopted, so the two rebases are serialized and no conversion can observe the gap. Ownership is therefore left exactly as it is. What lands instead is the invariant that keeps it true. LiveWorldOriginState.EnsureAgreesWithRuntimeFrame is checked at the landblock->world conversion and is terminal on disagreement, converting a silent 192 m-multiple misplacement into a loud failure with the offset in metres and the landblock being projected. Six focused tests pin it, including the cross-world portal case (0x09 -> 0xF6 = 45,504 m). Disagreement can no longer reach the probe, so ACDREAM_PROBE_WORLD_FRAME now emits a verbose per-conversion agreement trace - useful when a placement looks displaced for some reason OTHER than a frame disagreement. Complete Release solution: 10,844 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 14:33:46 +02:00
Erik	3c36b4cc21	fix(vfx): resolve an entity's cell through one owner so effects follow it ... Fixes #282 (plan S2). Adds register row AP-133. Retail gives a CPhysicsObj exactly ONE cell: ShouldDrawParticles @0x0050fe60 reads this->cell and calls IsInView on it, and set_cell_id @0x0050f4f0 / change_cell @0x00513390 are the only things that move it. acdream splits that into ParentCellId (render parent, deliberately null for outdoor dat stabs) and EffectCellId (the authored landcell those parentless stabs still need) - an adaptation, now recorded as AP-133. WorldEntity.EffectCellId documents itself as the stab field, with live and interior entities using ParentCellId. f24532ad began writing it for live entities too. Because EntityEffectPoseRegistry resolved EffectCellId FIRST, that write won - and the audit shows only 3 of 14 cell writers maintain it. The other 11 do not, including the hottest paths: RemotePhysicsUpdater:239,294 and LiveEntityOrdinaryPhysicsUpdater:107 write ParentCellId every physics tick from the snapshot, and LocalPlayerProjectionController:79 writes the local player's cell every frame. So a moving entity updated its cell constantly while EffectCellId stayed frozen at whatever cell it materialized in. Its particles and lights kept being tested against that stale cell and failed IsInView the moment it crossed a boundary - effects vanishing on a monster that is plainly visible, or drawing through a wall from a room the viewer cannot see. The consumers had also drifted into disagreeing: EntityEffectPoseRegistry preferred EffectCellId while WbDrawDispatcher.TryGetEntityCell and the remote spawn seed preferred ParentCellId - two answers to "which cell is this in". - WorldEntity.VisibilityCellId (ParentCellId ?? EffectCellId) is the single accessor; all five consumer sites resolve through it, so the precedence cannot drift apart again. - LiveEntityRuntime's three live-entity EffectCellId writes are removed, restoring the field to its documented purpose. Its real writers - LandblockLoader:80,97 and LandblockBuildFactory:408 - are untouched, and the parentless-stab path is pinned by a new test. - f24532ad's actual fix is preserved: RebucketLiveEntity still installs the committed cell, just on the one field live entities use. LiveEntityLightControllerTests.Refresh_FollowsCurrentTopLevelRootAndCell is back to moving the entity by ParentCellId alone - its original pre-f24532ad form - and passes. CanonicalOnlyRebucket_DoesNotOverwriteAuthoritativeFullCell had its two EffectCellId assertions (added by f24532ad, encoding the defect) replaced with the corrected contract: ParentCellId set, EffectCellId null, VisibilityCellId resolving - a stronger assertion, not a relaxed one. Complete Release solution: 10,836 passed / 4 skipped / 0 failed. User visual check still outstanding: a monster with an active spell effect crossing a cell boundary, and a lit static object, indoors and outdoors. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 14:02:03 +02:00
Erik	98e9f9e8c6	test(vfx): model the post-f24532ad effect cell and canonical body frame ... f24532ad changed two presentation contracts that these fixtures still expressed in their pre-change shape. Both failures date exactly to that commit; they are independent of the world-frame family fixed in 6dcb94ac. LiveEntityLightControllerTests.Refresh_FollowsCurrentTopLevelRootAndCell moved the entity by writing ParentCellId alone. f24532ad now populates EffectCellId at materialization and keeps it synchronized on canonical rebuckets (LiveEntityRuntime.RebucketLiveEntity:845-856), because retail's CPhysicsObj::set_cell changes the one CObjCell that ShouldDrawParticles reads. EntityEffectPoseRegistry.UpdateRoot:163 resolves EffectCellId ?? ParentCellId, so a production cell move writes both together and the old single-field move left effects and lights on the stale materialization cell. LiveEntityAnimationSchedulerTests.RetainedProjectileWithRemote_WhenMissileClears_TransfersMovementToRemoteOnce seeded its shared remote body by assigning Position directly. Projectile classification now validates and adopts the canonical body's own cell frame (ProjectileController:184-190 - body.CellPosition.ObjCellId / .Frame.Origin) rather than deriving it from the sidecar's FullCellId and the streaming center, since a residence-managed Create legitimately still reports FullCellId 0. A Runtime-committed body always carries its (cell, local) frame, so the fixture now seeds it through the same SnapToCell placement API; leaving it cell-less was correctly refused. Both fixtures keep their original assertions - only the modelled world state moved to match what production now commits. Complete Release solution: 10,831 passed / 4 skipped / 0 failed (App 4,048/3, Bake 15, Cli 4, Content 124, Core.Net 762, Core 4,247/1, Headless 79, Runtime 1,009, UI 543). Closes #281. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 13:32:46 +02:00
Erik	6dcb94ac1b	test(runtime): restore the world-frame precondition across first-entry fixtures ... 670f307c made remote first-entry placement resolve its landblock-local CreateObject origin through Runtime's world frame (RuntimeSetPositionState.PrepareMover:1526-1544) and return RetrySetupUnavailable until that frame exists. Only the accepted local-player Create publishes it (RuntimeEntityObjectLifetime.RegisterEntityCore:558-570 -> RuntimePhysicsState.ObserveLocalWorldFrame). Fixtures that drive remote conductors in a world with no local player - a state production never occupies, since the player's own Create always precedes broadcast Creates - therefore parked forever on RetrySetupUnavailable. Their initial-create residences never retired, which cascaded into rejected appearance updates, missing canonical bodies, unconverged ownership ledgers, and a GameRuntime teardown that could not complete stage 10. The measured blast radius was far larger than the handoff recorded. It claimed "six selected fixture failures"; a baseline run found 43. The App suite was fully green at 01f4791e and 670f307c broke 28 tests at once; the Runtime suite lost 13, twelve of them in RuntimeRemoteFirstEntryStateTests - the exact conductor that commit gated. Both commits were verified on focused runs only. The production gate is correct, so nothing here weakens it. It matches App's own coordinate owner: LiveWorldOriginState is initialized once from the local player's spawn (LiveEntityHydrationPorts.cs:226) and rebased only by StreamingOriginRecenterCoordinator.Advance at a teleport boundary - exactly ObserveLocalWorldFrame's semantics. Every fixture is repaired by supplying the missing precondition beside the resident landblock it already models, and not one expected value or assertion was changed. The mechanism shipped with zero tests. RuntimeWorldFrameTests now pins its contract: the local player publishes the frame, remotes never do, neighbouring landblocks convert at 192 m per step, ordinary movement across a landblock boundary must NOT rebase it, an accepted teleport must, and a zero cell id neither publishes nor resolves. That "no rebase on ordinary movement" rule is load-bearing - if it and LiveWorldOriginState ever disagree, remote objects are placed a multiple of 192 m from where the world is streamed. Runtime 1,009/1,009; App 4,048 passed / 3 skipped. Refs #281. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 13:32:28 +02:00
Erik	f24532adf3	fix(vfx): bind effects after canonical placement ... C3c created graphical effect, projectile, and static-animation sidecars before Runtime finished the entity's first SetPosition. One-shot F754/F755 packets could be discarded, projectiles could adopt a cell-less body, and animated statics could compete for body ownership. Keep effects behind an exact-incarnation presentation barrier, retry projectile/static binding on the committed visibility edge, and keep effect cells synchronized with canonical rebuckets. User verified spell, recall, arrow, projectile, portal, and static presentation; 90 focused App tests and the Release build pass.	2026-08-03 12:10:21 +02:00
Erik	1fc529cdcb	fix(interaction): restore distant use after runtime cutover ... Runtime GetObjectA lookup became intentionally non-constructing, so static doors and corpses entered MoveToObject without a physics host and their target snapshot timed out at the origin. Ensure the canonical minimal host exists before routing the server move. Runtime first-entry also grounds the local player before graphical PartArray attachment. That could leave an unmatched startup CMotionInterp node ahead of all later use and cast motion. Drain matched PartArray entries first, then retire only the impossible pre-attach suffix at the presentation attach boundary. Add focused regressions for static-target host materialization and attach-order reconciliation. User verified near and distant object use in the connected client; focused App tests pass 3/3.	2026-08-03 09:36:53 +02:00
Erik	01f4791e95	fix(streaming): stop replaying committed recenter retirements ... Root cause: pending-only live projection buckets were misclassified as landblock presentation owners during origin recentering. That manufactured a second full cleanup receipt for a generation whose first receipt was still advancing; the duplicate guard threw and the broad retry path replayed the already-committed detach 243 times. Keep pending live projections through the spatial identity map without issuing another receipt, and fail fast when a receipt-ledger invariant occurs after detachment. Evidence: docs/research/2026-08-02-collision-throughput-handoff/p1-retirement-receipt-loop.md. Release suite, lifecycle gate, and nine-stop soak pass.	2026-08-02 20:53:11 +02:00
Erik	529e0e9d88	feat(runtime): C3c - production placement cutover: both hosts on the residence conductors (routes 1+8) ... Campaign P remaining-physics-divergence, placement cutover slice C3c (docs/plans/2026-08-02-placement-cutover.md). Both production hosts now register every initial Create through the residence + continuation- executor + first-entry-conductor machinery (C0-C3b): - Graphical (route 1): RegisterEntityWithInitialResidence at Create; the shared RuntimeFirstEntryDriveController pumps both conductors from the placement-receipt flow; MaterializeProjection and RebucketLiveEntity are presentation-only while a residence is ACTIVE (ExecutorCompleted is the presentation-binding receipt); post-residence entities take the full legacy path including the prepare_to_enter_world clock edges. PlayerModeController attaches presentation to the Runtime-published controller; its legacy resolve/step-heights/host-construction path is deleted; presentation-only rollback (retail has no entry-flow rollback). - Headless (route 8): OnSpawned registers with residence when a drive exists; content-less sessions keep the pre-flip direct registration; SynchronizeLocalPlayer/CreateController/ApplySetupStepHeights deleted; prepared-collision read failure is a typed AwaitingCollisionSource retry; far remotes outside the service window complete celless. - RuntimeLocalPlayerMovementState.Controller setter sealed internal; all controller mutation flows through the publication lifecycle. Fix slices landed within this cutover, each dual-gated: - F1: live movement-stat/server-physics application routed through the Runtime ownership seam (post-logout ingest crash on the retired controller eliminated; RuntimeMovementSkillProjection deleted). - F2: login activation wedge - collision-admission prefix gate factored out of the seal (reentrant-commit RejectedAuthority), rearm generation identity corrected, PlayerModeAutoEntry requires the Runtime-published controller (world reveal can no longer seal unmaterialized). - F3: landblock-prefix 0-sentinel replaced by explicit absent-id guards; map-corner landblocks (grid row/col 0) fully legal through admission, park/rearm/retire, quiescence, and outdoor shadow seeds. - F5: local-player first-entry ground contact seeded by the shared SpawnPlacementSettler (moved App->Core) at FinalizeActivation - the retail first-gravity-frame touch (enter_world 0x00516170 carries no seed); the legacy unconditional force-seed is overwritten by a real floor-found contact; airborne spawns stay airborne; outbound contact bit verified end-to-end. Fixes the standing-cast 'You can't do that while in the air!' rejections. - R1 (dual-review round): login constraint leash armed at the committed placement (HandleReceivedPosition 0x00453FD0 analog); register rows AD-61 (settle-timing compression now covering the local player) and AD-42 (repointed off the deleted resolve split) in this commit; residence-conversion owner API; wire-landblock guards; drive-pending ledger in IsConverged; route attach/detach latch; executor-drain drift model documented + source-pinned. Gates: Runtime 1,003, App 4,039/3 skips, Headless 79, complete solution 10,816/0 failed/4 skips (Release, -m:1); connected lifecycle/reconnect gate PASS (logs/connected-world-gate-20260802-175401; graceful exits, world-visible, zero airborne rejections). The nine-stop soak remains red for the pre-existing 6b28ff99 whole-world collision-clone throughput regression (attributed with evidence; scheduled as its own slice before C5). Dual Opus reviews (retail-conformance + adversarial): delta PASS. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 18:10:33 +02:00
Erik	67f63e85e5	feat(runtime): bridge executor completion to the placement stream ... Cutover slice C0 (docs/plans/2026-08-02-placement-cutover.md): the seam work that lets C3 flip hosts onto a complete receipt stream instead of growing one mid-cutover. The executor's Released exit now publishes an acknowledge-only ExecutorCompleted receipt through the one placement projection stream — registered before observer dispatch, correlated to the full execution receipt, reaped exactly once on acknowledgement/ discard/session-clear, and counted in the convergence ledger. All three production placement sinks acknowledge-and-ignore the new kind via early returns proven behavior-preserving for every existing kind; without them the first such receipt at cutover would permanently wedge the exact-head FIFO behind sinks that return false. Provably inert today: the publisher has no production caller. Execute's live inputs now derive from Runtime's own owners bound at GameRuntime construction: UsePositionFromServer is retail's exact autonomy_level != 2 (CommandInterpreter::UsePositionFromServer 0x006B3B40, startup-only knob), and PlayerDistance uses the live movement controller's position with a null-safe fallback to the caller struct — never a fabricated origin. TryPrepareAndSubmitAuthoredPlacement chains the prepared-collision Setup read through PrepareMover to submission with zero validation-semantics changes. TryCommitParent and CommitWithdrawal gain the sibling cancellation flow (residence + ordinary placement family); TryCommitParent deliberately omits LeaveWorld — retail's set_parent performs its single gated leave_world (0x00515A90) and a second would have no counterpart. Not fully dormant: the two cancellation fixes change Runtime paths production already calls (today as no-op-adjacent hardening, since nothing upstream begins a residence yet); everything else is reachable only by tests. Reviewed: retail-conformance PASS + architecture/ adversarial PASS after one fix round (sink wedge, completion-receipt lifecycle, null-controller distance). Runtime 921/921; complete Release solution 10,716 passed / 4 intentional skips. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 05:22:37 +02:00
Erik	74103f75b5	feat(app): stage live entities before runtime placement	2026-08-01 18:43:23 +02:00
Erik	9b0f59bd1b	feat(runtime): atomically replace collision generations	2026-08-01 17:33:34 +02:00
Erik	f05ed5c3cd	feat(app): observe canonical placement receipts	2026-08-01 15:22:52 +02:00
Erik	378ca95a67	feat(headless): observe canonical placement receipts	2026-08-01 15:10:03 +02:00