2096 commits

Author	SHA1	Message	Date
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	b3e43d22c9	fix(physics): S1B — indoor cell membership admits on the part BOX, as retail does (#335, AP-159 narrowed) ... CellTransit.FindTransitCellsBox ports CEnvCell::find_transit_cells' part-array overload @0x0052cae0 line-for-line: per-portal x per-part order, the sphere cheap-reject at F_EPSILON+radius, the box admit whose "Straddle or crossing-side" rule is exactly retail's `eax != side` under the PDB Sidedness enum, leads-outside placed AFTER the admit, the unconditional unloaded-neighbour hint without the sphere overload's re-test, the destination box_intersects_cell gate with its deliberate no-break, and add_all_outside_cells after the loop. The box-vs-cell BSP traversal lands in BOTH representations behind the flat-authoritative dispatcher with a graph referee whose 20,000 installed comparisons are pinned by assertion (review F5), zero mismatch. Dual Opus review: PASS on both lenses. The mandatory D0 pseudocode pass caught that the contract's own supplementary note misattributed the box block to the sphere overload — it belongs to a SECOND check_building_transit overload @0x0052c680, whose portal-side convention is INVERTED and whose admit differs; the pseudocode doc now records that trap plus two byte confirmations made at review: which_side @0x00444720 is strictly > eps for POSITIVE, and intersect_box's in-plane early exit returns CROSSING(3) (jp @0x005aa1bc -> mov eax,3), settling review items b1/b2 for the future bridge porter. The bridge itself stays unported as AP-159's explicit remainder. The review also retired #335's severity premise honestly: "over- inclusive only, never a missed one" is wrong at production shape ratios, where the box (whole-vertex AABB) legitimately exceeds the sphere (physics-polygon root sphere). Measured, both populations: rigged (box << sphere) — 1,520 placements, 978 cells removed, 0 added; production-ratio (box >= sphere) — 950 placements, 20 removed, 1 ADDED through the loaded-neighbour gate, which is retail's direction, not a defect. The no-op guard (review F4) asserts removal is nonzero so an unwired admit cannot pass silently. Process note: the implementer authored against this session's worktree at bec5c69d, 25 commits stale — the recorded worktree-base class. All six files were byte-identical between bases, the diff transplanted losslessly, and every verdict-bearing run (referee, direction sweeps, this clean-room) was re-executed on current main. S2's uncommitted phase-1 edits were stashed for this landing so the suite verdicts exactly one changeset. Also untracks 341-slope-capture.jsonl (an accidental add) and gitignores it. Clean-room suite: 11,248 passed / 6 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 07:46:57 +02:00
Erik	d73125d3b0	fix(physics): S4/AD-65 — the away-from-plane response snaps to the surface, as retail does ... Campaign S slice S4, the half that landed. Retail's CTransition:: adjust_offset @0x0050a370 branches on dot(offset, contactPlane.N) at 0x0050a4fa: moving INTO the plane subtracts the normal component (0x0050a529), moving AWAY calls Plane::snap_to_plane @0x00509c50 — which preserves X and Y and re-solves ONLY Z so the offset lies in the plane (the d terms cancel algebraically), no-op under the 0.000199999995f |N.z| epsilon. acdream ran the orthogonal projection in BOTH directions, shrinking downhill XY travel by cos^2(theta): 25% at 30 degrees, 50% at 45 — AD-65's recorded shortfall, now retired. The combined Opus review independently re-derived the algebra, the branch polarity, the epsilon's bit-identity (17b75139), and the sabotage magnitude (the re-instated projection yields X = 0.75 = cos^2 30 exactly), and verified the delta is 4 non-comment lines with the into-plane arm, the crease arm, and both no-plane arms untouched. Its blast-radius sweep found the away arm exercised but NOT discriminated by any pre-existing test — every one asserts lower bounds the snap over-satisfies — so the two new exact-value tests are the only discriminating coverage, recorded in the test's class doc, and the felt 33-100% downhill speed-up is the morning gate's one row. AD-66 (the push-out's bare radius) is WITHHELD: byte-confirmed twice, implemented, then pulled after the same clean-room binaries measured contradictory absorbed-tick outcomes flipping with nothing but test assert shape — issue #341 carries the observation matrix and the apparatus plan; its two exact-value tests are [Skip]-ed; the retained substitution's rationale is restored at the site per review F1, with the review's remaining findings (F2/F3/F4/F5/F6) applied and F8 filed as #342. AD-69 filed: the same block omits retail's get_block_offset seam-frame correction, deferred to the AD-66 relanding for attributability. #340 filed: a fifth load-sensitive flake. Review verdict: PASS. AD-65 is provably unable to reach the #341 anomaly's code path (the absorb scenario takes the crease arm). Clean-room suite: 11,239 passed / 6 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 02:45:03 +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	8c97084289	docs: close #338 — headline refuted by full-capture statistics; AD-68 files the real residual ... The three-site probe answered it in one run: prepare and publish carry the authored 0.600/1.500 to the publication candidate, and resolve receives exactly those values for the entire session after one early 0.400 reading. Re-reading the ORIGINAL 337-support.log with statistics instead of an eyeball: authored pair 111,248 lines, 0.400 pair 358. The filing was built on an early line of a 255k-line capture; the alleged mechanism (values never wired to the mover) does not exist. The 358 are AD-68, now registered: GetSetupMoverShape's placeholder (empty spheres -> legacy capsule, 0.4/0.4 steps) during an entity's async Setup-residency window, plus the local player's own seconds-long window between controller construction and publication-candidate adoption. Retail loads synchronously and has no such window. Left as-is deliberately: shrinking it is streaming work. The filing still paid for itself: three false doc-comment claims corrected in PlayerMovementController (retail '~0.4 m' twice, and an ApplyStepHeights writer that never existed anywhere in the tree — replaced with the real writer chain), retail's actual fallback pinned at 0.04 (CTransition::step_up @0x0050b655), and the resolve probe now prints the mover id, because the early 0.400 was most plausibly a REMOTE player — remotes also carry IsPlayer — and the guid rule (feedback_probe_identity_attribution) exists precisely to stop that misread. No production behaviour changed; nothing for the morning gate. AD section 50 -> 51. Suite 11,234 / 4 / 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 00:44:42 +02:00
Erik	9b9bb6515f	docs: the #32 'fix failed' verdict is VOID — the tested binary never contained the fix ... Two checkouts, one relative launch path. Edits and builds ran in the main repo; every client launch ran from a PowerShell shell whose cwd was still the session worktree, so 'dotnet run --project src\AcDream.App\...' executed the worktree's 08-06 22:35 binary — #333 present, #32 fix, InitContactPlane and every #338 probe absent. Byte-proof both ways: 0 occurrences of the fix strings in the worktree's Core.dll, both present in the main repo's. Everything the previous entry concluded is therefore void: the byte-identical capture was the OLD code re-running (expected), the three probe silences were one fact (the instrumented binary never ran), and the 26,358-write attribution table is pre-fix baseline data of the old binary only. #32's fix returns to UNTESTED, with no evidence against it. The verification that was supposed to catch this confirmed the wrong binary: the DLL byte-check ran against the OTHER checkout's bin. So the self-report now prints typeof(PhysicsDiagnostics).Assembly.Location as its second line — binary identity becomes a recorded fact inside every capture instead of an inference from file timestamps afterwards. Memory updated with the multi-checkout rule: absolute launch paths, verify each shell's cwd before the first launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 00:27:57 +02:00
Erik	332045c7ad	fix(physics): split set_contact_plane from init_contact_plane (#32 local edge-slide) ... Measured live at Rithwic 2026-08-06 with ACDREAM_DUMP_EDGE_SLIDE=1. Six branch2/steep-cliffslide events, every one reporting curN=(-0.954,0.000,0.301) lastN=(-0.954,0.000,0.301) angle=0.0000 apply=False, outcome degenerate-cross/last-known. That is decision-table row 1 of the research doc, verbatim. CTransition::cliff_slide @0x0050a6d0 takes its slide direction from cross(steep contact normal, last_known_contact_plane.N) — it needs the surface the mover was STANDING ON as the second vector. acdream's CollisionInfo.SetContactPlane latched the last-known group on every call, so by the time cliff_slide ran, last-known had already been overwritten with the steep face itself: the cross product of a vector with itself, which is zero. Degenerate direction, no slide, walk off the cliff. Retail's COLLISIONINFO::set_contact_plane @0x00509d80 is 22 bytes and writes the CONTACT group only; the last-known group has four writers, none of them that function. So the four writes are DELETED and a new InitContactPlane mirrors CTransition::init_contact_plane @0x0050e850, writing both — the start-of-transition seed, where there is no earlier surface to remember. Only check_contact's SUCCESS branch calls it. The other eleven call sites keep the narrowed setter. This is a port, not a suppression: no guard, no grace period, no flag. The user's own A/B was the discriminator: Neftet's block plateaus hold (188 branch3/precipice-slide events, all before the teleport) while Rithwic's terrain cliff fails (6 branch2 events, all after). I had predicted the opposite — that terrain would be the flat-normal case — and position plus timeline corrected me, not reasoning. NEW DISCRIMINATING TEST, because the suite had none. It was green both before and after the production change, so nothing in it defended this behaviour. Issue32LastKnownContactPlaneTests seeds a walkable plane, asserts a steep mid-transition contact leaves it intact, and asserts the resulting cross product is non-degenerate. Sabotage-verified: restore the four writes and both discriminating rows fail while the InitContactPlane control keeps passing — the pair separates 'the latch is gone' from 'nothing writes last-known at all'. Two existing tests corrected rather than deleted. PhysicsSetPositionTests.FailedCheck_MapsCollisionHandlerResultToRetailError passed BECAUSE of the latch (the file the research named); its hook now populates both groups explicitly, since it asserts report plumbing, not setter semantics. RetailEdgeResponseOrderingTests.TransitionalInsert_ DegenerateCliffSlideOk_ContinuesOuterRetry was predicted to fail and did not — it now passes for a DIFFERENT reason (last-known absent rather than clobbered, which retail also answers with OK_TS). Its comment described the deleted behaviour and is corrected to say so, and to say it does not discriminate this fix. Also repairs the #338 probe. Its first placement in PlayerMovementController printed nothing across 11,523 live log lines — the wrong one of two resolve call sites — so it moves to PhysicsEngine.ResolveWithTransition where every caller passes through, filtered to the player. The dead site is removed rather than left in place; a probe that never fires is worse than none. The flag test now precedes the interpolated string: building it eagerly cost 128 B per resolve with the probe OFF, which Slice I1's zero-allocation gate caught. Suite 11,234 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 00:15:24 +02:00
Erik	45d7154712	probe(physics): ACDREAM_PROBE_STEP_HEIGHTS — three readings along #338's chain ... The live reading of 0.400 says the controller held its default at that instant, not why. Two very different causes produce it: the Setup-derived prepare/publish path never runs for the local player, or it runs and a later writer clobbers the result. Fixing without knowing which is a coin flip. One reading at each hop — prepare (Setup value computed and scaled), publish (assigned to the controller), resolve (what the resolver is actually handed) — with a decision table on the flag mapping each pattern to its cause, including the 0.000 case that would mean a null Setup took the retail dummy path. Edge-triggered per site, so the per-tick resolve site prints once per distinct pair and cannot drown the two one-shot sites it exists to be compared against. Prepare prints the raw authored pair beside the scaled one, so a surprise separates wrong-Setup from wrong-scale without a second run. Lives in PhysicsDiagnostics per code-structure rule 5 rather than as per-call-site env reads. Zero cost when off. Suite 11,231 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 22:50:42 +02:00
Erik	ea83b043df	fix(physics): delete the query-site broadphase reach filter (#333, closing #337) ... Transition.FindObjCollisionsInCell discarded a shadow candidate when |currPos - obj.Position| > sphereRadius + obj.Radius + movement.Length() + 2f obj.Position is the part ORIGIN; obj.Radius is the physics-BSP ROOT BOUNDING SPHERE's radius, measured about a centre AP-156 established is frequently metres from that origin (376 of 973 installed physics-BSP parts sit further from their part origin than half their own radius, worst 20.762 m). Geometry deep inside the real bounding sphere was therefore thrown away before BSPQuery ever ran: solid near the origin, permeable in a bounded shell beyond it. For the Neftet rock 0xC8766009 / gfx=0x01004751 the two points are 23.556 m apart, which is #337 — wedged on the plateau, jumps sinking into the mesh, corpses falling through. A live capture recorded 7,225 rejections on that one owner, every single one with wouldAcceptAtCenter=True. Deleted rather than re-centred. Retail has no distance pre-filter, disassembled from the PDB-paired v11.4186 binary (CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32) rather than read from Binary Ninja: CObjCell::find_obj_collisions @0x0052b750 walks shadow_object_list and calls CPhysicsObj::FindObjCollisions (0x0052b78b) UNCONDITIONALLY; its only early-out is insert_type == INITIAL_PLACEMENT_INSERT (0x0052b759). CPhysicsObj::FindObjCollisions @0x0050f050 contains no float compare at all. CPartArray::FindObjCollisions @0x00518180 is a bare do/while over parts, and CPhysicsPart::find_obj_collisions @0x0050d8d0 is two null checks plus a call. Retail's only spatial rejection is the BSP node bounding-sphere test inside the walk — correctly centred, which is exactly what the deleted filter was not. Re-centring it (carry BoundsCenter on ShadowEntry) would have preserved an invention retail does not have, including a +2f slack and a movement.Length() term with no retail counterpart, and left a second reach budget to be tuned forever. Retail's own cross-cell slack constant is F_EPSILON = 0.0002 m, not 2 m. The method's comment claimed the filter was "the analog of the part sorting-sphere early-outs inside retail's CPhysicsObj::FindObjCollisions — response-neutral, pure perf". Both halves were false and cost #333 and #337; it is replaced by the disassembly above. Gate: Issue333BroadphaseReachFilterTests drives the production path end-to-end (ResolveWithTransition -> FindObjCollisionsInCell -> CollisionTraversal) on a DAT-free fixture so it runs everywhere, as a discriminating pair. Sabotage-verified: restore the pre-check and OffCentreBspFloorStopsAFallingMover reaches z=37.800 — exactly the unobstructed fall, blockedAtLeastOnce=False — while CentredBspFloorStopsAFallingMover keeps passing. Without the control a fixture unable to fall would pass the first test for the wrong reason. Issue337's skipped TheBroadphaseAdmitsTheSurfaceTheMoverIsStandingOn asserted the now-deleted predicate and could never have gone green; it is rewritten as installed-DAT evidence pinning BOTH halves of the diagnosis and is no longer skipped. Perf measured, not assumed (Release, synthetic all-BSP cell, per ResolveWithTransition): at 38 candidates — the live maximum — 10.61 us -> 16.68 us (1.57x); at a deliberately unreachable 200, 17.34 -> 39.48 us (2.28x); ~0.16 us per additional candidate tested. Over 19,701 live [reach-q] samples the in-cell count is p50 = 9, p99 = 32, max 38. The ACDREAM_PROBE_REACH rejectedReach column is kept and is now structurally 0, so a post-fix capture stays comparable with the pre-fix one; dropping it would make the two incomparable. AP-158 retired (110 active AP rows). #333 and #337 closed pending the user's live acceptance at Neftet. Solution suite 11,231 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 22:16:53 +02:00
Erik	49a7e90652	probe(physics): ACDREAM_PROBE_SUPPORT + ACDREAM_WIRE_MESH — separate #337's three candidates ... The user is wedged at the top of Neftet rock plateaus, jumps sink into the mesh, and a corpse falls straight through. ACDREAM_PROBE_REACH already ruled out its own domain: blocked=0, every candidate tested-ok. Three candidates remain — terrain support, a collision mesh not where its visual is, or the transition wedging on an unobstructed path. ACDREAM_PROBE_RESOLVE alone cannot separate them. It prints a three-value contact-plane token, no plane normal, no plane height, no terrain sample and no plane provenance, so all three produce the same line. Two additions: [support] — one line per resolve for EVERY body, not just the player. A corpse is a plain physics body with no player-specific logic, so its fall-through is the cheapest available control on "movement code vs geometry data", and it is invisible to any player-filtered probe. The line samples the outdoor terrain INDEPENDENTLY at the body's own out-XY and prints the contact plane's own height at that same XY. Two heights at one point make support=terrain / object / none a measurement rather than an inference, and cpSrc= names the site that asserted the plane so provenance and classification cross-check. [geom] — once per GfxObj that comes near a mover: the object's physics-BSP vertex cloud against its visual mesh AABB in the same local frame, through the same prepared accessors the resolver queries. verdict=coincident REFUTES the working hypothesis for that object outright; no-physics-bsp / empty-physics-bsp / displaced / extent-mismatch each name a specific data defect. Built to refute, not to confirm — two diagnoses on this defect's lineage have already been refuted by measurement. ACDREAM_WIRE_MESH upgrades the existing F2 overlay, which drew a broadphase proxy cylinder for BSP objects and so could not answer the question at all, to the real physics-BSP polygon edges (cyan) beside the visual mesh box (magenta) and the terrain surface (yellow). Own class per code-structure rule 1. The provenance latch lives on PhysicsDiagnostics, not on CollisionInfo. Two fields there first — the obvious home — broke the flat/graph differential referee and the scratch-reset poison test, both of which compare CollisionInfo member-for-member. Teaching either to skip a member is a one-line green fix that puts a permanent hole in a referee whose whole job is comparing everything. Captured as feedback_probe_state_off_compared_types. Seven tests cover the support classifier's boundaries: a wrong classifier does not fail to answer, it answers confidently wrong. Gates: Release build 0 errors; complete suite 11,225 passed / 4 skipped / 0 failed from a cleaned tree — baseline 11,218/4/0 plus exactly the seven new tests, skips unchanged. Issue #337 filed with the symptom set, what is ruled out, and a table of what each possible output means. All of this is TEMPORARY and recorded for stripping with the physics-probe family. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 19:49:59 +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	b61f5fd4fc	probe(physics): ACDREAM_PROBE_REACH — discriminate #334's three candidates ... #334 is "large static formations can be walked through on flat ground, and jumping over them drops you inside" (Neftet, user-reported, pre-existing — reproduced on 52175aa1, before AP-22/AP-152/AP-156/AD-10). The report as originally filed pointed at one mechanism. The user's clarification that the formations are permeable on the ground generally, not only at a boundary between two of them, widens it to three, and a DAT sweep can only say which objects COULD fail, never which one IS failing at the spot. So: measure in game, at the failing spot, and let the log choose. The three outcomes this probe must tell apart, at the player's own collision query: (a) the object IS a candidate in the cell and the broadphase reach filter rejects it before its BSP is consulted — AP-158 / #333. That filter measures |currPos - obj.Position|, the part ORIGIN, against the BSP root sphere's RADIUS plus an acdream-invented 2 m slack. The sphere's CENTRE is frequently not the part origin (376 of 973 installed physics-BSP parts sit further from it than half their own radius; worst 20.762 m), so geometry well inside the sphere can be rejected. (b) the object is not in the cell's candidate set at all — a membership or registration failure. AP-156's territory, which did not fix this. (c) the object is a candidate, is not rejected, and still contributes nothing because no usable physics BSP resolves for it. Two line types from Transition.FindObjCollisionsInCell: [reach-obj] one per candidate, carrying mover guid, target entity id, GfxObj id, cell, and its disposition — exempt-self, exempt-missile, rejected-reach, exempt-rule, exempt-ethereal-stepdown, no-shape, bsp-only-skip, tested-{ok,collided,adjusted,slid}. For BSP candidates it also carries the origin-measured distance the filter used, the centre-measured distance it should have used, the budget, the shortfall, and wouldAcceptAtCenter — the boolean that separates a false rejection from an honest one. Identity is on every line (feedback_probe_identity_attribution). [reach-q] one per cell query, with the per-disposition tallies AND the raw entry count, emitted EVEN WHEN THE CELL YIELDS ZERO. That last part is the point: without it, an absence of rejection lines could not distinguish "nothing was rejected" from "nothing was there", and a criterion that cannot fail in the presence of the bug it exists to catch is the trap this campaign has already been caught by once. `blocked` is the control — it proves the probe can see a working collision as well as a missing one. The BSP root sphere is resolved through the SAME production accessor registration uses (GetFlatGfxObj(id).PhysicsBsp root node, per LiveEntityCollisionBuilder and ShadowShapeBuilder), so the probe cannot report geometry differing from what the registry actually emitted — AP-156's lesson was exactly that: one resolver. Volume: [reach-obj] de-duplicates per (mover, target, cell) and re-emits at once whenever the disposition changes or the shortfall crosses a 0.5 m bucket, otherwise at most once a second; [reach-q] de-duplicates per (mover, cell) on the whole tally tuple, so any change in what the cell yielded emits immediately, otherwise at most twice a second. Both emit eagerly on change — which is exactly when the player walks into the formation — and go quiet when nothing is happening. Nothing is aggregated away. Filtered to the player mover, matching PhysicsResolveCapture, so NPC and remote dead-reckoning resolves do not pollute the capture. The helper is static and takes everything by parameter so no closure display class enters the resolve path: Slice I1's 0 B/resolve budget holds with the probe compiled in and switched off. TEMPORARY. Strip with the rest of the physics-probe family once #334 is scored; both the flag and the call site say so. Clean bin/obj, Release build, full suite 11,208 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 17:29:44 +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	7b3e2895cd	docs: close the AD-10 review findings — AD-65's magnitude was half the truth ... Both AD-10 review lenses PASS; the deletion stands. These are the findings they raised. One production file touched, comment-only. AD-65 WAS UNDERSTATED BY HALF, and it is the finding that matters. The row states the factor as cos^2(theta) and then quantified 1-cos(theta): "13% at 30 degrees, 29% at 45". The correct figures are 25% and 50%. This is not algebra alone — #331's probe in the same push measures 0.0735 m travelled for a 0.1 m request at 30.96 degrees, i.e. 26.5% short, which is exactly cos^2(30.96). AD-65 is a LEAD for #269's slope-slide residual; at the understated magnitude it reads as marginal and could have been dismissed. At 50% short at 45 degrees it is a serious candidate. I repeated the wrong figure in conversation before the review caught it. "VERBATIM/FAITHFUL PORT" of Transition.AdjustOffset was asserted in five places and was false as of the very next commit, which filed AD-65 and AD-66 against that same function. Corrected to "structurally exact, with exactly two filed divergences" in the register row and the production doc comment. RECORDED, and it favours the change: the redundancy measurement is CONTINGENT on AD-65 — the two mechanisms agree today partly because both under-travel downhill. That makes this deletion a PREREQUISITE for fixing AD-65 rather than merely compatible with it; had the projection survived, correcting AdjustOffset would have re-introduced a disagreement between two live projections. The record claimed no such thing and should have. UNTESTED AXIS recorded: the contract's T2 — its mandatory wrong-plane-versus- right-plane discriminator — was dropped without record, breaching the contract's own clause requiring exactly that to be written down. The consequence is precise: the deletion is measured, but the change's only claimed BENEFIT (a walkable non-terrain surface now gets the committed contact plane instead of terrain far below) has zero automated coverage and rests on source reasoning. Stated in the row rather than left implied. #331 SEVERITY RAISED from UNKNOWN — the discriminator is known and it is not the fixture. With `body: null` the same uphill sweep climbs (ok=True, moved (0, -0.0999, +0.060)); with a body supplied it returns ok=False and zero movement, under a call profile identical to the local player's (IsPlayer|EdgeSlide + the human two-sphere Setup). A diagonal request keeps cross-slope X and zeroes only up-slope Y, and it fires on a 1.1 degree ramp. So "confined to the synthetic fixture" is no longer the comfortable default: the failing call shape is the shape production uses. Nothing in the suite asserts uphill progress on a walkable slope, which is why it was invisible — the test that found it passed vacuously, because the body never moved. Also: malformed XML doc on ComposeOffset (duplicate </summary> swallowed the retirement note from tooling) fixed; the placement-cutover plan's item 5 and its stale "After C5" line now record AP-22 and AD-10 as retired. Core builds clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 10:08:53 +02:00
Erik	886333a2a9	refactor(physics): delete the redundant pre-sweep slope projection (AD-10 retired) ... Stage 0's measurement (previous commit) says the projection is redundant, so AD-10 retires by deletion rather than by narrowing. The measurement. With the sample forced to null at BOTH fork sites, from a clean build: * a remote running 30 ticks down a 31-degree walkable ramp produces a BIT-IDENTICAL trajectory, position for position; * on an 8.4-degree ramp the two differ by at most 2.8e-5 m in Z after 30 ticks (0.03 mm) and are identical in X and Y — float ordering noise from projecting twice against the same plane rather than once; * the whole AcDream.Runtime.Tests suite is unchanged. That is what redundancy looks like, and the arithmetic explains it. The boundary projection and Transition.AdjustOffset are the same operation (v -= N * dot(v, N)) against the same plane, and the composition is idempotent: a vector already on the plane has dot(v, N) == 0, so the sweep's own projection is a no-op on an already-projected offset and the full-strength projection on an unprojected one. Either alone produces the same offset. On terrain a THIRD mechanism, ValidateWalkable's push-out, re-seats the sphere on the plane every sub-step regardless. Deleted: * both RuntimeRemotePhysicsUpdater sample sites (the host and no-host fork branches carried the block verbatim — the AP-22 shape, a row naming one site where two exist); * the terrainNormal parameter and projection block on RemoteMotionCombiner.ComposeOffset; * the same block on ComputeOffset, which has no production callers but held a second copy of the divergence, so leaving it would have made the row's retirement false; * PhysicsEngine.SampleTerrainNormal, now callerless. Removing the parameter rather than passing null is deliberate: it is what makes a future one-site-only regression a compile error instead of a silent half-fix. Two tests went with it — ComputeOffset_RootMotionFallback_SlopedTerrainNormal_ProjectsZOntoSlope and its flat-ground twin. Both were weak on their own terms: they drove the production-dead ComputeOffset and computed their expected values by re-implementing the projection formula, so they could catch a wrong MULTIPLY but never a wrong PLANE — which is exactly what the divergence was. The surviving coverage is geometric and runs the production tick. Three claims in the old row did not survive contact with the code and are recorded in the retired row rather than quietly dropped: the justification (remotes do run the sweep); the description of ComposeOffset's guard as "interpolation-active" when the code reads `if (!interpolationOverwrote`; and the roof clause, stale since Bug B gated the sample on OnWalkable — a steep roof is OnWalkable == false, so the path never ran on #32's geometry. The retail anchor is corrected too: pc:272296-272346 truncated both the sliding-normal validity gate at the head and the entire safety push-out block at the tail. The whole function is 0x0050a370, pc:272271-272393. This does not fix #32 and does not partially fix it. #32's remote half was already closed at 204d0ae0. What deletion does improve is the case #32 never covered: a remote on a WALKABLE non-terrain surface — a bridge, a dock, a gentle roof, a ramp inside a building — where the terrain sample returned the plane of the ground far below and applied a wrong plane rather than none. That surface now gets the body's own committed contact plane, because that is the only projection left. The planning contract this work executed is committed alongside as docs/research/2026-08-06-ad10-contract.md. Release build 0 errors. Complete solution suite 11,196 passed / 4 skipped / 0 failed against the ef976c6d baseline of 11,195 / 4 / 0 — reconciled exactly as +3 new Runtime tests and -2 deleted Core tests. Visual gate outstanding: G1 (the ~5 Hz staircase on rolling terrain) is the veto criterion and runs first; then slope-descent smoothness, a walkable non-terrain surface, the #32 roof scenario, and flat ground. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 09:35:22 +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	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	fafc0b65d9	fix(physics): adopt the settle's resolved cell across an indoor seam (#276 remainder) ... SpawnPlacementSettler committed settle.Position but discarded settle.CellId, so a compressed first-gravity-frame settle that crossed a cell boundary left the body's cell at the placement cell until some later resolve corrected it. Now committed through the same guarded channel the per-tick resolve writeback uses (RuntimeOrdinaryPhysicsUpdater): resolved cell when the transition reports one, source cell otherwise, never a zeroed residency. Retail anchor: CPhysicsObj::SetPositionInternal(CTransition const*) 0x00515330 commits both sphere_path.curr_pos.objcell_id and its frame, including EnvCells. WHERE THE DEFECT ACTUALLY BIT — #276's own framing is half wrong, and the half it misses is the whole fix. PhysicsBody.Position's setter already mirrors the world delta into the landblock-local frame and lets LandDefs.AdjustToOutside recompute the 24 m cell index from it, so an outdoor->outdoor settle already landed the right cell and dropping settle.CellId cost nothing there. It cannot do that for an EnvCell: an EnvCell id is not derivable from a position, so the mirror deliberately PRESERVES it. settle.CellId is therefore the only carrier of a cell identity across an indoor seam. The live defect is the issue's parenthetical ("outdoor/EnvCell seam, stacked EnvCells"), not its main clause — and the change is consequently a no-op on the outdoor path that dominates production, corrective only at the seam. That finding is what made the test possible. The three existing settler tests build bodies with NO CellPosition and pass identically with or without this change — shipping against them would have repeated C5b finding D3, a test that passed with its own change reverted. The new test seeds an EnvCell id over plain outdoor terrain instead, so the stale-id preservation is the discriminator and no EnvCell geometry fixture is needed. Sabotage-verified: restoring `body.Position = settle.Position` fails exactly the new test (1 failed / 4) and leaves the other three green — confirming both that the new test discriminates and that the old ones never could. Core suite 4,263 passed / 1 skipped / 0 failed, +1 for the new test. Still open and unverified, deliberately not claimed closed: whether the remote spawn-seed caller (LiveEntityNetworkUpdateController) hands in a body that carries a CellPosition at all. CommitTransitionPosition early-returns on a zero cell, so this fix is an inert no-op there and #276's remote half may survive. The C3c local first-entry caller is confirmed — it passes activation.Body.CellPosition.ObjCellId. Scoping detail in docs/research/2026-08-06-276-remainder-scoping.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 06:37:46 +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	9ee9c1a1a6	fix(runtime): close the C5b re-review findings — Gate A narrowing filed, no-window payload gate, bisect hazard recorded ... Both C5b re-reviews returned PASS on 02578441..ff100cf3. This lands the bookkeeping corrections they left, the one gate asymmetry both found independently, and one wrong retail fact neither of them caught. 1. AP-148 / #325 — Gate A's teleport test, wrong on primary source twice. The C5b contract stated retail's Gate A teleport term as "TELEPORT_TS equal" (and, in the trace block, as "must NOT be newer") and blessed acdream's `teleport == _timestamps[Teleport]` as retail-exact. Disassembly of the PDB-paired binary at SmartBox::HandleReceivedPosition 0x0045402B-0x00454054 says otherwise: the shortcut is taken iff the wire stamp is equal OR newer (wrap-safe) — `sbb eax,eax / neg eax` materialises the carry of the compare and the branch skips Gate A on CF, i.e. only when the wire stamp is strictly OLDER. It is CPhysicsObj::newer_event @0x00451B10's identical idiom with the operands swapped. Binary Ninja drops the flag test and renders it `if (-((eax_7 - eax_7)) == 0)`, always true — which is why two rounds of reading pseudo-C recorded it backwards. So acdream's ForcePosition disposition is a strict SUBSET of retail's Gate A set, and a local ForcePosition carrying a newer teleport stamp is misrouted into a full Apply: wire heading instead of preserved heading, unparent, possible placement frame, zeroed velocity, TELEPORT_TS advanced, and OfferTeleportDestination called for a packet retail never starts presentation for. PhysicsTimestampGate.cs is NOT changed. The predicate exists twice (also ValidAcceptedAuthority's PreviousTeleport == AcceptedTeleport), and the fix has to decide TELEPORT_TS's disposition on a Gate A path that has never seen a stale-but-equal pair. #325 records all of it and says explicitly that it is not a one-line comparison swap. C5b made this marginally better, not worse: clearParent was unconditionally true before C5b and is unchanged; installPlacementFrame moved toward retail's HasAnims gate. 2. Retail F2 / architecture L-A — the no-window route had no pre-merge payload validation. Root fix, not a documented asymmetry. The graphical route validates before the merge (OnPosition's payloadIsValid -> LiveEntityInboundAuthorityGate's !payloadIsValid return); despite its name CanAcceptPositionPayload is not projectile-scoped. The no-window route had no equivalent, and since D1 fed an unvalidated LandblockId into CommitWireCellRebucket — where 0 is the withdrawal shape, silently de-residencing the entity in the field every bot reads as CellId. RuntimeLiveEntitySessionController.OnPositionUpdated now applies the same rule at the same point, reusing RuntimeAuthoritativePositionRouteClassifier.IsValidCreateWirePosition plus the finite-velocity term — the exact pair TryApplyPosition already applies on its initial-residence branch. Chosen over documenting it because the fix is five lines and leaving it would have left two written claims falsified by the code. It is a behaviour change: headless now drops packets it merged. Against ACE the set is empty, and the graphical host has carried this gate since it was written; the argument is recorded in the contract's §15.2 rather than gated. Two test fixtures carried cell ids retail's own inbound_valid_cellid rejects (low words 0x41 and 0x51, above the 0x40 landcell ceiling). Their constants were corrected; their assertions were not. New test sabotage-verified in both directions: gate removed -> red at the withdrawal-shape assertion; gate moved to guard only the cell commit -> red at the pose assertion, which is what makes it a before-the-MERGE test rather than a before-the-commit test. 3. Register and doc corrections. - AD-64: "deliberately absent" was presented as the complete difference list and was not. Adds (a) the residence gate is weaker than the merge's own — both hosts' commits use TryGetCurrent while TryApplyPosition's FIFO branch uses TryGetTransaction, so the wire cell can commit ahead of the continuation that will replay it; (b) the two missile gates are two different expressions that agree today; (c) the payload gate, now present. Risk column records that (a) and (b) have no discriminating test on either side. - AP-147: amended for D1 — pre-D1 the no-window host published [Updated] alone and lost the Rebucketed, so a headless event log is now a real instance of the "consumer that snapshots a delta" the row warns about. - AD-60: "Matches retail exactly" scoped to the withhold, since the row's body documents two channels that do not. - CommitWireCellRebucket: notes the unreachable ThrowIfNull / EnsureNotDisposed precedence inversion. - TryCommitAcceptedWireCell: the discarded commit bool is explained rather than left bare — false means IsCurrent went stale, unreachable three statements after a synchronous TryGetActive. 4. Bisect hazard recorded in the C4 closeout handoff (the doc CLAUDE.md sends readers to before any C5 work) and in the contract's §15.3: commits 735f0a72..23aa62f2 contain a live headless defect — every remote's FullCellId frozen for the session — introduced by 735f0a72 and fixed only at ff100cf3. Nothing throws and no test in the range fails. Gates: Release build 0 errors/0 warnings. Complete suite 11,142 passed / 4 skipped / 0 failed against the 11,141 / 4 / 0 baseline — net +1, exactly the one new test. No flake appeared (#302, #308, #321 all green). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 23:10:24 +02:00
Erik	ff100cf33f	fix(runtime): give the no-window host a post-merge canonical cell commit (D1, AD-60/AD-64, AP-146/#320) ... C5b (735f0a72) made the steady-state accepted-Position merge stop writing residency. That is retail-correct — HandleReceivedPosition @0x00453FD0 reads the wire objcell_id into a local and never assigns the object's cell — and it stays. What C5b did not account for is that its replacement writers both live in AcDream.App: the OnPosition prologue rebucket (AD-60's W2) and the post-routing wire-cell adopt (W3, AP-135). The two hosts run parallel, non-shared inbound routes. LiveEntitySessionController -> LiveEntityNetworkUpdateController.OnPosition is graphical-only; RuntimeLiveEntitySessionController.OnPositionUpdated is the no-window route and is constructed only at HeadlessSessionHost.cs:682. So AcDream.Headless had NO post-merge cell writer at all. Every remote's FullCellId was written at create/placement and then frozen for the session — and RuntimeEntityObjectViews .Snapshot projects exactly that field as RuntimeEntitySnapshot.CellId, i.e. every bot's entire world view. The local player lost one of AP-146's three refresh edges, which matters beyond cosmetics: RuntimeSetPositionState .IsAffectedCollisionResident reads FullCellId to pick which bodies a landblock retirement parks, so a bot running A->B without teleporting would have retired A while parking a body physically in B. The fix, in three parts: 1. RuntimeEntityObjectLifetime.CommitWireCellRebucket — a new Runtime owner for the committed VALUE, extracted verbatim from LiveEntityRuntime .RebucketLiveEntity. This is also the root-cause fix for the layering inversion the review found: AD-60 was documenting its own correctness by naming an App class the Runtime assembly cannot reference. Behaviour on the graphical side is unchanged — record.FullCellId is a proxy for record.Canonical.FullCellId, which is the record the callee reads, and the commit is still CommitRebucket. Verified load-bearing for BOTH hosts: sabotaging the preserve branch reddens the graphical LiveEntityRuntimeTests.CanonicalOnlyRebucket_DoesNotOverwriteAuthoritativeFullCell as well as the new headless assertion. 2. RuntimeLiveEntitySessionController.TryCommitAcceptedWireCell — the no-window W2, under the same reachability rules the graphical route applies: Rejected writes nothing (the shape the App authority gate produces by returning false); a bound-projectile packet writes nothing (routed by the graphical host through the canonical projectile placement owner, which returns before W2); an active initial-create residence writes nothing (RebucketLiveEntity's own early return — while the lease is live the SetPosition conductor is the sole cell authority); a local ForcePosition writes only when the accepted-Position drive declined it (NotApplicable), because a handled force is placement-receipt-authoritative. W2/W3 themselves are untouched. 3. On the committed value (the landblock-vs-cell trap). RebucketLiveEntity's preserve branch fires on a LANDBLOCK-shaped id — low 16 bits 0xFFFF — and exists for LocalPlayerProjectionController.Project, the per-frame local movement caller that emits exactly that shape. An inbound wire objcell_id is never landblock-shaped, so on the accepted-Position route the branch is not taken and the exact wire cell is committed. That is what W2 commits today and what this now commits; the no-window host has no per-frame caller at all. Ordering is matched, not improved on: the force drive submits its placement before the commit, so its first submit still reads the pre-commit FullCellId — AP-138's amended route-2 CurrentCellId measurement. Bookkeeping in this commit: - AD-60 corrected. Its surviving-channel enumeration presented "the local force path, the missile arm" as exhaustive; the entire no-window host belonged in it. 23aa62f2's W2/W3-redundancy measurement is preserved verbatim. - AP-146 and #320 amended the same way — their three-edge list was written from the graphical host and silently assumed both hosts shared it. The no-window host had two of three; it now has all three. - AD-64 filed: the reachability decision is now expressed once per host. The value is single-sourced; the gate set is not. - #324 filed: unifying the two session controllers is the genuinely correct fix and is campaign-sized (presentation recovery, hydration, the equipped-child renderer, and the remote/projectile routing arms only one host has). Not attempted here, per the fix brief. Gates. Release build 0 errors. Complete suite 11,141 passed / 4 skipped / 0 failed, against the 11,134 / 4 / 0 baseline at 23aa62f2 — net +7, exactly the 7 tests added. Eight sabotages verified, each red on at least one discriminating test and green when reverted: remote commit removed (2 Runtime + the end-to-end Headless test); local ordinary commit removed; local NotApplicable-force commit removed; force commit made unconditional; residence gate removed; missile gate removed; Rejected gate removed; preserve branch broken (red on both hosts). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 22:36:31 +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	cff52c44f4	docs(physics): correct stale set_velocity claim in the 4a remote velocity comment ... LiveEntityNetworkUpdateController.cs's TryCommitAuthoritativeVelocity call site carried a comment claiming "MoveOrTeleport installs that exact vector with set_velocity". The C4 route 5 byte-decode of CPhysicsObj::MoveOrTeleport @0x00516330-0x00516438 (the immediately preceding commit) shows this is false: the function never reads its velocity argument's stack slot in any branch, and UnpackPositionEvent performs no set_velocity either. The only set_velocity in the whole accepted-Position chain zeroes the LOCAL player @0x004541B4, a different call site entirely. This commit only corrects the comment. The 4a call itself is left unchanged in production, deliberately out of C4 route 5's scope — the route governs RuntimeSetPositionOperationKind placement dispatch, not the pre-existing remote velocity commit. #317 (docs/ISSUES.md, filed in the previous commit) tracks the follow-up: audit the whole accepted-Position velocity chain and either find the correct retail source or remove the call with a divergence-register row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 21:04:06 +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	aaf0811f18	fix(physics): close #315 — cache the remote-arm callbacks instead of allocating per packet ... The OnPosition collapse (previous commit) converged RunRemoteArmTail's three duplicated call sites into one, which is what makes caching worthwhile: one cached pair of delegates now serves every remote guid instead of a fresh closure allocated on every accepted remote Position (5-10 Hz per remote), regardless of whether the packet was a teleport. RunRemoteArmTail's signature changes from a caller-constructed `Func<bool> isCurrentPositionOwner` closure to two plain value parameters (`ulong positionAuthorityVersion`, `WorldEntity? expectedEntity`). It stamps five per-packet scratch fields (`_remoteArmCanonical`, `_remoteArmMotion`, `_remoteArmPositionRecord`, `_remoteArmPositionAuthorityVersion`, `_remoteArmExpectedEntity`) from its own parameters, then passes the two CACHED delegates into ApplyRemoteContactRouting. Observably identical: the currency check reads the exact same positionRecord/positionAuthorityVersion/expectedEntity triple either way. Deviation from a bare cached-Func<bool>-field design, and why: UpdateFrameOrchestratorTests.ProductionFrameAdaptersRetainTypedOwnersWithoutWindowCallbacks asserts every typed production owner (LiveEntityNetworkUpdateController included) carries zero Delegate-typed fields — the GameWindow decomposition campaign's guard against a callback silently smuggling a window reference back onto one of these owners. Neither cached delegate here touches a window (both are bound to this controller alone), but the rule is written as a blanket field-type check, not a window-specific one. The two delegates are wrapped in a small nested RemoteArmCallbacks type instead of being bare fields, which satisfies the guard and keeps the cache a single named, auditable unit rather than working around the test. RunRemoteTeleportHook's own allocation (the six-action RemoteTeleportHookActions bundle) is unaffected — it stays teleport-path-only, already judged acceptable to defer by the C4 route 4b-3 round-2 architecture review's B4 finding. dotnet build AcDream.slnx -c Release: 0 errors. Focused suites green at this commit: AcDream.App.Tests 4104/4107 (3 pre-existing skips), AcDream.Runtime.Tests 1125/1125. Closes #315. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 18:11:36 +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	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	204d0ae047	fix(physics): remote bodies slide on steep faces instead of freezing (#32) ... A remote observed in acdream landed on a sloped roof and froze; the server slid on, the gap passed AP-87's 4 m threshold, and the body snapped — the visible blip. Live probe capture, two adjacent ticks 63 ms apart: t=88420671 rsInContact=True rsOnWalkable=False rsIsOnGround=True bodyCpNz=0.6097 floorZ=0.6642 steep=True gravity=True vel=(2.146,2.264,-3.549) t=88420734 contact=True onWalkable=True <- forced against the sweep gravity=False <- cleared velBeforeZero=(2.146,2.264,0.000) moved=0.0000 <- and every tick after The roof is 52.4 degrees against a 48.4 degree limit, so acdream's classifier was CORRECT and was then overruled. Four independent links each froze the body on their own: a per-tick force of Contact|OnWalkable, a per-tick velocity zero, a Gravity clear at landing, and a landing edge testing IsOnGround (= inContact || ...) instead of OnWalkable. The tick called HandleAllCollisions alone — the tail of SetPositionInternal without its prefix. Retail simulates remotes locally and derives these bits rather than asserting them: CPhysics::UseTime @0x00509950 iterates the whole object table; update_object @0x00515D10 gates only on parent/cell/FROZEN with no is_player fork; SetPositionInternal @0x00515330 sets CONTACT from contact_plane_valid @0x00515430 and ON_WALKABLE from contact_plane.N.z vs floor_z @0x00515465-@0x0051548E before handle_all_collisions @0x005154FE; set_on_walkable @0x00511310 fires HitGround @0x00511364 / LeaveGround @0x00511346 edge-triggered with no ownership gate; calc_acceleration @0x00510950 zeroes only when CONTACT && ON_WALKABLE && !Sledding @0x0051096B; calc_friction @0x0050EE70 returns at its first line when ON_WALKABLE is clear. acdream had copied retail's airborne no-op WITHOUT retail's local simulation. The fix is mostly deletion: stop forging the transients, stop discarding the authoritative velocity, stop clearing Gravity, and route the remote tick through the same SetPositionInternal commit TickHidden and the local player already use, with the landing edge derived from the sweep's own OnWalkable. AP-87's threshold and conditions and InterpolationManager's node_fail_counter snap-to-tail are deliberately untouched — this removes the CAUSE of the divergence rather than weakening the backstop. Cross-checked against ACE: its only creature-side VectorUpdate emitters are the jump broadcast and spell projectiles, so integrating the wire velocity cannot double-move a walking remote; and PhysicsGlobals.DefaultState already carries Gravity, so deleting the manufactured State |= Gravity is safe. Register: AP-81 narrowed (its GRAVITY half retired outright), AP-87 annotated, AP-139 filed (the interpolation-queue clear on the landing edge), AP-140 filed (the two routing gates select snap-vs-interpolate on walkability where retail uses CONTACT — adjust_offset @0x00555D30 gates on transient_state & 1 @0x00555D52). AP-140's follow-up is deliberately shaped as "point the two gates at Body.InContact", NOT "re-derive Airborne", which would perturb five writers and collide with a pinned RemoteTeleportPlacementTests assertion. Three gaps recorded in #32 rather than papered over: the new LeaveGround dispatch is untested for chatter; a persistently !Ok transition can latch a remote airborne; and — the visual-gate watch item — the deleted forge was a blanket guarantee of Contact|OnWalkable, and contact_allows_move @0x00528dd0 silently refuses action animations without both, which is the literal root cause of closed #270. Retail-correct on a steep face, a regression anywhere else. 10 discriminating tests over a real PhysicsEngine landblock whose contact normal Z is 0.61 against FloorZ 0.6642 — the live roof's exact relationship. Suite 11,019 passed / 4 skipped / 0 failed. Includes the temporary ACDREAM_PROBE_REMOTE_LANDING / ACDREAM_PROBE_REMOTE_SLIDE probe family that produced the capture above; strip with the family. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 10:21:16 +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	634bc5513a	fix(physics): restore a cancelled park instead of leaving the entity withdrawn ... Shipped-code defect affecting committed route-2 code, found while reviewing route 4b-1. RuntimeSetPositionState.ParkDeferred withdraws an entity from the world: body.InWorld = false, TransientStateFlags.Active cleared, WithdrawCanonical, SuspendObjectClock. CancelCoreDeferred then removed the operation and rewrote the pending Withdraw into a Discard while restoring NONE of it. So cancelling a wakeable park was strictly worse than keeping one — the park is wakeable, the cancel destroys the only object that could ever wake it, and the entity is left invisible AND intangible with nothing to bring it back. Route 2's re-issue funnel masked this: re-issuing is correct for a one-shot ForcePosition ACE never repeats, and wrong for a repeated remote stream, so the hole was hidden rather than fixed. Retail's own answer is a working park, verified in the decomp rather than assumed: CPhysicsObj::SetPositionInternal @0x00515BD0, when AdjustPosition yields no cell @0x00515C1D, calls prepare_to_leave_visibility @0x00515CDA, store_position @0x00515CE2 (the DESTINATION pose is committed), GotoLostCell @0x00515CF2 registering at m_position.objcell_id read AFTER store_position (so the destination cell), clears transient 0x80 @0x00515CF7, and returns OK @0x00515D07. InitObjCell @0x00508260 drains the lost list on cell load and calls reenter_visibility @0x00516250, which re-places from the object's OWN m_position with flags 0x11. Two corrections to the direction I gave, both forced by evidence and both right: The pose must NOT be rolled back — only the withdrawal. Three shipped route-2 tests capture positionAtPark AFTER the park and assert it survives the cancel, and retail agrees: store_position commits the destination and nothing un-commits it. Restoring residency at the body's committed cell is therefore retail's own cell choice, not merely self-consistent. The gate defaults to FALSE with four explicit opt-ins, rather than defaulting true with opt-outs at the withdrawal callers. That keeps every one of the ~20 shipped Forget/ForgetExactPlacement sites at exactly its current behaviour instead of depending on having correctly enumerated the withdrawal transactions. Review had already found the broad version corrupting five of them (TryApplyPickup, CommitAcceptedParent, CommitAcceptedParentCellless, CommitWithdrawal, CommitPositionChannelUpdate): they hand-roll a partial re-withdrawal that undoes the clock and FullCellId but not InWorld or the _spatialRoots re-registration, leaving a picked-up item both in inventory and an InWorld cellless spatial root in the physics workset. ParkDeferred's restorableOnCancel is opt-in for exactly one of its four callers — the plain unplaceable-destination park. Every quiescence and retirement park is excluded deliberately: those entities are withdrawn because their world is going away, and restoring residency inside a quiescing prefix blocks its retirement. VerifyPositionChannelCancellation now asserts InWorld and IsSpatialRoot per channel — Position is a cancellation and must restore; Pickup and Parent are withdrawals and must not. It previously asserted only !IsDeferred and counts, which is why five green states hid this. Register row AP-136 measured against GotoLostCell/reenter_visibility rather than labelled "retail-shaped". Files #309 (the restore-on-cancel residual, with park-survives recorded as the retail-faithful target and its two blockers named: the NewerPositionPickupAndParentEachCancelExactLostOperation invariant and teardown convergence) and #310 (an unbounded retirement stall — a retained preparation retry pins its prefix through HasOldPrefixPlacementDebt forever, and TickLostCellDeadlines has no production caller so the 25 s timer never fires). This is a user-observable change to shipped paths: restorableOnCancel: true sits in SubmitPreparedPlacementCore, the shared core behind every production placement. AP-136 and #309 carry the proposed two-client check. Gates: complete Release solution 10,973 passed / 4 skipped / 0 failed (baseline 10,938). Every new test discrimination-verified by reverting the fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 04:07:39 +02:00
Erik	eeec4fb42a	diag(physics): remote landing-edge probe; record the two live jump defects ... The user live-tested route 4a and reported two defects on player remotes: a remote holds the falling animation after landing before finally landing, and a remote jumping onto a house plants on the roof where retail slides off, then blips to the slid-down position. Neither is a route 4a regression. Do NOT revert 44830a0e — reverting would restore the per-packet render slam 4a removed without touching either defect. Bug B's root cause is identified and already covered by open issue #32, whose text names both symptoms in one sentence. Both landing sites assert TransientState |= Contact | OnWalkable unconditionally, where retail derives it from the contact plane — CPhysicsObj::SetPositionInternal @0x00515330 (`if (contact_plane.N.z < floor_z) set_on_walkable(0) else set_on_walkable(1)`). A steep roof is contact but NOT on_walkable; asserting both suppresses the slide response, so the body sits until the server's positions walk 4 m away and AP-87's threshold snaps it. That is the blip. Verified byte-identical pre-4a via `git show 19d95094:`. Bug B's *visible shape* IS 4a's: pre-4a every packet slammed the render entity to the wire pose, so a stuck body flickered toward the true sliding position 5-10x per second — jitter rather than a clean hold. Bug A stops at the goal's stop-condition rather than getting a speculative fix. Three hypotheses with non-overlapping fixes; picking wrong means changing a retail-ported gate on a guess. Retail's mechanism is already fully decoded, so what is missing is OUR runtime state — no cdb trace against retail is needed. Adds ACDREAM_PROBE_REMOTE_LANDING (PhysicsDiagnostics, read once at startup per the diagnostic-owner rule, one bool check when off). It logs both landing sites immediately before HitGround, and — the most diagnostic signal — emits a separate line when a site is reached but the gravity gate is about to no-op, which is hypothesis 1 (a wholesale Body.State write wiping the transient Gravity bit mid-air, exactly AP-81's stated risk). Temporary instrumentation, marked for stripping once the evidence is in. Evidence recorded rather than new bugs filed: #32 gains the observation, the root cause and the #173/AD-10 dependency caveat; AP-87 gains a live instance of its stated risk; AD-10's stale file:line is corrected to RemoteMotionCombiner with a note that its terrain-only normal cannot see a house roof at all. Also files #308 — a SECOND flaky test, distinct from #302, which was twice misattributed to it before being written down. #302 is a GC-allocation assertion in App.Tests; #308 is a wall-clock deadline loop in Core.Net.Tests that fails only under full-suite CPU contention (0 failures in 4 isolated runs). Conflating them hides one, and an agent told to "ignore the known flake" would wave through a real transport regression. Gates: complete Release solution 10,938 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 01:10:03 +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	19d9509497	fix(physics): #307 — PreviousTeleport was always 0 on the live Position path ... Shipped defect in route 2 (9966b531), found while reviewing route 4a. `InboundPhysicsStateController.TryApplyPosition` built its AcceptedPhysicsTimestamps via `Current(gate, teleportAdvanced: ...)`, omitting `previousTeleport`, which defaulted to a literal 0. The only site that populated it was the deferred initial-create path — which is why the continuation executor was correct and every newer consumer was not. Consequence in shipped code: route 2 feeds this into `ValidAcceptedAuthority`, which requires Previous == Accepted for a ForcePosition. Any local player whose TELEPORT_TS is nonzero — anyone who has portalled or recalled this session — had the authority rejected and the force correction SILENTLY DROPPED. The user's @pklite acceptance was genuine but narrow: that character had not teleported, so the stamp was still 0. Second latent consequence: with an accepted stamp >= 0x8000, wrap-safe TeleportRegressed also fires against the 0 and rejects ordinary Apply positions, not just ForcePosition. The fix captures `previousTeleport = gate.TeleportTimestamp` BEFORE `TryAcceptPositionEvent` mutates it, matching the shape the deferred path already used. Ordering is the whole point: capturing after would make Previous == Accepted unconditionally, so ValidAcceptedAuthority's check would pass vacuously — the symptom would disappear while the semantics broke. Also removes the footgun that allowed it. `Current`'s parameter is now `ushort? previousTeleport = null` resolving to `gate.TeleportTimestamp`, so the eleven non-Position channels — none of which can move TELEPORT_TS — get "previous == current" by omission rather than a literal 0 that is indistinguishable from a genuine "never teleported". Consumer audit: only TryApplyPosition was defective. The two route-2 call sites trace back to it; the RuntimeEntityObjectLifetime sites source from TryAcceptDeferredPosition and were already correct. Tests discrimination-verified by reverting the argument to 0: the stamp test fails Expected 10 / Actual 0, and the classifier test fails Expected SetPositionSimple / Actual RejectedAuthority — the shipped defect reproduced exactly. Gates: complete Release solution 10,935 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 23:48:09 +02:00
Erik	b633b10967	fix(chat): display retail's text for WeenieError 0x0504 and three PK siblings ... User saw "[System] WeenieError 0x0504" on login after a PK Lite reversion. 0x0504 is YouAreNonPKAgain; only ~56 of 378 codes had strings, so the raw hex fallback fired. Retail's source is ClientCommunicationSystem::HandleFailureEvent @0x00571990 — a switch with per-case literal UTF-16 strings, not a DAT string-table lookup, so hardcoding them is retail-faithful. The decomp could not be trusted for the text. Its dump of data_7d32c0 declares [0x5f] and shows 95 characters ending mid-word at "...protection of the Lig". The real string is 139 characters. The 0x5f is Binary Ninja's PREVIEW TRUNCATION LENGTH, not the array size — worth remembering for the rest of the switch, since a copy-paste from the dump would have shipped a truncated sentence. Recovered by PE byte read (VA 0x007D32C0 -> RVA -> .rdata file offset), cross-confirmed against the raw hex the pseudo-C carries immediately after the preview. Mapped 0x0504, 0x0505, 0x04EC, 0x04ED, each byte-verified and cited with its case address. Retail's trailing newline is dropped deliberately (documented in-comment): acdream renders one ChatEntry per system message where retail has a single scrolling buffer. Adjacent codes are deliberately left unmapped with a test pinning that 0x04EE still falls back to hex — a wrong message is worse than a raw code. Files #306 for the full port, with three findings that make it more than a string table: the switch is SIX compiler-lowered blocks spanning 339 distinct case values from 0x17 to 0x593, not one contiguous band; retail passes a colour argument with three values in use (0 x162, 0x1a x113, 7 x59) and acdream's chat has no colour concept; and HandleFailureEvent aborts an in-progress automatic attack on 0x43/0x3f7/0x3e/0x23/0x36 — verified against the decomp, with the nuance that 0x43 has no display case at all and is abort-only, so that one is a pure gameplay gap. Gates: complete Release solution 10,909 passed / 4 skipped / 0 failed (baseline 10,904; +5 = the five new tests). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 22:20:31 +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	88348f6791	fix(physics): #299 — port retail's mover-side IsImpenetrable exemption branch ... CollisionExemption checked only the TARGET's IsImpenetrable, and the class doc asserted "retail's pseudo-C only checks the target's IsImpenetrable(); acdream follows retail" while blaming ACE for checking both. That was backwards: ACE was retail-faithful and acdream was missing half the check. Retail short-circuits on EITHER the mover's own state & IS_IMPENETRABLE (0x80) OR the target's IsImpenetrable(); either alone exempts. Verified at the byte level rather than from the decompiler's rendering — Binary Ninja shows the mover test as `int16_t state_1 ... if (state_1 < 0)`, which reads like a 0x8000 test, but decoding the PDB-paired binary at the mapped offset gives: 8b 43 04 mov eax,[ebx+4] ; mover object_info.state f6 c4 01 test ah,1 ; 0x100 IsPlayer 84 c0 test al,al ; sign bit of AL = state & 0x80 78 3d js ... ; -> collide `test al, al; js` is a byte-level sign test on AL, i.e. 0x80, not 0x8000. Corroborated downstream in the same block (`test ah,8` = 0x800 IsPK, `test ah,0x10` = 0x1000 IsPKLite) and by OBJECTINFO::init @0x0050cf30 setting state |= 0x80 from the object's own IsImpenetrable(). Also corrected: ACCWeenieObject::IsImpenetrable @0x0058c8c0 returns (_bitfield >> 0x15) & 1 — retail genuinely conflates BF_FREE_PKSTATUS with "impenetrable", so acdream's FromPwdBitfield decode was already right. Both retail arms set collide, so ordering between them is semantically free and a misreading here could only ever produce spurious collisions, never a walk-through. Found while investigating #297; not symptom-causing on its own. No divergence row: this retires a missing port rather than introducing a deviation, and nothing in the register or the collision digest's DO-NOT-RETRY tables covers it. Gates: complete Release solution 10,887 passed / 4 skipped / 0 failed (baseline 10,867/4/0). Adversarial + retail-conformance review PASS on this change specifically. Both new tests discrimination-verified by reverting the branch and confirming failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 20:13:05 +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