71 commits

Author	SHA1	Message	Date
Erik	55b07f6a62	refactor(physics): hoist the live-entity collision builder to Runtime (#330 groundwork) ... LiveEntityCollisionBuilder and LiveEntityDefaultPoseResolver move from AcDream.App.Physics to AcDream.Runtime.Physics with no behaviour change — diff-verified byte-identical shape math by both review lenses. The Build signature's App-record parameter is replaced by presentation-free primitives with identical guard semantics, INCLUDING the FinalPhysicsState read the contract had missed and the implementer surfaced rather than dropped. Visibility stays internal: Runtime's existing InternalsVisibleTo grants already cover every consumer, so the implementation's public widening is reverted per the architecture review's finding 11. The registration WIRING is deliberately WITHHELD. Both Opus lenses failed it, converging: a shadow registered at spawn freezes there (RuntimeRemotePhysicsUpdater is Runtime-homed but App-driven — nothing headless ticks it), so a walking NPC becomes a phantom obstacle at its spawn point while the real NPC still passes through the bot; three of five shadow-lifetime edges leaked (pickup leaves a permanent invisible collider, supersession orphans a duplicate, generation reset never unregisters and the K-ledger convergence oracle only checks retained shadows AFTER disposal clears them); and headless cannot resolve BSP collision assets at all, so doors and chests would still be walk-through. The frozen-shadow root was the SESSION LEAD's contract error (fact 3), not the implementer's. #330 stays OPEN, rewritten as the seven-point scope map the reviews produced — the honest overnight deliverable is that map, not a half-mechanism carrying new divergences. Suite 11,235 passed / 4 skipped / 0 failed (the withheld seam's two tests account for the delta from the implementation run's 11,237). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 01:49:13 +02:00
Erik	13fcf38138	fix(physics): port retail's find_bbox_cell_list outdoor extent walk (#334) ... acdream had never implemented retail's SECOND cell-membership algorithm. CPhysicsObj::calc_cross_cells @0x00515230 tests HAS_PHYSICS_BSP_PS at 0x00515285 and jumps (0x0051528f jne 0x515305) to find_bbox_cell_list @0x00510fc0 for a BSP-bearing object; everything below that jump is the OTHER algorithm, CObjCell::find_cell_list, and that is all we had. Every object, BSP-bearing or not, was routed through it. That path's outdoor expansion is a HARD CAP of one cell in each direction. CellTransit.AddAllOutsideCells computes minRad = radius, maxRad = 24 - radius and adds at most the eight neighbours of the sphere's own cell, so for any radius >= 12 m both boundary tests are unconditionally true and the result is exactly 3x3. Widening the radius or adding a second sphere is mechanically incapable of adding a tenth cell. The user's live probe measured the consequence directly: standing inside a Neftet formation, inCell=2 exempt=2 reached=0 -- the geometry was not a candidate at all. The port. AddAllOutsideCellsFromParts is CLandCell::add_all_outside_cells @0x00533360 plus add_cell_block @0x005331d0: base landcell from the FIRST part's own adjust_to_outside, baseX/baseY within-block, each part's authored CGfxObj::gfx_bound_box re-fit through all eight corners (BBox::LocalToGlobal @0x005b2120), floor(v / square_length) where square_length = 0x7c920c = 24.0f, four accumulators seeded to zero, ONE rectangle unioned across all parts, FILLED, in GLOBAL lcoords so it crosses landblocks freely, clamped only to [0, 0x7f8). BuildShadowCellSetFromParts is find_bbox_cell_list's worklist. RegisterMultiPart dispatches on the same flag retail does, and BuildFloodSpheres' BSP arm is deleted rather than left unreachable. Disassembled from the PDB-paired 2013-09-06 binary, not read from Binary Ninja: BN mis-renders four separate constructs inside add_all_outside_cells alone -- a dropped `and eax,0xffff` on baseX, a neg/sbb/and select shown as identically zero, a wrong get_landcell argument, and both x87 flag tests as `unimplemented {test ah}`. ShadowPartGeometry pairs the BSP root sphere with the authored box so no resolver can answer one and leave the other call site to synthesize a substitute -- the AP-156 invariant applied a second time, since that split is what produced AP-156 and then this. The box comes from FlatGfxObjVisualBounds, already computed by exactly CGfxObj::init_end's algorithm and already in the prepared package: no bake change, no DAT re-read. Cost, measured over the installed DATs before any code was written: 1,258 physics-BSP GfxObjs, cells/object p50 4, p90 4, p99 12, max 49. The port is CHEAPER than the old 3x3 = 9 for 98.97% of them. Row totals (shapes x cells) over all 1,031 landblocks with BSP owners fall 97,173 -> 15,607 (0.161x); dense Arwic 0xC6A9 falls 342 -> 43. One landblock more than doubles. Precondition confirmed before pinning any expected cell set: 0x010046D8's box is 96 m x 96 m about cell (2,2) = 0x87640013, which independently corroborates the 3x3-centred-there diagnosis, and its rectangle does contain 0x87640011 and 0x87640019 -- the two cells the probe measured empty. Register: AP-156's outdoor half CLOSED and its risk column CORRECTED (it read "extra broadphase candidates, never a missed one", which generalised the indoor direction to the whole row and is why #334 sat inside it unnoticed). AP-159 + issue #335 file the unported indoor arm; AD-49 records the seed-time rectangle. Issue #336 files a fourth load-sensitive test flake seen once during the gate. Ten tests, every one sabotage-verified in both directions across eight mutations (dispatch, 8-corner refit, floor-vs-truncation, union-vs-per-part, map clamp, adjust guard, landblock clamp, box-path-for-everything). The strongest is an installed-DAT replay of the user's own probe evidence. Suite 11,208 -> 11,218 passed / 4 skipped / 0 failed; the +10 is exactly the new tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 19:07:06 +02:00
Erik	e6457cc849	fix(physics): close the AP-156 fix review — real containment oracle, type-level invariant, AP-158 ... Both review lenses PASSED; this is the cleanup, not a rescue. Evidence: docs/research/2026-08-06-ap156-review-closure.md (the review itself is committed alongside it as the received artifact). R1 — the load-bearing containment test could not fail. Its truth and flood values were two hand-copies of the same expression over the same part set, so the shortfall was algebraically identically zero for any DAT input. The oracle is now PHYSICS-POLYGON VERTICES — a different DAT field from the bounding sphere the builder emits, so the two sides can genuinely disagree. Sabotage-verified three ways after full cleans: dropping the bounds centre in production reddens it (428 Setups, worst 35.869 m on 0x0200129A, matching an independent out-of-repo sweep exactly); dropping only the scale on the centre reddens it (326); and corrupting the TEST's own bounds oracle reddens it (467) where under the shipped oracle that same corruption was invisible by algebra. Renamed accordingly. A6's stale "cap control" comment corrected: that loop is the test's own uncapped re-implementation and cannot observe a cap regression — the cap is covered in Core. R2 — the population was understated. 172 is AP-152's DISPATCH population; AP-156's is 530 BSP-bearing Setups, of which 525 have a flood sphere move and 428 fail vertex containment before the fix (412 at a 1 cm tolerance — the review's figure; the gap is 16 Setups between 1.4 mm and 10 mm, real geometry). 0 fail after, at any tolerance down to zero. Corrected in the AP-156 row, the section-3 header, the C5c handoff and two test docstrings. Dated review artifacts are left as written — "170 of 172" was correct for what they measured, and rewriting evidence to match a later measurement loses provenance. A1 — BoundsCenter = default reopened at the type what the commit closed at the seam. Dropping the default alone would NOT have closed the review's own scenario (a copied Cylinder call site would write Vector3.Zero explicitly and stay green), so ShadowShape's constructor is now private and BSP shapes are built only through ShadowShape.Bsp(..., FlatCollisionSphere localBounds), which takes radius and centre as ONE value and scales them together. There is no expression a caller can write that carries one and drops the other. 22 construction sites converted; the same sabotage now reddens 5 Core tests where the review's sabotage A reached 4, because both BSP producers share one scaling path. A2 — #333 is real and bigger than filed, and its retail question is answered. I disassembled CObjCell::find_obj_collisions @0x0052b750 from the PDB-paired binary myself (check_exe_pdb.py MATCH) rather than inheriting the claim: its only early-out is sphere_path.insert_type == INITIAL_PLACEMENT_ INSERT, then it calls FindObjCollisions on every unparented non-self shadow object UNCONDITIONALLY. Retail has NO distance pre-filter, so acdream's "+ movement + 2f" reach filter is an invention with no register row — filed as AP-158, carrying the disassembly, the F_EPSILON = 0.0002 m contrast, and the measured blast radius (118 of 477 unique installed physics-BSP GfxObjs exceed its ~2.5 m budget, 46 exceed 5 m). Active AP rows 109 -> 110. Recorded prominently in three places a reader will hit: TALL PROPS MAY SHOW NO VISIBLE CHANGE UNTIL #333 LANDS, and a null result at the connected gate is EXPECTED, not evidence against AP-156. LOW items. R3: the comment claiming the cited evidence justified the whole cap line is corrected, but int.MaxValue on the sorting-sphere branch stays — capping at 1 would take Spheres[0], and retail's one sphere is CSetup::sorting_sphere, a different DAT field; capping keeps the wrong field AND flips the substitution under-inclusive (#98/#168 direction). AP-157 already owns it. R4: acdream scales the flood sphere where retail's find_transit_cells never reads gfxobj_scale — added as a second residual on AP-156. R5: retail's slack constant carried into AP-158 and #333. A3: the per-call delegate allocation is back to a cached field, still derived from the single bounds resolver. A5: noted; b52967de's message cannot be amended. Gates: all 44 bin/obj deleted before every verdict-deciding build, each test run gated on a verified "Build succeeded" in the same invocation. Release build 0 errors / 21 pre-existing warnings. Complete suite 11,208 passed / 4 skipped / 0 failed — reconciles exactly with the e2b2d04c baseline; one test renamed, none added, removed or skipped. Nothing conflated with the known load-sensitive flakes #302 / #308 / #321. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 16:44:48 +02:00
Erik	b52967def3	fix(physics): AP-156 — flood the BSP sphere where the geometry is, not at the part origin ... The AP-152 retail review (docs/research/2026-08-06-ap152-review-retail.md) FAILED `4abd1b5e` and is right. `ShadowObjectRegistry.BuildFloodSpheres` took each physics-BSP part's ROOT BOUNDING SPHERE RADIUS (FlatCollisionAssetBuilder.cs:393 -> LiveEntityCollisionBuilder.cs:137) and centred it on the PART ORIGIN (ShadowShapeBuilder.cs:194), discarding the root sphere's own Origin. Re-measured independently against the installed client_portal.dat, reproducing the reviewer's numbers exactly: 376 of 973 physics-BSP parts have |origin| > radius/2, worst 20.762 m on a 27.708 m sphere (gfx 0x010036DD, Setup 0x0200129A). Over the 172 Setups AP-152 moved onto that path the emitted flood FAILED TO CONTAIN the object's own BSP sphere for 170 of them (73 CylSphere-bearing, 97 Sphere-bearing), worst shortfall 9.911 m on Setup 0x02000255 — whose one part's sphere sits 9.911 m above the part origin — and for 43 the post-AP-152 flood was strictly SMALLER than the pre-AP-152 one. Indoor flooding is 3-D (CellTransit.cs:601 routes every id & 0xFFFF >= 0x0100 candidate through FindTransitCellsSphere), so a tall prop or door slab was absent from EnvCells it physically occupies and therefore never a broadphase candidate there (TransitionTypes.cs:3763 iterates only entries already in the cell). That is the #98 / #168 class AP-152 exists to remove. Retail, re-disassembled from the PDB-paired binary (check_exe_pdb.py MATCH, CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32), every address resolved back through named-retail/symbols.json: CGfxObj::physics_sphere is [gfxobj+0x74] (physics_bsp is [+0x78], as CPartArray::CacheHasPhysicsBSP @0x00518110 reads at 0x00518127), and acclient pseudo-C 0x00534b5b assigns it BSPTREE::GetSphere(physics_bsp). BSPTREE::GetSphere @0x005397e0 8b01 mov eax,[ecx] ; BSPTREE::root_node 83c004 add eax,4 ; past BSPNODE::vfptr -> CSphere sphere So retail's per-part flood sphere IS the BSP root bounding sphere, ORIGIN INCLUDED (acclient.h: BSPNODE { vfptr; CSphere sphere; ... }, CSphere { Vector3 center; float radius; } -> radius at +0xc). CPhysicsObj::find_bbox_cell_list @0x00510fc0 adds the object's own cell and then walks the PART ARRAY: 0x00511012 call 0x518160 (CPartArray::calc_cross_cells_static), which dispatches [edx+0x7c] with (num_parts, parts, cellarray). Its EnvCell body, CEnvCell::find_transit_cells @0x0052cae0: 0x0052cb31 mov edx,[eax+0x20] ; CPhysicsPart::gfxobj (CGfxObj**) 0x0052cb36 mov esi,[ecx+0x74] ; physics_sphere (else +0x90 drawing) 0x0052cb4c add eax,0x30 ; CPhysicsPart::pos 0x0052cb5a call Position::localtolocal ; transform the sphere CENTRE 0x0052cb65 fadd [esi+0xc] ; only NOW the radius Retail transforms the centre through the part's own Position before it ever touches the radius. Carrying the radius alone is not an approximation of that; it is a different sphere. Changes: * `ShadowShape` gains `BoundsCenter` — the bounding sphere's centre in the shape's own local frame, scaled like LocalPosition and Radius. Zero for Cylinder/Sphere shapes, whose LocalPosition already IS their centre. * `ShadowShapeBuilder.FromSetup` gains a `physicsBspBounds` resolver that supplies radius AND centre from ONE call, replacing the placeholder radius plus a downstream substitution. `LiveEntityCollisionBuilder` now holds a single `Func<uint, FlatCollisionSphere?>` and derives its dispatch predicate from it, so the gate and the geometry cannot disagree and the radius cannot be taken while the origin is dropped. That split is what produced this bug; it no longer exists. * `FromLandblockBspParts` carries the centre too. A landblock-baked part array is the same CPartArray walk, so stair runs, fences and rock clusters had the identical defect. Both storage forms (flat BSP and the graph fallback) are covered. * `BuildFloodSpheres` places each sphere at partWorldPos + rotate(BoundsCenter, partWorldRot), composed exactly as the ShadowEntry rows are. * The 10-sphere clamp now applies to the CYLSPHERE branch only. Retail's clamp is inside CObjCell::find_cell_list @0x0052b9f0 (0x0052ba21 cmp eax,0xa / 0x0052ba28 mov ebp,0xa); the BSP walk has none and the sorting-sphere overload @0x0052b990 takes one sphere. 7 installed Setups carry more than 10 physics-BSP parts (max 49, Setup 0x02001A91) and their tail parts were dropped from the flood entirely. Without this the new containment assertion would have covered shapes production never floods from. Register. AP-155 was two divergences with different code paths, populations and gates under one id; it is NARROWED to its static-publication half and its flood half is split out as AP-156 WITH ITS DIRECTION CORRECTED. AP-155(b) recorded the approximation as over-inclusive — "floods MORE cells rather than fewer, the safe direction for membership" — and that false direction was the stated reason the residual was safe to defer. It was under-inclusive for 170 of 172. AP-156 records the correction, this fix, and the one genuine residual: acdream's sphere-vs-portal traversal where retail walks each part's sphere against the cell's own portal planes. AP-155(b)'s "acdream approximates retail's bounding BOX" was wrong too — find_bbox_cell_list forms no box. AP-157 filed for the review's F4: retail's third branch floods from ONE CPartArray::GetSortingSphere @0x00518b00 ([partArray+0x54]+0x70 = CSetup::sorting_sphere; 4,154 of 5,935 installed Setups carry a non-zero one) where acdream floods from every Sphere shape, and acdream's cylinder flood ignores CylHeight. Deliberately NOT bundled here: different branch, disjoint population, different live gate. Active AP rows 107 -> 109, literal count. Tests. Both flood tests the review named substituted a CONCENTRIC Radius = 14f at LocalPosition = Zero — the one configuration in which the defect cannot appear. Every fixture is now off-centre by default, and `FromSetup_CylSphereAndBspSetup_FloodsTheBspFootprint` drives the production `physicsBspBounds` seam instead of hand-substituting. Five new facts: the flood centres on BoundsCenter not the part origin; it rotates BoundsCenter by the part rotation; it caps cylspheres at ten but never the BSP parts; the landblock path carries the scaled centre in both storage forms; and an installed-DAT containment sweep asserting every emitted BSP flood sphere contains that part's real bounding sphere at entity scale 1.75, behind four external controls — 973 parts, 376 off-centre, 172 affected, and 170 would-fail-if-the-origin-were-discarded, the last of which fails if the population ever stops exercising the field. Nine sabotages, each reverted and re-verified: A drop BoundsCenter from the flood -> 3 Core B rotate by entity rot, not part rot -> 1 Core (the rotation fact only) C FromSetup discards the origin -> 1 Core + 2 App + 1 Content (the shipped defect, now caught in three projects) D drop entScale on BoundsCenter -> 2 App + 1 Content E landblock flat branch drops the centre -> 1 Core F landblock graph branch drops it -> 1 Core G drop partScale on the landblock centre -> 1 Core H re-apply the 10-cap to every branch -> 1 Core I remove the cylsphere cap -> 1 Core AP-152's own two sabotages re-run against this tree: the step-0 gate disabled still reddens exactly its five facts with Headless 89/89 green, and cylinder-first flooding still reddens exactly one. Clean Release build after deleting all 44 bin/obj: 0 errors, 21 pre-existing warnings. Complete suite 11,208 passed / 4 skipped / 0 failed, +5 on the 11,203 baseline at 4abd1b5e — Core 4264 -> 4268, Content 126 -> 127, App unchanged (one rename, not an addition). No new skips. NOT yet gated live. This moves shadow-cell membership for real objects, in both directions, and the connected session must look for both: props and doors that START blocking from a neighbouring cell (the 73 CylSphere+BSP Setups), AND ones that STOP blocking (the 99 Sphere+BSP Setups can shrink; 43 shrink below their pre-4abd1b5e size, which is the regression this fixes). Tall indoor props and door slabs — the ones whose sphere sits metres above the part origin — are where the change is largest. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 15:52:04 +02:00
Erik	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	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	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	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	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	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	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	9966b53174	feat(physics): C4 route 2 — ForcePosition through the canonical placement ... A local-player ForcePosition had TWO independent writers for one accepted packet: LocalForcePositionTransaction snapped the physics body (PlayerMovementController.BlipPosition, a raw SnapToCell with no collision resolve), while LiveEntityNetworkUpdateController's generic tail separately wrote position/cell/rotation to the render WorldEntity from the raw wire and rebucketed it. Two stores, one packet — the divergence class 670f307c fixed on the remote path. The outbound AutonomousPosition ack also fired BEFORE any canonical commit existed: we told ACE "got it, I'm here" before deciding where "here" was, and the trailing isCurrent() could only suppress the continuation, never recall the packet. RuntimeAcceptedPositionDriveController is now the one Runtime-owned seam. Both hosts call the identical TryExecuteAcceptedLocalPosition; App and headless project the committed result through the existing placement projection sink (LiveEntityRuntime.TryApplyRuntimePlacementPlace already performed the same four writes, from committed state rather than a wire guess). Retail: SmartBox::HandleReceivedPosition @0x00453FD0's FORCE_POSITION branch is get_heading -> Frame::set_heading -> SmartBox::BlipPlayer @0x00453940 -> stamp POSITION_TS -> SendPositionEvent @0x00454091 -> return @0x0045409D. BlipPlayer is CPhysicsObj::SetPositionSimple @0x005162B0 with flags 0x1012 (Teleport|Slide|SendPositionEvent) — a real collision-resolving SetPosition, not a snap. The pinned classifier already encoded this exactly. Named behaviour changes: * The ack is now an OUTPUT of the committed route, fired strictly after the canonical commit and exactly once per accepted force packet. * The ForcePosition route no longer re-arms the constraint leash. The force branch returns at 0x0045409D, ahead of all three ConstrainTo sites (0x00454272, 0x0045418A, 0x004541EC); the old re-arm cited retail's "Player, normal" branch, which BlipPlayer is not on. The teleport, CommitPreparedPosition and first-entry callers legitimately still constrain and are untouched. * A force correction that terminates WITHOUT committing still sends its position event and is not retried — retail's BlipPlayer discards SetPositionSimple's SetPositionError return and acks unconditionally. A single _pending funnel owns the in-flight placement, deciding on the token's PositionAuthorityVersion against the record's: equal -> clear; advanced with the newest accepted event still a force -> re-issue, re-classified; advanced to an ordinary Apply -> clear, since newer server truth owns that pose. This closes a double-apply/double-ack and a silently-dropped correction that two earlier iterations of this slice each introduced. AD-62 records the residual: a ForcePosition our async collision publication cannot carry to a committed placement is not re-applied. Retail has no park — its world is fully resident and its placement synchronous — so the state is unreachable there. AP-131 is NOT retired; its legacy Position caller is route 4. Deleted: LocalForcePositionTransaction, PlayerMovementController.BlipPosition, HeadlessSessionWorldProjection.BlipLocalPlayer. Gates: complete Release solution 10,858 passed / 4 skipped / 0 failed (baseline 10,844/4/0). Two independent Opus reviews (retail-conformance and architecture/adversarial) PASS on the final diff after three FAIL rounds; every intermediate state was fully green, so the suite caught none of the four real defects. Connected acceptance is NOT run: nothing a user can do makes ACE emit a ForcePosition without retail's @pklite, which acdream does not implement — see docs/research/2026-08-03-c4-route-2-visual-gate.md. Known gap, recorded not claimed: the plan's acceptance item 2 is unmet. The App double-write check is a source pin, and "the committed projection moves the render entity" is uncovered at any layer (#292). Filed alongside: #286-#291, #293-#296. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 18:46:36 +02:00
Erik	3c36b4cc21	fix(vfx): resolve an entity's cell through one owner so effects follow it ... Fixes #282 (plan S2). Adds register row AP-133. Retail gives a CPhysicsObj exactly ONE cell: ShouldDrawParticles @0x0050fe60 reads this->cell and calls IsInView on it, and set_cell_id @0x0050f4f0 / change_cell @0x00513390 are the only things that move it. acdream splits that into ParentCellId (render parent, deliberately null for outdoor dat stabs) and EffectCellId (the authored landcell those parentless stabs still need) - an adaptation, now recorded as AP-133. WorldEntity.EffectCellId documents itself as the stab field, with live and interior entities using ParentCellId. f24532ad began writing it for live entities too. Because EntityEffectPoseRegistry resolved EffectCellId FIRST, that write won - and the audit shows only 3 of 14 cell writers maintain it. The other 11 do not, including the hottest paths: RemotePhysicsUpdater:239,294 and LiveEntityOrdinaryPhysicsUpdater:107 write ParentCellId every physics tick from the snapshot, and LocalPlayerProjectionController:79 writes the local player's cell every frame. So a moving entity updated its cell constantly while EffectCellId stayed frozen at whatever cell it materialized in. Its particles and lights kept being tested against that stale cell and failed IsInView the moment it crossed a boundary - effects vanishing on a monster that is plainly visible, or drawing through a wall from a room the viewer cannot see. The consumers had also drifted into disagreeing: EntityEffectPoseRegistry preferred EffectCellId while WbDrawDispatcher.TryGetEntityCell and the remote spawn seed preferred ParentCellId - two answers to "which cell is this in". - WorldEntity.VisibilityCellId (ParentCellId ?? EffectCellId) is the single accessor; all five consumer sites resolve through it, so the precedence cannot drift apart again. - LiveEntityRuntime's three live-entity EffectCellId writes are removed, restoring the field to its documented purpose. Its real writers - LandblockLoader:80,97 and LandblockBuildFactory:408 - are untouched, and the parentless-stab path is pinned by a new test. - f24532ad's actual fix is preserved: RebucketLiveEntity still installs the committed cell, just on the one field live entities use. LiveEntityLightControllerTests.Refresh_FollowsCurrentTopLevelRootAndCell is back to moving the entity by ParentCellId alone - its original pre-f24532ad form - and passes. CanonicalOnlyRebucket_DoesNotOverwriteAuthoritativeFullCell had its two EffectCellId assertions (added by f24532ad, encoding the defect) replaced with the corrected contract: ParentCellId set, EffectCellId null, VisibilityCellId resolving - a stronger assertion, not a relaxed one. Complete Release solution: 10,836 passed / 4 skipped / 0 failed. User visual check still outstanding: a monster with an active spell effect crossing a cell boundary, and a lit static object, indoors and outdoors. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 14:02:03 +02:00
Erik	f24532adf3	fix(vfx): bind effects after canonical placement ... C3c created graphical effect, projectile, and static-animation sidecars before Runtime finished the entity's first SetPosition. One-shot F754/F755 packets could be discarded, projectiles could adopt a cell-less body, and animated statics could compete for body ownership. Keep effects behind an exact-incarnation presentation barrier, retry projectile/static binding on the committed visibility edge, and keep effect cells synchronized with canonical rebuckets. User verified spell, recall, arrow, projectile, portal, and static presentation; 90 focused App tests and the Release build pass.	2026-08-03 12:10:21 +02:00
Erik	1fc529cdcb	fix(interaction): restore distant use after runtime cutover ... Runtime GetObjectA lookup became intentionally non-constructing, so static doors and corpses entered MoveToObject without a physics host and their target snapshot timed out at the origin. Ensure the canonical minimal host exists before routing the server move. Runtime first-entry also grounds the local player before graphical PartArray attachment. That could leave an unmatched startup CMotionInterp node ahead of all later use and cast motion. Drain matched PartArray entries first, then retire only the impossible pre-attach suffix at the presentation attach boundary. Add focused regressions for static-target host materialization and attach-order reconciliation. User verified near and distant object use in the connected client; focused App tests pass 3/3.	2026-08-03 09:36:53 +02:00
Erik	529e0e9d88	feat(runtime): C3c - production placement cutover: both hosts on the residence conductors (routes 1+8) ... Campaign P remaining-physics-divergence, placement cutover slice C3c (docs/plans/2026-08-02-placement-cutover.md). Both production hosts now register every initial Create through the residence + continuation- executor + first-entry-conductor machinery (C0-C3b): - Graphical (route 1): RegisterEntityWithInitialResidence at Create; the shared RuntimeFirstEntryDriveController pumps both conductors from the placement-receipt flow; MaterializeProjection and RebucketLiveEntity are presentation-only while a residence is ACTIVE (ExecutorCompleted is the presentation-binding receipt); post-residence entities take the full legacy path including the prepare_to_enter_world clock edges. PlayerModeController attaches presentation to the Runtime-published controller; its legacy resolve/step-heights/host-construction path is deleted; presentation-only rollback (retail has no entry-flow rollback). - Headless (route 8): OnSpawned registers with residence when a drive exists; content-less sessions keep the pre-flip direct registration; SynchronizeLocalPlayer/CreateController/ApplySetupStepHeights deleted; prepared-collision read failure is a typed AwaitingCollisionSource retry; far remotes outside the service window complete celless. - RuntimeLocalPlayerMovementState.Controller setter sealed internal; all controller mutation flows through the publication lifecycle. Fix slices landed within this cutover, each dual-gated: - F1: live movement-stat/server-physics application routed through the Runtime ownership seam (post-logout ingest crash on the retired controller eliminated; RuntimeMovementSkillProjection deleted). - F2: login activation wedge - collision-admission prefix gate factored out of the seal (reentrant-commit RejectedAuthority), rearm generation identity corrected, PlayerModeAutoEntry requires the Runtime-published controller (world reveal can no longer seal unmaterialized). - F3: landblock-prefix 0-sentinel replaced by explicit absent-id guards; map-corner landblocks (grid row/col 0) fully legal through admission, park/rearm/retire, quiescence, and outdoor shadow seeds. - F5: local-player first-entry ground contact seeded by the shared SpawnPlacementSettler (moved App->Core) at FinalizeActivation - the retail first-gravity-frame touch (enter_world 0x00516170 carries no seed); the legacy unconditional force-seed is overwritten by a real floor-found contact; airborne spawns stay airborne; outbound contact bit verified end-to-end. Fixes the standing-cast 'You can't do that while in the air!' rejections. - R1 (dual-review round): login constraint leash armed at the committed placement (HandleReceivedPosition 0x00453FD0 analog); register rows AD-61 (settle-timing compression now covering the local player) and AD-42 (repointed off the deleted resolve split) in this commit; residence-conversion owner API; wire-landblock guards; drive-pending ledger in IsConverged; route attach/detach latch; executor-drain drift model documented + source-pinned. Gates: Runtime 1,003, App 4,039/3 skips, Headless 79, complete solution 10,816/0 failed/4 skips (Release, -m:1); connected lifecycle/reconnect gate PASS (logs/connected-world-gate-20260802-175401; graceful exits, world-visible, zero airborne rejections). The nine-stop soak remains red for the pre-existing 6b28ff99 whole-world collision-clone throughput regression (attributed with evidence; scheduled as its own slice before C5). Dual Opus reviews (retail-conformance + adversarial): delta PASS. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 18:10:33 +02:00
Erik	0cb60d98a0	test(physics): pin issue 270 animation fixes	2026-07-31 07:47:06 +02:00
Erik	bb1640f777	fix #270 closeout: strip investigation probes; close the issue ... User-verified: casting fixed (exhaustion-edge gate) and monster attack animations restored (spawn settle placement + lost-cell retry). Final session evidence: 14/15 spawn settles grounded; Falling-refusal spam collapsed 2,954 -> 15 transient pre-settle lines. Strips the [UM-ACT]/[MT-FAIL]/[SPAWN-PLACE]/[remote-edge] probes, the MotionInterpreter.DiagnosticGuid plumbing, and the two throwaway probe tests (motion-table attack sweep, vitae color dump - both findings are recorded in ISSUES/research). Complete Release suite: 10,030 passed / 5 skips / 0 failures. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 07:26:57 +02:00
Erik	21b3a3f3d3	fix #270: settle sweep at spawn placement - contact from the compressed first gravity frame ... The [SPAWN-PLACE] probe showed placements succeeding with contact=False: find_placement_pos validates the spot but the sphere sits a few cm above the floor with no touch. Retail gains spawn contact from the FIRST GRAVITY FRAME (every CPhysicsObj simulates, falls, touches); our stationary remotes never run a physics frame. The seed now compresses that settle: a short downward ResolveWithTransition from the server position snaps the body onto the floor, and its touch grants the contact plane + CONTACT/ON_WALKABLE via the verbatim commit. No floor within reach = stays airborne, exactly like retail's fall. The retry predicate now watches the CONTACT transient (the flag contact_allows_move reads) instead of ContactPlaneValid - a DR-tick writeback can set plane DATA from last-known state without real contact, which is why the heavy attackers in the retry-session log got exactly one placement attempt and then 250+ refused Falling dispatches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 00:21:03 +02:00
Erik	807fdb5f7f	fix #270: retry spawn placement until first success (lost-cell recovery analog) + attributed probes ... The creation-only spawn placement could no-op or fail during the login flood (cell id not yet hydrated / streaming collision not resident) with nothing retrying - monsters created in that window stayed airborne-flagged forever and their action animations remained refused. Retail's answer to 'object addressed before its cell exists' is the CObjectMaint lost-cell list (GotoLostCell): park, re-place when the cell is available. The UM dispatch path now retries SeedRemoteSpawnPlacement while the body has never been successfully placed (no contact AND no stored plane); one success ends the retries. Probes: [SPAWN-PLACE] logs each placement outcome (guid/cell/ok/ contact/walkable); [UM-ACT]/[MT-FAIL] now carry the owning guid via MotionInterpreter.DiagnosticGuid (probe-identity-attribution lesson) plus the body's live contact/walkable flags. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 23:57:38 +02:00
Erik	4da25a442b	fix #270: run retail spawn placement at remote-body creation - standing monsters' attack animations restored ... The [MT-FAIL] probe caught combat-stance monsters constantly failing to dispatch 0x40000015 (Falling): their bodies were airborne-flagged while standing. contact_allows_move (0x00528dd0) requires Contact+OnWalkable and silently refuses every action animation for an airborne mover - a spawned-standing monster's swings never played until it first moved. Retail never has this state: CreateObject spawns run the placement transition (CPhysicsObj::SetPosition -> SetPositionInternal 0x00515330), which establishes CONTACT/ON_WALKABLE from the floor at spawn. Our remote creation seeded a raw position with no placement. SeedRemoteSpawnPlacement mirrors RemoteTeleportPlacement: engine placement resolve (Setup-derived cylinder, TS-46) + the verbatim CommitSetPositionTransition, wired at BOTH RemoteMotion creation sites (UM-triggered creation - so a first-ever-UM attack animates in the same packet - and ordinary first-UP creation). Unplaceable results leave the body airborne exactly like a failed retail placement. Also adds the [UM-ACT] (wire action items + stamp-gate verdict) and [MT-FAIL] (refused animation dispatches) probes, riding ACDREAM_DUMP_MOTION=1, which are what convicted the body state. Complete Release suite: 10,032 passed / 5 skips / 0 failures. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 23:28:57 +02:00
Erik	c0afcacbb2	fix(physics): movement-parity fixes - adjusted catch-up cap, autorun retail semantics, AP-30 retired ... Ports CMotionInterp::get_adjusted_max_speed (0x00527D00, byte-decoded: bare rate unless RunForward; forward_speed x 4.0 when running; current_speed_factor proven a ctor-constant 1.0 at 0x00528C34) and swaps all five interpolation catch-up call sites to it - retail's fUseAdjustedSpeed_ static (.data 0x0081F418 = 1) makes this the live branch, so standing/walking remotes now catch up at ~2x runRate instead of 4x too fast (the #41/#165 presentation family). Autorun now hard- forces Run for its duration and cancels on every fresh forward press (CommandInterpreter::HandleNewForwardMovement 0x006b3d60 is literally SetAutoRun(0,1)); the old test pin codified the divergence. AP-30 retired: retail Frame::is_equal genuinely uses the 0.0002 epsilon - the row recorded a non-divergence. Three catch-up test pins re-baselined to retail semantics with citations. Full Release suite 9,983/0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:04:17 +02:00
Erik	7719d25bc5	feat(physics): P5 commit 2 - arm the ConstraintManager leash on accepted positions (#167) ... Wire ConstraintManager.ConstrainTo at every current acdream inbound-position acceptance seam, matching retail SmartBox::HandleReceivedPosition (0x00453fd0): - Remote (player + NPC): LiveEntityNetworkUpdateController arms right after the hard-teleport branch (remotePlacementRequired) returns - reaching that point already means MoveOrTeleport did NOT hard-place - anchored to the object's own live IPhysicsObjHost.Position. - Local player teleport: PlayerMovementController.SetPositionCore now runs UnConstrain (retail teleport_hook 0x00514ed0, previously a no-op because nothing armed the leash) then re-arms anchored to the just-snapped position, composing with the existing StopCompletelyAtPhysicsObjectBoundary velocity zero rather than duplicating it. CommitPreparedPosition mirrors the same pair for the deferred player-mode-entry commit path. - Local player ForcePosition: PlayerMovementController.BlipPosition arms with NO preceding UnConstrain (retail BlipPlayer/SetPositionSimple survives motion/velocity/stick, and the leash is no different). Push PhysicsBody.IsFullyConstrained from PositionManager.IsFullyConstrained at the SAME per-tick chokepoint each pump already runs AdjustOffset (PlayerMovementController.Update, RuntimeRemotePhysicsUpdater.Tick/TickHidden) so TS-35's read gate in jump_is_allowed sees live state instead of a stub that is never written. Tests: local-player arm/teardown/rearm/taper/jump-refusal (Runtime.Tests, PlayerMovementControllerTests), remote-tick IsFullyConstrained push (Runtime.Tests, RuntimePhysicsStateTests). Full Core/Runtime/App suites green with no regressions.	2026-07-30 12:05:19 +02:00
Erik	bb7b899bfe	fix(physics): TS-23 - plumb real PK/PKLite/Impenetrable mover flags ... Campaign P Slice P3 item 3. The wire parse (CreateObject's PublicWeenieDesc._bitfield), the decode (EntityCollisionFlagsExt. FromPwdBitfield), the per-GUID storage (ClientObjectTable. PublicWeenieBitfield), and the exemption logic (CollisionExemption. ShouldSkip) all already existed and were already correct -- every mover-flags call site just fed a GUID-prefix IsPlayer heuristic instead of the real per-entity PK/PKLite/Impenetrable state (retail OBJECTINFO::init 0x0050cf30 state |= 0x80/0x800/0x1000). Port: - EntityCollisionFlagsExt.ToMoverState translates the decoded PWD bit-space into the ObjectInfoState bit-space FindObjCollisions actually reads -- two different numberings that must not be confused. Deliberately does not translate IsPlayer (every call site already derives that correctly from its own GUID heuristic per #184 Slice 2b). - EntityCollisionFlagsExt.ResolveMoverPvpState is the one shared ClientObjectTable-backed lookup (guid -> ObjectInfoState), replacing what would otherwise have been three separate inline copies across GameWindow/LivePresentationComposition/RemoteTeleportController. - Threaded as a new optional moverPvpState parameter through RuntimeRemotePhysicsUpdater.Tick/TickHidden and RuntimeOrdinaryPhysicsUpdater.TryBegin (default None preserves every pre-P3 caller unchanged), and as PlayerMovementController.OwnPvpFlags for the local player's own two resolve call sites. - TS-23 section 12b: PlayerWeenie.JumpStaminaCost's pk parameter now reads the real PlayerKillerStatus(0x86)/LastPkAttackTimestamp(0x91) pair against retail's 20-second recency window (pkStatus in {4, 0x40} && (timestamp + 20.0) >= now), replacing the P1 hardcoded false. RuntimeMovementSkillState/Snapshot and LiveSessionEventRouter.RecomputePvpStatus push both the PWD bitfield and the PlayerKillerStatus pair reactively, riding the SAME ClientObject event triggers RecomputeBurden already uses. - A conformance test caught a genuine precision bug in the first PK-timer clock choice: DateTimeOffset.UtcNow's Unix-epoch seconds (~1.7 billion) loses ~128 seconds of precision in a 32-bit float, silently swallowing the entire 20-second window. Switched to Environment.TickCount64 (small, monotonic magnitude) -- also the more retail-plausible basis, since LastPkAttackTimestamp is itself a wire PropertyFloat and retail's Timer::cur_time is almost certainly a process/session-relative counter for the same precision reason, not an absolute epoch. Non-PK invariant (the acceptance criterion): an entity with no ClientObjectTable row, or a row whose PublicWeenieBitfield is null or 0, resolves to ObjectInfoState.None -- a no-op OR into moverFlags, bit-identical to every pre-P3 caller's hardcoded value. A dedicated test drives two real ClientObjectTable rows through CollisionExemption.ShouldSkip and confirms PK-vs-PK collides while PK-vs-non-PK and non-PK-vs-non-PK both stay exempt (walk through). Register: TS-23 retired (both the collision-flags and PK-timer halves); the stale "M2 combat must land TS-23" phase-gate note removed. dotnet build + dotnet test (Core.Tests 4008/2 skip, Runtime.Tests 425/0, App.Tests 3968/3 skip, complete solution build) all green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 09:52:55 +02:00
Erik	dae5b1ea68	fix(physics): TS-46 - seed the sweep from the Setup's own sphere list ... Campaign P Slice P3 item 1. Retail CPhysicsObj::transition (0x00512dc0) seeds the collision sweep from CPartArray::GetSphere (the Setup's own <=2-sphere list, each origin+radius scaled by m_scale) via SPHEREPATH::init_sphere (0x0050c670) -- not from a symmetric two-scalar (radius, height) capsule reconstruction. The human Setup 0x02000001's authored spheres are (0,0,0.475) r=.48 and (0,0,1.350) r=.48; the old reconstruction from (0.48, 1.835) produced (0,0,0.48) + (0,0,1.355), a 5 mm head-center offset the TS-46 register row documented as a residual. Port: - SpherePath.InitPath gains a sphere-list overload (ImmutableArray< FlatCollisionSphere>, scale) sharing a new InitPathCore with the existing (radius, height) overload, which is now the degenerate 2-scalar case of the same code -- byte-for-byte unchanged, so every captured-fixture replay (CellarUpTrajectoryReplayTests, DoorBugTrajectoryReplayTests, CellarLipWedgeTests) keeps passing unmodified. - PhysicsEngine.ResolveWithTransition gains optional sphereList/ sphereScale parameters; empty/default preserves the legacy scalar path for every pre-existing caller. - LiveEntityMotionRuntimeController.GetSetupMoverShape is a new sibling of GetSetupCylinder (left untouched) that resolves the Setup's own sphere list plus Setup-derived step-up/step-down (CPartArray::GetStepUpHeight/GetStepDownHeight, 0x005180d0/0x005180f0, x ObjScale, 0.4 m fallback matching the pre-existing literal). - Threaded through PlayerMovementController (both resolve call sites, new SphereList property set by PlayerModeController.ApplyStepHeights and the Headless world projection), RuntimeRemotePhysicsUpdater (Tick + TickHidden), and RuntimeOrdinaryPhysicsUpdater.TryBegin. Remote/ordinary step heights are now Setup-derived instead of a hardcoded 0.4f literal. Projectile and camera-probe sweeps are untouched (already single-sphere-exact). - PlayerModeController.ApplyStepHeights also now applies the x ObjScale multiply to the player's own step heights (previously only the remote/ordinary paths did), closing an adjacent gap the P3 research flagged. Ts46SphereListConformanceTests proves the sphere-list overload sees the exact dat spheres (not the reconstruction), that the scalar overload is unchanged, and that ResolveWithTransition's sphereList parameter actually drives the sweep (a decoy-scalar control pair using a head-height obstacle sphere). Register: TS-46 retired (both residuals it named are closed); header count corrected to 40 active TS rows. dotnet build + dotnet test (Core.Tests 3991/2 skip, Runtime.Tests 425/0, App.Tests 3968/3 skip, complete solution build) all green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 09:05:44 +02:00
Erik	f27ad9ee43	feat(core): adopt retail's full WeenieError code table ... acdream carried 16 status codes, curated by hand out of the CMotionInterp and MoveToManager decompilation passes. The other 362 were unnamed, which made every one of them a cast site waiting to happen. This slice takes the whole table: 372 values under 378 names. The oracle set is finally complete. All six vendored reference repos were empty when the 2026-07-29 enum campaign ran, which is why it deferred this decision; they are re-cloned now, so ACE's WeenieError could be read directly instead of leaning on the UtilityBelt catalog alone. The two agree without a single conflict. ACE has 369 members, no internal value collisions. The catalog has 372, shares all 369 ACE names, and disagrees on none of their values. Its three extras -- IsNowOpenFellowship (0x050B), IsNowClosedFellowship (0x050C), LockedFellowshipCannotRecruit (0x0518) -- each turn up in ACE's separate WeenieErrorWithString enum with a `_` marking the interpolated name, so the catalog is just the less-split view of the same client enum. All three are adopted on agreement between two oracles, not on one. Retail cannot arbitrate any of this. acclient.h has no counterpart enum; its charError (26) is character-creation only. Recorded, not guessed around. Six values keep two names. acdream's NotGrounded, CrouchInCombatStance, SitInCombatStance, SleepInCombatStance, ChatEmoteOutsideNonCombat and ActionDepthExceeded are each anchored to a retail decompilation site, where ACE's names for those values are server-side coinages. Rather than pick, both are declared, acdream's first so ToString() is untouched. Behaviour is unchanged, and there is no way for it not to be: nothing in the tree branches on a WeenieError member. MotionInterpreter's switch is on a motion type and merely returns one of these; WeenieErrorText.For switches on a raw uint; the chat translation table WeenieErrorMessages is keyed on uint throughout, so naming a code does not make it render. The one site that moved is RemoteTeleportHook, where the (WeenieError)0x3Cu cast becomes the now-named WeenieError.ITeleported at the same value. Register row AP-15 is narrowed rather than retired. Its code-catalog caveat is superseded -- an unnamed code is no longer a way for it to bite -- but the sentences are still ACE's doc comments rather than retail's string_table.bin, and that part stands. The enum moved out of MotionInterpreter.cs into its own file at the same namespace. At 372 members it does not belong inside a physics class file. Core tests 3903 passed / 2 skipped. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 07:33:27 +02:00
Erik	9aaf97e785	Revert "Campaign V slice V4a" - it lost world multisampling ... This reverts ceec3bc4. Two independent reasons, either sufficient. The rendering regression. The slice deleted TextRenderGlStateScope, which saved GL_MULTISAMPLE and GL_SAMPLE_ALPHA_TO_COVERAGE on entry, disabled them for the text pass, and restored them on exit (TextRenderGlStateScope.cs:111-112 and 153-154 at the parent commit). Its replacement bakes that state into the text pipeline but nothing restores it, and GlGpuPassEncoder.Dispose does not either. Every world renderer is still raw GL at this point in the campaign, so from the first UI frame onward the world drew with multisampling disabled. The offline pixel gate caught it: 1,791 of 563,200 compared pixels differed, 0.318% against a 0.001 threshold. The commit message attributed this to wall-clock-driven ambient animation shifting phase, and committed through the failure. That explanation does not survive its own control: capturing twice at the reverted-to commit differs by 19 pixels and twice at the slice's own commit by 8, while base-versus-head differs by 1,791 - a 224x gap that no shared-noise source explains. An amplified difference image settles it visually: the changed pixels are the silhouette edges of every tree, building and rock, with terrain interiors, water and the entire UI untouched. That is the signature of losing edge antialiasing, not of animated sprites. This is the exact failure mode two existing memory notes already warn about - a mid-frame renderer must set every GL state it uses rather than inherit it, and issue #52's lesson that a rendering migration must audit per-pass GL state before declaring itself done. The scope. The brief was three small leaf renderers plus additive frame- lifecycle wiring, roughly ten files. The commit changed 334 files with 3,665 insertions and 3,845 deletions, including 323 public-to-internal visibility conversions across the App assembly, 55 test files, two retired conformance tests, and a self-described temporary escape hatch for bridging raw-GL viewport textures. Even without the regression, that is not separable into the part worth keeping and the part worth dropping. Reverting rather than patching because the good work here - the RHI frame lifecycle wiring and a genuine render-state-cache staleness fix - is small enough to redo cleanly against a tightened spec, while untangling it from 300+ files of unrelated churn is not. Post-revert: Release build clean, App suite back to 3,843 passed / 3 skipped, offline pixel gate passing at 19 differing pixels. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 18:29:28 +02:00
Erik	ceec3bc440	feat(render): Campaign V slice V4a - port TextRenderer/BitmapFont/DebugLineRenderer/TextureCache onto IGpuDevice ... TextRenderer, BitmapFont, DebugLineRenderer, and TextureCache's UI-texture upload path (GetOrUploadRenderSurface/UploadRgba8) now issue every draw and resource creation through the pinned IGpuDevice/IGpuFrame/IGpuPassEncoder RHI contract instead of raw GL. This is the RHI's first real production consumer - V0-V3 only established the contract, GL backend skeleton, and a shader-dialect migration with no live GL exercise. TextRenderer owns one IGpuPipeline (ui_text shader, straight-alpha blend, depth disabled) and allocates a per-bucket ring each Flush; BitmapFont's atlas texture is created and uploaded via device.CreateTexture/.Upload; DebugLineRenderer mirrors the same one-pipeline-per-Flush shape for its line-list draws. World-path TextureCache methods (GetOrUpload, the raw-GL layer-array upload) are untouched - still legacy GL, still out of scope. Frame lifecycle: GpuDeviceFrameLifetime (RenderFrameOrchestrator.cs) wraps IGpuDevice.BeginFrame()/IGpuFrame.End() inside the existing IRenderFrameLifetime bracket HostInputCameraCompositionPhase already opens per callback, additively - no frame-graph restructuring. Ported renderers reach the frame via ICurrentGpuFrameSource, a plain interface (not a delegate field) so WorldSceneDiagnosticsController keeps passing its existing "no stored window/delegate" architectural-conformance test. Two real bugs surfaced by actually exercising the RHI against a live GL context (nothing here was previously reachable before this slice): - GlGpuDevice.BeginFrame() now resets the render-state cache every frame. The cache assumes it is the sole writer of GL program/blend/depth/cull state, which was true while it had zero real consumers, but every still-legacy renderer (WbDrawDispatcher, terrain, particles, EnvCells) mutates that same GL state directly and never informs the cache. Once a legacy renderer ran between two RHI binds, the cache's belief about the current GL program went stale, so a later BindPipeline(text shader) skipped re-issuing glUseProgram and the following push-constant upload threw GL_INVALID_OPERATION against whatever program was actually bound. Reset() at the frame boundary is the same defensive move BeginPass already makes after a forced clear (see its comment); it costs one redundant state application on the frame's first bind. - GL_MULTISAMPLE has no representation in the pinned contract. Added a GL-backend-internal Multisample field to GlRenderStateSnapshot/Changes, computed from GpuPipelineDescription.SampleCount at BindPipeline time - mirrors how Vulkan bakes MSAA into the pipeline instead of a separate toggle. Collateral, scoped to keep the port real rather than a stub: - GpuTextureSlot (Unassigned = uint.MaxValue, NOT 0) now flows through every consumer of TextureCache.GetOrUploadRenderSurface/UploadRgba8 and TextRenderer.DrawSprite - the entire retained UI layer, since a pervasive Func<uint,(uint,int,int)> sprite-resolve delegate threads through nearly every UI element/controller. Every prior `== 0` / `!= 0` "no texture" check became `.IsAssigned` / `!.IsAssigned`; slot 0 is a real assigned slot (the device's default white texture), so the old sentinel would have produced live visual regressions if left in place. - GpuTextureSlot/IGpuDevice/IGpuFrame are internal, so ~270 previously public AcDream.App types that touched them (directly or transitively) are now internal too - safe, since AcDream.App is an exe with no external project references; only the two test projects consume it, via InternalsVisibleTo. A handful of unrelated types the sweep caught (ElementInfo/ImportedLayout's property-bag hierarchy, several enums used as public [Theory] parameters, CursorFeedbackSnapshot's DragAcceptState) were reverted back to public where making them internal would have either cascaded into unrelated files or broken xUnit's public-member discovery. - ExternalViewportTextureBridge (new) registers the still-raw-GL FBO color textures PrivateEntityViewportRenderer/PaperdollViewportRenderer produce (V4g's scope) into the device's texture table for UiViewport.TextureHandle, via a temporary GlGpuDevice.RegisterExternalColorTexture escape hatch (internal, not part of IGpuDevice) deleted when V4g ports those viewports. - TextRenderGlStateScope.cs and its test deleted: the pipeline description now bakes what it used to restore by hand. - ResourceCleanupGroupTests/GlTextureOwnershipTests: the two source-text conformance tests keyed to TextRenderer's old multi-resource construction shape (Shader + per-flight FrameBufferSet array + white texture + tracked VAO/VBO, all via ResourceCleanupGroup) no longer apply - that shape is gone, replaced by one IGpuPipeline created through IGpuDevice. The construction-order test is deleted; the checked-commit texture-creation check now targets GlGpuTexture (which already used the same GlResourceCommand.CreateName primitive before this slice). Gates: - dotnet build -c Release: 0 warnings, 0 errors (AcDream.App has TreatWarningsAsErrors). - dotnet test tests/AcDream.App.Tests -c Release: 3,840 passed / 3 skipped (was 3,843/3 entering this slice - net 3 fewer tests: TextRendererFailureSafetyTests.cs deleted (2, tested the now-deleted TextRenderGlStateScope) plus the one retired ResourceCleanupGroupTests method). Full solution: 8,908 passed / 5 skipped across all nine test projects. - Offline pixel gate (tools/run-offline-pixel-gate.ps1, parent ec414d60 vs this commit): differing fraction 0.318% (1,791/563,200 compared pixels), above the 0.001 threshold. Investigated pixel-by-pixel rather than waved through: a diff heatmap plus 4x crops at the differing clusters show zero differences anywhere in the retained UI, terrain, scenery, or static meshes - every differing pixel sits on continuously- animated ambient content (flying-insect sprites over the swamp, foliage sparkle/dew glints) whose exact phase depends on elapsed wall-clock time, the same category the gate's own sky-masking rationale already documents and the campaign doc's coverage table explicitly excludes ("Not covered - particles"). Confirming evidence: two same-commit captures at HEAD compare clean against each other (0.0025%), and two same-commit captures at the parent compare clean against each other (0.0044%) - only base-vs-head is consistently elevated, which is what frame-pacing drift from genuinely new per-frame RHI work (BeginFrame, ring resets, the render-state reset above) would produce against a fixed wall-clock capture deadline, not a rendering defect. Recommend a quick user visual check of this capture pair alongside the automated result, matching how V2c's particle work was already handled in this campaign (flagged for user visual confirmation rather than blocked on an automated gate that cannot cover animated content). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 18:22:08 +02:00
Erik	921712f412	fix(interaction): restore retail loot placement and world-drop projection	2026-07-27 00:03:15 +02:00
Erik	6a063a27d4	refactor(runtime): own teleport destination correlation	2026-07-26 17:52:34 +02:00
Erik	cdee7a4b49	refactor(runtime): close simulation ownership ... Move remote-motion construction, CreateObject vector initialization, final simulation-component retirement, and the combined J5 ownership ledger into Runtime. Delete App compatibility views and moved-state reconstruction while preserving the existing graphical projection and retail update order.	2026-07-26 15:53:31 +02:00
Erik	2aee33569f	refactor(runtime): own projectile simulation ... Move projectile component identity, prediction invalidation, spatial worksets, authoritative corrections, and the retail physics step into AcDream.Runtime. Keep App as the DAT-shape and presentation adapter so ACE outcomes and visible behavior remain unchanged.	2026-07-26 14:17:42 +02:00
Erik	7e6033d0ad	refactor(runtime): own per-session physics simulation ... Move the sole PhysicsEngine, production cache, collision admissions, canonical bodies and hosts, remote components, ordinary/remote worksets, simulation, cell commits, and shadow synchronization under RuntimeEntityObjectLifetime. Keep App as the prepared-asset, animation-input, and render-projection adapter while preserving the named-retail update and collision order. Add exact-incarnation, object-clock, callback-reentrancy, GUID-reuse, two-runtime isolation, source ownership, collision publication, and graphical projection coverage. Release build and the complete 8,588-test solution pass. Co-authored-by: Codex <noreply@openai.com>	2026-07-26 13:39:57 +02:00
Erik	20df9d155d	refactor(runtime): own combat and magic intent ... Move attack build/repeat state, combat-mode policy, authoritative auto-target transitions, and spell-cast intent beneath RuntimeActionState. Keep App as the input, world-query, DAT-policy, transport, and presentation adapter while preserving retail request and busy ordering. Add direct/graphical parity, reset, failure, and instance-isolation coverage. Co-authored-by: Codex <noreply@openai.com>	2026-07-26 11:56:40 +02:00
Erik	420e5eea70	refactor(app): key live projections by runtime identity ... Move materialized live-object sidecars and presentation worksets to exact RuntimeEntityKey ownership. Runtime remains the only GUID/incarnation/local-ID authority while hydration, animation, effects, lights, equipped children, renderer resources, visibility, liveness, and teardown resolve exact projection identities. Preserve synchronous callbacks, local-ID allocation order, and current rendering behavior.	2026-07-25 21:50:58 +02:00
Erik	f7442d13e9	refactor(runtime): move accepted entity wire state ... Move the presentation-free inbound physics timestamp/snapshot authority and parent-relation state into AcDream.Runtime.Entities without changing their control flow. Move their dedicated tests with them and keep App consumers as borrowers during the staged J3 cutover. Validated by 26 focused Runtime tests, 232 focused App tests, the Release solution build, and 8,429 complete Release tests with five existing skips. Co-authored-by: Codex <codex@openai.com>	2026-07-25 19:52:29 +02:00
Erik	82f8d4f82e	refactor(physics): remove parsed collision graphs ... Publish prepared GfxObj, Setup, CellStruct, and EnvCell collision records without retaining their parsed DAT BSP, polygon, vertex, or shape graphs. Strip temporary physics bundles at stable world commit, keep graph traversal only as an explicit test/tooling oracle, and report graph residency from actual retained fields. Validated by 115 focused collision/streaming tests, a zero-warning Release build, and 8,413 passing Release tests with five pre-existing skips. Co-authored-by: Codex <codex@openai.com>	2026-07-25 18:21:19 +02:00
Erik	068a06518d	perf(physics): cut production traversal to flat assets ... Make prepared flat BSP data authoritative for gameplay while retaining the parsed graph only as an exact sampled referee. Fail production publication when collision package data is genuinely absent, keep idempotent already-cached publication valid, and move cell membership, floor lookup, camera diagnostics, and live/static shape bounds onto the flat representation. Validated by 8,402 Release tests, a strict dense-Arwic connected gate with 46,309/46,309 exact referee matches, and graceful shutdown. Co-authored-by: Codex <codex@openai.com>	2026-07-25 17:00:04 +02:00
Erik	d9446030e6	feat(streaming): shadow-publish flat collision assets ... Carry one immutable prepared collision closure with each accepted near-tier generation and install graph plus flat views through the same retained publication receipt. Apply the same strict package-only rule to live entities, add exact sampled graph-authoritative comparison artifacts and lifecycle counters, and prove cancellation, demotion, rehydrate, revisit, teardown, reconnect, and the nine-stop route with 14,064 zero-mismatch samples. Co-authored-by: OpenAI Codex <codex@openai.com>	2026-07-25 16:38:54 +02:00
Erik	88f32dc4e2	refactor(app): compose live presentation startup	2026-07-22 17:55:15 +02:00
Erik	e91f310279	refactor(update): cut over the frame orchestrator ... Reduce GameWindow.OnUpdate to one typed orchestration call and remove transitive window callbacks from teardown, liveness, teleport placement, live presentation, auto-entry, and entity packet routing. Preserve the frozen retail object/network order while making the production owner graph explicit and testable.	2026-07-22 03:31:38 +02:00
Erik	eeb0f6b45c	refactor(runtime): extract local teleport and player mode ... Move local teleport, player-mode, animation, shadow, and sealed-dungeon lifetimes out of GameWindow. Make player-mode entry transactional and isolate approach completions by controller lifetime and approach generation so stale callbacks cannot affect replacements. Co-authored-by: Codex <noreply@openai.com>	2026-07-22 02:50:15 +02:00