3349 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Erik
|
1dc81710f3 |
docs: close #32 — local edge-slide user-passed; AD-67 filed for the kept cell-id write
Both halves of #32 are now closed: remote at |
||
|
Erik
|
9b9bb6515f |
docs: the #32 'fix failed' verdict is VOID — the tested binary never contained the fix
Some checks are pending
Headless portability / portable-headless (ubuntu-latest) (push) Waiting to run
Headless portability / portable-headless (windows-latest) (push) Waiting to run
Headless portability / linux-graphical (push) Waiting to run
Headless portability / linux-vulkan (push) Waiting to run
Two checkouts, one relative launch path. Edits and builds ran in the main repo; every client launch ran from a PowerShell shell whose cwd was still the session worktree, so 'dotnet run --project src\AcDream.App\...' executed the worktree's 08-06 22:35 binary — #333 present, #32 fix, InitContactPlane and every #338 probe absent. Byte-proof both ways: 0 occurrences of the fix strings in the worktree's Core.dll, both present in the main repo's. Everything the previous entry concluded is therefore void: the byte-identical capture was the OLD code re-running (expected), the three probe silences were one fact (the instrumented binary never ran), and the 26,358-write attribution table is pre-fix baseline data of the old binary only. #32's fix returns to UNTESTED, with no evidence against it. The verification that was supposed to catch this confirmed the wrong binary: the DLL byte-check ran against the OTHER checkout's bin. So the self-report now prints typeof(PhysicsDiagnostics).Assembly.Location as its second line — binary identity becomes a recorded fact inside every capture instead of an inference from file timestamps afterwards. Memory updated with the multi-checkout rule: absolute launch paths, verify each shell's cwd before the first launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Erik
|
ee4d328408 |
docs: #32's setter split is necessary but NOT sufficient — and the instrument is not trustworthy yet
The
|
||
|
Erik
|
375cc0f950 |
docs: file #339 — stuck in portal space, destination reveal never becomes ready
Captured live 2026-08-07 with the raw log attached rather than summarised. Generation 2 to cell 0x3032001C: render, composites and collision are all False at begin and still all False at cancel, so complete and world-visible never fire and the five-second wait cue sits there until the client is closed. Filed rather than chased, per user direction. Two things recorded because they will otherwise be assumed: the same destination succeeded TWICE in the previous session, so it is intermittent rather than a broken landblock; and while it is mechanically very likely unrelated to the #32 contact-plane change landed minutes earlier (different subsystem, different thread), it fired on the first run after it, so the entry says to A/B against a binary without #32 before ruling it out rather than asserting independence. Also flags, without assuming either way, that #280's D-1 was an unrecoverable portal hang with the same visible symptom — this is either that regressing or a second mechanism wearing its face. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Erik
|
332045c7ad |
fix(physics): split set_contact_plane from init_contact_plane (#32 local edge-slide)
Some checks are pending
Headless portability / portable-headless (ubuntu-latest) (push) Waiting to run
Headless portability / portable-headless (windows-latest) (push) Waiting to run
Headless portability / linux-graphical (push) Waiting to run
Headless portability / linux-vulkan (push) Waiting to run
Measured live at Rithwic 2026-08-06 with ACDREAM_DUMP_EDGE_SLIDE=1. Six branch2/steep-cliffslide events, every one reporting curN=(-0.954,0.000,0.301) lastN=(-0.954,0.000,0.301) angle=0.0000 apply=False, outcome degenerate-cross/last-known. That is decision-table row 1 of the research doc, verbatim. CTransition::cliff_slide @0x0050a6d0 takes its slide direction from cross(steep contact normal, last_known_contact_plane.N) — it needs the surface the mover was STANDING ON as the second vector. acdream's CollisionInfo.SetContactPlane latched the last-known group on every call, so by the time cliff_slide ran, last-known had already been overwritten with the steep face itself: the cross product of a vector with itself, which is zero. Degenerate direction, no slide, walk off the cliff. Retail's COLLISIONINFO::set_contact_plane @0x00509d80 is 22 bytes and writes the CONTACT group only; the last-known group has four writers, none of them that function. So the four writes are DELETED and a new InitContactPlane mirrors CTransition::init_contact_plane @0x0050e850, writing both — the start-of-transition seed, where there is no earlier surface to remember. Only check_contact's SUCCESS branch calls it. The other eleven call sites keep the narrowed setter. This is a port, not a suppression: no guard, no grace period, no flag. The user's own A/B was the discriminator: Neftet's block plateaus hold (188 branch3/precipice-slide events, all before the teleport) while Rithwic's terrain cliff fails (6 branch2 events, all after). I had predicted the opposite — that terrain would be the flat-normal case — and position plus timeline corrected me, not reasoning. NEW DISCRIMINATING TEST, because the suite had none. It was green both before and after the production change, so nothing in it defended this behaviour. Issue32LastKnownContactPlaneTests seeds a walkable plane, asserts a steep mid-transition contact leaves it intact, and asserts the resulting cross product is non-degenerate. Sabotage-verified: restore the four writes and both discriminating rows fail while the InitContactPlane control keeps passing — the pair separates 'the latch is gone' from 'nothing writes last-known at all'. Two existing tests corrected rather than deleted. PhysicsSetPositionTests.FailedCheck_MapsCollisionHandlerResultToRetailError passed BECAUSE of the latch (the file the research named); its hook now populates both groups explicitly, since it asserts report plumbing, not setter semantics. RetailEdgeResponseOrderingTests.TransitionalInsert_ DegenerateCliffSlideOk_ContinuesOuterRetry was predicted to fail and did not — it now passes for a DIFFERENT reason (last-known absent rather than clobbered, which retail also answers with OK_TS). Its comment described the deleted behaviour and is corrected to say so, and to say it does not discriminate this fix. Also repairs the #338 probe. Its first placement in PlayerMovementController printed nothing across 11,523 live log lines — the wrong one of two resolve call sites — so it moves to PhysicsEngine.ResolveWithTransition where every caller passes through, filtered to the player. The dead site is removed rather than left in place; a probe that never fires is worse than none. The flag test now precedes the interpolated string: building it eagerly cost 128 B per resolve with the probe OFF, which Slice I1's zero-allocation gate caught. Suite 11,234 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Erik
|
45d7154712 |
probe(physics): ACDREAM_PROBE_STEP_HEIGHTS — three readings along #338's chain
Some checks are pending
Headless portability / portable-headless (ubuntu-latest) (push) Waiting to run
Headless portability / portable-headless (windows-latest) (push) Waiting to run
Headless portability / linux-graphical (push) Waiting to run
Headless portability / linux-vulkan (push) Waiting to run
The live reading of 0.400 says the controller held its default at that instant, not why. Two very different causes produce it: the Setup-derived prepare/publish path never runs for the local player, or it runs and a later writer clobbers the result. Fixing without knowing which is a coin flip. One reading at each hop — prepare (Setup value computed and scaled), publish (assigned to the controller), resolve (what the resolver is actually handed) — with a decision table on the flag mapping each pattern to its cause, including the 0.000 case that would mean a null Setup took the retail dummy path. Edge-triggered per site, so the per-tick resolve site prints once per distinct pair and cannot drown the two one-shot sites it exists to be compared against. Prepare prints the raw authored pair beside the scaled one, so a surprise separates wrong-Setup from wrong-scale without a second run. Lives in PhysicsDiagnostics per code-structure rule 5 rather than as per-call-site env reads. Zero cost when off. Suite 11,231 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Erik
|
d5dd0b554b |
docs: research #32's local half — the last-known contact plane is clobbered mid-transition
Report-only investigation of the local player running off cliff edges. No production or test code changed. Retail's rim slide is CTransition::cliff_slide (0x0050a6d0), whose direction is cross(steep contact normal, last_known_contact_plane.N) — it needs the surface the mover was standing on as its second vector. Disassembly of the PDB-paired binary shows COLLISIONINFO::set_contact_plane (0x00509d80, 22 bytes) writes only contact_plane_valid / contact_plane / contact_plane_is_water; the last-known group has exactly four semantic writers in retail, all outside the per-substep collision response (CTransition::init_contact_plane 0x0050e850, init_last_known_contact_plane 0x0050e8e0, the validate_transition tail 0x0050ad07, and the clears). acdream's CollisionInfo.SetContactPlane latches the last-known group on every write, at all 13 call sites. The step-down probe's own steep plane therefore overwrites the ground reference before EdgeSlideAfterStepDownFailed reads it, CliffSlide's cross product goes to zero, its degenerate OK return displaces nothing, and TransitionalInsert's retry accepts the candidate hanging over the drop. The latch dates to |
||
|
Erik
|
801ff5fd44 |
docs: #338 answered — retail DOES read the authored step height, so this is real
The gating question is closed against the decomp rather than reasoned from our source. CTransition::step_up @0x0050b610 defaults step_up_height to 0.0399999991f and substitutes object_info.step_up_height when (state & 2); step_down has the same shape at 0x0050b852 and reads the authored value unconditionally at 0x0050c232. Two things fall out. Retail's fallback is 0.04, not 0.4 — our value matches neither the fallback nor the authored 0.600/1.500. And state bit 0x2 is OnWalkable, so retail applies the authored height only while standing on walkable ground. We already port that gate faithfully in Transition.DoStepUp, including the stepDownHeight = oi.StepUpHeight assignment that reads oddly but is exactly what retail passes. The gate is not the defect; only the value fed into it is. The local player is the only affected population: its controller fields initialise to 0.4f, while remotes and live entities get Setup-derived values. The property's doc comment names PlayerModeController. ApplyStepHeights as the authoritative writer — that method does not exist anywhere in the tree; the identifier appears once, in the comment. Deliberately NOT fixed. A real writer does exist further out, and RuntimeSetPositionMoverPreparation does compute the Setup-derived value, so the plumbing is there. Whether it runs for the local player or runs and is overwritten is unproven — the probe reading 0.400 says the controller held its default, not why. Setting the field without knowing which path won would be a coin flip. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Erik
|
677f9a1628 |
docs: origin is a lagging mirror, not a stale local ref — correct the correction
The previous fix said the local origin/main ref had not been written since April and was three months stale. It was not stale: a fresh git fetch origin returned it unchanged at |
||
|
Erik
|
0ce54a5c4a |
merge: #333/#334 Neftet collision — the query-site broadphase is deleted
Some checks are pending
Headless portability / portable-headless (ubuntu-latest) (push) Waiting to run
Headless portability / portable-headless (windows-latest) (push) Waiting to run
Headless portability / linux-graphical (push) Waiting to run
Headless portability / linux-vulkan (push) Waiting to run
Closes #333, #334 and #337. The Neftet plateau defect — wedged at the
top, jumps sinking into the mesh, corpses falling through — was one
mechanism presenting as three symptoms: Transition.FindObjCollisionsInCell
measured the mover's distance to a shadow entry's part ORIGIN and compared
it against the BSP ROOT BOUNDING SPHERE's radius, two points 23.556 m apart
for that rock. Geometry deep inside the real sphere was discarded before
BSPQuery ever ran.
Deleted rather than re-centred: retail has no distance pre-filter at all,
disassembled from the PDB-paired binary rather than read from Binary Ninja.
Cell membership is retail's broad phase.
Also lands #334's outdoor extent walk (retail's find_bbox_cell_list),
retires AP-158, files #338, and opens Campaign S for the twelve remaining
collision-domain items — now the active work ahead of the M4 vendor
slices per user direction that physics and collision come first.
The ACDREAM_PROBE_SUPPORT / ACDREAM_WIRE_MESH / ACDREAM_PROBE_REACH probe
families are deliberately retained: C5c's connected gates still owe the
instrumentation they provide.
Gate: clean-room full solution suite at
|
||
|
Erik
|
bec5c69daf |
docs: correct the C5c handoff's "nothing is pushed" line — it was false
The handoff's opening said "Nothing is pushed — the branch does not exist on the remote, and there are 388+ unpushed commits ahead of origin/main." All three clauses were wrong, in the direction that would most alarm a successor into thinking the campaign could be lost. main and github/main are both |
||
|
Erik
|
a069094770 |
docs: open Campaign S — collision shape & response fidelity
Plans the twelve remaining collision-domain items. Slice boundaries come from file coupling, not from how the symptoms group: AP-157, the AP-156 residual and AP-159/#335 all edit ShadowObjectRegistry (two of them the same function), so they are ONE slice against a pinned contract per feedback_dont_parallelize_coupled_plan_slices. Ordering is membership-before-query, because we just watched a membership fix (AP-156) be made invisible by a query-site defect (AP-158) directly downstream of it. Every slice opens with a measurement that can cancel it. In this domain over the last two weeks: AP-155's recorded direction was inverted, AP-156's risk column was wrong (and that is why #334 hid inside it), AP-22 described an unreachable branch, and #331's headline claim was refuted. One row in four was materially wrong about its own population, direction, or existence. Two items are deliberately reclassified. AP-83/AP-91 are NOT fixes — the x87 PerfectClip tails do not decompile, so there is no retail text to port; the honest deliverable is proving the branch unreachable. AD-65's "live lead for #269" framing is retracted: #269 closed 2026-07-31 and AD-65's sign is opposite to that symptom. #32 and #338 are pre-work, not slices — both are blocked on a measurement far cheaper than the fix, and #32 is the outstanding half of the user's original two-bug report, so it does not sit behind six slices. Live gates batched into four sessions; #330 needs none and is the parallel track for whenever a gate is blocking. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Erik
|
3171f43002 |
docs: file #338 — player steps at 0.400 where Setup 0x02000001 authors 0.600/1.500
Spotted in the #337 [support] capture and deliberately left out of that fix so the fix stayed falsifiable. Filed with what is NOT established attached: whether retail reads the authored Setup field at all is the first question, and the entry says to grep named-retail before touching anything. The #337 lineage already burned two diagnoses reasoned from source. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Erik
|
ea83b043df |
fix(physics): delete the query-site broadphase reach filter (#333, closing #337)
Transition.FindObjCollisionsInCell discarded a shadow candidate when |currPos - obj.Position| > sphereRadius + obj.Radius + movement.Length() + 2f obj.Position is the part ORIGIN; obj.Radius is the physics-BSP ROOT BOUNDING SPHERE's radius, measured about a centre AP-156 established is frequently metres from that origin (376 of 973 installed physics-BSP parts sit further from their part origin than half their own radius, worst 20.762 m). Geometry deep inside the real bounding sphere was therefore thrown away before BSPQuery ever ran: solid near the origin, permeable in a bounded shell beyond it. For the Neftet rock 0xC8766009 / gfx=0x01004751 the two points are 23.556 m apart, which is #337 — wedged on the plateau, jumps sinking into the mesh, corpses falling through. A live capture recorded 7,225 rejections on that one owner, every single one with wouldAcceptAtCenter=True. Deleted rather than re-centred. Retail has no distance pre-filter, disassembled from the PDB-paired v11.4186 binary (CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32) rather than read from Binary Ninja: CObjCell::find_obj_collisions @0x0052b750 walks shadow_object_list and calls CPhysicsObj::FindObjCollisions (0x0052b78b) UNCONDITIONALLY; its only early-out is insert_type == INITIAL_PLACEMENT_INSERT (0x0052b759). CPhysicsObj::FindObjCollisions @0x0050f050 contains no float compare at all. CPartArray::FindObjCollisions @0x00518180 is a bare do/while over parts, and CPhysicsPart::find_obj_collisions @0x0050d8d0 is two null checks plus a call. Retail's only spatial rejection is the BSP node bounding-sphere test inside the walk — correctly centred, which is exactly what the deleted filter was not. Re-centring it (carry BoundsCenter on ShadowEntry) would have preserved an invention retail does not have, including a +2f slack and a movement.Length() term with no retail counterpart, and left a second reach budget to be tuned forever. Retail's own cross-cell slack constant is F_EPSILON = 0.0002 m, not 2 m. The method's comment claimed the filter was "the analog of the part sorting-sphere early-outs inside retail's CPhysicsObj::FindObjCollisions — response-neutral, pure perf". Both halves were false and cost #333 and #337; it is replaced by the disassembly above. Gate: Issue333BroadphaseReachFilterTests drives the production path end-to-end (ResolveWithTransition -> FindObjCollisionsInCell -> CollisionTraversal) on a DAT-free fixture so it runs everywhere, as a discriminating pair. Sabotage-verified: restore the pre-check and OffCentreBspFloorStopsAFallingMover reaches z=37.800 — exactly the unobstructed fall, blockedAtLeastOnce=False — while CentredBspFloorStopsAFallingMover keeps passing. Without the control a fixture unable to fall would pass the first test for the wrong reason. Issue337's skipped TheBroadphaseAdmitsTheSurfaceTheMoverIsStandingOn asserted the now-deleted predicate and could never have gone green; it is rewritten as installed-DAT evidence pinning BOTH halves of the diagnosis and is no longer skipped. Perf measured, not assumed (Release, synthetic all-BSP cell, per ResolveWithTransition): at 38 candidates — the live maximum — 10.61 us -> 16.68 us (1.57x); at a deliberately unreachable 200, 17.34 -> 39.48 us (2.28x); ~0.16 us per additional candidate tested. Over 19,701 live [reach-q] samples the in-cell count is p50 = 9, p99 = 32, max 38. The ACDREAM_PROBE_REACH rejectedReach column is kept and is now structurally 0, so a post-fix capture stays comparable with the pre-fix one; dropping it would make the two incomparable. AP-158 retired (110 active AP rows). #333 and #337 closed pending the user's live acceptance at Neftet. Solution suite 11,231 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Erik
|
5a1eeace73 |
docs(physics): #337 diagnosed — it is #333's query-site broadphase, not the mesh
Report-only. No production code changed. The collision mesh is present, correctly shaped, correctly placed in the world, and the BSP traversal reaches every part of it. The mover never gets as far as the query. FindObjCollisionsInCell's per-object broadphase measures the mover's distance to the shadow entry's Position — the part ORIGIN — and compares it against obj.Radius, which is the physics-BSP ROOT BOUNDING SPHERE's radius. For 0xC8766009 those two points are 23.556 m apart, so a mover standing on its plateau is inside the real bounding sphere by ~20 m of margin and is still rejected. Same defect AP-156 fixed in the flood and #334 fixed in the registration extent walk, left in place at the query site. Measured, not inferred. An offline replay against the installed DAT reconstructs all eleven landblock-0x8766 owners and matches the live [geom] placement exactly (0xC8766002 at (84.699,100.082,13.000) yaw -45.00 vs the log's objPos + bspCentreOffset). At the position the client fell through, the production swept query returns a hit on poly 31 at 0.037-0.366 m while the filter rejects the candidate: distToOrigin=60.434 > maxReach=59.697, distance to the bounding-sphere CENTRE 37.083 m against a 56.909 m radius. The live capture recorded that rejection 7,225 times with the probe's own wouldAcceptAtCenter=True on every one. Bounded because the dead zone is the shell between maxReach and the true sphere, up to ~23.5 m thick on the far side. movement.Length() is a budget term: a 0.25 m walking step gives shortfall +0.60, a 0.72 m step +0.14, and ~0.86 m passes — which is exactly why jumping over the spot works, walking into it does not, and a corpse falls through. Three hypotheses refuted by measurement, not by argument: - "the rock's own mesh never collides" — true of 0xC8766002 and it is INNOCENT; its geometry is 22.8 m from the wedge and it has zero brute-force hits over a 12,493-point lattice covering the plateau. It is a candidate only because it is a 130x147 m owner. The rock actually walked on is 0xC8766009. - wrong world transform — the offline placement reproduces the runtime exactly, and a uniform displacement cannot produce a bounded pocket. - BSP traversal hole — a referee ran the production walk against brute force at 7,770 on-surface probes across all eleven owners plus 137,423 lattice points. Mismatch 0 everywhere. A 0.5 m hole map also shows continuous upward-facing coverage across the whole wedge region. [geom]'s verdict=coincident was never able to decide this: LogGeometry compares the physics box against the visual box in the object's OWN LOCAL FRAME, so it proves shape agreement and says nothing about world placement. Recorded in the doc so the next reader does not re-trust it. Retail has no per-object distance filter on the BSP branch. Verified instruction-by-instruction with cdb against the PDB-paired v11.4186 binary: CPartArray::FindObjCollisions @0x00518180 is 14 instructions of bare do/while over parts[i]; CPhysicsPart::find_obj_collisions @0x0050d8d0 is 17 instructions of two null checks plus the call to CGfxObj::find_obj_collisions @0x00534700. No compare, no float math in either. The in-tree comment calling the filter a retail analog and response-neutral is wrong on both counts. The support=object cpNz=1.0000 readings inside the rock are not the rock: ValidateTransition:6076 is retail's stationary-fall failsafe manufacturing a flat plane through the sphere bottom, and :5997 is the LastKnownContactPlane restore holding a stale plane. Both are retail-correct responses to a stuck body, and they are why the client believes it is standing while ACE rejects the position. Preferred fix is to delete the pre-check for BSP entries and correct the comment; fallback is to measure to the bounding-sphere centre, which also needs BoundsCenter carried on ShadowEntry. Neither is landed. The reproducer was confirmed to FAIL when un-skipped, with the numbers above — this campaign has caught eleven green tests covering nothing, so a fixture that cannot distinguish the bug is worse than none. Gates: bin/obj deleted, Release build 0 errors, Core suite 4,287 passed / 2 skipped / 0 failed (baseline 4,286/1 plus three new dumps and the one deliberately skipped reproducer). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
49a7e90652 |
probe(physics): ACDREAM_PROBE_SUPPORT + ACDREAM_WIRE_MESH — separate #337's three candidates
The user is wedged at the top of Neftet rock plateaus, jumps sink into the mesh, and a corpse falls straight through. ACDREAM_PROBE_REACH already ruled out its own domain: blocked=0, every candidate tested-ok. Three candidates remain — terrain support, a collision mesh not where its visual is, or the transition wedging on an unobstructed path. ACDREAM_PROBE_RESOLVE alone cannot separate them. It prints a three-value contact-plane token, no plane normal, no plane height, no terrain sample and no plane provenance, so all three produce the same line. Two additions: [support] — one line per resolve for EVERY body, not just the player. A corpse is a plain physics body with no player-specific logic, so its fall-through is the cheapest available control on "movement code vs geometry data", and it is invisible to any player-filtered probe. The line samples the outdoor terrain INDEPENDENTLY at the body's own out-XY and prints the contact plane's own height at that same XY. Two heights at one point make support=terrain / object / none a measurement rather than an inference, and cpSrc= names the site that asserted the plane so provenance and classification cross-check. [geom] — once per GfxObj that comes near a mover: the object's physics-BSP vertex cloud against its visual mesh AABB in the same local frame, through the same prepared accessors the resolver queries. verdict=coincident REFUTES the working hypothesis for that object outright; no-physics-bsp / empty-physics-bsp / displaced / extent-mismatch each name a specific data defect. Built to refute, not to confirm — two diagnoses on this defect's lineage have already been refuted by measurement. ACDREAM_WIRE_MESH upgrades the existing F2 overlay, which drew a broadphase proxy cylinder for BSP objects and so could not answer the question at all, to the real physics-BSP polygon edges (cyan) beside the visual mesh box (magenta) and the terrain surface (yellow). Own class per code-structure rule 1. The provenance latch lives on PhysicsDiagnostics, not on CollisionInfo. Two fields there first — the obvious home — broke the flat/graph differential referee and the scratch-reset poison test, both of which compare CollisionInfo member-for-member. Teaching either to skip a member is a one-line green fix that puts a permanent hole in a referee whose whole job is comparing everything. Captured as feedback_probe_state_off_compared_types. Seven tests cover the support classifier's boundaries: a wrong classifier does not fail to answer, it answers confidently wrong. Gates: Release build 0 errors; complete suite 11,225 passed / 4 skipped / 0 failed from a cleaned tree — baseline 11,218/4/0 plus exactly the seven new tests, skips unchanged. Issue #337 filed with the symptom set, what is ruled out, and a table of what each possible output means. All of this is TEMPORARY and recorded for stripping with the physics-probe family. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
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>
|
||
|
Erik
|
f0588725cf |
docs: #334 measured in game — a landblock-spanning object is registered by one sphere
The reach-filter theory I proposed is REFUTED by measurement, and the real cause is found. Probe evidence committed as 334-neftet-probe.log (8,401 lines, ACDREAM_PROBE_REACH at |
||
|
Erik
|
b61f5fd4fc |
probe(physics): ACDREAM_PROBE_REACH — discriminate #334's three candidates
#334 is "large static formations can be walked through on flat ground, and
jumping over them drops you inside" (Neftet, user-reported, pre-existing —
reproduced on
|
||
|
Erik
|
d4e956b4e2 |
docs: file #334 — large static formations lose collision at their boundaries
User-reported in live play at Neftet: solid on approach, permeable at a
boundary between two formations, and no floor above — jumping over lands you
through.
NOT a regression from today's collision work, and that was established by
measurement rather than argument: a client was built at
|
||
|
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
|
||
|
Erik
|
e2b2d04cb5 |
docs: file #333 — the broadphase reach filter has AP-156's defect at the query site
Found while fixing AP-156 and deliberately NOT bundled into it: the shadow broadphase at TransitionTypes.cs:3756-3764 measures `currPos - obj.Position` against `sphereRadius + obj.Radius + movement + 2f`, where `obj.Position` is the PART ORIGIN but `obj.Radius` is the BSP root bounding sphere's radius, measured about that sphere's own centre. The same discarded origin, one layer down. It admits a real contact only when the sphere's centre is within about `movement + 2` metres of the part origin. For Setup 0x02000255 that offset is 9.911 m against a budget near 2.5 m, so a mover touching the upper half of the prop is discarded before BSPQuery runs. This is newly load-bearing: before AP-156 those objects were mostly not in the cell at all, so the filter never got to reject them. AP-156 puts them in the right cells and this becomes the next gate. It is the first place to look if the connected session finds a tall prop that still does not block. Filed rather than fixed because it is a different code path with an unanswered retail question — the `+ 2f` slack and the movement term look like acdream's own broadphase rather than a port of anything in CPhysicsObj::FindObjCollisions @0x0050f050, in which case it needs a divergence row of its own before it is touched. Bundling it would also make AP-156's connected gate un-attributable, which is exactly the fault that split AP-155. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
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 ` |
||
|
Erik
|
4abd1b5eb7 |
fix(physics): AP-152 — dispatch collision shapes BSP-first, at emission and at the cell flood
The register row predicted "catching or stopping on a doorway sill". That
symptom could not have been occurring. `Transition.BspOnlyDispatch`
(TransitionTypes.cs:1348, landed 2026-05-25 as A6.P7) already skipped both
primitive branches (:3911, :3954) whenever the target's wire PhysicsState
carries HAS_PHYSICS_BSP_PS, and ACE sets that bit from CSetup.HasPhysicsBSP
for every affected Setup. The extra primitive was never tested for collision.
The live defect was CELL MEMBERSHIP. The same shape list feeds
`ShadowObjectRegistry.BuildFloodSpheres`, which had no such guard and
preferred Cylinders over everything whenever any Cylinder existed — retail's
SECOND priority applied ahead of its first. For the 73 CylSphere+BSP Setups
acdream therefore flooded shadow cells from the cylinder and never from the
slab: an object absent from cells it physically occupies, which is the
#98 / #168 symptom class, not the door-collision class the row named.
Retail, re-disassembled from the PDB-paired binary (v11.4186, CodeView GUID
9e847e2f-777c-4bd9-886c-22256bb87f32, check_exe_pdb.py MATCH) rather than
taken from Binary Ninja, which drops flag tests:
CPhysicsObj::FindObjCollisions @0x0050f050
0x0050f165 test dword [esi+0xa8], 0x10000
0x0050f16f je 0x50f1a2 ; clear -> primitive dispatch
0x0050f18d call 0x518180 ; CPartArray::FindObjCollisions
0x0050f19d jmp 0x50f2b0 ; UNCONDITIONAL, past BOTH primitive loops
; (CylSphere 0x50f1a2, Sphere 0x50f21d)
0x0050f1d6 jae 0x50f317 ; CylSphere loop exhausted -> RETURN
0x0050f22f je 0x50f31b ; zero Spheres -> RETURN seeded OK_TS
CPhysicsObj::calc_cross_cells @0x00515230
0x00515285 test dword [esi+0xa8], 0x10000
0x0051528f jne 0x515305 -> CPhysicsObj::find_bbox_cell_list @0x00510fc0
0x005152d1 call 0x52b9f0 ; cylsphere branch, below the jump
0x005152fb call 0x52b990 ; sorting-sphere branch, below the jump
Priority at both consumers: BSP -> CylSphere -> Sphere -> nothing. BSP wins.
Every address above was resolved back to its symbol by exact lookup in
named-retail/symbols.json.
Changes:
* `ShadowShapeBuilder.FromSetup` gains a step-0 dispatch gate. Steps 1 and 2
are skipped entirely when any part's EFFECTIVE GfxObj carries a physics
BSP. The gate and step 3 now share one `EffectivePartGfxObjId` helper, so
they cannot read different identities — a gate on `setup.Parts` would,
after an ObjDesc swap, suppress the primitives while step 3 emitted
nothing and `Build` returned null, deleting the entity's collision.
Emission order is unchanged. This also removes acdream's undeclared
reliance on the server sending the flag: the gate is derived from the
parts, exactly as CPartArray::CacheHasPhysicsBSP @0x00518110 derives it.
* `ShadowObjectRegistry.BuildFloodSpheres` now applies calc_cross_cells'
own order: BSP, else Cylinder, else everything. Given the gate above this
is a no-op for every shape list acdream produces (FromSetup is now
exclusive; both landblock-static publishers already emit homogeneous
lists), so the measured membership delta remains attributable to the
gate alone. It is kept for the same reason BspOnlyDispatch is kept: retail
genuinely dispatches here, and it guards a future additive producer.
`Transition.BspOnlyDispatch` is deliberately untouched.
Register: AP-152 RETIRED with its four false statements corrected — the risk
statement (the symptom was already inert); "small and centred at the part
origin" (max primitive is 6.714 m, and 0x0200086E's sphere origin is
(0.759, 0.165, 5.842)); the cottage door's "~14 cm base Sphere" (it is
0.100 m; 0.141 is Setup.Radius, which AP-22 proved is never collision
geometry); and naming one pinning test where two existed. AP-153/154/155
filed: retail's dispatch flag is cached once at InitPartArrayObject+0x7e
where acdream's gate is live; the query-time guard takes a client-derived
flag off the wire; and the static publishers emit Setup Spheres as
height-capped Cylinders while BuildFloodSpheres approximates retail's
bounding box with bounding spheres.
Tests. Both pinning tests corrected, neither deleted:
`FromSetup_DoorSetup_ProducesFourShapes` -> `..._EmitsBspPartsOnly`;
`FromSetup_DoorSetup_SphereAtExpectedLocalOffset` re-hosted on
`_ => false`, the DAT-real configuration for the 3,605 Sphere-only Setups.
`FromSetup_ScaleFactor_MultipliesAllRadiiAndOffsets` was the campaign's
eighth green test covering nothing — its assertions sat inside
`if (CollisionType == Cylinder)` on a fixture with zero CylSpheres, so only
`Scale == 2.0f` ever ran. Proved empirically: with the sphere radius scale
deleted, the old body passes and the corrected body fails. Three new facts:
the effective-identity gate, the App-layer CylSphere+BSP registration (no
App fixture combined the two before), and the flood-set dispatch. One new
installed-DAT sweep pins 172 affected Setups (73 CylSphere+BSP, 99
Sphere+BSP) behind external bucket controls, re-measured independently and
agreeing exactly with the filing commit's separate sweep.
All eight sabotages run and reported; every discriminating fact reddens in
the intended direction and only there. Clean Release build after deleting
every bin/obj: 0 errors. Complete suite 11,203 passed / 4 skipped / 0
failed, +5 on the 11,198 baseline at
|
||
|
Erik
|
ec29a732f5 |
test(physics): settle #331 — the uphill "refusal" is the #137 anti-parallel absorb, not a defect
#331 reported that `PhysicsEngine.ResolveWithTransition` refuses ALL uphill
motion whenever a `body:` is supplied. It does not. It refuses a step whose
sub-step offset is exactly anti-parallel to a live sliding normal — the
#137-family absorb this project already recorded as retail-faithful.
Measured on the same fixture, same gradient, same body, varying only the
heading relative to the slope gradient:
(0, -0.1, 0) cross-slope 0 -> zero movement, latched
(0.0001,-0.1, 0) cross-slope 0.0001 m -> zero movement, latched
(0.001, -0.1, 0) cross-slope 0.001 m -> climbs 0.176 m in 5 ticks
(0.01, -0.1, 0) cross-slope 0.01 m -> climbs 0.176 m in 5 ticks
The threshold is retail's own F_EPSILON small-offset abort (0.0002 m): about
0.11 degrees off the exact gradient at a 0.1 m step. `RemoteRampHarness`
builds a ramp whose gradient is exactly along Y and the original probe pushed
exactly along -Y, so it hit the measure-zero case with probability 1.
The latch itself is production-real in mechanism — a pure gravity fall under
the production RuntimeRemotePhysicsUpdater, with no fixture settle seam
involved, lands leaving Contact|OnWalkable|Sliding with slidingNormal (0,1,0)
— but every link is faithful to retail, verified in the PDB-paired binary
rather than Binary Ninja (BN typed find_transitional_position `void` and
dropped the load-bearing return value):
validate_walkable sets collision_normal from the terrain plane when
OBJECTINFO CONTACT is clear 0x0050d251 / 0x0050d261 / 0x0050d26c
validate_transition converts it unconditionally 0x0050ac19-0x0050ac30
set_sliding_normal zeroes Z AND re-normalizes 0x0050a060
SetPositionInternal persists SLIDING_TS 0x005154c2 / 0x005154e1
get_object_info re-seeds it next frame 0x00511d44 / 0x00511d4f
find_transitional_position returns
`i != 0 && state == OK` on the step-0 abort 0x0050c0ed -> 0x0050c089
ACE agrees (Transition.cs:1027, CollisionInfo.cs:58). No production code
changed; no divergence introduced, so no register row.
What lands is the coverage whose absence made this invisible — nothing in the
suite asserted that a body-bearing mover makes uphill progress on a walkable
slope, and the test that found #331 passed vacuously because the body never
moved:
RuntimeRemoteUphillProgressTests.ARemoteWithABodyClimbsAWalkableSlopeAndKeepsItsFeetOnIt
per-tick climb + surface tracking under a realistic off-gradient heading.
SAB-A1 AdjustOffset -> Vector3.Zero reddens at tick 1
SAB-A2 fixture gradient -> 0 (flat) reddens at tick 1
RuntimeRemoteUphillProgressTests.AnExactlyUpSlopeOffsetIsAbsorbedByThePersistedSlidingNormal
characterization pin for the absorb, with the retail anchors inline.
SAB-B1 delete the get_object_info sliding seed reddens (climbs to 57.7544)
SAB-A1 reddens
SAB-A2 reddens
NON-discriminating, measured and documented: making the final tick
exactly up-slope leaves it green — by then the latch is already cleared.
RemoteRampHarness gains a warning block naming the axis-alignment trap so the
next vacuous uphill assertion is caught at authoring time.
Suite re-measured from a full clean (43 bin/obj removed): 11,198 passed /
4 skipped / 0 failed, against the 11,196/4/0 baseline at
|
||
|
Erik
|
0d62a5ffeb |
docs: close the placement cutover ledger — #280 user-passed, remaining gates NOT RUN
Campaign closed by user direction after the #280 connected gate passed. GATE RESULT. #280 user-accepted: "now portal space takes longer but terrain is complete when I exit" — both halves of the specified criteria, a measurably longer hold and a complete destination on reveal. Probe evidence: three Portal reveals plus a Login reveal, every one at radius=12 where pre-fix it was a hardcoded 1, each portal hold raising the wait cue at ~5.0 s before completing. An accidental but genuine A/B came out of the same session. An earlier run set ACDREAM_PROBE_REVEAL_RADIUS=1 — that variable is a radius VALUE, not an on/off flag — which forced the pre-fix window. The user saw the original defect under it and not under radius=12. That is the before/after pair the gate asked for, obtained by mistake. Recorded prominently because the same mistake would silently reproduce the bug for the next person. WHAT IS NOT CLAIMED. The ledger closes with most connected gates outstanding BY USER DIRECTION, not because they were discharged: D-1's two reachability scenarios, AP-136's six-step park protocol, route-7 thickening (the remote-teleport probe recorded ZERO lines), the two-client observation, the nine-stop soak, and the lifecycle/reconnect route. The closeout's section 2.6 is a table of exactly this, and both the campaign plan banner and this commit say that anyone citing "the campaign passed" must cite it alongside. THE PROBE FAMILY IS DELIBERATELY NOT STRIPPED. Closing the campaign would normally retire the six ACDREAM_PROBE_* flags, but their gates were never run, and stripping now would delete precisely the instrumentation those owed gates need — the failure the handoff's own rule exists to prevent. Honouring that rule means not stripping even though the campaign is closing. ACDREAM_PROBE_REVEAL_RADIUS is also kept despite #280 closing, because AP-149 and #326 are open and would both want the same A/B harness. #280 is marked CLOSED in ISSUES with its gate evidence, and its residual AP-149 is restated there: our outer ring accepts terrain-only readiness where retail's PreFetchCells also requires each landblock's LandBlockInfo and every building's EnvCells, so distant SCENERY may still fill in after reveal even though terrain does not. Not folded in — it costs further hold time and is a game-feel call. Memory updated with the campaign's closed state and the follow-up order: #331 first, then AP-152, #330, AD-65. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
1304dafa8b |
docs: C5c closeout + successor handoff; automated gate passes 11,196/4/0
Closes the automated half of C5c. Everything still owed needs the user at a live client, and the probe strip cannot precede it. AUTOMATED GATE — PASS. Complete Release suite on the final binary at |
||
|
Erik
|
7b3e2895cd |
docs: close the AD-10 review findings — AD-65's magnitude was half the truth
Both AD-10 review lenses PASS; the deletion stands. These are the findings they raised. One production file touched, comment-only. AD-65 WAS UNDERSTATED BY HALF, and it is the finding that matters. The row states the factor as cos^2(theta) and then quantified 1-cos(theta): "13% at 30 degrees, 29% at 45". The correct figures are 25% and 50%. This is not algebra alone — #331's probe in the same push measures 0.0735 m travelled for a 0.1 m request at 30.96 degrees, i.e. 26.5% short, which is exactly cos^2(30.96). AD-65 is a LEAD for #269's slope-slide residual; at the understated magnitude it reads as marginal and could have been dismissed. At 50% short at 45 degrees it is a serious candidate. I repeated the wrong figure in conversation before the review caught it. "VERBATIM/FAITHFUL PORT" of Transition.AdjustOffset was asserted in five places and was false as of the very next commit, which filed AD-65 and AD-66 against that same function. Corrected to "structurally exact, with exactly two filed divergences" in the register row and the production doc comment. RECORDED, and it favours the change: the redundancy measurement is CONTINGENT on AD-65 — the two mechanisms agree today partly because both under-travel downhill. That makes this deletion a PREREQUISITE for fixing AD-65 rather than merely compatible with it; had the projection survived, correcting AdjustOffset would have re-introduced a disagreement between two live projections. The record claimed no such thing and should have. UNTESTED AXIS recorded: the contract's T2 — its mandatory wrong-plane-versus- right-plane discriminator — was dropped without record, breaching the contract's own clause requiring exactly that to be written down. The consequence is precise: the deletion is measured, but the change's only claimed BENEFIT (a walkable non-terrain surface now gets the committed contact plane instead of terrain far below) has zero automated coverage and rests on source reasoning. Stated in the row rather than left implied. #331 SEVERITY RAISED from UNKNOWN — the discriminator is known and it is not the fixture. With `body: null` the same uphill sweep climbs (ok=True, moved (0, -0.0999, +0.060)); with a body supplied it returns ok=False and zero movement, under a call profile identical to the local player's (IsPlayer|EdgeSlide + the human two-sphere Setup). A diagonal request keeps cross-slope X and zeroes only up-slope Y, and it fires on a 1.1 degree ramp. So "confined to the synthetic fixture" is no longer the comfortable default: the failing call shape is the shape production uses. Nothing in the suite asserts uphill progress on a walkable slope, which is why it was invisible — the test that found it passed vacuously, because the body never moved. Also: malformed XML doc on ComposeOffset (duplicate </summary> swallowed the retirement note from tooling) fixed; the placement-cutover plan's item 5 and its stale "After C5" line now record AP-22 and AD-10 as retired. Core builds clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
2223ed1745 |
docs: file the uphill-resolve blockage (#331) and the headless remote-DR gap (#332)
Two findings from the AD-10 work that are out of its scope and are filed rather than absorbed. Neither is caused by AD-10 and neither is affected by its deletion. #331 — PhysicsEngine.ResolveWithTransition returns ok=False and the unchanged input position for EVERY uphill step on the synthetic constant-gradient terrain ramp, while the identical downhill step succeeds and produces a correct slope-following result. Probed and ruled out: gradient (fails at 2.9 degrees as at 31), step size, cell boundaries (five start positions with the cell id recomputed), and Z seating. It is not an axis bug either — inverting the ramp so it rises along +Y makes +Y the failing direction, so the failure tracks the slope. Filed with severity UNKNOWN on purpose. Players demonstrably walk uphill in acdream and the local player runs the same call, so either production terrain differs from what the fixture publishes (AddLandblock only, no flat-collision statics) or something in the live arguments does. That was not traced, and guessing which would be exactly the kind of inference this campaign keeps getting burned by. The issue names the one probe that decides it. It surfaced because an uphill counterpart to the AD-10 tracking test was written, PASSED, and was then found vacuous — the body never moved, so it "stayed on the surface" by standing still. That test was dropped rather than shipped. Any future uphill assertion against that harness is vacuous the same way until this is resolved, which is reason enough to record it even if production is fine. #332 — Headless bots appear to have no remote dead-reckoning at all. RuntimeRemotePhysicsUpdater has exactly one production instantiation, AcDream.App/Physics/RemotePhysicsUpdater.cs:46, and src/AcDream.Headless/ never names it or RemoteMotion. Remote entities on that host would move only at UpdatePosition cadence. Filed as an observation for the headless owner to judge, adjacent to #330 but a separate mechanism. #332 also records the reasoning trap it exposes, because it inverts the C5b lesson rather than repeating it: RemoteMotionCombiner is in Core and RuntimeRemotePhysicsUpdater is in Runtime, so "therefore headless runs it" is the natural correction to C5b's graphical-only survey — and it is wrong. Assembly placement is not reachability; the instantiation census is. AD-10 designed no headless gate for exactly this reason, and a passing one would have been vacuous evidence. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
fb454b748c |
docs(register): file the AdjustOffset snap_to_plane and safety-threshold divergences
Both were found inside acdream's port of CTransition::adjust_offset while retiring AD-10, and neither had a register row — grep confirms no existing row mentions snap_to_plane, SnapToPlane, naturalResting, or away-plane. Filed as AD-65 and AD-66. Neither is fixed here: both change LOCAL-PLAYER movement feel and need their own visual gate, and folding them into the remote-movement change would have put a local-player regression behind the wrong acceptance test. AD-65 — the `collisionAngle > 0` arm substitutes `result -= N * angle` for retail's Plane::snap_to_plane call, making the if and else arms byte-identical. snap_to_plane (0x00509c50) writes only v.z and leaves XY alone, so acdream descends slopes 13% slow at 30 degrees and 29% slow at 45. Uphill is correct. Recorded as a LEAD for the open #269 slope-slide residual, explicitly not a diagnosis — the direction fits but nothing here establishes causation. #269's friction and jump chains are byte-exonerated and are not re-audited; adjust_offset is a different function. AD-66 — the safety push-out substitutes `radius * Normal.Z` for retail's bare `radius` in both the trigger and the zDist numerator, knowingly and with a written rationale. The rationale may be right; the missing row is the defect. The code comment's "ACE and the published pseudocode have the original threshold" understates the case — the retail binary has it. Both directions are byte-verified against the PDB-paired v11.4186 binary (GUID 9e847e2f-777c-4bd9-886c-22256bb87f32, check_exe_pdb.py MATCH), not inferred from pseudo-C: Binary Ninja renders every x87 comparison in this function as the fnstsw/test-ah mush and cannot be read for branch direction. AD-65's row records the exact three instructions and the FPU condition-code reasoning; AD-66's records the four operand loads showing neither site multiplies by N.z, plus both float constants read from the image (0x795344 = 0.0f, 0x7c6878 = 0.00019999999494757503f). AD-10's own retail anchor was corrected in the previous commit for the same reason: pc:272296-272346 truncated the sliding-normal validity gate at the head and the whole safety push-out block at the tail. No code change; no test change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
886333a2a9 |
refactor(physics): delete the redundant pre-sweep slope projection (AD-10 retired)
Stage 0's measurement (previous commit) says the projection is redundant,
so AD-10 retires by deletion rather than by narrowing.
The measurement. With the sample forced to null at BOTH fork sites, from a
clean build:
* a remote running 30 ticks down a 31-degree walkable ramp produces a
BIT-IDENTICAL trajectory, position for position;
* on an 8.4-degree ramp the two differ by at most 2.8e-5 m in Z after 30
ticks (0.03 mm) and are identical in X and Y — float ordering noise
from projecting twice against the same plane rather than once;
* the whole AcDream.Runtime.Tests suite is unchanged.
That is what redundancy looks like, and the arithmetic explains it. The
boundary projection and Transition.AdjustOffset are the same operation
(v -= N * dot(v, N)) against the same plane, and the composition is
idempotent: a vector already on the plane has dot(v, N) == 0, so the
sweep's own projection is a no-op on an already-projected offset and the
full-strength projection on an unprojected one. Either alone produces the
same offset. On terrain a THIRD mechanism, ValidateWalkable's push-out,
re-seats the sphere on the plane every sub-step regardless.
Deleted:
* both RuntimeRemotePhysicsUpdater sample sites (the host and no-host
fork branches carried the block verbatim — the AP-22 shape, a row
naming one site where two exist);
* the terrainNormal parameter and projection block on
RemoteMotionCombiner.ComposeOffset;
* the same block on ComputeOffset, which has no production callers but
held a second copy of the divergence, so leaving it would have made
the row's retirement false;
* PhysicsEngine.SampleTerrainNormal, now callerless.
Removing the parameter rather than passing null is deliberate: it is what
makes a future one-site-only regression a compile error instead of a
silent half-fix.
Two tests went with it —
ComputeOffset_RootMotionFallback_SlopedTerrainNormal_ProjectsZOntoSlope and
its flat-ground twin. Both were weak on their own terms: they drove the
production-dead ComputeOffset and computed their expected values by
re-implementing the projection formula, so they could catch a wrong
MULTIPLY but never a wrong PLANE — which is exactly what the divergence
was. The surviving coverage is geometric and runs the production tick.
Three claims in the old row did not survive contact with the code and are
recorded in the retired row rather than quietly dropped: the justification
(remotes do run the sweep); the description of ComposeOffset's guard as
"interpolation-active" when the code reads `if (!interpolationOverwrote`;
and the roof clause, stale since Bug B gated the sample on OnWalkable —
a steep roof is OnWalkable == false, so the path never ran on #32's
geometry. The retail anchor is corrected too: pc:272296-272346 truncated
both the sliding-normal validity gate at the head and the entire safety
push-out block at the tail. The whole function is 0x0050a370,
pc:272271-272393.
This does not fix #32 and does not partially fix it. #32's remote half was
already closed at
|
||
|
Erik
|
fe6ee877d1 |
test(physics): measure whether the remote sweep alone tracks surface Z (AD-10 Stage 0)
AD-10 claims the remote slope projection is "relocated" out of the sweep
because "remote bodies don't run a full local transition sweep". That
justification is false at HEAD: RuntimeRemotePhysicsUpdater.Tick calls
PhysicsEngine.ResolveWithTransition with the remote's own body, and that
sweep runs acdream's verbatim port of CTransition::adjust_offset
(0x0050a370, pc:272271-272393) once per sub-step. So the boundary
projection is an EXTRA layer, not a relocation — and whether it is doing
anything the sweep does not is a measurement, never an argument.
This commit builds the fixture for that measurement and changes no
production code.
RuntimeRemoteSteepContactSlideTests' private Harness is extracted to
RemoteRampHarness so the new tests share it instead of cloning ~180 lines.
The extraction is behaviour-preserving; its only additions are the
fixture's own TerrainSurface (so an assertion about "is the body on the
surface" is answered by the surface geometry rather than by
re-implementing what the code under test computed), a SurfaceZ helper, and
a Tick overload that supplies a per-frame body-local root displacement —
the locomotion-cycle push a running remote actually carries. All ten Bug B
tests pass unchanged against it.
RuntimeRemoteSlopeProjectionTests then drives the production tick 30 ticks
down a 31-degree walkable ramp and asserts, on EVERY tick rather than at
the end, that the body's root stays within 5 mm of its settled offset from
the terrain beneath it. A staircase catching up on the final tick would
pass a start/end comparison; 30 unprojected ticks accumulate ~1.8 m.
Sabotage results, all from clean builds (bin/obj deleted), reported in
both directions:
* Discard the sweep's answer (Body.Position = postIntegratePos instead
of resolveResult.Position): RED at tick 1, body 0.05999 m off the
surface. This is the tracking test's discriminating sabotage.
* Flatten the ramp to gradient 0: RED on the anti-vacuity guard
(dz = 0.0000 m). That guard exists because the tracking assertion
passes trivially on flat ground, where Z never has to move.
* Short-circuit Transition.AdjustOffset to `return offset;`: GREEN.
Recorded, not hidden — it is the reason the contract's proposed T1
sabotage was rejected. On terrain the sweep has a SECOND independent
way to plant Z: ValidateWalkable's push-out re-seats the sphere at its
natural resting distance from the terrain plane every sub-step.
Removing the step-down probe as well does not change it either
(measured). The tests therefore assert the OUTCOME the projection
exists for, and say in their own doc comments that they are not unit
tests of adjust_offset and must not be cited as such.
One test the contract asked for is deliberately absent. An uphill
counterpart was written, passed, and was then found VACUOUS: on this
fixture ResolveWithTransition returns ok=False for uphill motion and the
body does not move at all, so it "tracked the surface" by standing still.
That finding is filed separately rather than shipped as a green test.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Erik
|
ef976c6dbb |
docs(register): correct AP-22's evidence claim (review follow-up)
The register half of
|
||
|
Erik
|
619de97ad1 |
fix(test): evaluate BOTH deleted guards; correct AP-22's overstated coverage claim
From the AP-22 dual review (both lenses PASS). No production change.
THE RECORD WAS WRONG.
|
||
|
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
|
||
|
Erik
|
bcb66ccdf3 |
fix(test): cover the atlas-tier seam the D-1 fix depends on; correct AP-150's citation
Both items come from the D-1 fix review (both lenses PASS, D-1 genuinely closed). No production behaviour changes. L1 — THE SEAM HAD NO COVERAGE. The D-1 fix's "empty by construction" claim rests on LandblockSpawnAdapter's atlas-tier filter (`if (entity.ServerGuid != 0) continue;`) skipping the live server projections DetachNearLayer deliberately RETAINS across a demote. The reviewer removed that filter and all 4,170 App tests passed — only two Core unit tests caught it, none through a demote. So the invariant the re-assert depends on could have been deleted silently, re-opening D-1 by another route: a non-empty re-assert whose mesh reference is never satisfied leaves IsRenderReady false, which is the portal hang again. NearToFarDemote_WithALiveServerEntity_StaysRenderReady now demotes a landblock that CARRIES a live server-spawned entity through the real GpuWorldState + LandblockSpawnAdapter + LandblockPresentationPipeline, and asserts the retained entity never enters the desired set. Sabotage-verified: with the filter removed, exactly one test fails — this one — and the other 25 pass, including all four D-1 regression tests. That is the finding restated as a measurement: the D-1 tests genuinely do not cover this seam, and now something does. AP-150 citation corrected: the row cited 0x004D7064 as the ECM_UI::SendNotice_DisplayStringInfo call site. That address is the PStringBase construction of the "In Portal Space - Please Wait..." literal (:219516); the actual call is 0x004D70A1 (-> 0x006925B0). Same class of slip the #280 commit had just corrected for #326 — worth noting that a row filed WITH a byte-level disassembly still mis-cited a neighbouring address. Also refactored the existing pipeline demote test to keep its doc comment attached to its own method (an earlier insertion had orphaned its [Fact]). App.Tests 4,170 -> 4,171 passed / 3 skipped, net +1 for the new test. No new skips; none of #302/#308/#321 surfaced. src/ is byte-unchanged (the sabotage was reverted and verified). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
43cfdc4a40 |
docs: accept #309 as a standing divergence rather than a planned fix (AP-136)
User decision 2026-08-06. #309 moves from OPEN to DEFERRED/ACCEPTED, and AP-136 becomes its permanent record rather than a staging note. No code changes. No new register row was filed: AP-136 already carries the full retail mechanism (SetPositionInternal 0x00515BD0 -> store_position 0x00515CE2 -> GotoLostCell 0x00515CF2, removed only by InitObjCell 0x00508260 -> reenter_visibility 0x00516250), the exact divergence, and the observable. Filing a second row would have duplicated it. WHY DEFERRED, recorded so a successor does not silently re-litigate it. The retail-faithful end state is a park that SURVIVES cancellation. That was implemented and reverted this round, because it costs (a) reversing a deliberate shipped invariant — NewerPositionPickupAndParentEachCancelExactLostOperation asserts that a newer Position cancels the park — and (b) GameRuntime teardown convergence (stage 10), where surviving parks never converge on shutdown. The observable requires a remote to teleport into a non-resident landblock AND then stop moving; ACE stops broadcasting for a stationary entity, while the ordinary 5-10 Hz case is superseded within ~150 ms. Revisit if teardown convergence is done for another reason, or if the observable is reported in ordinary play. CAUGHT WHILE RECORDING IT: deferring the fix does NOT cancel AP-136's six-step connected check. That check validates the SHIPPED rollback path (#312 / restorableOnCancel, which sits in SubmitPreparedPlacementCore — the shared core behind every production placement), not the deferred fix. It still needs running with ACDREAM_PROBE_PARK=1, and therefore must run BEFORE C5c's probe strip retires that flag. Both documents now say so; without that note the strip would have silently removed the instrumentation a still-owed gate depends on. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
73cdb95c7b |
fix(streaming): make a demoted landblock render-ready like a published one (#280 D-1)
Both #280 review lenses returned FAIL on the same defect, and both were
right. IsRenderNeighborhoodResident's widened outer arm requires
IsRenderReady out to FarRadius, justified by "a Far-tier landblock
registers with an empty mesh set and is therefore render-ready." That held
only for a landblock that ARRIVED as Far. The second, equally first-class
way to be Far tier is a Near->Far DEMOTE:
DemoteLandblock -> EnqueueNearLayerRetirement
-> LandblockRetirementStage.MeshReferences
-> GpuWorldState.ReleaseLandblockMeshReferences
-> LandblockSpawnAdapter.OnLandblockUnloaded => WantsLoaded = false
while DetachNearLayer deliberately keeps the landblock loaded, terrain-mesh
resident, terrain-collision resident and DRAWN. Nothing re-publishes an
already-loaded landblock, so the demoted member satisfied NEITHER arm of
the gate, permanently: wormhole tunnel plus centered "In Portal Space -
Please Wait..." forever, no recovery short of relog.
Reachable by ordinary play. Two consecutive recalls to the same landblock
with walking in between makes ChangesStreamingCenter false, so there is no
origin recenter and the region recentres through the ordinary demote diff.
Also reachable via a mid-hold quality-preset drop -- ironically the exact
scenario ReconcileDestinationReservationRadius was added to support. The
pre-#280 radius-1 gate never touched that band, because nothing inside the
Near ring can demote.
FIX SHAPE. Make the two routes genuinely equivalent rather than teaching
the predicate to tolerate the difference. ReleaseLandblockMeshReferences
becomes "reconcile the registration to the post-retirement tier": after the
release converges, if the landblock is still loaded AND still Far tier,
re-assert the empty registration -- the identical OnLandblockLoaded(lb,
empty) a PublicationKind.Far activation makes. It is empty by construction:
DetachNearLayer retains only live server projections, which the adapter's
atlas-tier filter skips. A full retirement is unaffected (DetachLandblock
clears both _loaded and _tierByLandblock), and a throwing release still
retries because the re-assert is only reached after the adapter converged.
The alternative -- "|| (IsFarTier && IsLoaded)" at the gate -- was
rejected: it fixes one caller while leaving IsRenderReady meaning two
different things, which is precisely how this defect arose. After this
change the predicate reads "drawable at its current tier" for every caller,
with no knowledge of how the landblock got there.
WHY THE TESTS MISSED IT, fixed here too:
- Proof obligation P2 was discharged against RESIDENCY (the FarRadius+2
eviction threshold) rather than against IsRenderReady, the gate's actual
atom. The contract now carries the correction and the restated
obligation: no transition may REVOKE IsRenderReady from a landblock that
stays inside FarRadius.
- WorldRevealDerivedWindowIntegrationTests advertised itself as end-to-end
against the real GpuWorldState but constructed it with no spawn adapter,
so its IsRenderReady degenerated to IsLoaded via the "?? true". The
single most load-bearing predicate in the change was stubbed out by a
null in the test named after it -- the same shape as C5b's D3 and #276's
three settler tests. Every fixture in that file now owns a real
LandblockSpawnAdapter.
- The P1 test's comment described its subject as "a Near-shaped completion
the streaming window has since DEMOTED to Far". It is not; it is a fresh
PublishAsFar, the case that does hold. Corrected, since a future reader
would have taken it as demote coverage.
Four new regression tests, all driving the real GpuWorldState +
LandblockSpawnAdapter + LandblockPresentationPipeline through an actual
demote, and all sabotage-verified in both directions (fail with the
production change reverted, pass with it):
NearToFarDemote_LeavesTheLandblockRenderReadyThroughTheRealPipeline
NearToFarDemote_LeavesTheLandblockRenderReadyUnderBudgetedRetirement
TieredWindow_StaysResidentAfterAnOuterRingDemote
OutdoorReveal_SurvivesAnOuterRingDemoteDuringTheHold
The budgeted variant exists because production composes
LandblockRetirementCoordinator.CreateBudgeted, whose MeshReferences stage
is a separate call site from the legacy pipeline's.
SECONDARY, same commit:
- R-1: ACDREAM_PROBE_REVEAL_RADIUS=0 was parser-accepted and
Runtime-rejected -- it yields far = 0 for an outdoor destination, which
fails invalid-readiness-shape on every acknowledgement, hanging the very
A/B route the probe exists to measure. Parser floor raised to 1, with a
7-case table test.
- R-2: the composite-warmup TRIGGER had silently moved onto the far
window's critical path. Pre-#280 the gate and the composite domain were
the same radius-1 square; #280 widened the gate without widening the
domain, so every composite upload serialised behind the last outer-ring
landblock for no readiness benefit. Warmup now starts once the NEAR
sub-window is published -- trigger scope == domain scope, as before. The
reveal gate is untouched: Evaluate still requires the full window AND
composite readiness.
- AP-150 filed: acdream's RetailWaitCueDelay = 5 s arming is NOT retail's
trigger, and #280's commit message got this wrong on both clauses. Retail
emits the notice unconditionally per tunnel rotation segment, in the else
arm of the segment-expiry test at 0x004D6FCD; segment duration is
RandDouble(0.6, 1.8) s, byte-decoded at 0x004D6FE6. The 5.0 constant at
VA 0x007991B0 is CellManager::CheckPrefetchStatus's prefetch RETRY
cadence and has nothing to do with the cue. acdream's own 0.6/1.8 segment
constants already match retail exactly; only the arming is wrong.
Adopting retail's unconditional emit is filed as #329 rather than folded
in here -- it is a user-visible presentation change and wants the user's
eyes.
- AP-151 filed: the gate is materially STRICTER than retail on the
mesh-build/GPU-upload axis. Retail's LScape::PreFetchCells blocks on DAT
RESIDENCY only -- no geometry construction, no upload; that work is lazy
at draw. acdream requires a DAT read, terrain mesh build, render-thread
upload, spatial commit, collision admission and spawn-adapter activation
per member of a 625-member window, metered at MaxCompletionsPerFrame.
Nothing bounds the hold. This is the OPPOSITE asymmetry from AP-149; both
are live at once, on different axes.
- AD-2's amendment stated the false Far-tier readiness assumption verbatim;
corrected, along with the same error in
claude-memory/reference_two_tier_streaming.md, which now carries an
explicit DO-NOT-RETRY on the special-case-the-predicate shape.
- AP-115 scope-noted (it covers the cue's presentation, not its arming).
- #326's SmartBox::set_mid_radius citation corrected: the entry is
0x00453180; 0x004531D0 is the mid-function re-arm branch.
Blast radius: GpuWorldState, LandblockSpawnAdapter,
WorldRevealReadinessBarrier and StreamingDiagnostics are all App-internal;
AcDream.Headless and AcDream.Runtime reference none of them outside
comments. Headless tests run green as part of the gate below, per C5b's
lesson about surveys that skip the no-window host.
Gates: Release build 0 errors, 18 pre-existing xUnit analyzer warnings.
Complete suite "dotnet test AcDream.slnx -c Release -m:1" with
ACDREAM_PAK_PATH set: 11,192 passed / 4 skipped / 0 failed, from a clean
rebuild (a prior session's deleted probe file had been compiled into a
stale test DLL). Baseline at
|
||
|
Erik
|
fafc0b65d9 |
fix(physics): adopt the settle's resolved cell across an indoor seam (#276 remainder)
SpawnPlacementSettler committed settle.Position but discarded settle.CellId, so a compressed first-gravity-frame settle that crossed a cell boundary left the body's cell at the placement cell until some later resolve corrected it. Now committed through the same guarded channel the per-tick resolve writeback uses (RuntimeOrdinaryPhysicsUpdater): resolved cell when the transition reports one, source cell otherwise, never a zeroed residency. Retail anchor: CPhysicsObj::SetPositionInternal(CTransition const*) 0x00515330 commits both sphere_path.curr_pos.objcell_id and its frame, including EnvCells. WHERE THE DEFECT ACTUALLY BIT — #276's own framing is half wrong, and the half it misses is the whole fix. PhysicsBody.Position's setter already mirrors the world delta into the landblock-local frame and lets LandDefs.AdjustToOutside recompute the 24 m cell index from it, so an outdoor->outdoor settle already landed the right cell and dropping settle.CellId cost nothing there. It cannot do that for an EnvCell: an EnvCell id is not derivable from a position, so the mirror deliberately PRESERVES it. settle.CellId is therefore the only carrier of a cell identity across an indoor seam. The live defect is the issue's parenthetical ("outdoor/EnvCell seam, stacked EnvCells"), not its main clause — and the change is consequently a no-op on the outdoor path that dominates production, corrective only at the seam. That finding is what made the test possible. The three existing settler tests build bodies with NO CellPosition and pass identically with or without this change — shipping against them would have repeated C5b finding D3, a test that passed with its own change reverted. The new test seeds an EnvCell id over plain outdoor terrain instead, so the stale-id preservation is the discriminator and no EnvCell geometry fixture is needed. Sabotage-verified: restoring `body.Position = settle.Position` fails exactly the new test (1 failed / 4) and leaves the other three green — confirming both that the new test discriminates and that the old ones never could. Core suite 4,263 passed / 1 skipped / 0 failed, +1 for the new test. Still open and unverified, deliberately not claimed closed: whether the remote spawn-seed caller (LiveEntityNetworkUpdateController) hands in a body that carries a CellPosition at all. CommitTransitionPosition early-returns on a zero cell, so this fix is an inert no-op there and #276's remote half may survive. The C3c local first-entry caller is confirmed — it passes activation.Body.CellPosition.ObjCellId. Scoping detail in docs/research/2026-08-06-276-remainder-scoping.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
408c8e8f34 |
docs: #276 remainder scoping — the outdoor half is already correct; EnvCell is the real gap
Analysis only. A candidate fix was written, built clean and passed the
three existing settler tests, then deliberately REVERTED — the only test
that discriminates it needs an EnvCell fixture that was not safe to
assemble at the end of this session. The production tree is unchanged.
Headline: the issue's framing is half wrong, and the half it misses is the
whole fix. PhysicsBody.Position's ordinary setter already carries the world
displacement into the landblock-relative frame AND calls
LandDefs.AdjustToOutside, which recomputes the outdoor cell index across
24 m cell crossings and wraps/bumps the landblock across 192 m boundaries.
So for an outdoor->outdoor settle, discarding settle.CellId costs nothing.
The live defect is EnvCells. An EnvCell id is not derivable from a world
position, and AdjustToOutside's guard ((cell & 0xFFFF) is >= 1 and <= 0x40)
deliberately excludes EnvCell ids from that path. settle.CellId is the ONLY
carrier of an EnvCell identity, and it is exactly what the settler drops —
so the defect is the issue's parenthetical ("outdoor/EnvCell seam, stacked
EnvCells"), not its main clause. That also means the fix is a no-op on the
outdoor path that dominates production and corrective only at the indoor
seam.
Recorded so the next reader does not repeat the misreading I made:
CommitTransitionPosition looks like it pairs a new cell with a stale local
origin, but line 259's `Position = worldPosition` runs the ordinary setter
first, so line 265 reads the already-updated origin. Retail anchor
CPhysicsObj::SetPositionInternal(CTransition const*) 0x00515330 commits both
objcell_id and frame, including EnvCells.
Also recorded: the three existing settler tests build bodies with no
CellPosition, so every one passes identically with or without the fix.
Shipping against them would repeat C5b finding D3 — a test that passed with
its own change reverted. The doc carries the exact discriminating test, its
required sabotage, and the fixture risk (the resolver must genuinely report
the EnvCell in settle.CellId; a fixture that silently resolves outdoor would
be green and prove nothing).
Open and unverified: whether the remote spawn-seed caller's body carries a
CellPosition at all. CommitTransitionPosition early-returns on a zero cell,
so the fix would be an inert no-op there and #276 would stay open for
remotes. Must be settled before claiming the fix closes both halves.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Erik
|
1d2d4bb8bd |
docs: #317 velocity-chain audit — verdict NO RETAIL BASIS (report-only)
Report-only per CLAUDE.md's investigation rule; no fix applied and none approved. The call at LiveEntityNetworkUpdateController.cs:2459 is untouched. Verdict: velocity is a SEPARATE WIRE CHANNEL in retail, and acdream's accepted-Position path crosses it. SmartBox::DoVectorUpdate 0x004521C0 is retail's sole velocity installer for a remote (set_velocity 0x0045221E + set_omega 0x0045222C), gated on update_times[3] = VECTOR_TS — not Position's update_times[0]. An exhaustive grep of its call sites returns exactly two, and neither is the Position path: SmartBox::HandleVectorUpdate 0x00453480 (call 0x004534E6) and SmartBox::HandleCreateObject 0x00454C80 (call 0x00454EE9). HandleReceivedPosition's only set_velocity is 0x004541B4, which ZEROES the local player on the teleport arm. Retail is not merely silent here, it is deliberate: PositionPack::UnPack 0x00516740 does decode a velocity off the Position wire (field written 0x005167E9) — retail receives the value and drops it on this path. acdream instead commits acceptedSpawn.Physics?.Velocity on every accepted Position, and the retail-correct mechanism ALREADY EXISTS one method away (TryCommitAuthoritativeVector, whose doc comment describes DoVectorUpdate's exact paired shape). The Position-path call is therefore both non-retail and redundant with a correct sibling. Sharpening the divergence: the call passes `?? Vector3.Zero`, so a Position without HasVelocity actively zeroes the body — something retail never does on this path. Recommended (NOT approved): either remove the call, or keep it and file a register row as a deliberate adaptation in AP-135's class. Three unresolved inputs decide which, listed in the report's section 5 — chiefly what consumes body.Velocity for a remote (AP-80's velocity-derived animation cycle is the specific unknown), and whether ACE sets HasVelocity at all. The retail half of the audit is settled; those three are cheap follow-ups that do not need the binary again. Successor note: this function family carries Binary Ninja's dropped-flag artifact (`-((eax_4 - eax_4))` at 0x004521F5 and 0x00452186), the same one the C5b review hit in Gate A. Do not read a comparison here from pseudo-C. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
429775d4c4 |
docs: #316 investigation — verdict COSMETIC, resolved without a live gate
Report-only per CLAUDE.md's investigation rule; no fix applied and none approved. Committed so the evidence is not lost. Verdict: the player arm's airborne-snap block skips the collision-shadow publish, but the stale shadow self-heals within one object quantum (~33 ms). Not the #184 invisible-but-solid class. The reasoning is structural rather than incidental, which is why it resolved offline instead of needing a connected sample. The per-tick gate at RuntimeRemotePhysicsUpdater.cs:840 compares the body against LastShadowSyncPos/Orientation, and those fields are stamped ONLY inside SyncRemoteShadowToBody immediately after a publish. They therefore record where the shadow actually is, which makes the gate an invariant check ("is the shadow more than 1 cm / 0.51 degrees from the body?") rather than a change-detector. The snap's two raw field writes leave that invariant violated and untouched, so the next quantum sees the full delta and republishes. Three findings beyond the question asked: - One residual does NOT self-heal: past 96 m the activity gate deactivates the remote while OnPosition is not distance-gated, so a distant player-remote's render entity moves and its shadow does not, until it re-enters the bubble. Unobservable in practice — everything that could sweep against it is gated by the same rule. - The "LANDING TRANSITION" naming throughout the file is stale: the predicate is !Body.InContact, the whole airborne period, so it fires on every airborne update rather than once at the landing edge. - RuntimeSetPositionState.cs:5037 stamps LastShadowSyncPosition before a guard at :5138 that can return ahead of the publish at :5148 — a possible masking hole, deliberately not folded in. Retail note: retail has no separate shadow at all — SetPositionInternal 0x00515330 calls remove_shadows_from_cells/add_shadows_to_cells in the same transaction, so the skip is a real divergence, just a 33 ms one. Recommended next step (NOT approved): an offline two-step test composing the collapse-matrix player-guid landing fixture with one Tick, asserting the shadow converges. Strictly stronger than a connected sample, which could only show that nobody noticed 33 ms. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
3aab05b0cc |
fix(streaming): derive the portal reveal window from the live streaming radii (#280)
The user watched far terrain visibly assemble after portal space exits.
The reveal gate was NOT missing a hold — Slice E's hold mechanism is
correct and already in place. The hold was measuring the wrong domain:
it opened at a hardcoded 3x3 landblock neighbourhood (~192 m) while the
visible world extends to the fog end (~2,189 m at the shipped High
preset, inside a 2,304 m Far window). An 11.4:1 ratio.
Retail's equivalent ratio is 1:1 BY CONSTRUCTION. `LScape` owns one
`mid_width x mid_width` array of `CLandBlock*` (`LScape::SetMidRadius`
@0x00504C00, `LScape::update_block` @0x005063A0), `mid_radius` is
assigned directly from the user's `Render.LandscapeDrawDistance`
preference (`SmartBox::SetRegion` @0x004531F0; values
`Render_LandscapeDrawDistance_Values` @0x007CA988 = {3,5,8,11,15,25},
default 8 — both byte-verified against the PDB-paired 2013 binary), and
that same square is simultaneously the prefetched set
(`LScape::PreFetchCells` @0x00505660), the drawn set (`block_draw_list`
over the same array), and the set the simulation blocks on
(`CellManager::blocking_for_cells`). There is no retail configuration in
which the client streams farther than it gates, because there is only
one number.
So the fix derives rather than duplicates. Four coupled parts, which is
why this is one commit and not four — D1 without D2 hangs the client and
D2 without D1 is dead code:
D1 `WorldRevealReadinessBarrier` takes a live `Func<StreamingRevealWindow>`
and stops being static: outdoor requires `FarRadius`, indoor still 0
(retail's `CEnvCell::PreFetchCells` @0x0052D1E0 arm). Read per
evaluation, never captured — the radii are runtime mutable through
Settings, and retail's answer to a mid-hold radius change is to reset,
re-radius, and re-arm the blocking prefetch at the NEW value
(`SmartBox::set_mid_radius` @0x00453180). `OutdoorNeighborhoodRadius`
is deleted; there is no constant left to drift.
D2 `StreamingController.IsRenderNeighborhoodResident` becomes tiered,
because acdream's loaded landscape is: inside `NearRadius`,
`IsNearTier && IsRenderReady`; out to `FarRadius`, `IsRenderReady` only.
Without this the fix cannot work at all — nothing outside the Near ring
is ever promoted, so any radius above `NearRadius` was unsatisfiable and
would have held the reveal forever. Proof obligation P1 (a Far-tier
landblock genuinely satisfies `IsRenderReady`) is now a test driven
through the real `PublicationKind.Far` pipeline against a real
`LandblockSpawnAdapter`, not an inference.
D7 `RuntimeWorldTransitState.AcknowledgeDestinationReadiness` re-derived
`indoor ? 0 : 1` and failed `invalid-readiness-shape` on any other
value, so changing the radius alone would have looked like "the fix
hangs the client". It is now a SHAPE invariant (`indoor => 0`,
`outdoor => >= 1`). Runtime does not own the graphical host's streaming
configuration and must not learn it; plumbing App radii into Runtime to
preserve the strict equality is exactly the assert-a-mechanism-that-does-
not-exist failure C5b was built to stop. Both non-graphical producers
keep emitting their centre-ring token and stay legal, annotated in place.
D6 `PhysicsEngine.IsNeighborhoodTerrainResident` rebuilt a full-map
`HashSet` on every call, every frame of every hold. At radius 1 that was
invisible; at radius 12 (625 ring members) it violates Slice I1's
0 B/resolve standard. Now an engine-owned scratch set, cleared in place;
measured at 0 bytes over 1,000 warmed radius-12 queries.
Also: the destination reservation opens at exactly the gate's radius and
reopens on the same generation when the radius changes mid-hold (retail
has one square for both, and no concept of prioritising an inner ring
differently). Composite warmup deliberately stays `NearRadius`-scoped —
the composite domain is entity-scoped and Far builds carry no entities,
so widening it would walk the outer window to warm nothing.
`ACDREAM_PROBE_REVEAL_RADIUS` is a measurement probe in a diagnostic
owner (CLAUDE.md rule 5) so the connected route can be run A/B on one
binary; it is NOT a user-facing prefetch knob, since a low setting would
reintroduce the decoupling this slice exists to close.
Register: AD-2 amended with the derived window, the two-tier split, and
the four new retail anchors. AP-149 FILED for the residual this does not
close — the outer ring accepts terrain-only publication where retail
requires LandBlockInfo and every building EnvCell, so a distant building
can still pop in at Far-ring distances. Do not let a later closeout
claim parity.
Docs: `ACDREAM_STREAM_RADIUS`'s CLAUDE.md description was wrong on every
clause (the default is unset, not 2; it forces `NearRadius`; it is
silently discarded by any Settings save) — corrected, since that is the
file every session reads. `reference_two_tier_streaming.md` corrected in
four ways, including "Far tier = terrain only": Far also publishes
terrain COLLISION, which is precisely what makes this fix viable.
#280's issue text had the right conclusion from a wrong premise (it
names a view-distance setting acdream does not have) — corrected, and
the missing Viewing Distance option filed separately as #326, with #327
(DDD progress readout) and #328 (hardcoded 5000 f far plane vs retail's
byte-verified 4000) filed alongside.
Expect LONGER holds and the "In Portal Space - Please Wait..." cue on
recalls MORE often. That is convergence toward retail, not away from it:
retail emits the byte-identical string for the whole duration of a
blocked prefetch and polls at 5 s intervals. The failure condition is
non-convergence, not duration.
Gates: Release build 0 errors. Complete suite 11,178 passed / 4 skipped
/ 0 failed, against a re-measured 11,142 / 4 / 0 baseline at
|
||
|
Erik
|
9ee9c1a1a6 |
fix(runtime): close the C5b re-review findings — Gate A narrowing filed, no-window payload gate, bisect hazard recorded
Both C5b re-reviews returned PASS on 02578441..ff100cf3. This lands the bookkeeping corrections they left, the one gate asymmetry both found independently, and one wrong retail fact neither of them caught. 1. AP-148 / #325 — Gate A's teleport test, wrong on primary source twice. The C5b contract stated retail's Gate A teleport term as "TELEPORT_TS equal" (and, in the trace block, as "must NOT be newer") and blessed acdream's `teleport == _timestamps[Teleport]` as retail-exact. Disassembly of the PDB-paired binary at SmartBox::HandleReceivedPosition 0x0045402B-0x00454054 says otherwise: the shortcut is taken iff the wire stamp is equal OR newer (wrap-safe) — `sbb eax,eax / neg eax` materialises the carry of the compare and the branch skips Gate A on CF, i.e. only when the wire stamp is strictly OLDER. It is CPhysicsObj::newer_event @0x00451B10's identical idiom with the operands swapped. Binary Ninja drops the flag test and renders it `if (-((eax_7 - eax_7)) == 0)`, always true — which is why two rounds of reading pseudo-C recorded it backwards. So acdream's ForcePosition disposition is a strict SUBSET of retail's Gate A set, and a local ForcePosition carrying a newer teleport stamp is misrouted into a full Apply: wire heading instead of preserved heading, unparent, possible placement frame, zeroed velocity, TELEPORT_TS advanced, and OfferTeleportDestination called for a packet retail never starts presentation for. PhysicsTimestampGate.cs is NOT changed. The predicate exists twice (also ValidAcceptedAuthority's PreviousTeleport == AcceptedTeleport), and the fix has to decide TELEPORT_TS's disposition on a Gate A path that has never seen a stale-but-equal pair. #325 records all of it and says explicitly that it is not a one-line comparison swap. C5b made this marginally better, not worse: clearParent was unconditionally true before C5b and is unchanged; installPlacementFrame moved toward retail's HasAnims gate. 2. Retail F2 / architecture L-A — the no-window route had no pre-merge payload validation. Root fix, not a documented asymmetry. The graphical route validates before the merge (OnPosition's payloadIsValid -> LiveEntityInboundAuthorityGate's !payloadIsValid return); despite its name CanAcceptPositionPayload is not projectile-scoped. The no-window route had no equivalent, and since D1 fed an unvalidated LandblockId into CommitWireCellRebucket — where 0 is the withdrawal shape, silently de-residencing the entity in the field every bot reads as CellId. RuntimeLiveEntitySessionController.OnPositionUpdated now applies the same rule at the same point, reusing RuntimeAuthoritativePositionRouteClassifier.IsValidCreateWirePosition plus the finite-velocity term — the exact pair TryApplyPosition already applies on its initial-residence branch. Chosen over documenting it because the fix is five lines and leaving it would have left two written claims falsified by the code. It is a behaviour change: headless now drops packets it merged. Against ACE the set is empty, and the graphical host has carried this gate since it was written; the argument is recorded in the contract's §15.2 rather than gated. Two test fixtures carried cell ids retail's own inbound_valid_cellid rejects (low words 0x41 and 0x51, above the 0x40 landcell ceiling). Their constants were corrected; their assertions were not. New test sabotage-verified in both directions: gate removed -> red at the withdrawal-shape assertion; gate moved to guard only the cell commit -> red at the pose assertion, which is what makes it a before-the-MERGE test rather than a before-the-commit test. 3. Register and doc corrections. - AD-64: "deliberately absent" was presented as the complete difference list and was not. Adds (a) the residence gate is weaker than the merge's own — both hosts' commits use TryGetCurrent while TryApplyPosition's FIFO branch uses TryGetTransaction, so the wire cell can commit ahead of the continuation that will replay it; (b) the two missile gates are two different expressions that agree today; (c) the payload gate, now present. Risk column records that (a) and (b) have no discriminating test on either side. - AP-147: amended for D1 — pre-D1 the no-window host published [Updated] alone and lost the Rebucketed, so a headless event log is now a real instance of the "consumer that snapshots a delta" the row warns about. - AD-60: "Matches retail exactly" scoped to the withhold, since the row's body documents two channels that do not. - CommitWireCellRebucket: notes the unreachable ThrowIfNull / EnsureNotDisposed precedence inversion. - TryCommitAcceptedWireCell: the discarded commit bool is explained rather than left bare — false means IsCurrent went stale, unreachable three statements after a synchronous TryGetActive. 4. Bisect hazard recorded in the C4 closeout handoff (the doc CLAUDE.md sends readers to before any C5 work) and in the contract's §15.3: commits 735f0a72..23aa62f2 contain a live headless defect — every remote's FullCellId frozen for the session — introduced by |
||
|
Erik
|
ff100cf33f |
fix(runtime): give the no-window host a post-merge canonical cell commit (D1, AD-60/AD-64, AP-146/#320)
C5b ( |
||
|
Erik
|
23aa62f292 |
fix(review): close the C5b architecture-review findings (D2/D3/D4, L1-L5, S1)
Follow-up to C5b ( |
||
|
Erik
|
ed8069976c |
docs(register): restore AP-131 as a struck-through retired row (C5b follow-up)
C5b deleted AP-131's row outright and recorded the retirement only in the AP section header, describing that as house style. It is not: the register carries 32 struck-through `~~ID~~` retired rows, including AP-1 and AP-145 retired one commit earlier in C5a, and the C5b contract explicitly mandated "rewrites the row's text to past tense with the evidence ... which the C5a/AP-1 and 4b-3/AP-137 rewrites established as the house style". A deleted row loses the evidence a header clause cannot carry, and leaves a reader who greps AP-131 with nothing rather than a retired row. Restored in the AP-1 shape, with one fact the header omitted and that is worth keeping: this row's own predicted retirement mechanism did not occur. AP-131 forecast "the legacy caller is deleted at the production cutover, retiring this row by construction" — the caller was corrected instead, and the steady-state merge remains a live production Position caller. That is the kind of prediction the register exists to be honest about. Active-row count is unchanged at 100; struck-through rows are retired, not active. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Erik
|
735f0a72af |
fix(physics): classify before merge on every steady-state Position (C5b, #275, AP-131/AD-60)
The steady-state accepted-Position merge did two things retail never does,
on every single Position packet: it installed the wire placement frame and
unparented unconditionally, and it derived the record's FullCellId from
bare wire acceptance. Both are now correct, and they land together - a
half-flipped intermediate (classified flags with the wire stamp, or vice
versa) is exactly the mixed-residency state this campaign keeps paying for.
WHY the flags need no route. SmartBox::HandleReceivedPosition @0x00453FD0
decides both pre-placement writes BEFORE MoveOrTeleport is consulted: Gate A
@0x0045400C returns @0x0045409D ahead of unset_parent @0x00454129 and ahead
of the HasAnims SetPlacementFrame gate @0x00454137. Neither gate reads the
near/far/teleport classification. So the two flags are a pure function of
(disposition, hasAnimations) and are computable inside the merge, pre-merge,
with no signature change, no route construction and no playerDistance - the
scoping's ~150-400-line route-plumbing estimate over-counted because it did
not see this. That truth table IS
RuntimeAuthoritativePositionRouteClassifier.ClassifyAcceptedPosition's own
ApplyPlacementFrameBeforeRouting/UnparentBeforeRouting rows; the classifier
stays the oracle and the equality is pinned by test, not by a shared path,
so each computation remains separately sabotage-verifiable.
WHY the cell is withheld. HandleReceivedPosition reads the wire objcell_id
into a LOCAL @0x00453FE3 and hands it only to BlipPlayer / TeleportPlayer /
MoveOrTeleport / ConstrainTo; it never assigns the object's cell. The
object's cell moves inside the placement family (SetPositionInternal
@0x00515BD0 to set_cell, enter_world) or per-frame transit, and nowhere
else. The continuation executor has encoded that rule since the executor
slice; this caller now matches it verbatim.
WHAT DELIBERATELY SURVIVES. Two steady-state wire-cell writers stay,
downstream of the merge and outside the classification window: the
OnPosition prologue rebucket (W2, into CommitRebucket), which is also the
local player's own cell-freshness path, and the post-routing wire-cell adopt
for non-placing arms (W3, AP-135). Gating W2 "for symmetry" would freeze the
player's canonical cell between teleports and #319's child-cell equality
would inherit the freeze. AD-60's rewrite names both so the retirement
cannot be misread as "wire acceptance never changes residency anywhere".
REGISTER. AP-131 RETIRED - the unconditional literals no longer exist; the
caller was corrected, not deleted, so the row's own "deleted at the
production cutover" framing is overtaken. AD-60's legacy half RETIRED and
the row REWRITTEN rather than deleted, naming W2/W3 (route 4b-3's D8
precedent: a silent whole-row deletion would hide surviving channels).
AP-130 amended - the merge consumes the same static HasAnimations proxy,
deliberately not escalated to a live animation-queue read. AP-146 and #320
amended - their "accepted inbound Position (RefreshSnapshot into
RuntimeEntityRecord.cs:234)" local-player cell writer is now the generic
tail's CommitRebucket, and a ForcePosition (which returns before that tail)
is placement-receipt-authoritative. #275 closed.
HEADLINE BEHAVIOURAL DELTA, stated once: a refused or contended local
ForcePosition now leaves FullCellId at the last committed cell where the
merge used to stamp the refused packet's wire cell. Retail cannot refuse
(AD-62) and its body keeps its last placed cell, so the new shape is the
retail-reachable one.
THREE CONSUMER SITES THE CONTRACT'S BLAST-RADIUS SURVEY MISSED, all
D2-caused, all found by the suite rather than by reading, all intended
semantics rather than regressions (recorded in the contract's new section
14):
(1) DatLiveEntityProjectionMaterializer's self-projection branch reads
FullCellId inside OnPosition's prologue recovery, ahead of W2. It now
correctly declines to project from an unplaced wire claim; production
installs the bucket at W2 in the same call (verified: no return between
the recovery call and W2 is conditioned on IsSpatiallyProjected or
FullCellId). Two hydration tests asserted the bucket at the recovery
boundary and now drive the production W2 step - the same shape as trap
T2, one layer up.
(2) ProjectileController.SyncPresentationFromResolvedBody writes
ParentCellId = record.FullCellId. On a refused missile placement that is
now the committed source cell. The MAJOR-1 invariant is unchanged and is
now asserted as the identity it always meant rather than as a wire-cell
constant.
(3) The merge's Rebucketed ternary does NOT become always-Updated as the
contract predicted, and is deliberately kept: the
Forget(restoreCancelledPark: true) above it can roll a wakeable
lost-cell park back, and RestoreParkWithdrawal restores canonical
residency. That is a real cell edge produced inside this method by a
placement owner.
TEST-COUNT RECONCILIATION. Baseline measured at this HEAD by stashing the
change: Runtime.Tests 1176, App.Tests 4135 (4132 passed / 3 skipped),
solution 11,106 passed / 4 skipped - matching the recorded figure at
|
||
|
Erik
|
0257844106 |
docs: file #321 — a THIRD load-sensitive test failure, filed rather than absorbed
A DatSoundCacheTests concurrent-decode-dedup fact failed once under full-suite load during C5a's commit-1 standalone verification and passed clean in isolation. Filed as its own issue deliberately. It is neither #302 (PortalProjectionTests GC-allocation, App.Tests) nor #308 (NakEmissionTests wall-clock, Core.Net.Tests), and the standing rule that those two must never be conflated exists precisely because absorbing a new intermittent into an existing "flake class" is how a real defect gets dismissed as noise. What is genuinely unknown is whether this is a fixture race or a thread-safety defect in the decode cache itself. That distinction is load-bearing: DatCollection is already recorded in project memory as NOT thread-safe, so an audio decode cache racing under load would be the same family rather than a coincidence. The first step is a repeat/stress run of Core.Tests alone — load- only means scheduling pressure, reproduction in isolation means a real race. Explicitly no retry, Skip, or delay: a masked race is worse than a red test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Erik
|
6921a02744 |
refactor(physics): delete legacy PhysicsEngine.Resolve/ResolvePlacement/HasCellSurface (C5a, AP-1/AD-1)
Member-wise deletion of the three legacy resolver members named in docs/research/2026-08-05-c5a-contract.md: PhysicsEngine.Resolve, PhysicsEngine.HasCellSurface, and PhysicsEngine.ResolvePlacement. An exhaustive receiver census over src/ found zero production callers of any of the three — every production placement writer already reaches the canonical PhysicsEngine.SetPosition transaction exclusively through RuntimeSetPositionState (three call sites total). The deletion is purely member-wise: IsSpawnCellReady and AdjustPosition, which shared the same source region as the deleted members, are preserved byte-identical — every remaining production caller of either (including PhysicsCameraCollisionProbe, AdjustPosition's sole surviving production caller) is unaffected. Companion changes: - PlayerMovementController's 3-argument SetPosition test overload is renamed to SeedPlacementForTest (internal) and CommitPreparedPosition is deleted; 83 call sites across 19 test files were mechanically renamed to match. - Seven pinned test dispositions from the contract are executed: 3.1 (PhysicsEngineTests.cs: 11 legacy-resolver tests deleted, 6 ResolveWithTransition tests kept), 3.2/3.3/3.4 (re-point to canonical SetPosition, with TransitionScratchDifferentialTests.cs additionally gaining positive IsCommitted assertions after each bitwise comparison so the differential proves a placement actually committed, not just that two possibly-uncommitted results match), 3.5 (Runtime rename), and 3.6 (PlayerMovementPlacementTransactionTests.cs rewritten — its xmldoc now states plainly that the render-root publish moved to RuntimeSetPositionState.cs, but the sticky-release relocation claim was false and is retracted; this disposition's coverage loss is the sticky release path, not silently absorbed elsewhere). - Stale `PhysicsEngine.Resolve`/`Resolve` doc citations in CellTransit.cs, PlayerMovementController.cs, and HeadlessSessionWorldProjection.cs are corrected to name the surviving canonical entry points by symbol (SetPosition, AdjustSetPosition/AdjustPosition, ResolveWithTransition) rather than fragile line numbers. Retires AP-1 and AD-1 in docs/architecture/retail-divergence-register.md: both rows described production zero-delta placement routing remaining on the legacy resolver pending the Slice 4B2/4B route cutover; that resolver no longer exists, so the condition each row tracked is now structurally false rather than merely narrowed. AP-145 (routed through the prior commit) and this commit's AP-1/AD-1 together bring the section counts to 101 AP / 47 AD active rows. Builds on the AP-145 fix (previous commit) — this commit's staged tree was independently rebuilt and its four suites independently rerun on top of that commit before this commit was created, in addition to the combined rebuild/rerun below. Full-solution build: 0 errors (21 pre-existing warnings, all unrelated). Suite results (combined tree): Core 4270/4271 passed (1 skip; the single DatSoundCacheTests concurrent-decode-dedup failure is a known load-sensitive race, confirmed passing standalone and unrelated to this change), Runtime 1176/1176, Headless 86/86, App 4132/4135 (3 skips). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |