Synchronize the architecture doc, milestones, roadmap, and ISSUES with the
continuation-executor behavior commit (5db3de3c): the residence system is
now a complete dormant mechanism, both independent reviews PASS, and the
next boundary is the all-host production cutover. The admission handoff
gains its superseded banner; the successor handoff records the executor's
ownership, the retail anchors proven during review (the wire-contact gate,
queue-by-parent-GUID relation replay, HasAnims semantics), the seven new
register rows, exact test totals, the rollback command, and the cutover
checklist. #275 filed for the post-cutover legacy-Position unification.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
User-verified: casting fixed (exhaustion-edge gate) and monster attack
animations restored (spawn settle placement + lost-cell retry). Final
session evidence: 14/15 spawn settles grounded; Falling-refusal spam
collapsed 2,954 -> 15 transient pre-settle lines.
Strips the [UM-ACT]/[MT-FAIL]/[SPAWN-PLACE]/[remote-edge] probes, the
MotionInterpreter.DiagnosticGuid plumbing, and the two throwaway probe
tests (motion-table attack sweep, vitae color dump - both findings are
recorded in ISSUES/research). Complete Release suite: 10,030 passed /
5 skips / 0 failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The [MT-FAIL] probe caught combat-stance monsters constantly failing to
dispatch 0x40000015 (Falling): their bodies were airborne-flagged while
standing. contact_allows_move (0x00528dd0) requires Contact+OnWalkable
and silently refuses every action animation for an airborne mover - a
spawned-standing monster's swings never played until it first moved.
Retail never has this state: CreateObject spawns run the placement
transition (CPhysicsObj::SetPosition -> SetPositionInternal 0x00515330),
which establishes CONTACT/ON_WALKABLE from the floor at spawn. Our
remote creation seeded a raw position with no placement.
SeedRemoteSpawnPlacement mirrors RemoteTeleportPlacement: engine
placement resolve (Setup-derived cylinder, TS-46) + the verbatim
CommitSetPositionTransition, wired at BOTH RemoteMotion creation sites
(UM-triggered creation - so a first-ever-UM attack animates in the same
packet - and ordinary first-UP creation). Unplaceable results leave the
body airborne exactly like a failed retail placement.
Also adds the [UM-ACT] (wire action items + stamp-gate verdict) and
[MT-FAIL] (refused animation dispatches) probes, riding
ACDREAM_DUMP_MOTION=1, which are what convicted the body state.
Complete Release suite: 10,032 passed / 5 skips / 0 failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Retail calls CPhysicsObj::report_exhaustion from exactly one site -
CommandInterpreter::HandleExhaustion (0x006b3c70), a notification handler
for the stamina-exhaustion EVENT. Campaign P P1 wired it to every
movement-stats application instead (every stamina regen/drain tick), and
each call re-dispatches the current movement state through the animation
sink - truncating any in-flight action animation. The diagnostic session
log shows 490 spurious casting-stance re-queues in one short session:
'sometimes stuck in spell animations' was every stamina tick that
collided with a cast gesture's play window.
The re-apply now fires only when the exhausted state (stamina == 0)
transitions, matching retail's event semantics. Stats still reach
PlayerWeenie immediately via RuntimeMovementSkillProjection.ApplyTo.
Also adds the [remote-edge] probe (rides ACDREAM_DUMP_MOTION=1): one
line per remote HitGround/LeaveGround - each such edge drains the
mover's pending action animations (retail HandleEnterWorld), the
working theory for intermittently missing monster attack swings.
Complete Release suite: 10,026 passed / 5 skips / 0 failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Retail jump landings BOUNCE: the floor touch records both a contact plane
(grounding) AND a collision normal (collided_with_environment), and
handle_all_collisions reflects the unmodified impact velocity off it at
5% elasticity (v += -(v.n)(elasticity+1).n, DEFAULT_ELASTICITY 0.05
@0x007c6a7c). Our transition already recorded both facts; the bounce was
suppressed by the AD-25 adaptation stack in the per-tick commit: a
Velocity.Z<=0 landing gate (needed because the resolver glued ascending
movers to the ground) plus a landing Velocity.Z=0 hand-zero whose stated
purpose was making the reflect a no-op. Downhill glided instead of
bouncing, flat-ground landings had no pop, and uphill jumps flapped
between grounded/airborne against the animation machine.
Three retail mechanisms replace the stack:
- check_contact (0x0050f5b0) seeding in ResolveWithTransition: a body in
CONTACT seeds the transition's contact only while v.contactPlane.N <=
0.0002; moving away seeds the last-known plane alone (get_object_info
0x00511cc0). Ascending jumps therefore run contact-free (ballistic, no
glue) - the gate's reason-for-being is gone. The plane requirement is
strict: Contact-without-plane is unrepresentable in retail.
- SetPositionInternal-shaped commit (0x00515330, byte-read end-to-end,
velocity-sign-FREE): contact purely from the transition's contact
plane, HitGround on the airborne->walkable edge, HandleAllCollisions
with unmodified impact velocity. Whole commit gated on Ok &&
candidateMoved (retail pc:283657 skips SetPositionInternal entirely
when the candidate did not move) - a standing body's contact state is
never re-derived, which is what keeps rest bit-stable (AD-41 updated).
- Byte decodes: gate override state&0x800000=Sledding, zero branch
state&0x20000=Inelastic, reflect strictly dot<0 - our port already had
all three correct.
Settle: real landings (>=0.25 m/s) bounce and decay geometrically;
smaller impacts are consumed by retail's unconditional small-velocity
zero, so standing never micro-bounces. Re-baselines documented in place:
landing-survival pin measures decay post-settle; LiveCompare_Tick0/376
pin the new IsOnGround=false on zero-move ticks (captured true was the
retired seed echo; tick 376's captured body carries an 11.8 m/s grounded
velocity from the deleted get_state_velocity-overwrite era); de-overlap
fixture now carries the plane real grounded bodies always have. New
pins: LandingBounceSeedingTests (ascent no-seed, rest keeps contact,
strict plane, slope 5% reversal + tangential preservation, Sledding
override).
Investigation + implementation record:
docs/research/2026-07-30-landing-bounce-family.md. Complete Release
suite: 10,031 passed / 5 skips / 0 failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs/ISSUES.md: #265 and #166 updated with the root cause and fix from
the prior two commits; closure of both pends the user's visual-gate
acceptance. #265 also records the confirmed-separate uphill-bounce
finding (AD-25, byte-exact retail, out of scope). #166 records that the
Campaign P visual-matrix recheck it was waiting on DID happen and found
the glide/bounce still missing even with AD-25/AP-7/AD-55/TS-4 all
landed - that negative result is what triggered the #265 capture bisect
and this fix.
docs/architecture/retail-divergence-register.md: AP-7's retirement note
corrected. The row's original claim ("no horizontal velocity to hammer")
undersold the gap - calc_friction was structurally unreachable with
meaningful data on any grounded path, not just inert on the root-motion
path. No new row filed: this change ports retail's mechanism faithfully
and does not introduce a new deviation.
docs/research/2026-07-30-265-capture-bisect.md: full "as-fixed" addendum
(new section 9) recording the implementation - the fix mechanism, fixture
results (freeze reproduced under the old model, slide+decay proven under
the new one), the downhill-direction derivation for the synthetic decay
case, the two separate mechanisms found while building the Runtime tests
(LeaveGround's edge-timing recompute, AP-77's no-sink fallback), the
uphill-bounce orthogonality proof, and final test totals.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Raw byte decode of MovementSystem::GetRunRate (0x006b0950, PDB-paired
binary): fild skill; fcom [800f]; fnstsw; test ah, 0x44; jp general —
the C2/C3 parity idiom whose 18/4 fall-through executes ONLY at
skill == 800 exactly. ACE read this as >= 800 ('max run speed?') and
Campaign P P1 inherited that misread when BN dropped the arithmetic,
flat-lining every maxed character at 4.5 (retail-true ~3.70, +21%) and
erasing the vitae differential (both 10200 and 15225 sat above 800).
The [stat-chain] live capture proved the enchant chain correct end to
end (vitae 0.67 -> eff run 10200 -> controller), isolating the formula.
General path byte-verified: (loadMod*(skill/(skill+200)*11)+4)/scaling/4.
InqMaxRunRate's skill=9999 probe gets ~3.6961, not 4.5.
Golden tests pin the 799/800/801 straddle and the maxed-skill vitae
differential; pseudocode doc §6 carries the decode plus a do-not-
reimport-ACE warning. Complete Release suite: 10,025 passed / 5 skips.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Retail CACQualities::EnchantAttribute (0x00594570), EnchantAttribute2nd
(0x00594670, already ported for #6), and EnchantSkill (0x005947b0) are the
three enchantment-composition functions the Character window's Attributes
and Skills tabs depend on. Primary attributes never reference the vitae
singleton in retail (only Attribute2nd/Skill do) — confirmed directly from
the decompiled function bodies, not assumed.
EnchantmentMath.GetMod gains requiredType/includeVitae parameters (default
to the prior behavior) so a numeric StatMod key collision across domains
(e.g. key=1 is both Strength and MaxHealth) can't leak a buff into the
wrong computation. Spellbook.GetAttributeMod/GetSkillMod and
LocalPlayerState.GetEffectiveAttribute/GetEffectiveSkill/
GetSkillVitaeModifier wire the retail chain through to the panel.
CharacterSheetProvider now reports the effective value as the main number
and CharacterSkill.CurrentLevel is no longer an alias of BaseLevel (this
also activates the previously-dead SkillValueColor buffed/debuffed row
coloring). CharacterStatController's footer-title parenthetical is cited
from gmAttributeUI::DisplaySelectionFooter_Attribute (0x0049d280) and
gmSkillUI::DisplaySelectionFooter_Trained (0x0049b860) +
SkillInfoRegion::GetVitaeModifier (0x004f0fa0): skills show up to two
segments (vitae's own contribution, then the buff-only residual), while
vitae-immune attributes show at most one; no parenthetical when the delta
is zero. The panel now refreshes on Spellbook.EnchantmentsChanged, not only
raw property/attribute updates.
Core goldens cover the user-reported 33% vitae example (303->203, "(-100)"
exactly), buff+vitae composition, and the attribute vitae-immunity finding.
Provider/controller tests cover the full row-click -> footer-title path and
live refresh. Full solution suite passes with zero failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Their 2026-07-05/17 'pending user visual gate' statuses are superseded by
the consolidated Campaign P matrix; automated backing since the fixes
(R6 acceptance, nine-stop soaks incl. today's PASS, P3 conformance
suites) is recorded per entry. The matrix result closes or reopens each.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Per docs/research/2026-07-30-ts4-116-oracle-plan.md, following the four
code commits that closed out TS-4 (5e2be19b), #116 shape-2 (01492205),
and AD-55 (252e8068), plus #116 shape-1's Path-6 fix (db2889af) and the
TransitionalInsert return-value fix (7e1be3de):
- ISSUES.md #116: shape-2 marked CLOSED (D4 un-skipped, structurally
confirmed, no cdb needed). Shape-1 narrowed, not closed: the Path-6
head-sphere fix is a real, independent improvement but the tick-22760
confirming replay showed it doesn't explain that specific symptom --
the mover is grounded there (Path 5, not Path 6) and the actual
no-normal-recorded mechanism (SpherePath.PrecipiceSlide's
find_crossed_edge-false fallback) is independently confirmed byte-exact
retail behavior too. Recorded the concrete next step (re-run against
the faithful Setup-based door registration instead of the simplified
fixture) rather than closing on an unmet acceptance criterion.
- ISSUES.md #166: noted TS-4 and AD-55 landed (the AP-7-family
completion this note was waiting on); closure still pends the visual-
matrix scenario-5 recheck against live retail.
- Campaign P plan (2026-07-29-physics-parity-campaign.md) P2 status
block: TS-4 outcome (retired, not deferred), #116 outcome (shape-2
closed / shape-1 narrowed), AD-55 outcome (retired).
Docs-only; no build/test change required for this commit.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PhysicsBody.IsFullyConstrained now reflects real ConstraintManager state
(pushed every tick by the same per-tick pumps commit 2 wired), so
jump_is_allowed's already-ported gate (WeenieError 0x47) actually fires
while an object is rubber-banding hard against a server position
correction, closing the last piece of #167.
Housekeeping:
- Delete register row TS-35 (retired: the write side is no longer stubbed).
- Rewrite the stale doc comments on PhysicsBody.IsFullyConstrained,
ConstraintManager (class + IsFullyConstrained), PositionManager.ConstrainTo,
EntityPhysicsHost.PositionManager, and PlayerMovementController.PositionManager
that described the leash as permanently unarmed/stubbed.
- Close#167 in ISSUES.md citing the research doc and commits e0629145 /
7719d25b.
- Add an "as-ported" addendum to
docs/research/2026-07-30-constraint-leash-constants.md naming the actual
current seam owners (the doc's own open question flagged this as
implementer-verify-required post-J-slices).
- Update docs/plans/2026-07-29-physics-parity-campaign.md's P5 status and
CLAUDE.md's Campaign P summary to reflect #167's closure (items #153/#72
remain open in P5).
Verification: complete solution suite green - 9,978 tests, 5 skips, 0
failures across all 9 test projects (Core.Tests, Runtime.Tests, App.Tests,
Headless.Tests, Core.Net.Tests, Content.Tests, UI.Abstractions.Tests,
Bake.Tests, Cli.Tests).
Two tests proved "these two unrelated DAT reads ran concurrently" by
racing a fixed Thread.Sleep(40) window against .NET thread-pool
scheduling latency for a second Task.Run. Under the CPU contention of
a full `dotnet test AcDream.slnx` run (all 9 test projects' VSTest
hosts launch concurrently) plus a busy machine, thread-pool injection
can occasionally miss the window, making MaxConcurrentReads read 1
instead of 2 and failing the assertion with no underlying code defect.
RetailAnimationLoader and RetailPhysicsScriptLoader both coalesce
same-key reads correctly via ConcurrentDictionary<K, Lazy<T>>.GetOrAdd,
which is atomic and timing-independent (verified by reading, not just
running) - only the test's method of proving cross-key overlap was
timing-fragile. DecodedTextureCacheTests already uses the correct
deterministic-gate pattern; this brings RetailDatLoaderTests in line
with it via a Barrier-backed rendezvous instead of a sleep race.
Filed as #248 (docs/ISSUES.md) with the full attempt matrix: could not
catch the originally-reported AcDream.Content.Tests failure in the act
despite ~72 Content.Tests executions across four contention strategies
over ~30 full-suite-equivalent runs, though the general mechanism
reproduced 3x in AcDream.App.Tests's already-known zero-allocation
flake class (left untouched, out of scope here).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Campaign P Slice P4 item 2. TerrainSurface.SampleWaterDepth now returns 0.1
(was collapsed to 0) for a partially-water cell's dry corner, matching
retail's ObjCell.get_water_depth / calc_water_depth (via ACE's unambiguous
C# port). ValidateWalkable's formula was already byte-for-byte verbatim
(ACE ObjectInfo.ValidateWalkable line 124); only the constant was collapsed.
The old collapse's justification ("0.1 destabilizes the feet-exactly-on-plane
contact-touch check because dist > EPSILON skips SetContactPlane that tick")
is structurally true of retail too - traced and confirmed this slice: in ALL
THREE implementations (retail, ACE, acdream) a skipped touch-reassertion is
NOT a fall, because Contact/OnWalkable are STICKY -
PhysicsEngine.ResolveWithTransition's onGround computation ORs the fresh
per-call ContactPlaneValid with the seeded, persistent
PhysicsBody.TransientState.OnWalkable bit (itself written back by the
caller's own sticky TransientState). PhysicsEngine.SampleTerrainWalkable's
isWater = waterDepth >= 0.45f threshold means the restore does not flip the
dry corner's water classification (0.1 still < 0.45) - only the sink-in
depth changes. Full Core.Tests suite green (4038/2 skips, up from 4026)
proves the sticky-bit argument held in practice.
WATER_CONTACT_TS (TransientStateFlags.WaterContact, declared but never
written) is now mirrored alongside CONTACT_TS/ON_WALKABLE_TS at every commit
point that writes them: PhysicsObjUpdate.ApplySetPositionContact (projectiles
+ remote teleport), PhysicsObjUpdate.CommitSetPositionTransition (remote
teleport placement), and PhysicsEngine's per-resolve body-state commit (local
player + remote dead-reckoning + ordinary movers via ResolveWithTransition -
the actual SetPositionInternal-equivalent path). No signature changes needed:
body.ContactPlaneIsWater is already fresh by the time each function runs.
CollisionShadowVerifier audit: no change needed. It diffs graph-vs-flat BSP
traversal outcomes (ObjectInfo/CollisionInfo/SpherePath fields already
including ContactPlaneIsWater); it never touches PhysicsBody.TransientState,
and the water-depth constant is computed identically upstream of both
traversal modes, so it cannot introduce a new graph/flat divergence.
Filed #264 for the three items research explicitly left open (none block
this port): no confirmed retail consumer of WATER_CONTACT_TS was found (an
xref scan wasn't attempted - bitmask reads aren't text-greppable); the
CLandCell ENTIRELY_WATER ethereal/swim exemption from terrain collision was
not cross-checked; jump-in-water/swim-animation effects were not
investigated (out of physics/collision scope).
Conformance: Ap10WaterSemanticsTests covers SampleWaterDepth golden values
(NotWater/EntirelyWater/PartiallyWater wet+dry corners), the isWater
threshold non-flip, WaterContact mirroring in both PhysicsObjUpdate
functions, and two settle-to-rest end-to-end PhysicsEngine.ResolveWithTransition
scenarios (water: sinks exactly waterDepth below the plane and sets
WaterContact; dry: rests exactly on the plane and clears any stale
WaterContact bit).
Register: retired AP-10 (92 active AP rows, down from 93).
AcDream.Core.Tests: 4038 passed, 2 skipped, 0 failed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Campaign P Slice P3 item 4. Per the plan's explicit instruction, this
is diagnose-only: the research's candidate (a)/(b) mechanisms did not
confirm, so no fix lands here.
Built the dat-free/dat-backed fixtures the plan asked for (no live
client) to test the two mechanisms a physics fixture CAN discriminate:
- (b) ruled out by code reading: RuntimeRemotePhysicsUpdater.Tick's
resolve gate reads RuntimeEntityRecord.FullCellId live. Every
FullCellId = 0 write site (TryApplyPickup, CommitAcceptedParentCellless,
CommitWithdrawal in RuntimeEntityObjectLifetime.cs) is a pickup/
parent-attach/delete path, never reachable for a live, freely moving
remote mid-session. The "one-frame grace" is genuinely first-spawn-only.
- (a) tested directly and does not reproduce, on two independent
geometries: InterpolationManager's unclamped stall-fail "tail delta"
snap (node_fail_counter > 3) can hand ResolveWithTransition an
arbitrarily large single-tick targetPos. New fixture tests replace a
proven small-step sweep (many 0.08-0.10 m ticks) with ONE resolve call
spanning the entire distance, against both a synthetic creature sphere
and the real Holtburg door BSP slab (Setup 0x020019FF/GfxObj
0x010044B5, the existing door-apparatus dat fixture) already used by
DoorCollisionApparatusTests. Both stop at the identical surface
distance the small-step tests pin, with a valid collision normal --
the sweep is not distance-limited and does not tunnel on a large
single-tick delta.
Candidate (c) -- render/interpolation presentation lag on the App side --
is the remaining hypothesis and is out of scope for a physics-fixture
pass (it's a claim about what gets drawn relative to the committed
PhysicsBody.Position, not something a Core fixture observes). #165
stays OPEN with (a)/(b) struck from the candidate list by the evidence
above and (c) named as the next concrete step (an App-layer render-vs-
physics-position diff, or a fresh live ACDREAM_PROBE_RESOLVE capture).
New tests: Issue165RemoteWallPenetrationDiagnosticTests (dat-free,
3 tests) and DoorCollisionApparatusTests.
Apparatus_SingleLargeTickJump_DeadCenter_StillBlocksOnBSP (dat-backed,
1 test, skips gracefully without the local dat directory).
dotnet build + dotnet test (Core.Tests 4012/2 skip, Runtime.Tests
425/0) green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Campaign P Slice P3 item 2. CPhysicsObj::handle_all_collisions
(0x00514780, pc:282647) is one uniform function retail calls
unconditionally after every SetPositionInternal, player or remote. The
gate is shouldReflect = !(prevOnWalkable && nowOnWalkable && !sledding).
RuntimeRemotePhysicsUpdater.Tick's post-resolve reflect was still the
2026-07-05 (#173) hand-inlined block, gated on
resolveResult.CollisionNormalValid and using two ad-hoc branches that
diverge from retail in exactly the cases the register row named:
- non-sledding: old = "!prevOnWalkable && !nowOnWalkable" (reflects
ONLY airborne-before-AND-after); retail reflects on every transition
except grounded-before-AND-after.
- sledding: old = "!(prevOnWalkable && nowOnWalkable)" (suppresses the
bounce exactly when both grounded); retail's "!sledding" term forces
shouldReflect = true unconditionally when sledding, the opposite
polarity.
Both gaps meant a remote's post-landing reflect never ran on a
grounded-transition tick at all -- the "acdream lands clean and dead"
half of #166's slope-landing composite.
Replace the hand-inlined block with a direct call to
PhysicsObjUpdate.HandleAllCollisions -- the same verbatim port the
local player and every ordinary body already use via
CommitSetPositionTransition -- passing the same
prevContact/prevOnWalkable/nowOnWalkable values the old code already
computed. Narrower swap per the research's explicit recommendation:
does not fold in CommitSetPositionTransition's HitGround/LeaveGround
dispatch, leaving the remote's bespoke landing-detection block
(interp-queue-clear, animation-hook-specific logic) untouched. The call
is now unconditional (matching retail's own unconditional call site)
rather than gated behind CollisionNormalValid, since HandleAllCollisions
already no-ops the reflect step internally when no normal was found but
still runs the frames-stationary-fall bleed regardless.
PhysicsObjUpdate.HandleAllCollisionsTests already exhaustively pins the
retail formula in isolation; this change is a mechanical wiring swap to
the already-tested function using values the removed block already
computed. Full regression suites (Core.Tests 3991/2 skip, Runtime.Tests
425/0, App.Tests 3968/3 skip) pass unchanged -- no existing test pinned
the old broken formula.
Register: AD-25 retired (both the local-player and remote halves are now
the ported HandleAllCollisions); #166's reattribution note updated to
reflect the closure, leaving only TS-4 as the remaining blocker on that
issue's downhill-jump-glide acceptance.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs/research/2026-07-30-response-layer-edge-family-pseudocode.md §3, §6
Step 6. Corrects two things in the original AD-25+AP-7+TS-4 framing:
AD-25's local-player half was already ported by the #182 rebuild
(2026-07-07) and the remaining gap is remote/NPC-only (Campaign P P3
scope); and no client-side PhysicsState.Sledding auto-toggle exists
anywhere in the named-retail decomp or ACE's PhysicsObj.cs -- the only
Sledding write site in any reference repo is a per-weenie game-data
property, not a physics landing response, so this issue must not wait on
inventing one.
AP-7 landed this session. TS-4's removal was attempted per its own
fixture-first requirement and reproduced the historical 2026-04-30 wedge,
so it stays deferred (see its register row and the research doc's §7 item
6). Closure pends TS-4 actually landing and a fresh capture against the
campaign's final visual-matrix item 5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
[snap] now permanently wired; three instrumented fresh logins against
local ACE reproduce nothing (consistent with the Coldeve rarity). Next
recurrence self-diagnoses; matrix scenario 11 is the structured re-test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Outbound 0xF61C requires the published movement controller, so the login
seed ran; the residual suspect is a seeded (cell,pos) pair the resolver
cannot operate on. PhysicsEngine.DiagnosticLog has no production
assignment, so the #111 [snap] lines were structurally absent from the
Coldeve log - wiring it is a P6 prerequisite.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zero landblock loads occurred before the login recenter (worker gated
until the real spawn center), so no stale Holtburg-frame physics blocks
ever existed. Remaining: (f) login SnapToCell seed race -> NO-LANDBLOCK
verbatim resolves, (e2) CellGraph/_landblocks skew, (g) root-motion Frame
not reaching the transition. The probe run's [resolve] line pattern
discriminates all three.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Log facts: outbound MTS/AP flowed all through the run-on-spot window;
reveal collision=True is attested by the SAME _landblocks dict the
resolver walks; the 'unattributed' recenter is the default Holtburg
pre-login center -> first real position. Deduction: local display is
client-authoritative, so ACE rejection cannot pin the local body - the
defect is local zero-advance resolves. Prime suspect: login recenter may
not route through Slice E generation retirement, leaving stale
Holtburg-frame neighbor landblocks overlapping the new frame (#145
stale-offset class, neighbors were explicitly left by the 2026-06-20
center-only fix).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The 2026-06-21 residual predates its own fix: AD-30's verbatim hold +
the #145 carried anchor kill the pick march, R3-W6 StopCompletely kills
the stale arrival velocity, canonical outbound position ownership kills
the 17410 wire artifact class, and the reveal barrier holds incomplete
destinations in the tunnel. Pinned by TeleportFarTownRunawayTests
(south+east unstreamed-edge); connected evidence: 20-teleport Coldeve
session 2026-07-29 + K3/K4 portal routes. Carried-debt lists updated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The issue's premise (HasOmega cleared, pi/2 fallback) was disproved by
the R6 complete-root-frame cutover: MotionTable 0x09000001 authors
omega.Z = -1.5 rad/s literally. The run turn multiplier is the verbatim
FUN_00527be0 port (RunTurnFactor = 1.5). No cdb capture needed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
General composite-translucency fix (16ed6e7c) user-verified on other items; the orb keeps traces. Remaining hypotheses (ClipMap-opaque shell / unattached-emitter scope split) and the discriminating probe set are recorded in the issue.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The acceptance session on Coldeve ran 20 portal transits with zero wedges and captured a real wire-loss recovery live (resend/s=1 nak-in=1 mid-session, converged net-final ledger, graceful logout) - the event class that permanently killed sessions before N1. #260 is closed on that evidence. The one unrelated observation (first-login run-on-the-spot until a recall reset, self-healed, not reproduced on relogin) is filed as #262 with hypotheses and the no-workaround rule restated. Campaign doc, roadmap, and CLAUDE.md pointers flipped to the closed record.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
All seven slices shipped and reviewed. The campaign doc status header and ISSUES.md #260 now record the implementation-complete state with every slice SHA; the campaign doc's double-encoded punctuation (one early PS5.1 ANSI round-trip) is repaired to clean UTF-8. Remaining acceptance: the user Coldeve endurance session.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Campaign N Slice N5 (docs/plans/2026-07-29-network-transport-campaign.md
section 8 rung 3): the permanent removal of the loopback blindness that let
#260 ship. Local ACE never drops a datagram, so every historical connected
gate was structurally incapable of exercising the N1-N4 recovery machinery;
from this slice on, tools/run-connected-loss-gate.ps1 runs the standard
lifecycle route through deterministic seeded loss and passes only on proven
non-zero recovery.
Observability:
- [net-tick] gains resend/s nak-out/s nak-in/s rej-in/s dup-drop/s parked/s
reclaim/s cache= nakset= - TransportStats window deltas mirroring the
acks/s cumulative-delta pattern, plus the two instantaneous depths (the
unbounded-like-retail sent-packet cache watchdog and the inbound NAK set).
TransportStats gains RejectsReceived (inbound RejectRetransmit packets).
Counters increment unconditionally; every string is behind
NetDiagnostics.ProbeNet (Code Structure Rule 5).
- WorldSession.Dispose emits one cumulative [net-final] totals line so the
loss gate asserts exact counters instead of reconstructing them from
rounded per-second rates.
- LinkStatusSnapshot.PacketLossPercentage is deliberately NOT wired: filed
#261 - retail's CLinkStatusAverages formula
(LinkStatusHolder::GetPacketLossPercentage @ 0x00411370) must be located
first; inventing a ratio is forbidden.
N4-review F3 fold-in:
- Fresh reliable sends stamp Header.Iteration = the session iteration
through the same shared retail header build already cited for Time (N3)
and the N4 control packets: FlowQueue::TransmitNewPackets @ 0x00547A60,
the stack build at 0x00547A84/0x00547AA8. The control-header rule now
holds across all three send shapes (fresh reliable, ack, NAK). ACE reads
neither Time nor Iteration inbound (campaign section 3) - wire-safe, and
resends keep the stamp verbatim per the N1 rebuild rule.
Loss injection (Transport/LossyTransportDecorator):
- IWorldSessionTransport wrapper with deterministic seeded per-direction
loss. Config via NetDiagnostics typed env properties read once:
ACDREAM_NET_DROP_PCT (0 = off = default), ACDREAM_NET_DROP_SEED (default
1), ACDREAM_NET_DROP_DIR (out|in|both, default both).
- Arming gate: NOTHING drops in either direction until the decorator has
FORWARDED the first ENCRYPTED outbound datagram - parse-free check on
length > 20 with EncryptedChecksum set in the LE flags word at bytes
4..8. The cleartext handshake always survives and the arming datagram is
never a casualty; handshake-loss testing belongs to N6's ConnectResponse
0.333 s retransmit.
- Structurally absent at 0%: WrapIfConfigured returns the raw transport -
WorldSession's default factory is the only production seam and a normal
run never constructs the decorator.
Root-cause fix the gate immediately exposed:
- The logoff-confirmation wait in Dispose processed inbound datagrams but
never pumped the transport, so a lost S2C logoff confirmation was
gap-detected but its healing NAK never went out. Retail's pump
(Client::UseTime @ 0x00411C40 -> PacketController::UseTime @ 0x005410D0)
runs until LogOffServer; the wait now sweeps per processed datagram,
making the logoff wait the third covered blocking pump (after Tick and
the handshake loops). A lost C2S logoff REQUEST remains unrecoverable by
ACE design (arrival-driven NAK; a quiet client is never NAKed - campaign
section 3 row 1), recorded in the gate header.
Gates:
- tools/run-connected-loss-gate.ps1 (-DropPct 2 -Seed 1): PASS vs local
ACE - the first automated observation of packet loss in project history.
Decorator ledger: dropped out=3 in=10 of forwarded out=183 in=496.
[net-final] resends=2 nak-in=2 nak-out=6 rej-in=0 acks-out=114
acks-in=119 dup-drop=0 sanity-drop=0 cksum-fail=0 parked=9 reclaimed=0
uncached-nak=0 cache=1 nakset=0. Every injected loss healed: both
ACE-driven C2S resend recovery (nak-in=2 -> resends=2) and client-driven
S2C NAK recovery (parked=9 -> nak-out=6) fired on a real connected
route, all six checkpoints validated, graceful logout confirmed, ACE
recorded the transport Disconnect.
- tools/run-connected-world-lifecycle-gate.ps1 (decorator absent): PASS -
zero behavior change on the no-loss baseline; the gate now defensively
clears the drop env vars.
- Core.Net Release: 747/747 (737 + 10 N5: decorator determinism/direction/
arming/structural-absence/env parsing, the 5% seeded WorldSession lossy
lifecycle with zero message loss both ways + ACE Headroom 256, the
[net-tick] field pins, the Iteration stamps).
- Full solution Release: 9,763 passed / 5 skipped / 0 failed.
Test-fixture note: FakeAceTransport gains AutoAdvanceOnBlockingReceive so
virtual time can move during the blocking Connect()/EnterWorld() pumps -
with the clock frozen there, a dropped handshake-window datagram could
never be NAK-healed (a fixture artifact, not a transport property).
Campaign section 9 ledger row added (SHA recorded at N6 kickoff).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The #260 investigation ended in a full root cause: acdream cannot
survive a single lost UDP packet in either direction. Outbound: the
server''s RequestRetransmit lists are parsed and consumed nowhere, and
no sent-packet cache exists - one lost C2S datagram permanently stalls
ACE''s ordered stream (actions void, position updates void, new areas
never stream: the whole #260/#256 symptom set). Inbound: the ISAAC
keystream is burned in arrival order, so one lost S2C datagram
permanently desyncs the cipher. Loopback ACE never drops packets,
which is why every historical gate passed.
The campaign doc pins the port target from the named retail decomp
(SentPacketStore/FlowQueue resend with reused ISAAC keys, the inbound
pre-drawn-key NAK set, the 2.0s cumulative ack / 0.6s NAK shared-gate
sweep, constants), the ACE constraint table Coldeve enforces (the
256-key crypto window, the exactly-AckSequence watermark rule, the
cleartext-NAK requirement), the Transport/ class design, slices N0-N6
with per-slice gates and Fable/Opus review assignments, the landmine
list, and eight divergence-register rows for the pieces that are
unsafe against ACE''s watermark hole.
#260 updated to point here; its memory half is closed as benign
(mapped-pak page residency + designed cache ceilings - measured, not
a leak).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The two-agent investigation refuted #260's as-filed hypotheses: every
UseWithTarget was acked (the J5.2 use gate never latched), and the LOH
leak is bounded sawtooth churn - the real climb is ~2.25 GB of native/
GPU memory (WS 3,261 vs managed 1,015 MiB at wedge). The wedge evidence
also showed why it could hide: the live combat toggle routes through the
generation-gated runtime command seam, and every rejection exit in that
chain (Disposed / StaleGeneration / !IsInWorld at Validate, plus the
operations slot reading IsInWorld=false when unbound) is COMPLETELY
silent - no log, no event.
ACDREAM_PROBE_NET=1 (NetDiagnostics owner, PhysicsDiagnostics pattern)
now arms three probe families, all zero-cost when off:
- [net-out] per reliable send at the SendGameMessage chokepoint: opcode,
GameAction type+sequence, fragment/packet sequence, managed thread id
(two tids would prove the cross-thread ISAAC-desync hypothesis alone),
and state; [net-out-EX] via an exception FILTER that logs without
catching, so propagation is unchanged.
- [net-tick] 1 Hz cadence from WorldSession.Tick: inbound/s, queue
depth, budget breaks, worst inter-tick gap (frame-stall witness),
out/s, acks/s.
- [cmd-gate] every silent runtime-command rejection with expected-vs-
view generation, lifecycle, and IsInWorld, plus the combat toggle
result (whose Inactive exit reads a DIFFERENT IsInWorld source).
One walked-portal repro session with this probe distinguishes all
remaining #260 wedge hypotheses. ISSUES.md #260 rewritten to the
corrected two-root framing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
First solid reproduction of the Coldeve findings: after sustained walked portal-network use the client wedges - server-round-trip actions (portal use, combat toggle) produce zero outbound send while client-predicted movement still works, and the LOH climbs to 574 MB. Combat toggle x3 with no send is the smoking gun for the one-request-at-a-time use gate latching closed on an unacked UseWithTarget. gcdump captured in the broken state. Supersedes the framing of #256/#257 - both are likely facets. Investigation not started; forbidden workaround (gate timeout) called out explicitly.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The first commit converted the four members the issue named and left the other
sites alone, reasoning that none had been observed failing. A 20-run
complete-solution baseline disproved that within minutes:
run 2 LiveEntityRuntimeTests.AnimationView_HotSpatialTraversal…
run 14 StaticRenderProjectionJournalTests.ActiveAnimatedSynchronization…
run 18 StaticRenderProjectionJournalTests.ActiveAnimatedSynchronization…
run 19 CurrentRenderSceneOracleTests.SurfaceOverrideFingerprint…
Both new names are the same shape as the four — one warm call, then a
thousand-iteration loop inside the measured window — and neither had been
recorded anywhere. "Not observed failing" only ever meant "not yet observed",
and leaving known-shape sites in place would have guaranteed the acceptance gate
failed. Run 19 is the sharper lesson: the issue named
`SurfaceOverrideFingerprint_DictionaryHotPathAllocatesNothing`, and the first
commit converted a *different* test in that same file, so the actually-named
member was still on the old shape. Matching by file was not matching by test.
Every strict-zero site in the assembly is now on the probe — ten tests. Two came
out stricter rather than merely steadier:
`StaticRenderProjectionJournalTests` was measuring a synchronise whose journal
does **not** coalesce. Repeating it grew the journal by 1,000 entries per call —
192,000 by the end of a probe run — so the steady state the test claimed to
measure did not exist and the single-call window had been hiding it. Its step is
now the whole frame cycle, synchronise *and* drain, which puts `DrainTo` inside
the measured window for the first time and asserts the journal ends empty.
`RetailInboundEventDispatcherTests` asserted a hard-coded 1,001 callbacks. It
now counts its own dispatches and pins the callback count against that, so the
assertion still proves the fast path ran the callback every time without being
coupled to a loop bound that no longer exists.
Left alone deliberately: the four sites asserting a tolerance rather than zero —
`CellViewDedupTests` and `PortalProjectionTests`. Their ceilings already absorb
this noise and none has flaked; changing a bound in either direction is a
separate decision from fixing a measurement. Worth noting that
`PortalProjectionTests`' ceiling exists explicitly to tolerate "a
tiered-JIT/ArrayPool bookkeeping transition ... to the first measured batch",
which is exactly what the probe removes, so it could probably be tightened to
zero now — recorded in the issue rather than done here.
Solution build 0 warnings / 0 errors; App suite 3,941 passed / 3 skipped.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The zero-allocation family failed about one full-suite run in three, on
unchanged trees, and had been dismissed as inherent noise in
`GC.GetAllocatedBytesForCurrentThread` three separate times. It is not noise.
Reading the four members side by side, they share one root: **the measured
window was never the warmed path.**
UiDatFontTests 1 warm call, then a 10,000-iteration loop inline
RenderFrameProductTests 8 warm calls, then a 1,000-iteration loop inline
OracleTests 1 warm call, 1 measured call
ArchRenderSceneTests warms Apply(registrations), measures Apply(updates)
Two mechanisms come out of that table. A test method is JIT-compiled at tier 0
like anything else, and a long-running loop in tier-0 code gets replaced
mid-flight by on-stack replacement — which compiles on the thread running the
loop, so its bookkeeping is charged to the window being measured. That is the
first two. And `ArchRenderSceneTests` warmed one arm of a switch and measured
the other, so the measured call was the first ever into `ApplyUpdate` and paid
that arm's JIT, type loads and static initialisation inside the window;
`RenderFrameProductTests` warmed 8 times, below the tier-0 call-counting
threshold of 30, so promotion was still pending when measurement began.
That also explains the signature nobody could account for. Alone, the process is
quiet and the runtime has finished before the assertion arrives. Alongside eight
other test assemblies, tier-0 compilation never stops, the call-counting delay is
re-armed continually, and the work slides into the window. Clean in isolation,
failing under load, on a tree that changed nothing.
`ZeroAllocationProbe` invokes the step many times before measuring anything, then
measures windows that run the same already-warmed loop over the same
already-taken path. Each window is a batch of 32 invocations and it reports the
minimum across 4 of them. Both halves are load-bearing: the minimum is what
excludes a one-time cost, and the batch is what keeps the assertion as strong as
the loops it replaces — minimising over *single* invocations would report zero
for a path that allocates every tenth call, which is a real regression made
invisible. I had written it that way first and the apparatus test caught it.
**The bound is untouched: exactly zero, no tolerance, no retry, no assertion
relaxed.** `ZeroAllocationProbeTests` proves the apparatus can still fail — a
step allocating every call reads above zero and does throw, a first-invocation
cost reads as zero, a cost every tenth call is caught, and the one stated limit
(the batch must cover the period) is pinned as a test rather than left as prose.
Without those, a later edit could quietly make the whole family unfailable.
Twelve further sites in this assembly still use the hand-rolled shape. None has
been observed failing, and each needs its own repeatability analysis — several
mutate state or consume monotonic sequences — so they are listed in the issue
for adoption when next touched rather than converted blind at scale.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`FrustumPlanes.FromViewProjection` extracted the near plane with the
Gribb-Hartmann form written for OpenGL's `[-1,1]` clip-space z range. Every
acdream projection comes from `Matrix4x4.CreatePerspectiveFieldOfView` or
`CreateOrthographic`, whose range is `[0,1]`. Under `[-1,1]` the near plane is
the locus of `clip.z = -clip.w`, which is `col4 + col3`; under `[0,1]` it is
`clip.z = 0`, which is `col3` alone.
Concretely, the mismatch put the effective near threshold at `-n·f/(2f-n)` —
about 0.5 m where the retail chase camera asks for 1.0 m. That error only ever
kept geometry the true frustum would have dropped, never the reverse, which is
why it produced no visible defect and was filed instead of hot-fixed during
Campaign V. It is still wrong, and it is the same mistake that *was* visible in
`PortalProjection`, where it culled the cell behind a doorway the camera stood
close to.
The far plane is `col4 - col3` under both conventions and is untouched. A test
pins it anyway, so that a future edit to this function cannot drift it while
nobody is looking.
The acceptance criterion asked for a unit test pinning the extracted near
distance to the camera's near value, and that is what landed: a theory over four
near/far pairs asserting the plane is unit-length, faces down -Z, and stands off
the eye by exactly `nearDistance`, plus a kept/dropped pair straddling it. The
test was checked against the old formula before commit and fails all four cases
there — it measures the fix rather than merely accompanying it.
The other half of the acceptance criterion — unchanged culling in the offline
pixel gate and the connected route — could not be run: #259 has Win32 surface
creation failing machine-wide, so no gate that needs a window is available
tonight. Recorded as outstanding rather than assumed.
Solution build 0 errors; `AcDream.Core.Tests` 3,898 passed / 2 skipped / 3,900.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Brings `github/overnight/wire-audit` (`41f74fcd`) forward onto the V11 tree.
Like the enum branch it was cut at `b70b9832`, and like the enum branch its
subject is disjoint from the deletion: the audit lives in `AcDream.Core.Net`
and its tests, V11 emptied `AcDream.App`. One conflict, in `docs/ISSUES.md`,
resolved below.
What it carries: three real parser fixes — ranged speech was carrying a range
float the parser ate, a chat type that is never sent was silently dropping every
transient string on it, and `xpSpent` is a dword on the wire where we were
writing eight bytes. Plus the transport flag word pinned against ACE across all
twenty-three bits, golden fixtures generated from ACE's own writer instead of
hand-typed hex, and the audit document covering all three hundred forty-nine
opcodes.
**The conflict, and how it was resolved.** Both this branch and V11's closeout
reopened#255 — the RetailDatLoader concurrency tests that measure the thread
pool rather than the loader — on the same day, from different trees, without
knowing about each other. Neither reopening is a duplicate of the other: the
V11 gate saw 2 failures in 5 complete-solution Release runs on the
post-deletion tree, the audit session saw 2 in 4 on the pre-deletion tree, and
both saw 124/124 in isolation every time. They independently reached the same
conclusion, that `TaskCreationOptions.LongRunning` is a hint rather than a
guarantee, and independently proposed the same fix, a rendezvous inside the read
stub.
So the two notes are merged into one issue with both evidence sets kept as
labelled subsections rather than one overwriting the other. Four failures across
nine runs on two trees is a materially stronger case than either half, and the
agreement between two blind observations is the part worth preserving. No
assertion was weakened and no retry was added; the fix itself remains open.
Verified on the merge result: Release build 0 errors, and
`AcDream.Core.Net.Tests` at 659 passed / 0 skipped, up exactly the 59 the branch
claimed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Records what V11 actually achieved and, more importantly, what it did not.
The deletion landed: 204 files, +1,870 / -27,607 lines across five commits.
Section 5.5.24 keeps the three findings that outlive the diff.
* Chorizite could NOT be dropped, and not for the reason section 6 predicted.
The risk register assumed the package survived only because the ManagedGL
types implemented IUniformBuffer from it. The audit found TextureFormat in
the IWorldTextureArray signature the VULKAN path implements, and
BoundingBox serialized into the pak format. Dropping it is a slice that
touches the on-disk format, not a V11 cleanup.
* Two traps the V11 row did not know about. Studio/SampleData.cs is
production code behind the character sheet's fallback, so it moved rather
than died; ACDREAM_DEVTOOLS also gates Vulkan debug-utils, so the flag
survives and now says out loud that its UI is gone.
* Deleting GL surfaced a real bug: WbMeshAdapter.Dispose() was still
pattern-matching the GpuFrameFlightController that V6a replaced, so its
wait for submitted GPU work had been silently dead on every Vulkan run
since. Removing the type turned a no-op into a compile error.
The runtime gates did not run, and the honest reason is written down rather
than smoothed over. The client dies at vkGetPhysicalDeviceSurfaceCapabilitiesKHR
in files V11 never touched. Bisecting put the failure at the PRE-V11 commit
whose Vulkan soak had passed 91 checkpoints three hours earlier, and
`vulkaninfo --summary` -- a Khronos tool with none of our code -- fails at the
same call. Win32 surface creation is broken machine-wide; Vulkan itself is
fine. That is issue #259, with the one-line diagnosis at the top so the next
person checks the machine before bisecting the tree.
So the row reads DELETED AND STATICALLY GREEN, RUNTIME GATES BLOCKED. Release
build is 0/0 and the complete Release suite is 8,999 / 5 skipped (-218 against
V10, every one a test that lost its subject). Nothing was relaxed to
manufacture a pass: section 7.1 rule 2 cuts both ways, and a gate that could
not run is not a gate that passed. The rerun list is in 5.5.24, and the
pre-deletion pixel baseline was captured BEFORE the deletion, so the
self-differential is still available whenever a window can be made again.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Retires the GL framing from the documents that described a two-backend,
two-UI-stack client, and files what the deletion left behind.
Divergence register:
* AD-46 (anisotropic tap pattern in dense alpha scenery) is REFRAMED rather
than retired. Its substance survives -- distant foliage may read denser
than retail's -- but it was measured GL-vs-Vulkan, and with GL gone it is
a Vulkan-vs-retail question against the D3D oracle it already cited. The
measurement is kept as the evidence that the residual is a driver tap
pattern; the row now records that it is no longer falsifiable by
self-differential, which is a real loss the deletion causes.
* AD-47 and AD-48 are NEW, and the campaign's own risk register scheduled
them here: MSAA sample positions (measured at 8.83% of the frame at 4x,
which is why every strict gate runs MSAA off -- and therefore why a
regression confined to the multisample path would not be caught) and
present pacing (#235 is the live instance).
* AD-17's justification moves from a GL clip-plane citation to Vulkan's
maxClipDistances floor, which is the same 8, so the divergence is
unchanged and only its authority moves.
* AP-92 keeps IUiViewportRenderer.TextureIsBottomUp rather than folding it
flat, because it is what let the origin question be answered by data.
Architecture and code structure: the layer diagram, the frame order, the
residency vocabulary and the reference table all said OpenGL. The UI section
said two stacks. Rule 3's rationale is rewritten around what actually
happened -- ImGui was deleted and not one panel, ViewModel or command had to
change, because none of them had ever imported ImGuiNET. That is the rule
paying for itself, so it is recorded as evidence rather than removed as
obsolete.
Issues: #258 files the dev-panel host as a decision rather than an accident,
and #255 is REOPENED. Its TaskCreationOptions.LongRunning fix asks the
scheduler for a thread but does not promise two callbacks overlap; under nine
concurrent test assemblies it still failed 2 of 5 whole-suite runs. The
earlier evidence tested a narrower pool, not a contended one. The fix it
needs is a rendezvous inside the read stub -- not a weakened assertion.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The wire-stack audit's final full-suite gate turned up
AnimationCache_CoalescesSameDidAndAllowsUnrelatedReadsInParallel failing twice
in four runs on Windows, on a tree that already carries #255's LongRunning fix.
Run alone the project passes 124 of 124 every time. Both failures were
--no-build runs, which start faster and so crowd the machine harder, which is
the original diagnosis rather than a new one.
TaskCreationOptions.LongRunning asks for a dedicated thread. It does not
promise one, and it does nothing about the other eight test projects saturating
the box while these two forty-millisecond sleeps are supposed to overlap. The
assertion on MaxConcurrentReads is therefore still measuring the host.
The note suggests the shape that would actually close it: gate both threads on
a barrier so each is provably inside the read before either is released. Then
the count is a property of the loader instead of the scheduler and no amount of
load can move it. Filed rather than fixed because this session's diff is
confined to Core.Net, its tests, and docs, and the audit had no business
editing content loaders on its way past.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Issues #256 (server-spawned signs and portals go invisible after repeated
portal runs, while staying interactive) and #257 (working set grows to
~1.5 GB over the same session) were observed together in one long live
Vulkan session, and both filings demanded the same thing before V11 deletes
the OpenGL backend: run the churn on GL too. Vulkan-only growth or drift
would mean the new arm's resource lifecycle is broken, and deleting its only
reference implementation while that was true would be wrong even with the
cutover signed.
So the discriminator is built and run first, and it can stop the slice.
tools/run-portal-churn-soak.ps1 generates a route of N cycles over three
portal-bearing stops taken from the two existing connected routes, runs it
once per backend from one binary, and measures three things the existing
instruments do not measure together:
* working set and private bytes, sampled from the OS every two seconds and
joined to each checkpoint by timestamp -- the client's own snapshot has
no view of its own working set, which is exactly #257's quantity;
* the published-versus-live pair already in the checkpoint JSON, because
"alive in the object table, gone from the presentation" is #256's whole
symptom and a drift between those halves at the SAME stop across cycles
is what would show it;
* a within-arm capture comparison -- cycle 1 against cycles 10, 20 and 30
at a pinned viewpoint -- plus a difference map and a row histogram,
because a number cannot tell an absent object from a walking NPC and the
map can.
Every teleloc carries the identity quaternion so the heading repeats, and
the four determinism levers the differential gate forces are forced here for
the same reason: an unpinned sun would swamp the signal.
Result at 90 transits per arm, 91 checkpoints, zero errors, graceful exits:
neither arm reproduces either symptom. Working set means agree to 1 MiB
(GL 1864, VK 1863) and warm-half drift is NEGATIVE on both (-48.0, -27.0).
GPU accounting is exactly constant per arm. worldEntities holds 10,382 at
all thirty cycles on both. The difference maps show every building, the
portal, the statue and the treeline still drawn at cycle 30.
That refutes the one outcome that would have blocked V11, and it does not
identify the pre-existing bug -- so both issues stay OPEN with the negative
recorded, and the follow-up named: walked portal transits rather than
/teleloc, which do not take the same path into the transit state machine.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
